Community Stacking Pools

Currently, user stacking is limited to a few companies offering custodial pooling services. While these have been hugely valuable to the community, several community projects could use a base smart contract that would lower the barrier to providing stacking pools for a diverse range of communities and applications and be extensible so that individual stacking pool providers can differentiate their services.

Last week the Boom team was awarded a grant to build the foundational pieces for this vision. You can find the details of the grant here:

Milestone 1 of our roadmap includes building an initial prototype. To find out what is needed to run a pool, “Friedger Pool” was created as soon as the Stacks Wallet supported delegation. It has been wildly successful. Over 1 million STX from roughly 200 users has been stacked in the initial test of a community pool led by @friedger. I’m still amazed by this, but we intend to make it easier for communities to build their own stacking pools. We received a lot of feedback and questions that will help us to create better documentation and tools.

“Friedger Pool” uses a smart contract to manage the delegated STXs. This is based on the “Boom Pool” contract. You can find that here. This contract has been deployed to testnet.

The development of the prototype happens in the clarity-pool-registry git repo. It contains the following smart contracts and unit tests:

  • pool-tool for pool administrators
  • pool-registry for the registry of pools

Here I’ll give a general overview of the plan and layout the roadmap for continued development.


The components/architecture include:

1.Pooling PoX trait- A “trait” is basically a standard building block. This building block will house the delegation function. This will allow a standard interface to build on. By separating this from the actual Pool Provider contract (see below), we can enable communities to build the rules for their own pools independently.

2.Pool Provider contract- An example contract that implements the Pooling PoX trait (#1 above), registers with the Registry contract (#3 below), and adds functionality specifically for a community. For example, our initial example includes a bond, or insurance, that guarantees a minimum payout per stacker, if the reward is not paid. Other Pool Provider contracts may implement fee structures, minimum stacking amounts, membership requirements, or whatever suits their particular demographic. These are just examples and would need to be provided by the Pool Providers.

3.Registry contract- Provides a listing of Pool Providers that choose to register. This contract will enable a simple way for users to find Stacking pools in a decentralized way. Web sites like Start Stacking can use the contract to build their recommendations.

4.Web app- An example web application that queries Pool Providers from the Registry (#3) list and allows the user to join a pool by calling the Pool Provider (#2).

Here is a high-level view of the flow and data interactions:

Development tasks

Over the next 2 weeks, we plan on:

  1. Document the process of delegation and running a pool

  2. Document interfaces for the Pool Trait

  3. Work with the community to build simple Pool Provider options and test, e.g. variations of Boom Pool and a Charity Pool.

  4. Build the web application


After building these components, we will deploy them to mainnet. Your feedback and questions are appreciated.