Across Governance Operating Manual

WELCOME đź‘‹
1

Overview

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.

Governance Components

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.

Governance Toolkit:

  • 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.

Governance Participants:

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

Across Council - The Council executes approved Snapshot proposals prior to the implementation of optimistic governance. The current signers are Risk Labs representatives.

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.

Proposal Types:

  • 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%
Committee implementation, removal, or replacement A vote to introduce a new committee or replace an existing committee Forum + Snapshot 7 days + time required for steps 1 and 2 in voting cycle 6M Yes 51%

Soft Quorum
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.

Composing Committee Proposals:

This proposal type should include the following components in addition to those required in the current proposal template:

  • Purpose of the committee. What is the value added for Across?
  • Scope of the committee. What work will they be responsible for?
  • Reporting requirements and frequency. How can tokenholders assess the quality of work done by the committee? What time interval is appropriate for their job?
  • Intended lifespan of the committee. Is this a special purpose committee, or will it fulfill a role that the protocol needs continuous support on?
  • Composition of the committee. Include a link to bio of each member and outline their participation in Across up until now. Share any relevant experiences or qualifications they have. At minimum we’d like to see discord handle, twitter handle, an Across active wallet, and a bio for each member.
  • Starting monthly budget breakdown. Committees may manage a small amount of capital to meet the needs of their operational purpose. If applicable, include information about the address that is intended to be used for operational funds. This budget does not include committee compensation. Committees will receive their budgeted funds at the start of each month from the Across DAO Treasury. Whenever possible, this amount should be limited to 1 month of operating expenses at a time.
  • Brief overview of committee operations (general workflow, communication channels, expected outputs, etc.)
  • If the proposal is to remove or replace a committee, it should still address the above components.

Committee - tokenholder relationship:

By voting to form a committee, tokenholders are voting to entrust and delegate a specific set of decision-making responsibilities to the committee. It is, therefore, ACX tokenholders that each committee is accountable to. If a committee fails to perform, it is the duty of ACX tokenholders to replace or remove the committee from service in a reasonable amount of time.

Committee Membership:

Committees should include no more than 5 and no fewer than 3 members, each of which should have relevant experience and/or qualifications to support their presence in the committee. It is recommended to designate a committee lead, who would be held responsible for the coordination and reporting on behalf of the committee.

All committees are compensated by the Across DAO Treasury in the same way. Upon approval, a committee will receive a base level of rewards in the amount of $10k equivalent in $ACX. This amount is meant to last for a 3-month period. It is up to each committee to determine the distribution of these tokens, the details of which must be included in the snapshot vote. This should include wallet addresses and amounts for each committee member.

At the end of each quarter of service, a committee will be given an additional $10k equivalent in $ACX, except in the case of a committee being removed from service by tokenholders during that quarter, in which case there will be no additional rewards. The distribution of these funds will be determined by the committee members by way of a peer review score. This is to be paid out by the Across DAO Treasury.

Committees that are composed of Risk Labs representatives will not receive compensation from the DAO.

Note: the peer review process will be found in more detail in a new “committee” section of the forum after this proposal is passed. The template for peer review (TBD) should be evaluated regularly and updated as needed to meet the needs of committee participants. Because this process only effects the distribution of funds amongst committee members and does not change the amount of funds designated to a committee, this template can be updated whenever there is a soft consensus that it’s necessary (no formal vote required).

Committee Tools:

  • Discord - to be used for general communication between committees and tokenholders.
  • Forum - to be used for more formal committee reporting, and committee peer reviews.

Process

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.

Header

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)

Body

Summary:
Give us a TL;DR on your proposal; no more than 2-3 sentences.

Motivation:
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?

Rationale:
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?

Downside (Cons):
Are there any disadvantages with implementing the proposal? Are there any security considerations or potentially negative financial exposures to consider?

Voting:
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.

Starting Parameters:
Collateral: WETH
Bond: 10
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.

6 Likes