stockpilelabs/stockpile-v2

Community driven funding for the open internet.

Stockpile v2

Funding Without Barriers.

Website • Twitter • LinkedIn

Overview

Stockpile is a decentralized funding engine for the open-internet. Leveraging the speed of Solana, the protocol facilitates general crowdfunding campaigns, quadratic funding rounds, and fair hackathons with verifiable transfers/calculations, all at the speed of light. Stockpile is designed for builders and creators to leverage their communities to raise the funds needed for their next endeavor, and is (to our knowledge) the first of its kind on any blockchain.

Highlights

• General Crowdfunding: Inspired by the likes of Kickstarter and Indiegogo, the protocol features general crowdfunding by default, which is applicable for most projects and initiatives. This also features optional reward distribution via NFTs, which is handled on the frontend.
• Funding Rounds: Stockpile features permissionless, configurable quadratic funding rounds hosted on-chain. Anyone with size is permitted to create a round to equitably fund projects and causes pertaining to the initiative their looking to move forward.
• Milestones: Most ecosystems structure grants in milestones. We've taken this into account, and implemented this on-chain in conjunction with both general crowdfunding, and funding rounds. Milestones are created under a project, and require the user to specify a condition, along with an intended completion date. In addition, future pools will be have the option to gate based on a presence of these accounts. As of right now, there is no approval process, and these exist only for transparency. This feature is still experimental, and requires proper frontend implementation to be useful.

Getting Started

Ensure the Solana-CLI & Anchor-CLI are installed

solana --version && anchor --version

Clone this repository

git clone https://github.com/StockpileProtocol/stockpile-v2.git

Build & generate an IDL

anchor build

Program Addresses

Mainnet & Devnet: STKUaKniasuqrfer3XNbmrrc578pkL1XACdK8H3YPu8

Contributing

Review the CONTRIBUTING.md file for more information on how to contribute to Stockpile v2.

Disclaimer

This code is unaudited. Copy and use at your own risk. We incur no liability in the event that a third-party uses this code, and has issues deriving from exploits or any other attacks.

Credits

Special thank you to Buffalo Joe (Solana Labs) & Valentin Madrid (Squads) for helping to get us started, and Sean (Squads) for technical advisory.

stockpile-v2's Issues

Unit Tests for Milestone Resolution

This functionality is a bit accessory, but still important for those looking to build on top of the Stockpile Protocol. Need to make sure milestone resolution works as intended, where a project creates one or more milestone PDAs, where the percentages denote how much they can withdraw. The milestone is then resolved by an admin key, which will be one of three wallets under our control (someone forking this can change that though). These tests would require both Rust for the helpers and Typescript for the entire instruction.

Quick note on this. I've thought about slightly changing this system to allow X% of the total goal to be withdrawn upfront, and having completion of the milestones account for the withdrawal of the other Y%. Was thinking something along the lines of 10% upfront. Any input on this idea is welcomed!

Unit Tests for Claiming Process

To ensure everything is working as expected, it'd be helpful to write unit tests for the "claim_payout" function and it's helpers. This is the key last leg of the journey for a project participating in a funding round, and the idea of this being exploited saps the joy from my life.

New: Implement MarginFi to Stockpile Trusts

The early build of the stockpile-trusts program supports only Kamino, but that's far from the endgame. In vault.rs, you'll see an enum meant to denote a user's protocol of choice, and next up is MarginFi.

The business logic can be handled with simple control flow, however the CPI into their program is what's holding me back. They do not (to my knowledge) have a published crate for v2, and I am too lazy to go through their IDL right now.

If anyone wants to take the plunge on this, I'm happy to help!

Chore: Optimize "contribute_with_vote" CU usage

The "contribute_with_vote" instruction is intended to to three things:

• Validate that the relayer partial signed the transaction, or the caller has a valid Civic Pass
• Reallocate project shares via the quadratic funding algorithm
• Conduct the token transfer and corresponding account mutations

As you can probably imagine, this is very compute heavy. With a small sample size of projects and voters, this is not a huge issue. With priority fees prepended to the transaction, it has few problems landing in a block. The problem comes in rounds with larger sample sizes. Since there are more votes to account in the calculation, the compute unit usage will quickly escalate to the 1.4m bound. That being said, there are ways to optimize the instruction and its helpers to alleviate this bottleneck.

Instead of one pool account, this should likely be redesigned to use a network of PDAs, and doing this is on the table if you're looking to attack this issue

Add: Switchboard/Clockwork Automation

One of the key pieces I'd like to add to this program is automated withdrawals and contributions via Switchboard or Clockwork. This would make the flow truly passive for a user, allowing them to deposit and auto contribute interest. This is one of the intended functions of the program, but isn't a total dealbreaker.

Unfortunately, I have zero experience with Switchboard's functions feature (not that well documented), and Clockwork was sunset months ago. From my understanding, there's a fork of Clockwork that is being actively maintained, and has workers running on mainnet. However, I have not been able to find this repo anywhere.