ERC-721 Character Ownership and Creator-Royalty Escrow for AI Character Assets

Abstract

This article analyzes the practical architecture for Realbits character assets as on-chain entitlements while keeping runtime data off-chain. The focus is not a marketplace primer; it is an engineering evaluation of contract boundaries, trust boundaries, and failure modes for ERC-721 character ownership combined with creator royalty escrow in the existing Realbits repository shape.

The central claim is that the ownership layer should be minimal and opinionated. Character identity, ownership, and entitlement checks should be contract-native, but prompt policy, model pins, and conversation behavior should remain in existing web and app runtimes. In this setup, on-chain ownership provides scarcity and transferability guarantees for characters, while escrow-based settlement provides deterministic distribution of sale proceeds to creators. This hybrid model aligns with the repository’s role separation: packages/contracts for ownership, packages/web for publishing/auth, and Flutter apps for runtime consumption. The design is evaluated through standards behavior, real-world NFT research findings, and the constraints of a cross-app asset surface.

Realbits Context

Realbits is already a provider-first product model with reusable character cards and multiple app surfaces. The contract layer includes character and royalty primitives inside packages/contracts, while ownership and creator economics are meant to be enforced through shared web-facing flows in packages/web and consumed by apps in apps/.

Within this setup, a character is not just UX text; it is an identity object tied to user wallets. The tokenization layer can be used as a deterministic gate for unlock status: if a user owns a token ID for a character, the app can allow that character pack in that user profile and across all active app surfaces with minimal per-app entitlements logic.

This means the architecture has a strict separation of concerns:

• On-chain contracts: ownership and payout guarantees.
• Web control plane: mint, publish metadata, and entitlement APIs.
• Client runtimes: local model packs, local inference, and UI.

Using ERC-721 for this role is coherent with Realbits' strategy because ERC-721 was designed for uniquely identified, transferable units with explicit holder and operator semantics, not because every asset is a literal media object. For characters, the valuable part in a provider stack is reproducible entitlement and update lineage, not raw prompt storage on chain.

Related Work

ERC-721 formalizes the ownership and transfer primitives needed for portable assets. It defines owner tracking and transfer initiation paths through owner, approved address, or authorized operator, and it standardizes safe transfer behavior to avoid token lock-up risks. This makes it a natural fit for representing character ownership in a cross-app provider context.[S4]

Royalty signaling on its own is less powerful. ERC-2981 defines an interface for reporting royalty terms so marketplaces can read payment guidance, but it does not itself enforce payment logic. It helps with interoperability, but not with trustless settlement guarantees for a specific marketplace flow.[S5]

For creators, the case for royalty enforcement is not only normative but economic. The arXiv study on NFT royalties shows royalty design can improve creator outcomes through pricing and risk-sharing mechanisms in ongoing secondary flows.[S1] However, there is also a hard risk edge: studies of NFT-to-asset linkage show that many assets rely on off-chain references and can become unavailable or duplicated, weakening entitlement certainty in practice.[S2] Even metadata quality research also flags that ERC-721 collections vary in how robustly they preserve permanence and uniqueness signals.[S3]

In short, the literature suggests two opposing forces: ERC standards provide a strong identity and transfer base, but AI asset systems still need application-specific controls around metadata integrity and revenue routing to avoid false assumptions about security and ownership semantics.[S1][S2][S3]

Architecture Analysis

1) Character ownership as access identity, not content key

For Realbits, CharacterNFT should represent the right to use a character instance, not the entire character definition. The token should be small and auditable: token ID, owner fields, creator identity, and a URI pointer to metadata snapshots where non-sensitive, versioned descriptors live off-chain. This is exactly the ERC-721 model of uniquely identifiable units with explicit transfer/approval flow.[S4]

A practical implementation flow is:

1. Minting creates a token ID in CharacterNFT.
2. A metadata pointer references off-chain character card data.
3. packages/web updates character catalog rows with nftTokenId and contract address.
4. Flutter clients enforce feature flags by wallet check.

OpenZeppelin ERC-721 tooling supports this style because ERC721 plus URI storage patterns separate per-token metadata lookup from transfer and balance state. That keeps token identity and token metadata update points explicit rather than hidden in ad hoc storage code.[S6]

