Contracts and audits

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, the Veto Module, and completed security reviews.

​

Deployed contracts

TODO: Add contract addresses for SentinelOracle, Consensus, FROSTCoordinator, SafenetGuard, and RealityVetoModule once deployed. Replace source links to main/beta with links to the exact release tag or commit corresponding to the deployed Safenet Aegis version. 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 canonical Safenet Oracle will be 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.
• SafeDAO fee 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. TODO: Add the final Guard deployment addresses for each supported network. 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. TODO: Add addresses for the SafeDAO Safenet Safe, Safenet Security Council Safe, and Reward Distribution Safe once deployed. The SafeDAO Safenet Safe on Gnosis Chain is the governance address configured in the Safenet Oracle and is also the SafeDAO fee receiver. The Safenet Security Council Safe on Gnosis Chain resolves arbitration when Sentinel decisions are split. The Reward Distribution Safe on Ethereum Mainnet publishes accepted reward distributions. See Governance and Rewards for the corresponding processes.

​

Veto Module

The Reality Veto Module is a Safe module for a SafeDAO Safe on Gnosis Chain that executes proposals through SafeSnap. It gives one address, the vetoer, a single power: invalidating a pending SafeSnap proposal. The vetoer cannot propose, approve, or execute transactions, or act as the Safe in any other way. How a veto works A SafeSnap proposal passes a Snapshot vote, then waits through a challenge period on Reality.eth. After that, anyone can execute its transactions through the Safe. The vetoer can invalidate the proposal until its transactions have executed. The module does this by making the Safe call the Reality module’s existing function for invalidating proposals. It adds no other capability.

• A veto is permanent for that proposal. SafeDAO can submit the same change again as a new proposal, which starts a new challenge period and cooldown.
• After a veto, the proposal’s remaining transactions can no longer execute. If a proposal contains several transactions, any that already executed are not reversed.
• The vetoer can also invalidate a proposal before it is submitted. That exact proposal can then never be submitted.

Configuration The Safe, the Reality module, and the vetoer are fixed when the module is deployed. The module has no admin functions and no configurable parameters. Changing the vetoer requires deploying a new module, which SafeDAO enables in place of the old one. SafeDAO can disable the module through a governance proposal. Like any other proposal on that Safe, a proposal to disable the module can be vetoed. Status The Veto Module is not yet deployed. Its audit by ack3 is listed under Audits. See the contract source and the module README for the implementation and threat model. TODO: Add the Veto Module address once deployed. Name the SafeDAO Safe it is enabled on and the governance decisions it can veto.

​

Audits

The following audits cover contracts used by Safenet, newest first. An audit reviews specific code at a specific commit. It does not guarantee that the code is free of vulnerabilities. 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.