Skip to Content

System Contracts

Genesis deploys three system contracts that the chain itself calls or that govern it: BlockMeta, the foundation MultiSignatureWallet, and the AutomationRegistry. Predeployed Contracts names them and the other contracts deployed at genesis; this chapter documents their interfaces — which entry points a given caller may use, the preconditions that make a call revert, the events, and the ABI to import into a development environment.

PageCovers
BlockMetaThe per-block system scheduler
MultiSignatureWalletThe foundation wallet, and deploying your own wallet against the same implementation
AutomationRegistryThe registry diamond and its seven facets

Using automation is covered by Getting Started with Automation, which registers a first task end to end with Foundry, How Automation Works, which describes cycles, configuration, fees, task validity, and UST versus GST, and Automated Transactions over RPC, which describes automation activity as the Ethereum JSON-RPC and Supra REST APIs report it.

The reserved range their system calls come from is in SupraEVM Precompiles.

The contract registry

The chain records the address of every genesis contract in the contract registry: the 0x1::evm_config::EvmContractsDetails resource in Move state. Each entry pairs a key — the contract’s name, such as AutomationRegistry, BlockMetadata or WrappedSupra — with its address. Pages in this chapter refer to an entry as a contract registry key. How to read the resource, and how its addresses are derived, is in Finding the address.

The contract registry is unrelated to the automation registry, which is one of the contracts it lists.

Ownership

The foundation wallet owns BlockMeta, the automation registry diamond, and MultisigBeacon at genesis; read owner() for the current owner. While the wallet is the owner, every owner-gated function on them — registering a block-prologue entry, changing automation configuration, upgrading an implementation, replacing a facet — is reachable only through that wallet’s submit, confirm and execute flow, and needs its confirmation threshold to be met. See MultiSignatureWallet.

Interfaces and ABIs

The Solidity sources are in solidity/supra_contracts/src of the revm fork at tag revm-29.0.0-supra-v1.0.0.rc17, the revision the node deploys, with the public interfaces in src/interfaces.

Downloading the interfaces

The public interfaces are the 17 files in src/interfaces at the pinned tag. They are not self-contained:

  • ICoreFacet, IConfigFacet, IRegistryFacet and IRegistryViewFacet import ../libraries/LibCommon.sol and ../libraries/LibAppStorage.sol, which declare the structs and enums they use.
  • IWrappedSupra imports OpenZeppelin’s IERC20, and the two libraries import its EnumerableSet. The contracts are built against OpenZeppelin Contracts v5.5.0.

GitHub serves a whole repository as a zip, not a single directory. The repository at the pinned tag is revm-29.0.0-supra-v1.0.0.rc17.zip , with the interfaces under solidity/supra_contracts/src/interfaces. To fetch only the files the interfaces need, use a sparse checkout:

git clone --depth 1 --filter=blob:none --no-checkout \ --branch revm-29.0.0-supra-v1.0.0.rc17 https://github.com/Entropy-Foundation/revm.git cd revm git sparse-checkout set --no-cone \ /solidity/supra_contracts/src/interfaces/ \ /solidity/supra_contracts/src/libraries/LibAppStorage.sol \ /solidity/supra_contracts/src/libraries/LibCommon.sol git checkout

That checks out the 17 interfaces and the two libraries, and nothing else. To compile them in a Foundry project, copy the interfaces and libraries directories into the project’s src, keeping them side by side, then install OpenZeppelin Contracts and map its import prefix in foundry.toml:

forge install OpenZeppelin/openzeppelin-contracts@v5.5.0
remappings = ["@openzeppelin/contracts/=lib/openzeppelin-contracts/contracts/"]

Generating a JSON ABI

The repository does not publish JSON ABIs. Generate one with Foundry from a project that compiles the interfaces — the set above, or the solidity/supra_contracts directory of a full checkout:

forge inspect IRegistryFacet abi --json > IRegistryFacet.json

Without --json, forge inspect prints a table of signatures and selectors rather than an ABI a client library can load.

Each page in this chapter lists the interfaces it draws on.

Last updated on