2) Royalty escrow as the trust boundary

If ERC-2981 is only a reporting standard, then enforcing creator revenue needs a payment path under contract control. In Realbits terms, CreatorRoyaltyEscrow is the execution point that receives sale proceeds and executes split rules at transfer-time or claim-time depending on business logic.

A robust split design usually includes:

• platform fee sink,
• creator beneficiary,
• optional prior owner share for secondary-sale compatibility,
• explicit event emission for reconciliation.

This is directly aligned with the creator-economy requirements in the repo: creators need predictable payout behavior independent of marketplace cooperation. The arXiv royalty model result supports this direction because creator value often depends on durable and repeatable royalty flows rather than one-off listing events.[S1]

3) Security pattern for payout functions

Escrow and payout functions are inherently high risk because they involve ETH transfers and external calls. OpenZeppelin recommends pull-payment patterns where recipients withdraw owed funds, which reduces reentrancy and blocking risk.[S7] Ethereum security guidance also stresses checks-effects-interactions as a baseline ordering to break classic reentrancy windows.[S8]

For Realbits contracts, this implies:

• Use effect-first state updates for balances and shares.
• Use withdraw pull patterns for payout distribution when possible.
• Add reentrancy guards on withdrawal pathways.
• Add pausing for emergency kill-switch scenarios.

The OpenZeppelin docs also expose explicit pausing patterns and error requirements for transfer-critical contracts, which are useful for staged launches and incident response if metadata or mint surfaces misbehave.

4) Off-chain metadata strategy and integrity envelope

Realbits needs to protect itself from brittle metadata links. The off-chain fragility findings show that inaccessible or duplicated linked assets can still create user trust failure even when token transfer works.[S2] Therefore, metadata should be versioned and integrity-anchored rather than implicitly mutable.

A practical envelope:

• Use immutable schema versions for character card JSON.
• Store hash or CID-backed references instead of mutable URLs when possible.
• Record a hash of the referenced metadata on-chain or in a separate registry event stream for integrity checks.
• Keep sensitive prompt fields out of token metadata if those are intentionally not chain-persistent.

This architecture does not remove fragility, but it reduces ambiguity: on-chain ownership stays definitive while off-chain content integrity becomes detectably auditable.

5) Indexing and runtime resolution path

Cross-app portability depends on efficient ownership checks. A naive path that queries chain state on every render across all app surfaces can produce latency and RPC dependence issues. A better pattern is:

• read cached ownership at launch from a signed entitlement payload,
• periodically refresh via background sync,
• fallback to direct RPC read when cache is stale.

Polygon chain choice matters operationally. Polygon PoS Amoy testnet and Polygon mainnet endpoints are available with known RPC URLs and chain IDs in the official documentation, and the project already positions itself around this network family.[S9] Using chain parameters from source docs prevents accidental chain mismatch failures and avoids deployment drift when wallet UI, RPC, and block explorer links diverge.

6) Compatibility and optionality

Standard interoperability still matters. Even if escrow is the source of truth for Realbits settlement, adding ERC-2981-facing information keeps integrations with external wallets and marketplace tooling easier without locking the protocol to one marketplace path.[S5] A combined design is therefore layered:

• ERC-721 for entitlement identity.
• escrow for Realbits-specific payout math.
• optional royalty signal interface for broader ecosystem visibility.

This layered approach avoids overfitting on non-universal assumptions while preserving deterministic payouts for Realbits flows.

Limitations

1. ERC-2981 does not by itself enforce royalties, so external marketplaces can ignore or partially honor signals. For this reason, Realbits must preserve internal enforcement for first-party transactions and avoid over-reliance on external market behavior.[S5]
2. Off-chain metadata remains a single point of user trust risk. The arXiv findings about linkage fragility imply that token ownership and user-visible character value can diverge if metadata is removed, altered, or inaccessible.[S2]
3. ERC-721 metadata and contract-level transfer semantics are expressive, but they do not fully solve semantics like creator licensing terms, usage scope, or model quality guarantees. A character token can be transferred, but that does not automatically imply runtime fairness contracts or policy constraints.[S3][S4]
4. Operational friction on Layer2-equivalent networks can still arise from RPC limits, explorer delays, faucet constraints, and chain migration windows. Even with documented Amoy parameters, testing and observability remain non-trivial.[S9]

