Juicebox primary sources — 2026-05-10

What I reviewed

• Official site / docs:
  • https://juicebox.money/
  • https://docs.juicebox.money/
  • https://docs.juicebox.money/dev/
  • https://docs.juicebox.money/dev/v5/learn/overview/
  • https://docs.juicebox.money/dev/v5/learn/glossary/ruleset/
  • https://docs.juicebox.money/dev/v5/learn/glossary/splits/
• Official repositories:
  • https://github.com/jbx-protocol/juice-docs
  • https://github.com/jbx-protocol/juice-contracts-v3
  • https://raw.githubusercontent.com/jbx-protocol/juice-contracts-v3/master/README.md
  • https://raw.githubusercontent.com/jbx-protocol/juice-interface/main/README.md

Key takeaways from primary sources

• Juicebox should be cataloged as programmable treasury infrastructure, not merely as a donation or crowdfunding site. The current docs describe it as a payment processor and capital-formation engine for tokenized fundraises, revenues, incentives, and financial operations.
• The core mechanism is the scheduled ruleset. Each project can pre-commit evolving policies for token issuance, payout caps, surplus allowances, reserved-token allocation, and cash-out conditions.
• The project NFT is an important governance surface because it represents the administrative control point over future configuration.
• The payout-limit / surplus / cash-out structure is the main treasury insight: projects can spend within programmed limits while token holders may reclaim value from surplus, which creates a more structured contributor exit claim than ordinary crowdfunding.
• Splits are not just bookkeeping. They let projects pre-program the routing of funds and reserved tokens across addresses, other Juicebox projects, or hook contracts, so distribution logic becomes part of the protocol surface.
• The hooks system is analytically important because it makes Juicebox extensible at the edges. Projects can change payment handling, cash-out behavior, split execution, and ruleset approval criteria without abandoning the base system.
• The interface repository matters because practical Juicebox governance is partly exercised through defaults, flows, and documentation in the live frontend, not only through base contracts.

Specific source signals worth retaining

• Developer introduction: frames Juicebox as a payment processor and capital-formation engine; explicitly highlights rulesets, hooks, contract addresses, and AI-readable docs.
• V5 overview: shows the protocol as a configurable project machine with project NFTs, queued rulesets, payout limits, surplus, reserved-token splits, omnichain support, and custom hooks.
• Ruleset glossary: makes timing and approval-hook governance explicit, especially the fact that active rulesets are fixed while future ones can be queued.
• Splits glossary: confirms that payout and reserved-token routing can target wallets, projects, or contracts and can be selectively locked.
• juice-contracts-v3 README: grounds Juicebox as a substantial contracts system with its own architecture, deployment flows, and protocol docs reference.
• juice-interface README: confirms there is an official frontend application layered over the protocol and funded/maintained within the ecosystem.

Why this entry belongs in the corpus

• Juicebox belongs because it offers a reusable treasury design pattern: tokenized capital formation with scheduled configuration, programmable distribution, and contributor redemption rights.
• It is especially useful next to MolochDAO, Allo Protocol, Gitcoin Grants Stack, and Commons Stack because it separates questions of fundraising, issuance, governance, and treasury exit more cleanly than many “DAO” products do.
• The reusable insight is that treasury systems often hide their real politics in issuance schedules, payout ceilings, exit rights, and routing defaults rather than in headline token-voting mechanics alone.