Autonomous Partners (ASP) Founders’ Reward Positioning: Support for Avichal Garg’s Proposal with Amendments
tl;dr: Autonomous Partners (ASP) supports Avichal’s Garg’s Proposal but suggests an alternative initial seat allocation (1 to ECC, 1 to ZF, 3 voted on by community) and recommends using staggered elections.
Autonomous Partners (ASP) is a long-term oriented crypto fund. We invest in both crypto assets and equity of crypto-focused projects. ASP has been an active investor across the crypto space. Investments include Dharma, Kadena, Celo, Maker DAO, and 0x. We are backed by Brian Armstrong, Steve Cohen, and Union Square Ventures, among others.
ASP was founded by me, Arianna Simpson, in 2017. I have been active in the crypto space since 2013, and left Facebook in 2014 to become the 3rd employee at BitGo. In 2015, I launched Crystal Towers Capital––a seed stage venture capital fund–– with my partner Tikhon Bernstam. I remain a remains a venture partner.
Huge thanks to @JacobPPhillips from the ASP team for his help researching and putting together our position and comments.
At the time of writing, ASP owns ZEC.
Why are we writing this?
ASP looks to further the discussion around the Zcash Founders’ Reward debate by sharing our position on the subject. ASP is a strong believer in the importance of privacy tech and a long-time supporter of Zcash. Thus, we feel compelled to have an active voice in the community to help ensure the success of the project.
As others have noted, this issue has the potential to dramatically alter the future of Zcash. Zcash has a long road ahead––both in terms of technical development and user adoption. Zcash has amassed a category-leading tech stack and a strong team comprised of some of the best zero-knowledge developers & researchers in the space, but considerable work remains to be done to ensure the success of the network and currency.
Summary of the Founders’ Reward Discussion
Per our research, the community appears to be largely in agreement on the following:
- The founders’ reward to compensate founders, early employees, and investors should not be renewed.
- There should be a development fund of some sort.
- There needs to be much greater transparency and accountability around management of Zcash community funds.
- Governance of the fund and protocol development should involve greater input from the Zcash community.
However, the community appears to be still in discussion on the following:
- How large should the development fund be? How should it be funded?
- How will the development fund be managed? Specifically, what role will the ZF & ECC play going forward, and how will the Zcash community be involved in decision making?
- How will the Zcash community ensure transparency and accountability for the management of funds?
ASP’s Position on the Founder’s Reward Debate
ASP’s positioning on the founder’s reward debate is most closely aligned with Avichal Garg’s proposal. See here: Dev Fund Proposal: 5-Entity Strategic Council Approach.
Key Takeaways from Avichal’s proposal:
- 20% of block reward is used to create a development fund
- A 5-person strategic council is created. Council members are elected and serve two year terms. 1 seat is reserved for miner signaling. 1 seat is reserved for ZEC holder signaling (1 ZEC = 1 vote). The remaining 3 seats are elected 1 person = 1 vote.
- This council has full discretion over management of Zcash funds. 3-of-5 votes are needed to distribute funds. No more than 33% of funds can go to one single entity.
- Teams/individuals are required to clearly outline a grading rubric in their project proposal. Project performance is graded by the strategic council. “Thus [developers] are held accountable by the board and the board is held accountable by the community.”
ASP recommends accepting Avichal’s proposal with the two suggested revisions:
- The initial 5-person strategic council should be comprised of 1 representative from the Electric Coin Company (ECC), 1 representative from the Zcash Foundation (ZF), and 3 representatives from the Zcash Community as voted on by ZEC token holders.
- The first election should occur 12 months after the initial seat allocation. After this, elections should be staggered with 1 seat put up to a vote every 6 months.
Rationale for Recommendations:
20% of block reward is used to create a development fund.
Zcash’s current implementation lacks the privacy, scalability, and trustlessness needed to achieve its vision. Zcash is far from its end state and will require significant and ongoing R&D to reach mass adoption. Dedicating 20% of the block reward to a development fund should be sufficient to sustain ongoing development.
Some community members have expressed concerns about the possibility of overfunding the development fund in the event that ZEC sees a significant increase in price (an outcome we all envision). With this in mind, we should error on the side of being too generous toward development, as opposed to not generous enough. Underfunding development represents an existential threat to the adoption and long-term viability of Zcash. Overfunding would be far less detrimental. Ongoing R&D is likely to increase the security of Zcash far more than the additional security it would bring if allocated to miners. In particular, moving toward privacy as the default, increasing scalability, and improving/removing the trusted setup would all significantly benefit Zcash security.
A 5-person strategic council is created with 3-of-5 votes needed to disburse funding.
This seems to strike a good balance between centralization and decentralization. We echo Avichal’s commentary on the need for agility and flexibility in funding. A council of 5 individuals works to ensure this, while still preserving widespread representation of interests.
ASP prefers this approach to entity-based councils, as entities will be more difficult to hold accountable than individuals. Threat of replacement is a key mechanism that holds council members accountable. In entity-based councils, the act of replacing an entity is met with significant friction. For example, Placeholder suggests a 2-of-3 council comprised of ECC, ZF, and a 3rd entity created by the Zcash community. Under this model, to replace ECC or ZF, the Zcash community would either need to identify an existing organization well-suited to take up the role or establish a brand new organization from scratch. Neither route would be easy, reducing the likelihood that ECC or ZF would be replaced.
To ensure proper accountability for the management of development funds, we see a council of elected individuals as the best solution. In this model, representatives of entities may still occupy positions on the council, but an affiliation with an entity is not a requirement. As such, the barriers to entry are reduced, allowing any individual within the Zcash community to compete for a council spot. This leads to less friction associated with replacing council members and a higher level of council member accountability.
Initially allocate 1 seat to ZF, 1 to ECC, and 3 to ZEC token holders. None of these seats are permanently reserved and may be replaced through elections. At any given time, no more than 1 seat may be allocated to individuals affiliated with ECC, ZF, or another given entity.
ZF & ECC have done a good job managing the strategic direction of Zcash thus far, and they deserve an initial minority representation on the council. If the community becomes displeased with the ECC’s & ZF’s ability to lead Zcash under increased transparency requirements, representatives of these organizations can easily be replaced in the next election.
However, we feel that some in the community may be understating the importance of the ECC and ZF in Zcash’s road to adoption. To date, these organizations are largely responsible for the development, growth, and evangelization of Zcash. In addition to having assembled a top-tier team of developers and researchers who routinely deliver industry-leading privacy technology, these groups are responsible for many diplomatic initiatives that are arguably just as important, including working with regulators and establishing Zcash communities around the globe. As a community, we should welcome ongoing leadership from the ECC and ZF, though with greater input from the community at large.
Despite granting ECC & ZF an initial seat on the strategic council, the Zcash community still maintains the majority of seats on the board, giving the representatives token holders elect full veto power over ECC & ZF.
This allocation also simplifies the community election process in the establishment of the council. Under this plan, the community only needs to elect 3 representatives to start.
In contrast to Avichal’s proposal, ASP is advocating against allocating a council spot to support miner interests. While miners undoubtedly play an important role in the current Zcash ecosystem, their interests are not necessarily aligned with the success of the protocol. As a simple example of this, imagine if overwhelming research suggested that Zcash would be more scalable and secure using proof of stake consensus. This would eliminate hardware miners from the equation—as such, we would expect the miner representative to vote against the proposal. In this case, the miner representative’s interests are not aligned with that of the protocol.
However, this does not mean miners cannot participate in Zcash governance! Miners whose incentives are aligned with that of the core protocol will be holders of ZEC, allowing them to participate in token holder voting for council seats.
The first election should occur one year after the initial allocation of seats. After this, elections should be staggered with 1 seat rolling off every 6 months.
Credit goes to Mitchell Krawiec-Thayer (mitchellpkt) for this suggestion, (which Avichal also supported). Staggered elections are a widely used mechanism in corporate governance used to reduce the risk of hostile takeovers. Through staggering, a faction looking to overtake the board must win seats in multiple elections over an extended timeframe, a notably more difficult process than in a single election.
In Zcash, staggered elections would allow for a steady stream of new ideas/perspectives to flow to the council. Significant shifts in strategy and ideology could be implemented gradually, and the crypto-equivalent of a hostile takeover would be more difficult to perform.
Staggering elections also breaks down the process of electing a council into more manageable chunks. Staying informed and involved in discussion on 5 different elections at the same time may be difficult for members of the Zcash community, ASP included, leading to lower community participation. By breaking up elections into 6 month intervals (with 1 seat up for election each interval), the Zcash community only needs to focus on one council seat at a time. There has been great community discussion about the upcoming founder’s reward, but imagine if there were 4 other major upcoming community decisions being debated simultaneously––our hunch is that this would hurt the overall quality & quantity of participation.
More specifically, we think it makes sense for ECC & ZF to be the first two seats to roll off and be put to an election. This gives these entities a year and 18 months, respectively, to demonstrate their ability to add value to the Zcash strategic council under increased transparency and accountability requirements. After this trial period, the community can vote on whether or not to extend a governance position to these entities. The initial 3 community seats voted on by token holders would roll off in subsequent periods.
There are a number of details and additional items to discuss as it relates to this proposal and any other proposal the community may choose to go forth with. Avichal mentions a few, including impeachment process & requirements for amending the rules that govern the strategic council. These are important discussions to have as a community—however, many of these can’t be discussed until some consensus on the path the community will take is reached. We encourage the community to actively support Avichal’s proposal to allow us to begin having discussions around implementation details now.