ERC-8432: Onchain IP Asset and License Registry

ERCs
,
1

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.

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.

11 Likes
2

We’ve published a post on the Soneium blog about ERC-8432 and why we think it matters:

In short, Soneium will support ERC-8432 and aims to see it adopted across our ecosystem as well as by global IPs. The objective is to make it possible to register once and license everywhere on Soneium.

By registering tokenized IP under a shared, registry-agnostic standard, rights holders become instantly discoverable and accessible to catalogs, marketplaces, and AI agents across different platforms and ecosystems. Developers integrate once without getting locked in, and AI agents can seamlessly read, verify, and transact rights without needing bespoke setups for every platform.

We will keep following the discussion closely and share feedback from builders within the Soneium ecosystem as the draft moves forward. If you are working on IP licensing and would like to collaborate on implementing ERC-8432 on Soneium, we would love to connect.

6 Likes
3

How should an agent distinguish declared exclusivity from exclusivity actually enforced by a registry?

Suppose the same asset has two overlapping offers with exclusive = true. Could two users acquire agreements that both remain active under the core rules?

I understand that resolving conflicting rights across registries is outside scope. But should there be a standard capability signal for exclusivity enforcement within one registry? Otherwise an agent needs deployment-specific knowledge to interpret a seemingly portable license field.

4

Thank for taking the time to look at this ERC and your valuable input.

I agree that a standard signal would be useful. I am considering a small addition to the core that standardizes reporting without requiring every registry to enforce exclusivity:

function enforcesExclusivity() external view returns (bool);

The important part would be defining its semantics precisely:

  • false: the registry advertises no standardized exclusivity-enforcement guarantee. Additional deployment-specific policy may still exist.
  • true: for each asset, the registry prevents an unexpired, non-revoked exclusive agreement from coexisting with any other unexpired, non-revoked agreement for that same asset.

This would be a deliberately conservative, asset-wide guarantee, covering both owner-issued grants and self-service acquisitions. It would not compare territories or domain-specific rights: an exclusive Japan-only agreement would also block a separate US agreement on the same asset. A registry applying narrower conflict rules could not advertise this particular guarantee unless it also satisfied the asset-wide rule.

To keep this simple, the signal would be fixed for the deployment. Temporary agreement freezing or a failed token-holder lookup would not release the exclusivity restriction; expiry or permanent revocation would.

The existing exclusive field would retain its meaning as a declaration in the terms. The new read would separately identify a specific registry-enforced guarantee, without changing core activity semantics or implying legal or global exclusivity.

Independently of whether this addition is adopted, the draft should explicitly clarify your example: under the current core rules, both overlapping agreements can remain active.