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
Illustrated overview
Reference Implementation
Tests
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:
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?
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?
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?
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 | "Module: A Reusable State-Machine Framework for NFT Capabilities (Ownership Module v0.5 → v1.0)" | 0 | 12.53 | 27-09-2026 |
| 2 | ERC-8415: Asynchronous Register Projection for NFTs | 0 | 12.36 | 28-09-2026 |
| 3 | ERC-8226: Regulated Agent Mandate | 0 | 5.76 | 28-09-2026 |
| 4 | ERC-8320: Regulated Asset Claim | 0 | 7.2 | 28-09-2026 |
| 5 | RFC: Procedure Manifests - Mechanism for AI Agents to Resolve Contractual Disputes | 0 | 9.98 | 28-09-2026 |
| 6 | RFC: Procedure Manifests - Mechanism for AI Agents to Resolve Contractual Disputes | 0 | 13.78 | 29-09-2026 |
| 7 | ERC-8183: Agentic Commerce | 0 | 12.88 | 28-09-2026 |
| 8 | ERC-XXXX: Holding-Time Auto Staking for NFTs | 0 | 32.22 | 28-09-2026 |
| 9 | ERC-8427: Portable Spend Grants | 0 | 10.76 | 28-09-2026 |
| 10 | ERC-8392: Asset Status Interface for Tokenized Assets | 0 | 8.06 | 28-09-2026 |