EAS Integration
Maroo's architectural approach to embedding the Ethereum Attestation Service.
Maroo integrates the Ethereum Attestation Service (EAS) as a core primitive for identity and reputation. EAS lives as standard Solidity contracts at canonical addresses; the chain's x/eas helper lets PCL's AnteHandler read those contracts efficiently during transaction validation. dApp callers see the standard EAS surface — getAttestation, the Indexer's reverse lookups — and don't need to know the chain helper exists.
Two surfaces, one source of truth
The source of truth is the Solidity preinstall — the EAS contract (
App developers should reach for the EVM path. The chain helper exists to power on-chain compliance evaluation, not as a client surface.
0x1000…0007) and its Indexer (0x1000…0008). Two surfaces read from it:- EVM JSON-RPC (the canonical path for dApps): viem / ethers / cast / eas-sdk all hit the contracts directly, exactly as on any other EVM chain.
x/easchain helper (used internally): converts internal queries intoeth_calls so PCL's AnteHandler can read attestations efficiently during transaction processing.
App developers should reach for the EVM path. The chain helper exists to power on-chain compliance evaluation, not as a client surface.
Identity & Compliance
Maroo uses EAS for its Programmable Compliance Layer (PCL). KYC (Know Your Customer), KYB (Know Your Business), and KYA (Know Your Agent) statuses are represented as on-chain attestations. The
x/eas module allows the PCL to verify these statuses efficiently during transaction processing.Contract Addresses
The integration relies on specific contract addresses for the EAS Registry and the Schema Indexer. These addresses are typically constant across Maroo networks (Mainnet/Testnet) but can be configured via module parameters or query arguments.