Skip to main content
Safenet uses smart contracts across Gnosis Chain, Ethereum Mainnet, and the networks where the Safenet Guard is deployed. This page provides references for deployed contracts, source code, governance accounts, ENS records, the Veto Module, and completed security reviews.

​
Deployed contracts

The Staking and reward-distribution contracts are carried forward from Safenet Beta.
TODO: Add the SafenetGuard deployment address for each supported execution network (Ethereum Mainnet, Gnosis Chain, and Arbitrum). Core protocol The core Safenet protocol contracts run on Gnosis Chain:
  • SentinelOracle coordinates Sentinel checks, fees, bonds, arbitration, and configurable protocol parameters.
  • Consensus coordinates Validator attestations and Validator-set epochs.
  • FROSTCoordinator coordinates Validator FROST signing ceremonies.
The Safenet Explorer is a helper for examining activity on these contracts, such as transaction checks, results, and attestations. It reads onchain data and is not part of the protocol. The contracts remain the authoritative source. The canonical Safenet Oracle is identified through oracle.safenet-gov.eth. SafeDAO can change configurable SentinelOracle parameters without replacing the Oracle, including:
  • Sentinel set.
  • Transaction-check fee.
  • SafeDAO fee share.
  • Bond parameters.
  • Protocol funds receiver.
Changes to immutable Oracle configuration require deployment and activation of a new Oracle. See Governance for Oracle governance and upgrades. Safenet Guard The Safenet Guard verifies Safenet attestations and can require a valid secure attestation before normal Safe execution. Guard contracts are deployed on the execution networks where Guard enforcement is supported. A Safenet Guard deployment is configured with the Safenet consensus context and delayed-execution parameters at deployment. Changes to this configuration require a new Guard deployment. See Safenet Guard for the enforcement model. Staking and reward distribution The Staking contract on Ethereum Mainnet manages SAFE staking, delegation, withdrawal configuration, and the active Validator set. The contract is non-upgradeable. Its SAFE token and configuration-change delay are fixed at deployment. The contract owner can propose changes to the withdrawal delay and active Validator set, subject to the contract’s configuration delay. Validator and Delegator rewards are distributed through the reward-distribution contract on Ethereum Mainnet. See the table above for its address, source, and audit. See Staking and Rewards.

​
Governance accounts

Safenet uses separate Safe accounts for protocol governance, arbitration, and reward distribution. The table also lists the Reality Modules that execute SafeDAO proposals on the Safenet Governance Safes. Safenet Governance Safe (Mainnet)
  • Mainnet governance: executes SafeDAO decisions on Ethereum Mainnet.
  • Staking governance: owns the Staking contract and the reward-distribution contract.
  • Governance ENS control: is the registrant and owner of safenet-gov.eth and its subnames. See ENS records.
  • Reward distribution: executes accepted reward distributions, updating the rewards-contract Merkle root, funding the rewards contract, and updating the rewards.safenet-gov.eth reference.
Safenet Governance Safe (Gnosis Chain)
  • Sentinel Oracle governance: is the governance address configured in the SentinelOracle and executes approved Oracle parameter changes.
  • Protocol funds: is the protocol funds receiver, which receives the SafeDAO fee share and slashed bonds.
Safenet Security Council Safe
  • Arbitration: resolves arbitration when Sentinel decisions are split.
Owners and modules Each Safenet Governance Safe has a single owner, the inert address 0x0000000000000000000000000000000000000002, with a threshold of 1. This address cannot sign, so no signer can execute transactions from either Safe. Each Safe has two modules enabled:
  • Reality Module: executes a proposal’s transaction bundle after a final Yes answer on Reality.eth, the cooldown, and before expiration.
  • Veto Module: can only invalidate pending proposals. See Veto Module.
See Current configuration for the Reality Module bonds and timing, and Governance and Rewards for the corresponding processes.

​
ENS records

Safenet’s governance ENS names are on Ethereum Mainnet. The Safenet Governance Safe (Mainnet) is the registrant of safenet-gov.eth and the owner of the name and each subname, so changes to these records execute only through Mainnet governance. Routine Oracle parameter changes do not touch ENS. They execute through the Safenet Governance Safe (Gnosis Chain). Charter The charter.safenet-gov.eth contenthash establishes which Charter version is adopted. Copies in the safenet-charter repository are mirrors and do not establish adoption on their own. Changing the adopted Charter requires a Mainnet governance proposal that updates the contenthash. Oracle The Gnosis Chain address record identifies the canonical SentinelOracle. The epochStart text record is a Safenet consensus epoch ID. It is not a block number or a timestamp. Replacing the Oracle requires a Mainnet governance proposal that updates both records. See Oracle replacement. Rewards The rewards.safenet-gov.eth contenthash is updated by each accepted reward distribution, together with the Merkle root on the reward-distribution contract. Until the first distribution executes, the record has no contenthash. The onchain Merkle root, not the ENS record, determines which claims are accepted. See Distribution and claiming.

​
Veto Module

The Reality Veto Module gives one address, the vetoer, a single power: invalidating a SafeDAO proposal on a Safenet Governance Safe before its transactions execute. The vetoer cannot propose, approve, or execute transactions. On both chains, the vetoer is a Safe Ecosystem Foundation (SEF) Safe, and the veto is only to be used for tax, sanctions, or AML compliance. This restriction is a usage policy and is not enforced by the module.
  • A veto is permanent for that proposal. Transactions that already executed are not reversed. SafeDAO can submit the change again as a new proposal.
  • The module has no admin functions or parameters. Changing the vetoer requires a new module. SafeDAO can disable the module through a proposal, which can itself be vetoed.
See the module README for the implementation and threat model, and Audits for the ack3 review.

​
Audits

The following audits cover contracts used by Safenet, newest first. An audit reviews specific code at a specific commit. It does not establish that the code is free of vulnerabilities, that a deployment is configured correctly, or that a component is ready for operation. Read each report for its scope, findings, and the resolution status of each finding. The audit index in the safenet repository lists the Safenet reports and their commits. The safenet-utils audit index lists the Veto Module report. Report a security issue See Bug bounty for how to report a security issue.