SIP 31.1 - A New Draft Arrives

[alexlmiller]

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

[franco_79001]

This revised version still has a lot of issues: centralized allocation authority remains, emissions are unconditional regardless of real demand, burn mechanisms are delayed and discretionary, there’s no built-in path for unused capital, and transparency depends on off-chain reporting. It also retains regulatory risk due to committee-based fund control and lacks any structural mechanism to align emissions with actual community participation or market discipline. These core flaws leave it vulnerable to inefficiency, capture, and legal scrutiny.

Quote:

“The Treasury Committee will also hold the keys to the Endowment’s mint address and will make regular, approved transfers of tokens to the Endowment’s operational wallets.”

This centralizes monetary power in the hands of a few appointed members. Even if they’re community-nominated, authority over minting and disbursing funds is retained by a fixed body, violating any meaningful principle of decentralized capital allocation. It is top-down monetary management with a democratic façade.

---

Quote:

“The rest of the Endowment will be created via new emissions over a 60 month period… These new tokens will be minted and deposited directly to the Treasury address.”

Token emissions are predetermined and unconditional. There is no mechanism for opt-in participation. No matter how engaged or disengaged an STX holder is, they are subjected to dilution. This model enforces inflation passively and does not allow for economic signaling through individual action.

---

Quote:

“If the size of the Endowment’s total liquid assets grows to exceed $1b USD, it will devise a burn program and present that program to the community for a vote.”

This burn plan is contingent on speculative valuations and committee discretion. Instead of building burns directly into the system as a voluntary check against excess, this approach institutionalizes it as a reactive, bureaucratic process. It incentivizes hoarding until arbitrary thresholds are met, rather than discipline through design.

---

Quote:

“Community Grants… will be administered by the operational entity… with final allocations made by direct vote of the Treasury Committee.”

This undermines the notion of “community” participation. Input may be visible, but power remains concentrated. Voting is symbolic, not decisive. The committee retains full discretion and can override majority (or minority or individual) preferences without consequences.

---

Quote:

“A key element of the mandate for the Endowment… is to clearly communicate… the activities being undertaken… The Endowment staff will be mandated to produce and publish a detailed annual report.”

Transparency is not a substitute for consent. Annual reports are retroactive, not proactive. Publishing actions after the fact does not empower individuals to determine those actions in advance. It is the illusion of accountability without structural restraint.

---

Quote:

“All STX for the Endowment will initially flow through publicly published addresses on chain so that the Endowment’s STX are traceable…”

On-chain traceability is meaningless when participants cannot influence the flow. Surveillance without sovereignty does not equal decentralization, it only broadcasts the movements of a bureaucracy to its subjects.

[Tycho]

The updated SIP-31.1 draft strikes me as spot-on and in line with what the community wants & expressed on the first draft. By keeping allocations out of the code itself, we keep the freedom to adjust later—essential when we can’t predict what tomorrow brings. I’m happy to back this version and hope it moves ahead. Great stuff!

[Haddy]

@alexlmiller

Firstly, thank you for quick turnaround in updating this and providing link to google doc.

Based an X post today, which indicates that voting is planned to start next week. Can you please update to include the proposed / planned date for voting.

[alexlmiller]

I don’t have an exact date for voting starting as I think it depends in part on how conversations around this draft and other questions go, but I believe end of next week is the earliest it might be - will check wiht folks

[Algorithm]

The update highlights important additions that the community, particularly indie buidlers and users, desires, prioritizing their needs.

It’s important to clarify that the burn (or buy-back) plan will need to pass a SIP in the future if the treasury grows sufficiently, as it’s hard to accurately predict future conditions of the industry.
We can draft the burn (or buy-back) SIP immediately after the SIP-031 vote begins and modify it as necessary in response to the future realities of the industry. This is crucial because the ecosystem requires sufficient treasury funds for real growth, regardless of industry conditions. It also balances the hodlers needs.

We aim to move forward with the updated SIP-031 as quickly as possible for the betterment of the ecosystem.

