> For the complete documentation index, see [llms.txt](https://docs.originprotocol.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.originprotocol.com/ogn/governance.md). # Governance ### Principals Origin Protocol is developed and maintained by Origin Protocol Labs, a legal entity incorporated in the Cayman Islands. Origin Protocol Labs serves as a core contributor and operational steward of the protocol, acting in accordance with the direction of xOGN governance. Protocol upgrades, parameter changes, and strategy approvals are subject to the governance processes described below. Origin products operate as decentralized protocols governed by a distributed set of stakeholders. Yield generation, fee collection, and fee distribution are executed entirely through smart contracts. Upgrades to these contracts pass through a timelock and can only be initiated through governance controlled by xOGN holders. Although the initial contracts and strategies were developed by the Origin team, protocol evolution is open to the broader community. Governance participants can propose parameter changes, introduce new strategies, contribute code, or vote on active proposals. The expectation is that major decisions are made collectively, while limited day-to-day responsibilities may be delegated to trusted contributors who maintain the protocol’s operations. Governance proposals require participation from at least 20% of the xOGN supply to reach quorum. There is no minimum requirement to cast a vote on existing proposals. All approved proposals are executed only after passing through a timelock, ensuring a delay between approval and implementation. This delay provides transparency and allows users to exit positions if a proposal introduces changes they deem unfavorable. ### **Proposal lifecycle** Changes to Origin’s smart contracts require onchain proposals to be created, approved, and executed by governance token holders. All pending and historical onchain proposals are visible on the governance page of the [Origin Dapp](https://app.originprotocol.com/). Initiating this type of formal, binding proposal requires technical skills and knowledge of the protocol’s code. Onchain proposals also involve transaction costs (gas fees) necessary to update the state of the blockchain. As a result, most proposals go through an informal, off-chain process occurring on the [Origin Protocol Snapshot Space](https://snapshot.org/#/origingov.eth). Snapshot enables any eligible governance token holder to create a proposal or vote at no cost. This also reduces the complexity and expense required to make a proposal and allows for the community to signal its approval or opposition to a given change. We encourage everyone to propose improvements at any time. To help stay up to date on Snapshot proposals, you can enable email notifications by visiting [Snapshot V1](https://v1.snapshot.box/#/), clicking on your username, and adding an email. It’s natural for proposals to be accompanied by healthy debate or discussion regarding implementation, reasoning, methodology, etc. Discussions regarding new proposals now start in the [Origin Governance Forum](https://governance.originprotocol.com/) and are cross-posted to [Origin's Discord server](https://originprotocol.com/discord). ### **Timelock Contract** All approved proposals execute onchain through a timelock that enforces a mandatory 2-day delay (172,800 seconds) between governance approval and implementation. This window gives any user time to review an approved change and take action before upgrades take effect. **Contract address (Ethereum):** 0x35918cDE7233F2dD33fA41ae3Cb6aE0e42E0e69F The Ethereum Timelock uses role-based access control. The GovernorSix contract holds the proposer and executor roles, allowing it to schedule proposals approved by xOGN governance and execute them after the mandatory 48-hour delay. GovernorSix and the 5-of-8 Admin multisig hold the canceller role, allowing either to cancel scheduled operations. Holding both proposer and executor roles does not bypass the delay. ## **Participating In Governance** Snapshot is Origin's off-chain, gas-free signaling venue, and it's where nearly every governance proposal starts. Here's how to participate in Snapshot governance: 1. Obtain OGN from a centralized exchange (Coinbase, Binance) or a decentralized exchange (Uniswap, Curve). 2. Stake OGN for xOGN using the [Origin Dapp.](https://app.originprotocol.com/#/ogn/staking) xOGN is what grants voting power; the longer you stake, the more voting power is allotted per OGN staked. 3. Submit and discuss your proposal on the [Origin Governance Forum](https://governance.originprotocol.com/), and share it in the #governance channel on Origin's [Discord server](https://originprotocol.com/discord) for visibility. 1–4 weeks of discussion is typical before moving forward. 4. Submit the proposal on [Snapshot](https://snapshot.org/#/origingov.eth) for a signaling vote. Creating a Snapshot proposal requires at least 25,000 xOGN; voting on an existing one has no minimum. 5. Cast your vote, or delegate your voting power to another Ethereum address if you'd rather not vote directly yourself. Feel free to use one of the [templates](/resources/governance-templates.md) as a guide when writing a proposal. ### Onchain Governance Process Once a proposal has clear community support on Snapshot, it can move to a binding onchain vote. Onchain proposals are formal, require gas fees to submit, and execute directly against Origin's smart contracts. 1. Hold at least 250,000 xOGN, then submit the proposal onchain through the governance contract: 0x1D3Fbd4d129Ddd2372EA85c5Fa00b2682081c9EC. 2. Voting opens 24 hours after the proposal is created, giving holders time to acquire tokens or delegate votes before the window begins. 3. The voting period runs for 14,416 blocks, approximately 48 hours. Quorum requires For votes representing at least 20% of the xOGN supply at the proposal snapshot. If quorum is first reached with fewer than 7,208 blocks remaining, the deadline extends to leave 7,208 blocks—approximately 24 hours—from that point, giving the community time to respond. 4. If the proposal passes and quorum is reached, it needs to be queued in the Timelock contract. 5. After the 48-hour Timelock delay has passed, the proposal can be executed onchain. ### Parameters High-level criteria are required to vote and make proposals: Hold sufficient xOGN tokens (Staked Origin Tokens) * No minimum to vote on existing proposals * 25,000 xOGN to create a Snapshot proposal * 250,000 xOGN to create an onchain proposal (Note, you have the option to delegate your votes to another Ethereum wallet.) #### Here are the parameters currently configured on the governance contract: | Name | Value | Description | | --------------------- | ------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Voting delay | 7,200 blocks (24 hours) | How soon the voting period begins following the submission of a proposal - can be used to enforce a delay after a proposal is published for users to buy tokens, or delegate their votes | | Voting period | 14,416 blocks (48 hours) | The window of time for votes to be cast following the end of the voting delay | | Proposal threshold | 250,000 xOGN | The minimum number of tokens required for an account to be eligible to submit a proposal | | Quorum | 20% of xOGN supply | The minimum number of votes needed for a proposal to succeed (assuming a majority of them are in support of the proposal) | | Late quorum extension | 7,208 blocks (1 day) | The amount of time required to pass from when a proposal reaches quorum until its voting period ends | | Timelock delay | 172,800 seconds (2 days) | The minimum amount of time required after the end of the voting period before a proposal can be executed and take effect | ## Guardians Guardian multisigs can act without a timelock delay for time-sensitive operations: depositing and withdrawing from strategies, adjusting vault buffers, pausing deposits and redeems, and managing rebasing. These functions require the multisig threshold but not a governance vote or timelock period. The Guardian multi-sig can perform the following actions on supported vaults: * `depositToStrategy` — deposit Vault assets into an approved strategy. * `withdrawFromStrategy` — withdraw assets from an approved strategy back to the Vault. * `setVaultBuffer` — set the target proportion of assets retained in the Vault. * `setDefaultStrategy` — set the approved strategy used for automatic allocation. * `withdrawAllFromStrategy` — call an approved strategy’s full-withdrawal function to return available assets to the Vault. * `withdrawAllFromStrategies` — call the full-withdrawal functions of all approved strategies. * `pauseRebase` — pause yield distribution through rebasing. * `unpauseRebase` — resume rebasing. * `pauseCapital` — pause minting, withdrawal requests and claims, automatic allocation, and strategy mint/burn operations. This does not block privileged manual deposits into or withdrawals from strategies. * `unpauseCapital` — resume those capital operations. * `rebase` — account for accrued yield and distribute it through an increase in OToken supply, subject to the configured limits. The configured operator and governor can also call this function. * `setRebaseRateMax` — set the maximum yield-distribution rate, within the contract’s hard limit. * `setDripDuration` — set the target duration used to smooth yield distribution. These permissions do not authorize the Guardian to upgrade Vault contracts or approve new strategies. ### Governance & Guardian Addresses
RoleChainAddressConfiguration
AdminEthereum0xbe2AB3d3d8F6a32b96414ebbd865dBD276d3d8995-of-8 Safe
AdminBase/HyperEVM0x92A19381444A001d62cE67BaFF066fA1111d72025-of-8 Safe
AdminSonic0xAdDEA7933Db7d83855786EB43a238111C69B00b65-of-8 Safe
AdminArbitrum0xfD1383fb4eE74ED9D83F2cbC67507bA6Eac2896a5-of-8 Safe
GuardianMultichain0x4FF1b9D9ba8558F5EAfCec096318eA0d8b5419712-of-8 Safe
GuardianArbitrum0xfD1383fb4eE74ED9D83F2cbC67507bA6Eac2896a5-of-8 Safe
GuardianSonic0x63cdd3072F25664eeC6FAEFf6dAeB668Ea4de94a2-of-8 Safe