Designing the Stacks Grants Process

The goal of Stacks Grants are to fund infrastructure development, community resources, tools, research, and education that serve our mission of a user owned internet, powered by the Stacks Blockchain.

We aim to create an open, efficient, and transparent proposal process that creates a path for teams to build novel and needed infrastructure in the Blockstack ecosystem. After research and development, we’re gearing up for our beta Grants Program launch. This post shares more about the background on the design. Input and feedback welcome! We’ll have more details on the application process soon.

Beta Grants Program

At Blockstack, we’ve always taken a phased approach to building : start with research and development, learn from early infrastructure and pilots, then launch for growth. We’re using the same approach for our the Stacks Grants program.

The initial Stacks Grants program will run as a beta program to build momentum, test our process, and build a system set up for success. We will use this time to award initial grants up to $5k, improve the application process, measure the participation, gauge interest in grant categories, and understand the structure and requirements for the grants committee going forward.

The beta program will run through the launch of STX 2.0. After STX 2.0 we we will have the opportunity to award grants in STXs, propose a new grants committee structure, and have the option to increase the size of grants. This is a great opportunity for the community to provide proposals on the structure of review and voting by using the beta data to understand the potential needs of the system.

Program Research and Design

As part of the research and design phase, we’ve focused on learning first. We’ve had the opportunity to speak to many peers in the space who’ve run grants programs at other projects, including Ethereum Foundation, ZCash Foundation, LivePeer, and Tezos. Grants are also a topic that have come up in our community discussions and discord threads for several months. This advice has been incredibly valuable in making sure we create the most opportunity for our network while minimizing risk factors that others didn’t anticipate.

I’m grateful to my candid peers, especially since most advice was on what not to do, rather than what worked well. It’s part of the reason why we’re beginning in beta, as even the best plans can teach new lessons so our approach to start small is an effort to build over time instead of making sweeping changes mid-flight. We’ll learn together and plan to share our lessons over time.

To begin, here are the top lessons learned that we’ve been using as assumptions to build our beta program:

Design Considerations:

  • Create goodwill in the community by highlighting wins often, create avenues to broadcast good work and accomplishments. Bad actors are usually the loudest so counter those with transparency.
  • Make the process transparent to avoid a belief that grants are only for insiders or friends
  • Watch out for scammers and project shoppers only looking for cash
  • Well intentioned developers may still fail at execution, so make sure scope reflects experience
  • Respond quickly (<1mo) to applications so applicants don’t get discouraged
  • Long, arduous requirements can discourage teams from ever applying, so you can require more information or diligence once they are through the first hurdle
  • A mix of grants (user created) and bounties (call for applicants) help direct where people build
  • Measure ROI - either on funds granted, proposals considered, or impact of contributions


  • Scout for strong teams and developers to pursue grants or bounties, academia, hackathons and dev teams are a great place to look
  • Make sure all grantees and bounties are building truly open source, it should belong to the community. Be specific about the type of open source license they must use.
  • The Foundation should own all of the domain names and trademarks for key pieces of infrastructure, ie: if a bounty is rewarded for - would be owned by the Foundation and licensed to the project for use. If the dev disappears, you don’t lose a piece of infrastructure.
  • Create the application process so it is transparent to the community for comment and input. Zcash has even added tipping so community members can chip in funding for a project, whether it receives a foundation grant or not.
  • Use legal contracts to your advantage, if a grantee is not delivering, enforce them. It will create legitimacy for the program and provide protections for the community that bad behavior is not okay.
  • Work with large service providers should use SLAs, not just standard grant legal docs.
  • Use proven momentum to issue larger grants, for example, all grantees would need to fulfill a smaller bounty or create something for the community for free to start. Then they could apply for a $1-$5k grant. If they successfully deliver, then they can be considered for up to a $50k grant, then $100k. It helps move quickly with smaller grants, and creates a path for people to graduate to larger grants.

Grants Program Next Steps

We’re working to kick off our Grants Program soon. Now’s the time to get involved. We’re still taking feedback on the application questions through Github Governance here and are interested in hearing from individuals and teams who plan to submit an application.

We have ambitious visions for the Grant Program which are only possible through community involvement, feedback, and applications. We’re starting small but this is only the beginning!


awesome. Thanks for feeding this info back to the community. Buidl on.

1 Like

I wonder about the implications of having the Foundation own everything… the domains, trademarks, etc. This is obviously centralized ownership. It can reduce the reward incentive of third parties to contribute and build infrastructure. Also, if any content is created atop these Foundation owned domains that a government, for example, does not like, the Foundation could see pressure to take down some site or content, which is counter to our self-sovereign/user-owned goal. I think it could also be unpleasant (/sarc) for the Foundation to have such pressure from gov agencies.
cc: @dant


I agree that we want less centralized control but keeping spaces open. The advice came from a project that had funded a grant, let’s say it’s for a project called X project. A team built and built a large following and customer base. Lots of community members invested a lot to support the In less than a year, the original developer abandoned the project and now the domain still has high traffic but no activity. In hindsight, they wished they could reclaim the domain for the community’s use by having it be owned by the community and redirect towards new community projects.

I would prefer a method that allows for (a) community ownership (b) high level domains in the ecosystem to be used like utilities {where they can be used by many}. Foundation ownership, or co-ownership is the MVP but a better solution would be very welcome!


Near term I think your plan will be fine. Longer term I would hope, if it’s possible, that apps move away from requiring domains at all and use other distribution means. Domains are a way to take down apps (by gov agencies), or lose control of them as you said above. I think this is relatively easy with mobile apps and desktop apps - where apps can be distributed via apps stores even non gorilla ones like (eg. Blockstream’s green wallet is published there) but also users can distribute apps via the Android .apk binary files if they want. Also I assume that .apk files, Windows .exe files, and Linux binaries can be distributed via Torrents and current FOSS distribution means. Long term I hope we can stop using the centralized domains/DNS system. @jude is it possible at least for apps that don’t have a server-side component? Progressive Web Apps?


Very excited about this. I am certain it will lead to great things, although I share some of the same reservations as @fluidvoice.

@fluidvoice, technically, BNS could already be used to resolve to IP addresses. Naturally that means that you still need a server if you want to be compatible with the old-fashioned internet/browsers. With some tinkering you could probably have something consume information from a Gaia bucket.