Onchain IP Asset and License Registry

I propose an Onchain IP Asset and License Registry standard. AI agents can find and reuse works faster than people can review individual licenses, while rights and agreements still live largely in documents and platform databases. Token ownership alone does not answer what use is licensed. This draft proposes a common interface for independent registries to identify IP assets, publish machine-readable license terms, and record and check license agreements. It standardizes the shared mechanism, not legal rights or policy. I would welcome feedback from rights-management platforms, agent developers, wallet and marketplace teams, and people working on licensing and legal-tech standards. - [Draft specification](https://github.com/sgc-web3/ERCs/blob/ipasset-and-license-registry/ERCS/erc-ipasset-and-license-registry.md) - [Illustrated overview](https://github.com/sgc-web3/erc-ipasset/blob/master/docs/erc_overview.md) - [Reference Implementation](https://github.com/sgc-web3/erc-ipasset/tree/master/src) - [Tests](https://github.com/sgc-web3/erc-ipasset/tree/master/test) The reference implementation validates the specification; it is not audited or intended for production use. ## A concrete use case A music rights holder registers a recording and attaches reusable license terms. An agent making a video finds the offer, inspects the terms and rights-holder evidence, checks `canLicense`, and acquires an agreement if the transaction's checks pass. An application can then check the agreement's onchain state before using the recording, while separately evaluating the terms and any off-chain conditions, such as payment. An ERC-8004 agent identity may inform a deployment's `canLicense` hook; x402 payment can settle around `acquireAgreement`. The core composes with both but depends on neither. The asset, terms, and agreement may be referenced across registries and chains (identified by EIP-155 chain ID); the registry does not verify remote state or prove that the licensor holds the underlying rights. Assets and agreements need not be tokens, although ERC-721 binding is supported. The draft includes hooks for deployment-specific policy and asset claims that draw on ERC-3643's claim-topic, issuer-scoped claim, and trusted-issuer patterns. It does not require ERC-3643 or prescribe claim topics or signature schemes. ## How this differs ERC-5218 and ERC-5554 provide token-centered rights and licensing interfaces; Story Protocol offers an integrated IP and licensing system on its own network. This proposal instead targets independently deployed registries with content-addressed terms, non-tokenized or ERC-721-bound records, and scoped cross-registry references. Payments, royalties, graph traversal, legal enforcement, and cross-chain verification remain outside the core. The draft's Overview and Specification describe the model and its limits in detail. ## Feedback requested I would especially welcome confirmation of these design choices from people working with real rights catalogs and licensing flows. Concrete counterexamples and suggested alternatives are equally welcome: 1. **Independent registries:** Does a permissionless, multi-registry model fit existing IP rights systems, where no single authority can resolve every claim? The ERC identifies each record by `(chainId, registry, id)` and leaves assessment of rights and competing claims to consumers. Is that a useful boundary in practice? Where would it break down? 2. **Trust without a gatekeeper:** Is registry reputation, together with issuer evidence and application or catalog selection, sufficient to establish trust without having the ERC designate a central authority? What additional interoperable signals, if any, would help them make that choice? 3. **Licensing vocabulary:** Does a shared rights summary alongside domain-specific terms give integrators a useful comparison floor without implying that the registry can determine legal permission? Where would this model misrepresent a real license? 4. **Core lifecycle:** Do the asset, terms, agreement, and claim interfaces provide a useful common basis for independent implementations? If part of this surface creates disproportionate cost or friction, what concrete integration would benefit from a narrower core? A worked integration—or a licensing scenario the model cannot express—would be especially valuable. 1 post - 1 participant Read full topic