Skip to documentation
Resources/Docs
DevelopersSinjoh v2

Governance & security boundaries

Immediate Safe powers, creator/service separation and the protections that remain economic invariants.

3 min read·
On this page

Any current Safe; immediate execution

The four team-controlled Safes are named Fee, Operator, Replacer and Veto. In the current deployment each has the same administrative authority: any one current Safe can execute an administrative action immediately. There is no protocol timelock, role-specific permission split or second-Safe confirmation requirement. Each Safe’s own configured signer threshold still applies.

perform(power, args) validates and executes a governance power in one transaction. act handles immediate restrictions/pause/path-disable operations. Optional schedule/propose/execute interfaces retain compatibility but do not introduce a minimum wait. Prepared-operation windows and migration deadlines are expiry rules.

Authority reference

ActorBoundary
Current team SafeFeeds, paths, hook/version approvals, keeper/attester/randomness settings, pauses, Safe/creator replacements, treasury administration, platform routing and migration approval.
Current creatorBounded rate reductions/static switch, metadata, ordinary creator route/reward settings, fee destination and voluntary succession.
Approved keeperRestricted automation execution under existing configuration; no power to invent recipients or alter governance settings.
Attester / proverPost bounded closed-round commitments / provide verifiable randomness under their assigned roles.
Trader / holderWallet-authorized trades and applicable permissionless payment/retry calls.
DeployerNo continuing administrative authority merely from creating the contracts.

Replacements and immutable market identity

Replacing a Safe revokes the old address’s current-Safe authority immediately. Pending operations use their recorded roles/epochs for cancellation semantics. Compatible hook approval is add-only; retiring a hook blocks new launches through it without rewriting existing pools.

The system uses immutable service/contract connections for this release rather than a general-purpose market upgrade proxy. New deployments need explicit manifests and consumer wiring. Profiles and application data are separate from protocol contract state.

Economic validations remain

  • Protected floor backing is outside spendable treasury powers.
  • A credit belongs to its market/round/asset and cannot be paid twice.
  • Trade limits, deadlines and exact-output settlement are enforced.
  • Actual transfer receipt and supported token behavior matter; a matching interface name is insufficient.
  • A failed action preserves its original allocation and does not create fictitious successful output.

Application and signing boundaries

Profile data is authenticated server-side, while wallet transaction authorization remains a separate wallet action. Linking a sign-in account is not a token transfer or approval. Integrators must bind chain, wallet, spender, amount and transaction to one quote and must not expose server/provider signing material in public responses.