Governance

SafeDAO governs Safenet’s Charter, Oracle, participant sets, and configurable protocol parameters. SafeDAO decisions execute through two Safenet Governance Safes, one on Gnosis Chain and one on Ethereum Mainnet. Each Safe executes proposals through Snapshot, Reality.eth, and a Zodiac Reality Module. A passed Snapshot vote alone does not execute any transaction.

​

How Safenet governance works

SafeDAO proposals execute through one of two Safenet Governance Safes, depending on the chain and the change: A passed Snapshot vote becomes executable only after a final Yes answer on Reality.eth and the cooldown. Anyone can then execute the bundle through the Safenet Governance Safe on the relevant chain. Safenet Governance Safe (Gnosis Chain)

• Oracle parameter governance: is the governance address of the Safenet Oracle and executes approved Oracle parameter changes, such as Sentinel set, fee, and bond changes.
• Protocol funds: receives the SafeDAO fee share and slashed Sentinel bonds.

Safenet Governance Safe (Mainnet)

• Mainnet governance: executes SafeDAO decisions on Ethereum Mainnet.
• Staking governance: owns the Staking contract, which records the active Validator set and the withdrawal delay. Changes are subject to the contract’s configuration delay.
• Canonical references: controls the charter.safenet-gov.eth and oracle.safenet-gov.eth ENS records, which identify the canonical Charter and Oracle.
• Rewards distributions: executes accepted Validator and Delegator rewards distributions. This follows a separate process described in Rewards.

See Governance accounts for the addresses of both Safes and their Reality Modules. The Safenet Security Council is not part of this execution path. It resolves arbitration when Sentinel results for a transaction check are split. It does not execute SafeDAO proposals.

​

How proposals execute

Proposals on both Safes follow the same steps. Every step after the Snapshot vote is permissionless. 1. Snapshot vote A SafeDAO Snapshot proposal passes together with its executable transaction bundle. The bundle is the exact set of transactions the Safe will run if execution is authorized. 2. Reality.eth question Anyone can submit a Reality.eth question for the proposal. The question binds the proposal to the hash of the exact transaction bundle and to the applicable authorization criteria. It asks whether executing that bundle is authorized. A question asked before the Snapshot vote has concluded is answered Invalid. 3. Answers, challenges, and bonds Anyone can answer Yes, No, or Invalid by posting a bond in SAFE. Anyone who disagrees can challenge by posting a different answer with at least double the previous bond. Each new answer restarts the question timeout. The answer that stands when the timeout elapses becomes final. Bonds escalate with each challenge. When an answer is overturned, its bond goes to the participants who gave the final answer. This makes defending a wrong answer increasingly costly, but it does not guarantee a correct answer. The outcome depends on participants who are willing to post bonds to correct a wrong answer in time. No arbitrator is configured, so bond escalation is the only way to dispute an answer. 4. Execution Once all of the following conditions hold, anyone can execute the bundle through the Zodiac Reality Module:

• The Reality.eth answer is final and Yes.
• The cooldown after finalization has elapsed.
• The answer has not expired.
• The proposal has not been vetoed.

Other outcomes

• No or Invalid: the bundle cannot execute on the basis of that question. Making the change requires a new proposal.
• Veto: the Safe Ecosystem Foundation (SEF) can permanently invalidate a pending proposal, only for tax, sanctions, or AML compliance. This is a usage policy and is not enforced onchain. The veto cannot initiate, approve, or execute transactions. See Veto Module.
• Expiration: if the bundle is not executed before the answer expires, it can no longer execute on the basis of that answer. Making the change requires a new proposal.

Rewards distributions On the Safenet Governance Safe (Mainnet), the same question format has a second authorization case for rewards distributions. It asks whether a published reward dataset correctly applies the reward methodology approved in SEP 56, as amended by later approved SEPs, and whether the bundle performs only the permitted distribution actions. Routine distributions use this case, so a distribution does not need its own Snapshot vote. See Rewards. Monitoring Because answering and challenging are open to anyone, this process relies on participants watching for new questions, answers, challenges, and pending executions, and acting within the configured time windows. A wrong answer that no one challenges before the timeout becomes final. See the safenet-utils governance contracts and the safenet-staking-scripts repository for implementation details, commands, and deployment information.

​

Current configuration

The Reality Modules on both Safenet Governance Safes use the following configuration. The onchain module configuration is authoritative if it differs from this page. Timing An unchallenged answer becomes final 3 days after it is posted. Each challenge restarts the timeout, so challenges can extend the time to finalization. After finalization, execution waits for the 5-day cooldown. The answer expires 7 days after finalization, which leaves a 2-day execution window after the cooldown ends. Owners 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. Transactions execute only through the Reality Module after the checks above. See Governance accounts. ENS references Control of the safenet-gov.eth ENS records has been handed over to the Safenet Governance Safe (Mainnet). Routine Oracle parameter changes go through the Safenet Governance Safe (Gnosis Chain). Changes to the Charter reference and replacement of the Oracle go through ENS governance on Mainnet. See ENS records for each record and its purpose.

​

What SafeDAO governs

Charter The Safenet Charter defines the rules Sentinels apply when evaluating transactions. The canonical Charter version is referenced through charter.safenet-gov.eth. For convenience, the Charter is also published in the safenet-charter repository. SafeDAO can adopt a new Charter version and update the canonical reference through governance. A Charter change applies according to the effective time or epoch defined for that version. Oracle parameters The Safenet Oracle is deployed on Gnosis Chain. It contains the protocol logic and configuration used for Sentinel participation, fees, bonds, arbitration, and related Safenet mechanics. SafeDAO can update configurable Oracle parameters without replacing the Oracle contract:

• Sentinel set: Add or remove Sentinels.
• Transaction-check fee: Change the USDC fee charged for a Safenet check.
• SafeDAO fee share: Change the portion of transaction-fee revenue directed to DAO-controlled protocol funds.
• Bond slashing: Change the amount of a Sentinel bond that can be slashed under the applicable rules.
• Protocol funds receiver: Change the address receiving DAO fee revenue and slashed bonds.

These changes execute through the Safenet Governance Safe (Gnosis Chain). See Fees for the current economic parameters. Oracle replacement Some Safenet rules are immutable within a deployed Oracle contract. Changing them requires deploying and activating a new Oracle. This includes changes to:

• Immutable protocol logic.
• Fixed Sentinel incentive mechanics.
• The Oracle’s Governance address.
• The Safenet Security Council address.

Changing the Safenet Security Council Safe’s members or signature threshold does not require an Oracle upgrade. An Oracle upgrade is required only when the Security Council Safe address itself changes. Only one Oracle is canonical at a time. SafeDAO controls which one through the oracle.safenet-gov.eth ENS record on Ethereum Mainnet. The record identifies the canonical Oracle contract on Gnosis Chain and the activation epoch for a new Oracle version. Validators must adopt the new Oracle configuration for that epoch. Safenet uses a two-week transition period for Validator adoption. At least two-thirds of Validators must adopt the new Oracle version, and Validators that do not update within the transition period lose rewards. Participant sets SafeDAO governs the Sentinel and Validator sets. The Sentinel set is configured in the Oracle on Gnosis Chain. The Validator set is recorded in the Staking contract on Ethereum Mainnet. The initial participant sets are approved through SafeDAO governance. Later additions and removals follow the applicable governance process. See Participant selection for how Sentinels and Validators are proposed, approved, added, and removed.