testnet
GitHub

Maroo Precompiles Architecture

core external-dapp

How Maroo extends the EVM with native blockchain features through precompiled contracts.

Maroo registers four core precompiles at genesis, plus the standard set inherited from Cosmos EVM. The four Maroo-specific precompiles are: OKRW (stablecoin operations), PCL (compliance enforcement), EAS (KYC/KYB attestation queries), and Agent (ERC-8004 agent identity indexing). Each lives at a fixed address and exposes a Solidity-callable interface. Identity primitives are intentionally split into two precompiles — EAS for human/corporate attestations and Agent for AI agent identity — because the underlying attestation models differ.

Key Features

Native Performance

Operations run as optimized Go code, offering significantly lower gas costs and faster execution than equivalent logic written in Solidity.

Seamless EVM Integration

Developers interact with precompiles just like any other smart contract, using a standard Solidity interface and familiar tools like Hardhat and Foundry.

Four Core Precompiles

OKRW (stablecoin operations), PCL (compliance enforcement), EAS (KYC/KYB attestation queries via Ethereum Attestation Service), and Agent (ERC-8004 agent identity indexing). Each at a fixed address.

Modular and Extensible

The registration system allows for the easy addition or removal of precompiles, enabling customized Maroo network configurations for specific use cases.

Architecture

graph TD
    A[Solidity Contract] -.->|calls fixed address| C{Precompile Map}

    subgraph Maroo["Maroo-specific precompiles (4)"]
        D1[OKRW] --> K1[x/okrw Keeper]
        D2[PCL] --> K2[x/pcl Keeper]
        D3[EAS] --> K3[x/eas Keeper]
        D4[Agent] --> K4[x/agent Keeper]
    end

    subgraph Std["Standard Cosmos EVM precompiles"]
        S1[Staking] --> KS1[x/staking]
        S2[Bank] --> KS2[x/bank]
        S3[Gov] --> KS3[x/gov]
    end

    K4 --> R[ERC-8004 IdentityRegistry preinstall]

    C --> D1
    C --> D2
    C --> D3
    C --> D4
    C --> S1
    C --> S2
    C --> S3

Architectural overview of the Maroo precompile system. Solidity contracts call a precompile address, which the EVM routes to a native Go implementation. This implementation uses a Cosmos SDK keeper to interact with the underlying blockchain state.

The Registration Process

All precompiles available on the Maroo network are registered when the node starts. The process is centralized in the DefaultStaticPrecompiles function, which constructs a map of precompile addresses to their Go implementations.

This function uses a builder pattern, starting with a base set of standard precompiles inherited from the Cosmos EVM (such as staking, governance, and bank operations) and then progressively adding Maroo's custom precompiles. The WithOkrwPrecompile and WithPclPrecompile methods are called to add Maroo's core functionalities to this map. The final map is then passed to the EVM module, making the precompiles available for execution.

Dependency Injection via Keepers

Precompiles do not operate in a vacuum; they need to interact with the blockchain's state. For example, the OKRW precompile needs to access account balances and minting permissions. In the Cosmos SDK architecture, this access is managed by modules called 'keepers'.

When a precompile is initialized (e.g., in WithOkrwPrecompile), it is 'injected' with the keepers it depends on. The okrwKeeper provides access to the x/okrw module's state and logic, while the bankKeeper provides access to the universal x/bank module for token transfers. This dependency injection pattern ensures that precompiles are secure, modular, and can safely interact with the rest of the blockchain state without having unrestricted access.
Note: This keeper-based architecture is a core concept of the Cosmos SDK and is fundamental to how Maroo securely bridges the EVM world with its custom, application-specific logic.

Next Steps

Source: maroo
ESC
Type to search