[xenitron]

SIP-031 heavily references TVL, LP, and DeFi incentives.

How will the Endowment measure and fund traction for consumer-facing apps — GameFi, social, creator economy — where success is wallets, sessions, or NFT trades, not TVL?

---

Sybil-Resistant KPIs for Non-DeFi Projects

A proposed model for measuring real human engagement and economic utility on-chain — beyond TVL.

KPI Formula

Sybil-Resistant KPI Score = (Retained real users × Paid on-chain actions × Avg spend) − Net subsidies

This model is designed to help the Stacks Endowment and Treasury Committee evaluate traction in consumer-facing apps — such as GameFi, social, and creator economy — where traditional DeFi metrics like TVL and LPs are not applicable.

Metric Definitions

1. Retained Real Users

Humans who return regularly — not bots or one-time airdrop participants.

What counts:

Daily/weekly wallets that return ≥3 times in two weeks
Wallet has claimed a .btc name
Passed voice, video, or skill-based challenge
Repeated sign-ins to the same game, app, or social interface

Example:
500 players solved a game at least 3 times per week in the last month.

2. Paid On-Chain Actions

Voluntary transactions where the user spends STX, sBTC, or app-native tokens.

Examples include:

Minting or upgrading NFTs
Paying for quests, battles, or events
Tipping a creator or joining a live session
Purchasing in-game items directly on-chain

Example:
10000 FTs minted at 3 STX each = 30000 STX in organic spend.

3. Average Spend (ARPU)

Shows the depth of user engagement and willingness to pay.

Formula:
Avg spend = Σ(user on-chain spend) / retained users
Tracked monthly or quarterly to assess loyalty.

Example:
2,000 retained users spent 30,000 STX last month → ARPU = 15 STX

4. Net Subsidies

Rewards not backed by genuine effort or spend. Deducted to prevent inflated KPI scores.

Include as subsidy:

Pure airdrops for likes, retweets
Referral bonuses without follow-up actions
Unlocked liquidity mining

Exclude (acceptable incentives):

Prizes for skill-based games
Educational bounties that trigger paid actions
Small starter kits requiring user top-up

Formula:
Net subsidies = total incentive payout – value converted into real spend

Sample Score Calculation

Retained users: 2,000
Paid actions per user: 4
Avg spend: 10 STX
Net subsidies: –10,000 STX

Result:
(2,000 × 4 × 10) – 10,000 = 70,000 STX of net, Sybil-resistant value created

Who Evaluates and How

Treasury Committee & Community Grants

1. Role of the Treasury Committee

As defined in SIP-031, the Treasury Committee is responsible for reviewing and approving funding proposals, including Community Grants. This KPI model provides a consistent framework for comparing consumer-facing applications beyond DeFi.

All grant applicants should submit their Sybil-Resistant KPI estimates based on this model.
Treasury members will use these inputs to evaluate traction quality, economic activity, and capital efficiency of the application.

2. Public Data & Accountability

All grant applications and KPI submissions must be made publicly (e.g., GitHub or Forum).
The community can provide feedback or flag suspicious or over-inflated metrics.
Treasury decisions remain independent but are made in view of public commentary and data.

3. Platform Admin by Ops Entity

The Operational Entity (as outlined in SIP-031) is tasked with building and maintaining the infrastructure to collect, track, and publish KPI-related data — but does not decide which grants are approved. That remains solely the role of the Treasury Committee.

Conclusion

This proposed KPI model helps ensure that funding decisions are based on real user behavior, not speculative TVL or artificial engagement.

It’s Sybil-resistant
It’s built for games, social apps, and creators
It rewards projects that convert attention into sustainable economic activity

We invite the Treasury Committee, builders, and the broader Stacks community to adopt and refine this model as part of the funding framework under SIP-031.

[Haddy]

Really like this @xenitron, thank you for sharing.

We need more assessment models/formulas for the diverse array of tooling, products and services that will require funding, now and in the future.

