Guardrails

Trust-minimized launch guardrails for Axiom

The first version of Axiom is launching with three administrative roles. Although Axiom itself only holds user funds to accept payment for query fulfillment, the protocol has some administrative functions to:

• Protect against catastrophic outcomes for downstream applications in case of an exploit.

• Allow upgrades stay in sync with future changes to Ethereum.

These functions are permissioned to three roles: PROVER_ROLE, GUARDIAN_ROLE, and TIMELOCK_ROLE. This page documents their capabilities and limitations to provide transparency about their security implications.

Proving

At launch, proving is limited to PROVER_ROLE to guard against exploits of the Axiom ZK circuits. In the event that a ZK circuit is found to be under-constrained, this prevents exploits by malicious provers who could use this to prove inaccurate facts about the historic on-chain data. As the ZK circuit codebase matures, we intend to remove this permissioning.

Freezing

If a vulnerability is found in the Axiom smart contracts or ZK circuits, the GUARDIAN_ROLE, which is held by a Gnosis SAFE multisig, will use

function freezeAll() external onlyRole(GUARDIAN_ROLE)

to pause all update functionality to the Axiom ZK circuits, including:

• Updates to the cache of historic block hashes in AxiomV1

• Submission of new queries into AxiomV1Query

• Fulfillment of queries into AxiomV1Query

By pausing updates to the contracts, this safety mechanism provides time for any potential issues to be mitigated. It is intended to be used only in the event of an exploit. As the protocol matures, we intend to remove this mechanism.

Upgrades

The AxiomV1 and AxiomV1Query contracts are currently upgradeable via the OpenZeppelin UUPSUpgradeable pattern and have upgradeable verifiers for ZK proofs of historic block hashes and query results. These upgrades are permissioned to the TIMELOCK_ROLE, which is assigned to an OpenZeppelin Timelock controller controlled by a Gnosis SAFE multisig.

We use a Timelock delay to provide users recourse in the event of a contract upgrade they disagree with. Because execution of upgrades can only take place after the timelock delay, users are able to verify upgrades are not malicious and have time to exit the protocol if they disagree with any changes. As detailed in On-chain ZK Verifiers, to guard against metamorphic contract attacks, users should check that each deployed verifier contract bytecode does not contain SELFDESTRUCT or DELEGATECALL. For convenience, we have integrated this check into our Github CI in the axiom-v1-contracts repo.

The upgrade functionality is intended to be used for three purposes:

• Recovery from any vulnerabilities or exploits found in Axiom.

• To upgrade the Axiom ZK circuits to match protocol upgrades to Ethereum.

• To introduce new optimizations or extensions to the Axiom query format.

As the protocol matures, we intend to expand the set of multisig holders and perform non-mandatory upgrades infrequently.