Add ERC: Service Objects

[MeltedMindz]

Summary

This PR adds ERC-8278: Service Objects.

The draft defines a small ERC-721 extension that exposes:

• a service manifest commitment,
• a service operator,
• a payment route consisting of revenue recipient, payment manifest, payment manifest hash, and route nonce.

The intent is to standardize only the token-readable control surface that wallets, indexers, clients, and payment middleware need before interacting with an offchain service.

Scope

This proposal is intentionally narrow. It does not define service discovery, reputation, validation, payment settlement, endpoint execution, smart account behavior, escrow, revenue splitting, MCP runtime semantics, or x402 settlement behavior.

The richer architecture in the reference repository includes experimental receipt, service account, and x402/MCP integration material. Those pieces are intentionally not included in the base ERC draft because they are more contentious and should be discussed as optional extensions or separate proposals.

Relationship to existing ERCs and protocols

• ERC-721 provides ownership, transfer, and marketplace compatibility. This proposal does not redefine ownership.
• ERC-7656 defines generalized contract-linked services. This proposal defines a specific service-object state surface: manifest, operator, and payment route. A later profile could expose these semantics through an ERC-7656-linked service contract.
• ERC-6551 token-bound accounts may be useful for operational accounts or receipt signing, but are not required by this draft.
• ERC-8004 addresses agent discovery, reputation, and validation. This proposal does not define an agent registry or trust system; it can complement ERC-8004 by exposing service-route state for a service token.
• x402 may be represented in a payment manifest, but x402 negotiation and settlement are out of scope.
• MCP endpoints or capabilities may be represented in a service manifest, but MCP protocol behavior is out of scope.

Discussion

Ethereum Magicians discussion: https://ethereum-magicians.org/t/erc-8278-service-objects/28659

Reference repository: https://github.com/MeltedMindz/erc-service-object

Minimal source draft: https://github.com/MeltedMindz/erc-service-object/blob/main/docs/ERC-draft-minimal.md

Local validation

• npx markdownlint-cli2 ERCS/erc-8278.md --config config/.markdownlint.yaml: passes
• eipw -c config/eipw.toml ERCS/erc-8278.md: passes

[eip-review-bot]

File ERCS/erc-8278.md

Requires 1 more review from Editors: @g11tech, @jochem-brouwer, @samwilsn, @xinbenlv

[github-actions]

The commit 852bbf8 (as a parent of f4746c2) contains errors.
Please inspect the Run Summary for details.

[MeltedMindz]

Hey I Am getting the error when trying to make a discussion on magicians An error occurred: Access Denied

…

On May 27, 2026, at 11:38 PM, Andrew B Coathup ***@***.***> wrote: @abcoathup commented on this pull request. In ERCS/erc-8276.md <#1777 (comment)>: > @@ -0,0 +1,126 @@ +--- +eip: 8276 +title: Service Objects +description: An ERC-721 extension for service manifests, operators, and payment routes. +author: MeltedMindz ***@***.***) +discussions-to: https://ethereum-magicians.org/t/post-eip-erc-split-create-erc-1-an-erc-specific-version-of-eip-1/16301 Please create a discussions topic for this ERC on Eth Magicians. It just needs to include a link to this PR and perhaps the abstract — Reply to this email directly, view it on GitHub <#1777?email_source=notifications&email_token=AW2OG3K267BFLYH3C4EINHD447NEVA5CNFSNUABKM5UWIORPF5TWS5BNNB2WEL2QOVWGYUTFOF2WK43UKJSXM2LFO4XTIMZXHA2DIOBWHE32M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#pullrequestreview-4378448697>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AW2OG3OVJ6AO2CPYXO5YC73447NEVAVCNFSM6AAAAACZQHL6W6VHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHM2DGNZYGQ2DQNRZG4>. You are receiving this because you authored the thread.

[MeltedMindz]

would like feedback on a small ERC-721 extension for service objects.

Problem

A transferable ERC-721 token can represent control over an offchain service, but clients and indexers do not have a standard way to resolve the current service manifest, service operator, or payment route before interacting with that service.