[blockface]

Hello,

My name is Blockface.

Every single post by every single community member on this forum boils down to one thing: recentralization. Tell me I’m lying.

The community is concerned that the proposed endowment will be spent by the central authorities exclusively. These concerns often come off as “Can I Haz Da Monies” but hey, it is what it is.

So, to make sure we put a fine point on the root cause of The Community’s Concerns so it’s right here out in the open…

(I wonder if I can use Markdown? Anyhoo. I guess I’ll find out after I press reply huh)

Governance and Centralization Risks

For STX holders, SIP-031 introduces a new operational structure with potential centralizing risks, particularly concerning appointments to key positions. The community should closely monitor these appointments to ensure the continued decentralization and accountability of the Stacks ecosystem.

Treasury Committee Authority and Composition

Significant Concentrated Power

The Treasury Committee will hold significant power, being responsible for:

• Supervising and maintaining the Stacks Endowment’s assets
• Approving all major actions and allocations
• Setting the endowment’s investment policy
• Determining asset allocation
• Overseeing investment performance

Critical Control Mechanisms:

• Mint Address Control: The committee will hold the keys to the Endowment’s mint address
• Authorization Power: They will authorize all token transfers to operational wallets
• Monetary Concentration: This concentrates substantial monetary power in the hands of a few appointed members

Committee Structure and Self-Perpetuation Risk

The committee is designed to have nine members:

• Five keyholders with ongoing terms
• Four rotating members serving 36-month terms

Selection Process Concerns:

• Future appointments will follow an open community nomination period
• However, they ultimately require a two-thirds supermajority vote of the existing Treasury Committee
• This mechanism allows the incumbent committee to have strong influence over who joins
• Potential risk: This could lead to a self-perpetuating group

Initial Appointment Concerns

Temporary Appointments Committee

A significant point of concern is the initial formation of the Treasury Committee:

• A temporary Appointments Committee will be formed to make foundational appointments
• The specific individuals who will comprise this Appointments Committee were initially listed as “OPEN ITEM” in the draft SIP
• Critical Issue: The composition of this temporary committee is crucial, as it will determine the initial makeup of the powerful Treasury Committee without a prior community-governed selection process for itself

Pre-Allocated Positions

• At least three initial keyholder positions on the Treasury Committee are proposed
• One position explicitly reserved for the Chief Investment Officer (CIO) of the Endowment
• The CIO is responsible for overseeing the Endowment’s investment portfolio and strategy
• Centralization Risk: This pre-allocation of key roles, especially one tied to an internal operational function, could centralize financial control from the outset

Community Concerns: Community members have expressed concern that these initial appointments might favor:

• “The same people currently running Stacks (maybe add in a few VCs)”
• “Influential entities”

[easterntraveler]

Would be nice to see these points discussed

[andrewsaul]

I read this as Polkadot Foundation type death. The minute I see “KOLs” in a funding proposal I know it’s not something that a foundation should be in charge of.

The examples given of Avalanche and Near are not accurate. There’s not a lot of evidence of any of those original marketing spends worked (as per what is on chain today).
Instead the places both have succeed were entirely market driven and outside of the initial grant programs (which just tried to copy paste Ethereum apps onto each chain). In fact Illia Polosukhin himself, in a recent Blockworks 0xResearch episode, lamented the failure of Near ecosystem growth incentives to deliver any apps or usage of consequence to the Near ecosystem. Having seen the very legitimate goes that Near had in Asia with these over the last few years I’d posit not many ecosystems could match the effort and quality Near Foundation delivered. But they failed. As did all the others.

I cannot see the logic behind the Render or Sui examples either. Sui has barely started, some promising signs no doubt, but it’s still early days.
Render rode the AI boom with everyone else. It had nothing to do with tokenomics.

Fantom > Sonic have a gas monetisation program that rewards apps for usage on chain. It’s worked. Just do that. Fantom should be dead, it’s not, that’s down to the gas monetisation scheme. It won’t MAKE the ecosystem, you still need successful apps, but it gives any app a much better chance at making a sustainable business cause you remove a lot of work they need to do around monetisation.