The practical implication is that character NFTs here are a strong entitlement primitive but not a complete legal or semantic contract.

Implications for This Repository

Realbits should treat ERC-721 and escrow not as isolated contracts but as a provider-wide entitlement protocol with explicit interfaces to web and app layers.

Recommended implementation posture:

• Keep CharacterNFT minimal and conservative: ownership, transfer semantics, creator tagging, and stable tokenURI pointers.
• Keep prompt and full character policy off-chain; keep on-chain fields limited to governance-safe identifiers.
• Implement CreatorRoyaltyEscrow with deterministic split math and pull-based withdrawal.
• Add explicit reentrancy and pause controls around sale and withdrawal entry points.[S7][S8]
• Add periodic reconciliation events for mint, purchase, split execution, and withdrawals.
• Expose a wallet verification path in packages/web that supports signed and cacheable entitlement responses.
• Add metadata integrity checks tied to version and hash so stale or missing off-chain assets are detectable early.[S2][S3]
• Use ERC2981 compatibility as a compatibility surface only, and not as the authority for Realbits settlement logic.[S5]

Given the repository direction, this architecture enables a useful sequence: first, reliable ownership proof; second, deterministic creator payout; third, user-facing portability across apps; and only then optional marketplace federation. That order fits the repository’s provider-first strategy and avoids building complex external assumptions into the core asset model.

References

• S1: https://arxiv.org/abs/2212.00292
• S2: https://arxiv.org/abs/2212.11181
• S3: https://arxiv.org/abs/2209.14517
• S4: https://eips.ethereum.org/EIPS/eip-721
• S5: https://eips.ethereum.org/EIPS/eip-2981
• S6: https://docs.openzeppelin.com/contracts/5.x/api/token/ERC721
• S7: https://docs.openzeppelin.com/contracts/4.x/api/security
• S8: https://ethereum.org/developers/docs/smart-contracts/security/
• S9: https://docs.polygon.technology/pos/reference/rpc-endpoints

Source Ledger

• [S1] Economics of NFTs: The Value of Creator Royalties (arxiv): https://arxiv.org/abs/2212.00292 - Empirical model of why creator royalties can add value beyond one-time sales; supports incentive design in Realbits creator economy.
• [S2] Do NFTs' Owners Really Possess their Assets? A First Look at the NFT-to-Asset Connection Fragility (arxiv): https://arxiv.org/abs/2212.11181 - Demonstrates practical fragility of off-chain NFT-linked assets, directly relevant to metadata and prompt/storage design.
• [S3] The Fungibility of Non-Fungible Tokens: A Quantitative Analysis of ERC-721 Metadata (arxiv): https://arxiv.org/abs/2209.14517 - Assesses metadata quality and expectations around ERC-721 permanence/uniqueness, useful for Realbits asset schema governance.
• [S4] ERC-721: Non-Fungible Token Standard (standards): https://eips.ethereum.org/EIPS/eip-721 - Defines ownership, transfer, approvals, and safe transfer semantics used as the base entitlement model.
• [S5] ERC-2981: NFT Royalty Standard (standards): https://eips.ethereum.org/EIPS/eip-2981 - Defines a common royalty query interface and clarifies that the standard mainly signals royalty information rather than enforcing payments.
• [S6] OpenZeppelin ERC-721 API (v5.x) (official-doc): https://docs.openzeppelin.com/contracts/5.x/api/token/ERC721 - Practical implementation surface for ownership, token URI handling, and royalty extension patterns in Solidity contracts.
• [S7] OpenZeppelin Security Utilities (official-doc): https://docs.openzeppelin.com/contracts/4.x/api/security - Documents Pausable, PullPayment, and ReentrancyGuard patterns that are directly applicable to escrow and mint-sale flows.
• [S8] Ethereum Smart Contract Security (official-doc): https://ethereum.org/developers/docs/smart-contracts/security/ - Explains checks-effects-interactions and related reentrancy controls for ETH transfer functions.
• [S9] Polygon RPC Endpoints (official-doc): https://docs.polygon.technology/pos/reference/rpc-endpoints - Confirms chain parameters and connectivity details for Amoy testnet and Polygon mainnet operations.