The Across governance process will evolve to meet the needs of Across DAO as it grows, and this is a living document. Anyone can participate in the Across Governance process, and anyone with ACX voting power can vote on proposals.
Presently, tokenholders control treasury spending and updates to governance.
The Across Governance process follows the pathway from ideation, to draft, to proposal, to implementation. Anything subject to governance will follow this path and be decided on by ACX tokenholders.
- Forum: A platform for discussion and deliberation on governance proposals
- Snapshot: A platform for where all governance proposals are submitted for vote
- oSnap: a mechanism for trustless execution of snapshot votes. You can view our deployment of oSnap here.
Voters - anyone who holds ACX, or ACX representative tokens that hold voting power, and participates actively in governance. See list below for voting eligible tokens
- ACX (eth) = 1 vote
- Av2-ACX-LP = 1 vote
- ACX tokens that have been provided as bridging liquidity within Across Protocol
- Address: 0xb0C8fEf534223B891D4A430e49537143829c4817
- ACX ST = 1 vote
- ACX Success tokens. Min payout of 1 ACX, max payout of 2 ACX
- Address: 0x4CBD49FCB56bBd06658103ab9fB3Ae0fAfFe365A
- Staked ACX LP = 1 vote
- Staked ACX LP tokens within Across.
- multiplied by current exchange rate of ACX-LP to ACX
- Staked ACX Rewards
- Unclaimed rewards accrued for all staked LP tokens within Across.
- Custom strategy for staked voting can be seen here.
Across Council - The Council executes approved Snapshot proposals prior to the implementation of optimistic governance. The current signers are Risk Labs representatives.
Across DAO Ethereum Safe: 0xB524735356985D2f267FA010D681f061DfF03715
Across DAO Optimism Safe: 0xfd0CF79C568c08b78484F2D165eB8c7f569BdCf9
Across DAO Arbitrum Safe: 0xd16D904b68429b93F1DFCD837F61AeDCd224e8F4
Across DAO Polygon Safe: 0x5BCBeBAFb2934400525FA53CF74f26Fe4cf75A5B
- Signers (same addresses on each chain):
- Signers (same addresses on each chain):
Committees - Subject matter experts that consider and pursue goals specific to their domain, acting in the best interests of the Across DAO. Committees are able to make updates to parameters without the need for a full tokenholder voting cycle, allowing the bridge to remain adaptive. Shortly after launch, RL will upgrade the protocol to allow for committee implementation.
- Treasury Funding
- Governance Updates
- Committee implementation or replacement (future)
- Protocol upgrades (future)
|Type||Description||Submission requirements||Vote Duration||Quorum||Soft Quorum||Approval Threshold|
|Treasury Funding - Large||Treasury distributions to proactively encourage the growth and development of the Across ecosystem valued at $150,000 or higher||Forum + Snapshot||7 days + time required for steps 1 and 2 in voting cycle||6M||No||66%|
|Treasury Funding - Medium||Treasury distributions to proactively encourage the growth and development of the Across ecosystem valued between $50,000 - $150,000||Forum + Snapshot||7 days + time required for steps 1 and 2 in voting cycle||6M||No||51%|
|Treasury Funding - Small||Treasury distributions to proactively encourage the growth and development of the Across ecosystem valued below $50,000||Forum + Snapshot||7 days + time required for steps 1 and 2 in voting cycle||6M||Yes||51%|
|Governance Updates||A vote to update a component of Across governance system.||Forum + Snapshot||7 days + time required for steps 1 and 2 in voting cycle||6M||Yes||51%|
For votes that do not reach Quorum, assume that 70% of the votes necessary to achieve quorum would be against the proposal. If this would still result in a majority of votes being in favor of the proposal, the proposal can be considered passed. Not all proposal types are eligible for soft quorum (see table above). This Soft Quorum Calculator can be used to evaluate how a proposal would resolve under these rules.
Note: Risk Labs has historically acted as the only builder of Across Protocol. In order to enable others to contribute at a protocol level, we are in the process of outlining the protocol parameters and requirements for a protocol upgrade template. Stay tuned for more details.
Step 1: Request for comment (Forum)
Post a proposal draft in Ideas and Feedback in Forum. Collect feedback from the community and update the proposal as needed. There is no hard timeline on this step, but proposals that don’t take this step seriously are not likely to pass. Once your idea is ready to submit as a proposal, it will need to follow the template below, so you should consider drafting your idea in this format to start. You can also find this template here.
Title: (enter proposal title)
Author(s): (enter name(s) of associated authors)
Status: (RFC, Proposal, Vote)
Related Discussions: (optional - paste link here)
Submission Date: (Enter Date)
Give us a TL;DR on your proposal; no more than 2-3 sentences.
What problems will this proposal address/solve? What’s the value-add?
Specification & Implementation:
Describe the proposal in as much detail as is necessary. Explain the vision for the proposal. How will this affect the protocol both technically, socially, financially (if applicable), and governance-wise? What steps need to be taken to implement this proposal?
Explain any decisions above that were chosen over an alternative. Why is this the best way to do it? How will the implementation of this proposal advance the protocol?
Are there any disadvantages with implementing the proposal? Are there any security considerations or potentially negative financial exposures to consider?
Define what a “yes” and “no” vote entails. Once the proposal moves to a vote, please include the link to Snapshot here.
Step 2: Request to proceed (Forum)
After implementing any changes to the proposal based on feedback received in step 1, you should present a final draft in the Proposal section of forum and request to proceed to snapshot. If applicable, you should include the appropriate tag for your proposal when creating your post. You will also want to make sure to include a link to your discussion draft in the final proposal.
Any Forum admin can review the proposal for format compliance and provide an indication that the proposal can move to snapshot. This is not an indication of support for the ideas in the proposal, but rather an indication that the proposal meets the requirements needed to move to a vote. Proposals that are not properly formatted should not move to a formal vote.
Step 3: Formal vote (Snapshot)
Proposals that have been approved in step 2 are ready to be voted on and may be posted to snapshot with a 7 day voting period. A proposer must have a voting weight of at least 20,000 ACX in order to submit a proposal. If you do not meet the requirement for submitting a proposal, a qualified voter may post the proposal on your behalf if they wish to do so.
Step 4: Results
If a proposal passes Snapshot, it will be executed by the Across DAO Safe. Across uses a governance solution called oSnap to optimistically execute the on-chain results of passing Snapshot votes. At this time that includes Treasury funding proposals. Protocol upgrades are still handled by the Across Council mentioned above.
Summary of oSnap implementation:
oSnap is a Snapshot plugin built by the UMA team that will allow anyone to propose transactions, do an off-chain governance vote, and have the transaction data submitted in a trustless fashion. After a transaction execution is proposed, it must pass through a liveness period, during which time anyone may dispute its validity. Risk Labs has set up a robust combination of monitoring tools to alert in several locations whenever an execution transaction is proposed. This includes both the UMA and Across discords, the Optimistic Oracle UI, and Risk Labs internal alert channels. In the event that a proposal is disputed, it will escalate to UMA’s DVM for settlement by $UMA tokenholders, which will use human-readable rules to determine the validity of the proposed transaction. Across has opted to deploy oSnap using conservative parameters to start, which can be adjusted over time through governance.
Liveness: 5 days
Snapshot space: Snapshot
Voting quorum: 6,000,000
Voting period: 168 hours
Rules Parameter (human-readable rules):
I assert that this transaction proposal is valid according to the following rules: Proposals approved on Snapshot, as verified at Snapshot, are valid as long as there is a minimum quorum of 6000000 and a minimum voting period of 168 hours and it does not appear that the Snapshot voting system is being exploited or is otherwise unavailable. The quorum and voting period are minimum requirements for a proposal to be valid. Quorum and voting period values set for a specific proposal in Snapshot should be used if they are more strict than the rules parameter. The explanation included with the on-chain proposal must be the unique IPFS identifier for the specific Snapshot proposal that was approved or a unique identifier for a proposal in an alternative voting system approved by DAO social consensus if Snapshot is being exploited or is otherwise unavailable.
Across’ deployment of oSnap can be viewed on-chain here.