Then you can spin up small but targeted initiatives. Again based on what has worked.
Follow the Solana model by building your own Hacker Houses, Colosseums, etc… to help support start-ups. Solana succeeded where so many others failed (Near, Polkadot, EOS, ICP, and list goes on and on) as these were all separate entities that the foundation encouraged and supported but didn’t run themselves. That gave them the ability pick and choose winners as goes what was working. This then becomes a market in of itself.

Create a couple of small well targeted Foundation teams to focus on particular areas. By narrowing the focus you deliver better results much more cost effectively.

[Haddy]

To avoid issues:

All funding should be public and a list of explicit exceptions should be public too.

From application to completion - full lifecycle

A list of funded activities that aren’t made public (exclusions), should be disclosed publicly.

Can this be added to SIP?

[HeroGamer]

For those who might have scrolled passed (I did) the Google Doc hyperlink that contain the full text of the new SIP 31.1 draft, here is the link:

SIP 31 - Update 6/4/2025

Please do give it a thorough read.
Encourage CAB members to also to read this draft as well.

[alexlmiller]

Making some additional updates to this draft based on feedback and more conversations with folks, in particular revising how the Treasury Committee is appointed to give the community a direct vote on appointments, specifically:

(1) The Treasury Committee will still have 9 seats - 8 filled by the community and 1 by the Chief Investment Officer

(2) All 8 community seats serve 4 year terms, with 4 seats re-appointed every 2 years to provide continuity (so we’re not always facing a totally new board). At each appointment time, the Endowment will provide a list of proposed Treasury Committee members, based on conversations with the community, and that list must receive 2/3rds approval via a SIP vote (similar to the process with the initial Appointments Committee)

(3) Keyholders will be a separate role from voting members of the Treasury Committee and will continue to serve indefinitely to minimize how often key rotations are needed. Keyholders may still be members of the Treasury Committee but don’t have to be - they’re appointed/removed by a 2/3rds vote of the Treasury Committee

(4) To fill the seats on the Treasury Committee initially, a majority of the seats (5 of 9) will be appointed by the Appointments Committee. For details on the Appointments Committee, see the forum post on that

Additionally, to enable the initial setup of the Endowment, three existing leaders from the Stacks ecosystem who are making substantial contributions to the Endowment (either via their entities or personally) and have substantial experience in managing large crypto treasuries will be appointed as keyholders as well as members of the Treasury Committee, with their seats up for re-appointment at the first appointments period in 2 years. These include Alex Miller (CEO of Hiro), Mitchell Cuevas (Interim Director of the Stacks Foundation), and (Muneeb Ali, Co-Founder of Stacks).

You can see the full text in the SIP draft here.

PS: Yes, I’m aware its a little funny that I’m proposing myself as one of those first appointees, but I’ve discussed this with a number of community members and think it makes sense

[Algorithm]

Interesting

[stacksonchain]

I am now in support of this sip. Thank you & the team for taking the feedback into consideration.

[mrwagmi.btc]

I want to formulize a thought into its own post that I’ve been floating around. It originated from concerns presented regarding the SIP-031 Endowment Treasury and its sustainability over time. A handful have expressed concerns that Year 1 funding is super critical given the existing STX token price. The performance over the first couple years all relies on this bazooka approach. But, what if there was another way, a potentially more self-sustaining way, and possibly one that turns it into a more probable growth model.

We can call the “The Stacks Strategy”.

What if the underlying treasury assets could be re-vamped to like a MicroStrategy approach, but on chain, using our own Stacks ecosystem.

Could it extend the runway and also make the endowment prosperous to fund our ecosystem initiatives beyond what we thought was possible?

My concerns:

• Basing in USD or fiat could become more unpredictable with inflation. How will this impact cost of living (CoL) over the next couple years - which then affects the cost the treasury absorbs.

