ERC-721 Characters as Provider Assets, Not Prompt Containers

Abstract

Realbits' provider model treats AI characters as reusable assets that can move across the flagship chat hub, themed apps, and the web creator studio. That pushes ownership into the architecture rather than leaving it as a store badge or database flag. The repository already points in this direction through packages/contracts, CharacterNFT.sol, and CreatorRoyaltyEscrow.sol: ERC-721 provides a public ownership handle, while escrow handles creator economics. The important design constraint is that an AI character is not just a collectible file. It is a bundle of public identity, private prompts, runtime policy, model-pack compatibility, voice references, and provider-managed distribution rights.

The core argument of this article is that Realbits should use ERC-721 as an ownership boundary, not as a prompt container. ERC-721 gives wallets, indexers, and apps a standard way to track non-fungible ownership and transfers [S1]. It does not solve privacy, mutable runtime configuration, royalty enforcement, or app entitlement caching. EIP-2981 adds a common royalty query interface, but royalty payment remains voluntary in the standard's model [S2]. Therefore the defensible Realbits architecture is layered: a compact ERC-721 token for ownership and provenance, a first-party escrow contract for enforced sale splits, and provider manifests for the AI-specific runtime payload.

Realbits Context

The Realbits pivot makes the web package the creation and publishing surface, the native apps consumption surfaces, and the contracts package the on-chain ownership layer. In this setting, a character asset needs two identities. The first is a product identity: character id, name, avatar, tags, model-pack compatibility, voice id, and prompt configuration. The second is an ownership identity: contract address, token id, owner wallet, creator wallet, mint event, sale event, and royalty accounting. These identities overlap, but they should not collapse into one storage layer.

CharacterNFT.sol is the right name for the ownership primitive because ERC-721 tokens are designed around unique assets rather than balances of identical units [S1]. A Realbits character token can answer a narrow question: which wallet owns the access right to this provider-managed character asset? That ownership fact can then be consumed by packages/web, app manifests, and mobile entitlement APIs. It should not require each Flutter app to reconstruct all contract state during every launch. The practical path is a server-derived entitlement response backed by on-chain reads and event ingestion.

CreatorRoyaltyEscrow.sol has a different job. It should not merely describe desired royalties. It should execute the payment split for Realbits-controlled sales. Primary sales can credit the creator and platform according to the product policy. Supported secondary sales can credit seller proceeds, creator royalty, and platform fees. A claimable balance model is attractive because it avoids coupling purchase success to several recipient transfers in one transaction. The creator dashboard can then show pending balance, claimed balance, and sale history without inventing an off-chain accounting system that conflicts with contract events.

Related Work

ERC-721 defines a standard interface for ownership, approvals, transfers, and transfer events for non-fungible tokens [S1]. OpenZeppelin's ERC-721 implementation documents the expected behavior around ownerOf, balanceOf, approvals, transfer events, and safe transfer checks for contract recipients [S3]. For Realbits, this standardization matters less as a collectible convention and more as a compatibility surface. Wallets, explorers, indexers, and marketplace tools already understand ERC-721 ownership.

EIP-2981 addresses royalty discovery. It lets a marketplace ask a contract for the royalty recipient and amount for a given token id and sale price [S2]. That is useful, but it is not equivalent to enforcement. The standard itself describes royalty payments as voluntary and leaves payment mechanics outside the interface [S2]. Recent research on royalty mechanisms makes the same systems point in another form: ERC-721 is not aware of sale values, so royalty enforcement usually depends on third parties or extra mechanisms [S7].

The economics literature is more nuanced than the common claim that royalties are always good or always priced away. Falk, Tsoukalas, and Zhang argue that royalties can create value under realistic market conditions, including risk sharing, asymmetric information, and heterogeneous buyers [S6]. That supports Realbits' creator-economy hypothesis, but only if royalties are actually paid. A voluntary royalty signal may help compatible marketplaces, while escrowed first-party sales can provide the stronger guarantee creators need.

NFT market measurement also needs caution. Work on wash trading finds that a large share of NFT trades or value on some exchanges may be manipulative, with substantial variation across exchanges [S8]. For Realbits, secondary volume should not become the primary success metric. Better measurements are mint success rate, mint-to-first-message latency, percentage of paying users with at least one owned character, creator claim success rate, repeat usage by owned-character users, and number of creators who publish usable assets.

Architecture Analysis

The token metadata boundary is the most important technical choice. A CharacterNFT token should expose only durable public information: display name, public avatar reference, tags, creator address, maybe a content hash for public metadata, and the Realbits character id needed to join app data. It should not expose personaPrompt, private example dialogue, safety rules, unpublished scenario text, premium model-pack links, or user-specific settings. Public token metadata should be treated as public forever. If Realbits writes private prompt material into a token URI, it loses the ability to correct, revoke, or gate that content later.

The provider manifest should carry the AI runtime payload. That manifest can be versioned, access-gated, and patched. A wallet that owns token N in contract C can request an entitlement. The provider can verify ownership, return a signed entitlement, and allow the app to download the approved character bundle. This also gives Realbits room to support account abstraction, custodial onboarding, or email-to-wallet recovery later without changing the Solidity contract.

The ERC-721 contract should stay deliberately small. Standard behavior should come from well-reviewed libraries rather than custom ownership logic. OpenZeppelin's implementation already covers the expected ERC-721 interfaces and transfer behavior [S3]. Realbits-specific additions should be limited to mint authorization, character-id linkage, metadata URI policy, and events that make indexing easy. Adding marketplace mechanics directly to the token contract would increase audit surface and make future product changes harder.

