Summary
Recently, the Orca team announced their intention to further decentralize the protocol by transitioning control to the community. Doing so would empower the community with ownership of the protocol and open up the development process to outside contributors.
We’ve thought a lot about this process at Reverie. This post is an attempt to share an idea for how Orca could engage in the decentralization process and start a discussion on the topic to get feedback from both the community and the core team.
Traditional DAO structures, managed through tokenholder voting, tend to move slowly. For Orca to keep growing, the protocol will need a better system that enables speedy product upgrades. Shipping upgrades quickly will help Orca remain competitive as a leading AMM. We think that this structure will allow for quicker upgrade deployment while maintaining community ownership.
The core idea entails tokenholders electing a Council of qualified individuals and delegating to the Council the ability to make proposals on behalf of, and in parallel with, tokenholders. This will not limit the ability for tokenholders to propose changes through voting. Instead, it will strengthen Orca’s position in the ecosystem through a broader range of perspectives and speedier decision-making.
In short, if the community is in favor of implementing this idea, both the Council and tokenholders will be able to make proposals to improve Orca.
Description
As mentioned in a prior blog post, the team plans to hand over control of the underlying Orca protocol to the community. While there are many ways to do this, we think the easiest, fastest, and most practical way to do this would be to form a Council of trusted individuals.
As part of this process, the tokenholders would elect a governance Council that would operate on behalf of, and in parallel with, the community in maintaining the protocol. We think this model is an improvement over the status quo of governance only by tokenholders — in our experience, most tokenholders are passive; to rely on them to rapidly iterate/upgrade the protocol is to put scaffolding on a construction site with no workers. Nothing gets built!
Once the Council is elected, the protocol would mint one Council Token per member. Holding a Council Token enables a member to make and vote on Council Proposals (1 token = 1 vote). Council Proposals would require a quorum of 4/7 votes in order to pass. This would allow the protocol to be efficiently upgraded when necessary, supplementing the usual tokenholder voting process, which would remain available.
In addition, the change in contract ownership would also mean that Orca’s development is no longer limited to the existing core team. Outside parties would now be able to contribute to the protocol’s growth and push upgrades.
Under this model, the existing development team could become one of multiple teams helping to build Orca. The Council would be responsible for finding and managing the right development teams to help the protocol grow. Moreover, to attract and retain the best-in-class talent, the Council would also be able to propose allocating a portion of ORCA from the Treasury to compensate these outside parties for their development work.
While the Council will help expedite decision-making, we’d like to stress that the community would continue to retain ultimate control of the protocol. Tokenholders’ ability to make proposals will remain unchanged; they will also have veto power over Council proposals, the ability to elect the Council, and finally, be able to remove a Council member at any time.
Motivation
It’s important to us that the community knows that Reverie is a tokenholder and advisor to Orca. We previously worked with the team to design the Governance v0 framework. In doing so, we developed a strong understanding of the protocol. We are leveraging that understanding to put forward this proposal.
As part of our mission to help DAOs grow, Reverie has participated in and created governance proposals across different organizational structures. We learned a lot along the way.
We know from experience that community-led proposals tend to be slow and inefficient. Low engagement can make it difficult to gather the support and votes needed to pass a proposal, so even popular proposals can fail to pass.
Having observed and studied these pitfalls on many other protocols, we believe the Council model described above best equips the community to carry out the efficient upgrades needed to continue developing the best product in a competitive market.
For sake of clarity, we’d like to emphasize that under this approach, control of the protocol remains with the ORCA community. For every proposal, the community will hold veto power over Council actions prior to execution, securing the protocol from any actions inconsistent with the community’s wishes. The community will also have the ability to propose removing Council members and electing new members. Through this system, the Council ultimately reports to the community and is held constantly accountable by ORCA tokenholders.
The Council will be tasked with holding the appointed development teams accountable.
In short, this governance system empowers the community of ORCA tokenholders with control while giving the Orca protocol ability to grow rapidly.
Specification
Contract Changes
The table below outlines all core contracts that we think can be transitioned to community ownership. We’ll need the team to confirm the accuracy and completeness of the table below, but from our analysis of existing contracts, the below table shows all of the contracts that the team would need to transfer to the community.
Term definitions and the contract table are displayed below:
Tokenholders: All ORCA tokenholders must vote on a proposal to execute the functions using standard Proposal thresholds (100,000 ORCA proposal and 500,000 ORCA passing).
Council: Council members can vote on a Council Proposal to execute a subset of proposals using their Council Token. 1 Council Token = 1 vote, and a 4/7 quorum is needed to pass. ORCA tokenholders do not participate in the voting process for Council Proposals, but can Veto any Council Proposal prior to execution. The Veto process is outlined in the Proposals section below.
| Contract/Account | Functions | Control |
|---|---|---|
| Orca Treasury | Own Funds and Spending (e.g. Diversification) | Council, Tokenholders |
| Impact Fund | Own Funds and Spending (e.g. Charitable Donation) | Council, Tokenholders |
| Orcanaut Royalties | Own Funds and Spending (e.g. Charitable Donation) | Council, Tokenholders |
| Pools / Whirlpools | Token/Pool Whitelisting | Council, Tokenholders |
| Pools / Whirlpools | Rewards and Fee Rates assignment | Council, Tokenholders |
| ORCA Token | Ownership of ORCA token program | Tokenholders |
| Council Token | Ownership of Council token program | Tokenholders |
| Council Token | Assign/Revoke Council members | Tokenholders |
Council
The Council will follow the initial structure outlined in the table below:
| Item | Value |
|---|---|
| Total Members | 7 |
| Proposal Quorum | 4 of 7 Yes votes |
| Compensation | $50,000 USDC-SPL per year |
| ORCA Grant | $15,000 ORCA, 1 year cliff |
| Term Length | 12 months |
| Early Resignation | 3 months notice |
Proposals
Anyone on the Council can submit a Council Proposal, which is voted on exclusively by Council members. Council Proposals are limited to functions in which the “Control” column in the above Contract Changes table includes the Council. All proposals will be shared with the community ahead of voting to socialize planned changes. We advise a 4 day minimum advance notice.
Once a proposal has been passed by the Council, a two-day ratification period will be enforced within which the community can submit a Veto proposal. The Veto proposal, if passed, will block the execution of the Council proposal, resulting in a proposal failure. This veto power gives the community of ORCA tokenholders final say on all council proposals. Veto proposals will be subject to standard proposal quorums.
Elections
If the community favors the Council model, elections would be held shortly following the passing of this proposal to determine the initial 7 members. At the end of their term, the community will need to re-elect the existing Council or elect new members through a governance vote.
- Re-Election
If the existing member wishes to stay, they can submit a Council proposal for re-election. All other Council members will need to vote Yes for this to pass. The community can veto the decision with a governance vote.
- Election
If a member chooses to leave, or the community voted against re-election, new candidates will need to submit applications for Council membership. A proposal will then be required to formally initiate a vote on that candidate. Creating this proposal requires the usual minimum threshold of ORCA tokens, which can come either from the candidate themselves or from other community members.
After that, the actual election vote will follow the same rules as any other proposal
Member Resignation/Removal
During a Council term, a member may be removed from the Council through these methods:
- Resignation
In the event of resignation, the member will remain on the Council for 3 months to allow the community to find a new Council member. The Council will take the voice of the community into account to identify a suitable candidate and submit a replacement proposal.
- Community Removal
The community may submit a proposal to remove an active member of the Council. To avoid too much churn in Council members, Council removal proposals would have higher passing thresholds (standard being 0.5%), requiring 2.5% of the total ORCA supply in Yes votes to be executed.
- Council Removal
Council members may also submit a proposal to remove an active member. If this Council proposal passes (the other 6/7 vote Yes), a community proposal will be made. The member is removed if the community passes its proposal. Again, the community proposal will require 2.5% of the total ORCA supply in Yes votes to be executed.
Once removed, a new member will be elected through a community proposal.
Accountability
Holding others accountable in a decentralized governance space is difficult. The lack of structure often leads to inefficiencies that can go unchecked. The Council structure will need to function in a transparent environment that allows the community to assess its performance. To that end, we propose starting off with an in-depth quarterly report shared with the community to break down all Council progress and protocol developments. This would include both aggregate summaries of actions taken and data on the participation of each council member, including meeting participation and proposal / voting history.
This will be an iterative process of accountability. We fully expect different measures to evolve as the Council and community grow.
Distributed Development
Assigning control of Orca contracts to the governance program will mean the existing core team will no longer be solely responsible for the development of Orca. Instead, growth and development can be pursued in a distributed manner.
The Council will be responsible for recruiting these third parties to ensure the protocol receives timely maintenance and continues to grow. Contributing teams will report to the Council with quarterly reports, through which the Council will measure performance and respond accordingly. Subsequent actions could include hiring replacement teams, offering grants, or increasing/decreasing compensation. The Council will enact protocol upgrades as built by the developing team via community-approved Council proposals.
Given their strong backgrounds and success developing Orca into one of the leading protocols on Solana, we believe the current core team remains highly qualified to continue contributing to the protocol.
Therefore, we recommend that the Council continue engaging the current core team as one of the initial development teams. One early responsibility could be securely transitioning and continuing to make upgrades to the existing contracts. However, the Council will also have the ability to engage other outside parties to develop the protocol.
One of the major problems with DAO governance is the inability to competitively compensate development teams, which can slow protocol development. To attract industry-leading talent and retain high-output developing team members, the Council should be capable of proposing the allocation of Treasury funds to compensate the development teams. As with all other proposals, Treasury allocations to contributors will be subject to ORCA tokenholders’ veto abilities.
Proposal
Assuming a willingness to transition control of the contracts, we propose that Orca adopts a governance Council structure as outlined above. If approved, elections will be held shortly following the proposal to determine the initial membership. Once elections are complete, 7 new Council Tokens will be minted, enabling the Council to create Council Proposals that enable the efficient upgrades of Orca contracts.
If the feedback to this proposal is positive and the proposal passes, tokenholders will be able to nominate themselves or another community member for the Council.
The election will be open to any candidate and give the community an opportunity to vote on all nominees. Reverie has also identified several individuals who we feel would be suitable candidates for the Council. If the community is supportive of this proposal, we’ll share their names with the community, and if there is support, encourage them to run for Council election.
We look forward to feedback and comments from the community. This proposal is substantial, with long-lasting implications for Orca and its community, and it should not move forward without alignment from tokenholders.