ERC-8004 Identity Registry (Preinstall)
The on-chain primitive for AI agent identity. Standard ERC-8004 contract, deployed at genesis, owned by no one.
Maroo treats AI agent identity as a chain-level primitive by deploying a standard ERC-8004 IdentityRegistry contract as a preinstall — i.e., the contract is part of the genesis state at a fixed, well-known address rather than being deployed by any single dapp. This means agent registration, attestation, and revocation use the canonical ERC-8004 ABI, so any tool that supports ERC-8004 elsewhere works on Maroo without modification. The Maroo-specific agent precompile sits on top of this contract to provide low-gas indexed reads (see agent-precompile-overview).
Why preinstall (not a dapp-deployed contract)?
If the IdentityRegistry were deployed by a single dapp (or worse, by individual issuers), agent identity would fragment across competing registries — the very problem ERC-8004 was designed to solve. Maroo eliminates that fragmentation by including the registry in the genesis state. There is exactly one canonical IdentityRegistry on the chain, at a fixed address, and
Compare to OKRW or PCL, which are precompiles (Go-native code at fixed addresses). The IdentityRegistry is a regular Solidity contract — its bytecode follows the ERC-8004 standard verbatim. Preinstall is the chain operator's way of saying "this is foundational; you don't need to deploy your own."
x/agent indexing + the agent precompile track that one contract.Compare to OKRW or PCL, which are precompiles (Go-native code at fixed addresses). The IdentityRegistry is a regular Solidity contract — its bytecode follows the ERC-8004 standard verbatim. Preinstall is the chain operator's way of saying "this is foundational; you don't need to deploy your own."
What's covered in V1
ERC-8004 defines three sub-registries: Identity Registry, Reputation Registry, and Validation Registry. Maroo V1 implements only Identity Registry. The other two are deferred to V2+ and are out of scope for current development.
In practice that means V1 supports:
Reputation scoring and validator-style claim verification (the other ERC-8004 pieces) are not present in V1.
In practice that means V1 supports:
- Registering an agent (creates an
agentId+ assigns the agent's own EVM address). - Linking an agent to its owner (a human or corporate account that holds an EAS KYC/KYB attestation).
- Recording delegation scope — session keys, spending limits, allowed function selectors — as on-chain attestations attached to the agent.
- Revoking an agent (state change, irreversible at the protocol level).
Reputation scoring and validator-style claim verification (the other ERC-8004 pieces) are not present in V1.
Owner ↔ Agent linkage and KYA
Per Maroo whitepaper §6.3, KYA (Know Your Agent) is not a KYC extension. It's an emergent property of three components:
1. Owner identity — KYC/KYB EAS attestation held by the human or corporate account that registered the agent.
2. Delegation scope — session keys, daily/monthly spending caps, function selector allowlists. Recorded as ERC-8004 attestations or auxiliary attestations on the agent.
3. Action constraints — what the agent's wallet is technically permitted to do, enforced by PCL at execution time.
The IdentityRegistry stores (1) and (2). PCL reads (1) via the EAS precompile and (2) via the Agent precompile, and enforces (3). The whole stack composes KYA without requiring any single registry to encode it monolithically.
1. Owner identity — KYC/KYB EAS attestation held by the human or corporate account that registered the agent.
2. Delegation scope — session keys, daily/monthly spending caps, function selector allowlists. Recorded as ERC-8004 attestations or auxiliary attestations on the agent.
3. Action constraints — what the agent's wallet is technically permitted to do, enforced by PCL at execution time.
The IdentityRegistry stores (1) and (2). PCL reads (1) via the EAS precompile and (2) via the Agent precompile, and enforces (3). The whole stack composes KYA without requiring any single registry to encode it monolithically.
Calling the registry
From a Solidity contract you call the IdentityRegistry the same way you'd call any standard ERC-8004 deployment:
``
``
solidity
interface IIdentityRegistry {
function register(...) external returns (bytes32 agentId);
function attest(bytes32 agentId, ...) external;
function revoke(bytes32 agentId) external;
// plus standard ERC-8004 view methods
}
contract MyAgentDeployer {
IIdentityRegistry constant REGISTRY = IIdentityRegistry(0x...); // Maroo preinstall address
// ... use as normal
}
`
The address is published in the chain's genesis configuration and won't change. For querying ("list agents owned by X"), use the