Escrow should own sale settlement. A primary sale can route payment into CreatorRoyaltyEscrow, calculate creator and platform shares, and credit balances. A Realbits-supported secondary sale can additionally pay the seller and calculate the creator royalty. The contract should emit events that map directly to analytics: token id, character id, buyer, seller, creator, sale price, creator amount, platform amount, and prior-owner amount when present. These events are better than scraping marketplace pages because they are canonical for Realbits-controlled flows.

EIP-2981 can still be implemented as an interoperability layer. It communicates royalty expectations to compatible marketplaces [S2]. The product copy and creator dashboard, however, should distinguish between enforced Realbits-routed royalties and externally honored royalties. If Realbits wants universal enforcement, it would need restrictive transfer policies, marketplace allowlists, or another royalty-enforcement mechanism. Those approaches reduce composability and can conflict with user expectations around transferable ERC-721 assets. For a consumer AI app, the better default is to keep transfers standard and enforce royalties where Realbits controls the sale path.

Polygon Amoy is a practical rehearsal environment because Polygon documents Amoy's chain id, gas token, RPC endpoint, and explorer as a public testnet setup [S4]. Hardhat fits the package workflow because it supports Solidity development, tests, deployment, coverage, and verification workflows [S5]. The engineering sequence should be local tests, Amoy deployment, explorer verification, web mint-flow integration, event ingestion, and only then production deployment. The product-critical path is not the mint alone; it is mint confirmation, entitlement refresh, manifest availability, and first successful character message.

Limitations

ERC-721 ownership does not define legal ownership of a persona, copyright, likeness, model output, or prompt text. It defines a tokenized control record. Realbits should present the asset as an access and portability right under product terms, not as unrestricted ownership of every associated creative or runtime component. This distinction matters when prompts need safety edits or model packs need compatibility updates.

Royalty enforcement remains partial. EIP-2981 standardizes royalty information, but it does not force payment [S2]. Research on royalty enforcement highlights the deeper issue: the prevailing ERC-721 transfer model does not know the sale value [S7]. Escrow can enforce royalties for Realbits-controlled sales, but direct wallet transfers and non-compliant marketplaces can bypass the intended split.

Market analytics can be misleading. Wash trading evidence means secondary volume, average resale price, and transfer frequency should be treated as noisy signals rather than proof of demand [S8]. Realbits should join on-chain events with first-party usage and creator metrics before making product decisions.

There is also operational complexity. Wallet onboarding, gas abstraction, RPC reliability, event indexing, chain reorganizations, failed withdrawals, and support recovery all become product concerns. If those details leak into the chat experience, ownership becomes friction. The architecture should hide chain mechanics behind clear web flows and robust entitlement APIs.

Implications for This Repository

The repository should preserve a clean split of responsibilities. packages/contracts should answer ownership and settlement questions. packages/web should run minting, sale orchestration, creator dashboard views, event ingestion, and entitlement APIs. Flutter apps should consume signed entitlements and provider manifests rather than embedding marketplace logic.

For CharacterNFT.sol, the safest path is a standard ERC-721 with narrow Realbits-specific extensions. For CreatorRoyaltyEscrow.sol, the highest-value tests are split math, withdrawal accounting, role permissions, duplicate settlement prevention, and event idempotency. For analytics, the web package should treat contract events as source data but not as final business metrics until joined with user, creator, and app-session data.

The architectural rule is simple: put scarcity on-chain, put settlement in escrow, and keep AI runtime state in provider systems. That gives Realbits a credible ownership layer without freezing prompts, exposing private character logic, or pretending that royalty standards alone solve creator trust.

References

S1: https://eips.ethereum.org/EIPS/eip-721

S2: https://eips.ethereum.org/EIPS/eip-2981

S3: https://docs.openzeppelin.com/contracts/5.x/api/token/erc721

S4: https://docs.polygon.technology/pos/reference/rpc-endpoints/

S5: https://hardhat.org/docs

S6: https://arxiv.org/abs/2212.00292

S7: https://arxiv.org/abs/2403.07896

S8: https://arxiv.org/abs/2311.18717

Source Ledger

• [S1] ERC-721: Non-Fungible Token Standard (standards): https://eips.ethereum.org/EIPS/eip-721 - Defines the ownership, transfer, approval, and event interface that can anchor Realbits character asset ownership.
• [S2] ERC-2981: NFT Royalty Standard (standards): https://eips.ethereum.org/EIPS/eip-2981 - Defines the standard royalty information interface and its voluntary payment model, which frames why escrow is still needed.
• [S3] ERC721 - OpenZeppelin Contracts 5.x API Reference (official-doc): https://docs.openzeppelin.com/contracts/5.x/api/token/erc721 - Documents production ERC-721 interfaces and implementation behavior relevant to a Solidity CharacterNFT contract.
• [S4] Polygon PoS RPC Endpoints (official-doc): https://docs.polygon.technology/pos/reference/rpc-endpoints/ - Provides current Polygon Amoy network details, including chain id, gas token, RPC endpoint, and explorer.
• [S5] Hardhat Documentation (official-doc): https://hardhat.org/docs - Documents the Solidity development, testing, deployment, and verification environment used for contract workflows.
• [S6] Economics of NFTs: The Value of Creator Royalties (arxiv): https://arxiv.org/abs/2212.00292 - Analyzes when NFT creator royalties can add economic value through risk sharing, information asymmetry, and price discrimination.
• [S7] SACRE BLEU: Self-Assessed Creator Royalties Enforced by Balancing Liquidity Estimation and Utility (arxiv): https://arxiv.org/abs/2403.07896 - Explains why ERC-721 alone is weak for royalty enforcement because it is not aware of sale values.
• [S8] Can AI Detect Wash Trading? Evidence from NFTs (arxiv): https://arxiv.org/abs/2311.18717 - Shows that NFT market metrics can be distorted by wash trading, which affects how Realbits should evaluate secondary-market signals.