As promised, below is my proposal for the revision of SIP-31.
This draft was made based on the conversations with the community for the last week and written in conjunction with @codeonedotzero and @cuevasm. A huge thank you to everyone who participated in these conversations (here and in spaces and elsewhere) over the last week - this update would not have been possible without the deep and thoughtful engagements we had and is exactly what we hoped for this process to produce.
The full draft is available in this Google Doc - please make that the primary place for comments on the draft to make collaborating easier as move forward.
Additionally, I’ve talked to the Foundation team who have said they will propose a process and next steps for choosing Appointments Committee members by the end of the week, so keep an eye out for that.
The rest of this post contains a summary of the major changes and the thinking behind them.
(1) Clarified the intent of the SIP as benefitting ALL builders
(2) Added a “Community Grants” program
(3) Added a section on burning tokens if the Endowment grows sufficiently
(4) Added a “Potential Risks” section
(5) Added more detail around reporting expectations from the endowment
(6) Clarified limitations on the Endowment
Clarified the intent of the SIP as benefitting ALL builders
There was feedback from a number of community members that they felt the SIP was overly focused on DeFi at the expense of other projects - based on these conversations I added the clear strategic vision of the Stacks ecosystem as being the home of the entire Bitcoin economy and looked for changes throughout to clearly reflect the community-wide impact of the SIP.
Added a “Community Grants” program
While the entire SIP is meant to benefit the entire community, there was a concern that community members working on something that may fall outside the highest current/ immediate ecosystem priorities would be left out. While a clear strategy is good, we are building a global, comprehensive ecosystem and there should still be a path for projects that widely benefit the community. This can help ensure that various areas of the ecosystem have a way to request resources, even during times when more widely impactful or critical work (like Nakamoto and sBTC were) is the clear priority.
As such, I’m proposing a “Community Grants” program to address this. Anyone can request a grant and the requests, much like DeGrants and the Stacks Foundation grants before that, would all be public. Community members can ‘upvote’ / comment on the ones they think are valuable, similar has been done via GitHub on Grants and Critical Bounties historically, with the final allocations decided by the Treasury Committee. This is to ensure there’s no gaming of the system, to establish a legal relationship with the Grantee such that they can be paid, and gives the committee leverage to hold Grantees accountable if needed.
Because the community input is all public, it will be obvious if the committee is routinely not funding things that the community as a whole thinks is valuable, feasible, and impactful and action can be taken to address (hearings, SIP, etc.).
There was the suggestion that this should be just a set budget that the “community” gets to allocate but I think that gets problematic very quickly (who is ‘the community’, what’s the accountability process around it, etc). These are issues previous experiences and grant programs have solved for over the years with a structure very similar to what I’m proposing above. Using the Treasury Committee means all the accountability processes we’re already building can get re-used for it and the committee is made up of nominated community leaders anyway.
Finally, the reference to the Operational Entity administering it is just to indicate that they need to do the work to ensure there is a process/platform for these grants to happen, they don’t make the calls on what gets funded.
Added a section on burning tokens if the Endowment grows sufficiently
Another concern brought up was the amount of tokens being raised - in order to avoid having to consider another set of emissions later, the rate of emissions in this SIP were chosen based on the third party economic analysis and to ensure that the Endowment raised sufficient funds even in a scenario where the token price does not considerably rise.
Conversely, it is possible that if STX materially overperforms the model in the economic report in the short to mid-term (for instance if it rose to $10+ /token), then the Endowment will likely be sufficiently equipped without needing all of the planned emissions and a token burn can be set up to burn the later part of the emissions.
Therefore, I’ve added a section that if the Endowment exceeds $1B USD in liquid value across all its assets, then it must create a token burn plan to burn the future/excess tokens and present this to the community to be voted upon. This was chosen because $1B, well invested, should easily provide $50m+ USD per year for ongoing operations.
I chose not to create a specific burn plan now but rather require the development at the time for several reasons, in particular: (1) we don’t know what the economic situation of crypto/the world will be at the time that it exceeds $1B and that would affect what the most responsible plan is. (2) The community should have the option to decide at that time if they want to burn the tokens or if there is a better use for them.
Added a “Potential Risks” section
As noted by several people, it is prudent to include a section on the potential risks of this SIP, I added those based on suggestions from the community and key contributors…
Added more detail around reporting expectations from the endowment
While there were commitments made in the SIP around reporting, there is not enough context as to why those are chosen or what some of the larger communication should be. In order to balance both operational efficiency with clarity for the community I added specific detail as to the reporting standards and made clear that all funds should flow through on-chain addresses to be traceable by the community.
Clarified limitations on the Endowment
The SIP already contained a restriction on the Endowment not voting with its tokens on SIPs, but I increased the clarity in order to ensure it remains neutral and to remove any potential effect it would have on the governance process.
Thank you again to everyone who made this possible and I look forward to discussing your thoughts on this!
Alex
Sample Score Calculation