Skip to main content

Governance

OMY governance has two phases. Phase 1 launches with a committee multisig because token-based governance is unsafe when the governance token has no measurable value (an attacker can cheaply acquire a majority and attack the oracle). Phase 2 transitions to stake-weighted commit-reveal voting in $OMY once the token has real value backed by protocol revenue.

The interface between the oracle and the resolver is stable across phases. Consumer contracts don't need to change anything when the resolver upgrades.

Phase 1 — Committee multisig​

The committee is M-of-N trusted signers — typically 3 to 5 reputable TON-ecosystem actors. When an assertion is disputed, the assertion sends OpenVote to the resolver address registered at deploy time. The committee signers cast votes; once threshold M is reached, the resolver sends Resolve back to the assertion with the final answer.

Properties:

  • Fast settlement — usually a few hours from dispute to resolve
  • Low operational overhead — no token, no slashing, no commit-reveal
  • Centralized — depends on signer set being honest and available
  • Appropriate for low-to-moderate TVL — until TVL grows enough that a malicious M-of-N becomes economically rational

Operations:

  • Signer set is updatable via owner — adding / removing signers, rotating keys
  • Threshold is updatable via owner — can raise to require larger consensus as TVL grows

The committee model is intentionally temporary. It's the safest possible launch posture — small attack surface, well-understood mechanism — and it buys time to grow $OMY to a value that supports the Phase 2 model.

Phase 2 — $OMY DVM (Data Verification Mechanism)​

The Phase 2 resolver is a stake-weighted commit-reveal voting contract. Anyone can stake $OMY to participate; on a dispute, stakers commit a vote (hashed) in one window and reveal in the next. The winning side is rewarded from the losing side's slashed stake.

The mechanism design (essentially the proven UMA DVM pattern, ported to TON):

import {DocFeatures, DocFeature} from '@site/src/components/docs/DocFeatures';

Vote weight = amount of $OMY locked at commit time. Cannot inflate weight post-commit. Vote hash committed in window 1; plaintext revealed in window 2. Prevents last-mover advantage. Slashed losers fund rewarded winners exactly. No protocol surplus on settled votes. Stakers who commit but don't reveal are slashed. Tracked as "surplus"; swept by governance. If quorum isn't met, the case reopens for a new round. Capped at 3 rounds to prevent indefinite stalls. If 3 rounds fail, anyone can abandon the case so locked stakes become claimable. Assertion falls back to TimeoutRefund.

Why stake-weighted voting works (the Schelling argument):

Honest voters expect every other honest voter to vote with the obvious truth. Voting WITH the majority earns a reward; voting AGAINST is slashed. Attacking the vote requires buying enough $OMY to be the new majority — which is both expensive (token supply is finite) and self-defeating (the token's price crashes when it gets used to attack the oracle that backs it).

When Phase 2 launches​

The Phase 2 resolver is already implemented and tested in the codebase — the StakeVoteResolver contract. What's pending is launching the $OMY token itself, which we gate on real traction:

  • ≥ $1M cumulative settled volume
  • ≥ 100 unique users
  • ≥ 3 external integrations (consumers other than our reference Market)
  • ≥ $50k / year proven fee revenue routed to treasury

Without those metrics, a token launch is a memecoin event and the price doesn't reflect protocol value — defeating the security model. We refuse to launch on speculation.

The governance switch​

When Phase 2 activates, OracleFactory.UpdateMonetization is called by the owner to point treasuryAddress from the Phase-1 multisig to a RewardsDistributor contract. The RewardsDistributor splits all incoming treasury fees 50/50 between:

  • The protocol treasury (for operational expenses, audits, infrastructure)
  • Staked $OMY holders, pro-rata to staked weight, distributed weekly

This single config change flips the entire fee economy without redeploying any assertions. Already-deployed assertions snapshot their Config at spawn time and are unaffected. Only NEW assertions inherit the new treasury target.

Permissions today​

RoleHolderPowers
OracleFactory ownerMultisig at launchUpdateMonetization, retry-wallet, no ability to alter live assertions
CommitteeResolver ownerMultisig at launchAddSigner, RemoveSigner, SetThreshold
Committee signersPhase 1 trusted setCast votes on disputed assertions
Asserters / DisputersAnyonePost bonds, propose/dispute on any open assertion

In Phase 2, vote rights migrate from committee signers to $OMY stakers. The committee resolver stays deployed for backward compatibility — consumers that explicitly bound it as their resolver continue to use it — but new consumers default to the DVM.

What we explicitly do NOT do​

  • Upgradeable contracts. No SetCode action. Bug fixes ship as v2 contracts at new addresses. The trade-off: no governance footgun for altering protocol behavior on live state.
  • Emergency pause. No admin can stop a live assertion mid-flight. The only escape from a stuck dispute is the TimeoutRefund mechanism, which is permissionless after the arbitration window.
  • Fee redirection mid-flight. UpdateMonetization affects only NEW assertions. An assertion's fee + treasury are snapshotted into its immutable Config at spawn time.

Where next​