MRC 58 — Agent Registry Smart Contract Specification

A canonical, on-chain registry for the smart agents that consume the Morpheus inference network. Drafted by Hypnex Labs as the proposed implementation for MRC 58.

Status: Reference implementation deployed and verified on Arbitrum + Base mainnet (2026-05-08), awaiting Morpheus community review.

Deployed addresses

Chain	Address	Verified source
Arbitrum One	0xCC258a7BBF361fd824e87D4b3C0D394De6Fd454F	Arbiscan ↗
Base mainnet	0xd4D014De1e0D6287BeeD39CD6de99E3A73645ca4	BaseScan ↗

Both deployments are identical bytecode (Solidity 0.8.20, optimizer 200 runs, viaIR enabled). Source verified on both explorers.

Why this exists

The Morpheus protocol currently has no canonical, on-chain registry for the smart agents that consume its inference network. Five upstream MRCs (21, 60, 76, 86, 87) all assume an agent registry exists. MRC 58 unblocks all of them.

MRC	Initiative	Dependency on registry
MRC 21	Non-Fungible Agents	Need a stable agent identifier to wrap as an NFT
MRC 60	Agentic Tools Marketplace	Tools are bought by agents — agents need to be addressable
MRC 76	Performance Benchmarking	Benchmarks attach to agent ids; without ids, no leaderboard
MRC 86	Builder list using inference marketplace	Already a placeholder; the registry IS the list
MRC 87	Public list of inference providers	Same — providers register to be discoverable

What the contract does

• Stable bytes32 agentId = keccak256(namespace + "/" + name) per registration
• Public agent records: owner, name, namespace, metadataURI, capabilities[], pricePerCallWei, modelId, isActive, createdAt, updatedAt
• Capability tag index — find agents by keccak256("chat"), keccak256("code"), etc.
• Ownership transfer + deactivate/reactivate lifecycle
• Pagination for cheap reads off the all-agents list
• Cheap on gas: append-only secondary indexes; readers cross-check via getAgent(id).capabilities for current set

Interact

Via SDK

pip install hypnex-registry
# or
npm install hypnex-registry

See hypnex-registry SDK reference →.

Via Etherscan write tab

• Write on Arbiscan ↗
• Write on BaseScan ↗

Connect any wallet, call register(namespace, name, metadataURI, capabilities[], pricePerCallWei, modelId). Cost: ~$0.05 in gas per registration.

Design decisions

Why no fees?

Cheap = high adoption. Spam control comes from (namespace, name) uniqueness — anyone can squat the obvious names, but nothing forces consumers to use the squatted ones. Reputation (a separate contract) handles quality filtering.

Why not bake reputation in?

Reputation is opinionated. Different applications want different signals (latency, accuracy, user ratings, tool-call success rate). Putting reputation inside the registry forces one definition and makes it expensive to upgrade. Better: separate ReputationOracle contracts that read from the registry.

Why bytes32 capabilities instead of strings?

Cheaper storage + faster indexing. Apps map human-readable strings ("chat", "code", "vision") to keccak256(...) client-side.

Why store modelId?

So the registry doubles as a public list of which Morpheus models are in active use, satisfying MRC 87 ("Public list of Morpheus inference providers") for free. Aggregators can agentsWithCapability("chat") and group by modelId to see which models have ecosystem traction.

Hardenings vs the original draft

Added before deploy (community-feedback-friendly defaults):

• MAX_NAME_LENGTH = 64
• MAX_NAMESPACE_LENGTH = 64
• MAX_METADATA_URI_LENGTH = 1024
• MAX_CAPABILITIES = 64
• transferOwnership now updates updatedAt
• New custom errors: NameTooLong, NamespaceTooLong, MetadataTooLong, TooManyCapabilities

Foundry test suite: 19 / 19 passing.

Open questions for the community

1. Should the registry charge a small MOR fee on registration to discourage squatting? (Hypnex draft says no; flexible.)
2. Should updateMetadata emit a content hash so subgraphs can index the metadata directly? (Trade-off: extra event arg vs simplicity.)
3. Should there be an explicit "deprecate to successor" function so an upgraded agent points to the new agentId?
4. Should pricePerCallWei support multi-asset pricing (USDC, MOR, ETH)? Current draft is MOR-only for simplicity.
5. Multi-sig namespaces — should certain namespaces (e.g. morpheus) be reserved for an admin multi-sig?

Adoption path

If accepted, the foundation can either:

• Adopt the Hypnex draft as-is — Hypnex Labs deploys with foundation-controlled admin keys, audit funded by foundation
• Fork + iterate — community PRs against the reference repo, deploy under foundation namespace
• Specify only — leave implementation to the highest-quality community version

In all paths, the same canonical address should be referenced by downstream MRCs (60, 76, 86, 87) so they stack on a single source of truth.

Sources

• Full spec: docs/MRC-58-DRAFT.md
• Solidity: registry-contracts/contracts/HypnexAgentRegistry.sol
• Deploy record: registry-contracts/DEPLOYMENT.md
• Tests: registry-contracts/test/HypnexAgentRegistry.t.sol