Today, each service marketplace, API provider, agent registry, or payment middleware has to invent its own metadata and payment-route conventions. That makes it hard for wallets, indexers, and clients to answer basic questions:

Which manifest describes this service?

Which operator is currently associated with it?

Which revenue recipient and payment manifest should paid endpoints use?

Did the payment route change since the client last inspected it?

Proposed primitive

The proposed base interface is intentionally small:

interface IERCServiceObject is IERC165 {
event ServiceManifestUpdated(uint256 indexed serviceId, string uri, bytes32 indexed manifestHash);

event ServiceOperatorUpdated(uint256 indexed serviceId, address indexed operator, uint64 expiresAt);

event ServicePaymentRouteUpdated(
    uint256 indexed serviceId,
    address indexed revenueRecipient,
    string paymentURI,
    bytes32 indexed paymentManifestHash,
    uint64 routeNonce
);

function serviceManifest(uint256 serviceId)
    external
    view
    returns (string memory uri, bytes32 manifestHash);

function serviceOperator(uint256 serviceId)
    external
    view
    returns (address operator, uint64 expiresAt);

function servicePaymentRoute(uint256 serviceId)
    external
    view
    returns (
        address revenueRecipient,
        string memory paymentURI,
        bytes32 paymentManifestHash,
        uint64 routeNonce
    );

}

The current reduced interface ID is 0xf94c99e5.

Non-goals

This proposal does not define:

service discovery

reputation or validation

payment settlement

endpoint execution

smart account modules

MCP behavior

x402 behavior

escrow

revenue splitting

service quality guarantees

x402 and MCP can be used as offchain manifest profiles, but neither is required by the ERC.

Relationship to existing ERCs

ERC-721 provides the ownership and transfer semantics. This proposal does not redefine ownership.

ERC-7656 defines generalized contract-linked service deployment and linking. This proposal defines service object semantics: manifest, operator, and payment route. It should be possible to expose this interface directly on an ERC-721 service token or through a later ERC-7656-linked profile.

ERC-8004 addresses agent identity, reputation, and validation. This proposal does not define an agent registry or trust system. A service object could be referenced by an ERC-8004 registration, and service route state could be used by clients before interacting with a registered agent.

ERC-6551, ERC-4337, ERC-7579, and ERC-6900 cover token-bound accounts and smart-account execution. Service accounts and receipt signing are useful extensions, but they are not part of the minimal base interface proposed here.

Repository and drafts

Repository: https://github.com/MeltedMindz/erc-service-object

Minimal draft: https://github.com/MeltedMindz/erc-service-object/blob/main/docs/ERC-draft-minimal.md

Hardening review: https://github.com/MeltedMindz/erc-service-object/blob/main/docs/final-hardening-review.md

Reference implementation: https://github.com/MeltedMindz/erc-service-object/tree/main/src

Questions for review

Is this better framed as an ERC-721 extension, an ERC-7656 service semantics profile, or both?

Is serviceOperator necessary in the base interface, or should the base only expose manifest and payment route?

Should the payment route include the revenue recipient, or should that be a separate getter?

Is routeNonce the right primitive for clients and indexers to detect stale payment offers?

Should ERC-1155 support be excluded from the base draft and handled only by a later singleton/controller profile?

Are signed usage receipts better as a separate ERC rather than an optional extension?

I am especially looking for feedback from ERC-7656, ERC-8004, wallet, marketplace, indexer, x402, MCP, and smart-account implementers.

[abcoathup]

What is your Eth Magicians username and I can take a look

[MeltedMindz]

Same as here, I signed up using GitHub. Thank you.  

[abcoathup]

@MeltedMindz
I bumped your permissions so you should be able to create a new topic now on Eth Magicians.
https://ethereum-magicians.org/u/meltedmindz/summary

[MeltedMindz]

@abcoathup Thank you added it to the pr and here it is as well

https://ethereum-magicians.org/t/erc-service-objects/28659