Skip to main content

Governance Process

Current Phase: Shadow Mainnet Testing

Multyr contracts are deployed on Arbitrum One. The system is currently in validation phase. Deposits are not open to the public. Behavior described on this page reflects the protocol's designed behavior; some mechanisms are active in shadow testing, others become active at public launch. See the Status page for details.

This page describes the lifecycle of a governance action in Multyr.

Step 1 — Proposal​

A governance action begins when SAFE_GOV (3/5 multisig) schedules a transaction through the root timelock.

The scheduled transaction includes:

  • target contract
  • function call
  • parameters
  • execution delay

Once scheduled, the action becomes publicly visible on-chain.

Step 2 — Timelock Delay​

The transaction enters a mandatory delay period.

  • Duration: 48 hours
  • Visibility: fully public on-chain
  • Effect: no execution can occur before the delay expires

This delay cannot be bypassed.

Step 3 — Veto Window​

During the timelock period, SAFE_VETO (1/1 multisig) may cancel the pending action.

This provides protection against:

  • incorrect proposals
  • compromised transactions
  • newly identified risks

Cancellation is immediate and irreversible.

Step 4 — Execution​

After the timelock expires, SAFE_GOV may execute the transaction.

For certain vault-level parameters, an additional internal delay applies before the new value becomes active.

Step 5 — Activation​

After execution:

  • some changes take effect immediately
  • certain vault-level parameters become active only after the internal delay expires

This creates a second protection layer for parameter changes affecting system behavior.

Summary Flow​

schedule → timelock delay → optional veto → execute → activation

What Governance May Change​

Governance actions may include:

  • strategy onboarding or removal
  • fee parameter updates
  • router or buffer configuration changes
  • role updates
  • recovery actions after emergency states

What Governance Does Not Bypass​

Governance does not bypass:

  • mandatory timelock delays
  • internal parameter activation delays
  • immutable deployment constraints

All governance actions follow the same public and delayed process.