Governance Council


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.


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.


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.


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


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


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.


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.

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

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

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

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

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


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.


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.


Thank you for this proposal. In general, I support the governance structure as outlined.

Here are a few thoughts:

  • I believe compensation for council members is a bit rich and should be more heavily weighted towards tokens. I propose $25K USDC, $25K of ORCA, 1 year cliff and 12 month linear vest. Consider 3/5 rather than 4/7 to reduce overhead. Core team should remain primary drivers of protocol development for the foreseeable future and I expect council person responsibilities to be very part-time.

  • I propose an 8th paid position (or 6th if 3/5) who plays the role of the “4th Estate”. They are responsible for monitoring council/team activities and producing more frequent and informal updates than the quarterly reports. They are a safeguard against Council abuses of power with the primary responsibility of sounding the alarm and submitting veto proposals (it may be unrealistic for the community to play this role). They are trusted by tokenholders to permit the team and council to be temporarily secretive when the normal transparency standard would aid competitors.

  • I propose an automatic dissolution of the Council after 2 years unless token holders vote to reinstate. This will create an opportunity for token holders to reflect on learnings and propose alternative models without inertia from the original model.


Appreciate the comment! Great thoughts, will address each one below:

  • Hear you on the compensation, finding the right number in our space is never easy. We want to make sure the Council role is financially competitive to attract talented individuals while keeping their incentives aligned and engagement high. The risk of underpaying members is a lack of engagement and underperforming Council. To that end, $65k/yr package seems fair given the responsibilities expected. I do agree we could play around with the structure, e.g. we could reduce to $60k total with $30k USDC / $30k ORCA.
    Happy to hear more thoughts from the community around compensation.

  • Love this! We had also thought of assigning a non-Committee member as Secretary or similar to sit in on all the meetings, share notes with the community, and keep the members accountable. It would be great to start hearing thoughts on existing community members that would be good candidates for the role.

  • Great idea for dissolution. The community will hold the ability to dissolve the council at any time through a governance proposal, but hard-coding a timeframe for the initial launch also makes sense!


I also think this is a great idea and support the proposal to form a Governance Council.

With respect to total number of members, I would caution against reducing headcount from 7 to 5. People come and go so frequently in crypto, and if someone were to decide to call it quits and walk away without notice, the Council would be in a really tough position. Even with procedures in place to remove a member, you wouldn’t want to be playing musical chairs with 20% of the voting power.

I, for one, would still be excited about the opportunity to contribute even if there’s less compensation on the table because Orca’s success is key to Solana’s success.

Also support dissolution of the Council after a pre-determined period, but that then begs the question of who exactly would assume control in the event that the community decides the model is not working. We would have to be very clear and intentional on this point.


Thanks for sharing!

  • Agreed, 7 members is much more prudent and improves efficient processing from the Council.

  • Great to hear!

  • If we follow the transition outlined in the post, control would return to the community without the added council. Upgrades would need to be issued through community proposals, a more standard method of governance. With 24 months (2 terms) before a dissolution vote, I think we can assume the Council has enough time to improve based on community feedback and lessons so that it would receive continued support. The dissolution could even act as added accountability to improve performance.


Totally agree. Thanks for clarifying!


Thank you for this proposal @cbergz!

We discussed a number of topics on the governance call in discord yesterday. I think it’s worth continuing and elaborating on some of the discussion here.

2 topics:

  1. optimistic governance mechanism
  2. community expectations of the council

Optimistic Governance Mechanism

I think it’s important that the community is fully aware of the tradeoffs that come with optimistic governance. I also think it’s worth opening the discussion on how the DAO can be prepared to mitigate the tradeoffs when necessary and also work towards a future where token holders have more agency beyond opting in to council proposals by default.

Community Expectations of the Council

The proposal speaks to important and practical functions of the council but I don’t think it fully sets expectations on what the council would seek to achieve in addition to operating the protocol in a more decentralized way. I think token holders would expect some aspirational trajectory in order to justify the cost of the council. Two ways to explore this come to mind:

  • The proposal is amended to include either: a charter laying out the councils mandate to improve the Orca ecosystem or some set of high level metrics that token holders should judge the council’s success by.

  • The council candidates could use this as their platform to seek election by the token holders. I see some downside here in potentially pulling the council in too many directions at once.

I would like to state my bias as someone who is considering running for election to the governance council. From this perspective I feel that the second topic is most important. If I were elected to the council I would want to ensure that council and community expectations were aligned and documented so that during my term I would be confident that I was working to the will of the voting token holders.



1 Like

Hey Adam,

Appreciate the response and participation in the governance call!

You bring up some great points, and I’d like to build off this to more properly define objectives for the Council ahead of the proposal.

Council Objectives

Protocol Maintenance & Upgrade
The Council will act on behalf of the community to maintain and upgrade the underlying Orca contracts so as to keep the protocol healthy and drive forward progress. The council will schedule proposals at the recommendation of the Development team to best support the maintenance and growth of the protocol. This includes reviewing upgrades submitted and submitting technical proposals to perform the necessary changes.

Developing Teams
The Council will be responsible for growing and guiding the teams building on Orca. This would include the following:

  • Holding the teams accountable for protocol development
  • Issuing ORCA allocations to hire, incentivize, and grow contributor talent
  • Hiring and Removing teams based on performances

DAO Growth
The Council will be responsible for advising the evolution of Orca’s DAO as it evolves through this transition. This may include structural changes, like forming Working Groups, and launching community initiatives, like an Orca Grants Program or other incentives programs.

This will also include Treasury management, with opportunities to diversify and re-allocate the community treasury to better align the financial health of the protocol.

The Council will report to the community on a quarterly basis through a detailed breakdown of activities within both the Council and Developing teams. All proposals, attendance, discussions, upgrades in development, and more will be shared for community assessment.
The Council will also be expected to host quarterly, at least, calls to discuss the report and developments.

The Council will continue to adapt as Orca transitions and the community grows. While we expect the above to provide a clear guidance for initial expectations, the community should expect responsibilities to grow alongside the protocol’s growth. We also hope to hear more from the community on ideas for other OKRs.


Thought had posted this earlier but didn’t seem like it went through:

Agree about including provisions about emergency proposals if funds are at stake or if there is smart contract risk. Council members should be able to shut down functions without a vote if and only if it’s perceived funds are at risk

Regarding community removal: Maybe pin it at a % of circ? 2.5/20 is around 12.5% circ which might be high? Maybe make it so that if 10% of circulating orca votes out a member (majority) then it’s finalized. Would imagine the tokens are not very decentralized especially as investors and teams unlock. This amount should take those factors into account. How much of the token is circulating now that investors may be unlocking this month?

Also agree regarding automatic dissolution of Council after 2 years unless token holders vote to reinstate.

I really like this idea