• How does this impact our native $STX token and the greater crypto market at whole, cycle to cycle?

• How can we remain resilient, cycle to cycle, and make this last the longest?

What if our Treasury Endowment moved to a $SBTC standard, our 1:1 pegged Bitcoin. Upon an initial acquisition of funds, $SBTC was procured, then HODLED.

Upon the creation of the Treasury Endowment (external entity), it were to also be tokenized to represent the utility and functions of this group. With tokenization, it serves as another resource and gauge of the community sentiment in carrying their affiliated duties of marketing, development, operations, etc.

Every quarter, when the Treasury Endowment needs funds for marketing, operations, etc. they borrow against the $SBTC via Dapps in our ecosystem and receive $USDH, the Bitcoin backed stable by the Hermetica team.

Those funds are then made available for doing business. They could be swapped to USDC which is more widely acceptable until USDH options are available more widely.

Then, key part here, The Endowment Treasury would then also issue more debt in the form of it’s token noted above to procure more $SBTC for its treasury.

In my opinion, this could very well be an unseen innovative approach the entire crypto ecosystem has yet to see… I wonder what kind of marketing buzz this could create? Also, as you may have seen a lot of these Bitcoin Treasury companies are creating a lot of buzz in the world and at the recent conference. To me, I’m quite intrigued by this option as an investor. The traditional Bitcoin treasury companies are in essence providing “Paper Bitcoin” as I understand? With this potential option, our Endowment Treasury would be providing on chain transparency.

Per Satoshi Nakamoto’s original forum posts, he noted “crypto proof” as a goal rather than “trusting” centralized entities. This sounds like it aligns more to that ethos, don’t you you think? We are the pioneers. We build on Bitcoin. We have a whole ecosystem now. This could be that next step in demonstrating to the world - Why Stacks and How Stacks Further Aligns To Satoshi’s vision.

So, to me, its a question of:

• How confident are you in the future of Bitcoin?

• How confident are you in our technology, $SBTC, $STX, and $USDH?

• How confident are you in fiat?

I’m not a financial or legal expert, so we would need to funnel this up to the appropriate eyes to validate.

But, if its viable and supported this could:

• Extend our runway.

• Attract eyes as a new offering within the Stacks ecosystem.

• Go beyond extending the bazooka runway approach and provide more resources:

• to fund more marketing over time.

• to fund more development over time.

• to fund more operational needs, etc.

Ideally, by basing in a $SBTC Standard, hopefully we would never have to re-visit the idea of increasing the supply of $STX in the future for additional funds. With this treasury approach, the goal is to have our treasury support itself and provide more support to the Stacks ecosystem.

What do you think?

Please debate, critique, and share with the math wizards and legal guru’s.

[alexlmiller]

Look forward to seeing what other folks have to say on this one, but I think the endowment/cio strucutre is going to be good for the eco exactly because they can explore things like this (along with the proper legal/financial/regulatory diligence) that are out of reach of the current orgs given the distributed treasuries and staff

[mrwagmi.btc]

Logging an idea here that Davek expressed on a space that I think would be very beneficial and efficient. He mentioned common needs that surface for builders such as: needing a server, audit, or other resources. If there were a way to mitigate/reduce these costs for new builders it would be extremely helpful.

It got me thinking. What if we had a Stacks (GPO) Group Purchasing Organization, therefore, these common needs could be negotiated at scale to secure better pricing and formalized onboarding. Whether this on the table for the Endowment or an organization/entity that arises out of the ecosystem itself.

[fabohax]

Servers, audits and other resources are important but, if taked, must be from a planning perspective. It sounds like those can be run by devs themselves and doesnt requires much budget, maybe a way to promote auditing offices especialized in Stacks would be great benefitial, idk of those others really need a Group dedicated specifically to it.

Lets put funds smartly. I just heard yesterday that Stellar gave 15K to a group in Chile that no one of them are devs and even don’t know how to make that app. LOL, well, maybe it’s a joke.