Boost Protocol

• Name: Boost Protocol
• URL: https://boost.xyz/
• Category: onchain incentive infrastructure / action-reward middleware / growth-and-retention campaign protocol
• Summary: Boost Protocol is a campaign rail for paying users to do specified onchain things. The reusable part is not the quest frontend but the module split between actions, validators, incentives, budgets, allowlists, and registry-managed implementations. Keep it as infrastructure for sponsor-defined behavior and retention campaigns, with practical discretion still sitting in action approval, validation, and distribution.
• What it does:
  • Lets teams create one-time campaigns that reward discrete onchain behaviors such as mints, swaps, votes, delegations, and contract interactions
  • Supports time-based campaigns that reward the size and duration of open onchain positions rather than a single completed action
  • Breaks campaign logic into reusable modules including actions, validators, incentives, budgets, and allowlists coordinated through Boost Core and a Boost Registry
  • Uses offchain indexing, validation, and claim-signature generation where needed, then verifies proofs and distributes rewards onchain
  • Provides a self-serve platform, API, and SDK for configuring campaigns, retrieving claim data, and integrating Boost-backed incentives into other applications
  • Surfaces campaigns to users through rabbithole.gg, which acts as a distribution and claim interface for both one-time and time-based campaigns
• Key claims:
  • The platform docs make the product split explicit: Boost now spans both One-Time Actions and Time-Based Incentives, so it should be modeled as general-purpose incentive infrastructure rather than only as a quest product.
  • The V2 architecture page is analytically useful because it shows where the protocol economizes trust: complex action validation can happen offchain, but a signed proof is brought onchain for verification and reward distribution. That means practical power can centralize in validation and signature policy even if final claims settle onchain.
  • The repository README gives the clearest modular picture. A Boost is not one monolithic contract but a composition of Core, Registry, Action, Validator, Incentive, Budget, and AllowList components, each of which can be reused or customized. This is the main reason the entry belongs in the corpus.
  • The Budget and AllowList abstractions matter because they show that campaign governance is not only about reward size. The deeper control plane is who can participate, what treasury pot funds the incentives, and whether campaigns can be chained together to progressively reward more specific user cohorts.
  • The One-Time Actions setup docs reveal that Boost is not fully permissionless in practice today: new actions are reviewed and approved by the Boost team before use. That is an important live centralization point because it determines which behaviors can be productized into campaigns and how quickly novel integrations go live.
  • The Time-Based Incentives docs matter because they shift the system from rewarding discrete completions to continuously rewarding retained positions. That makes Boost comparable not only to quests but also to liquidity mining, retention campaigns, and offchain growth tooling wrapped around onchain state.
  • The rabbithole.gg distribution layer is part of the mechanism, not a side detail. Discovery, user onboarding, and claim UX can become a rent-collection and demand-shaping surface even when underlying reward logic is modular.
  • Boost is a useful comparison class for Royco because both are trying to turn user behavior into programmable incentive objects, but they differ in emphasis: Royco increasingly prices negotiated market behavior and orderflow-like coordination, whereas Boost packages sponsor-defined onchain actions and retention targets into campaign infrastructure.
  • The strongest caution signal from the primary materials is that the protocol remains under active development and warns against production use prior to first official release, so any downstream adoption analysis should distinguish between architectural ambition and current operational maturity.
• Whitepaper: No canonical standalone Boost Protocol whitepaper surfaced in this pass. The strongest primary materials were the official platform docs, One-Time Actions architecture and setup docs, Time-Based Incentives docs, and the official repository README; see ../whitepapers/boost-protocol-primary-sources-2026-05-10.md.
• Sources:
  • https://boost.xyz/
  • https://docs.boost.xyz/platform/overview.md
  • https://docs.boost.xyz/v2/documentation/overview/introduction
  • https://docs.boost.xyz/v2/documentation/architecture/core-boost-v2
  • https://docs.boost.xyz/v2/documentation/getting-started/setting-up-an-action.md
  • https://docs.boost.xyz/tbi/how-it-works.md
  • https://github.com/boostxyz/boost-protocol
  • https://raw.githubusercontent.com/boostxyz/boost-protocol/main/README.md

Internal linkages

• royco-protocol is the clearest market-style contrast: Royco prices user actions directly, while Boost packages sponsor-defined actions into campaign modules.

• merkl is the cleaner reward-computation contrast: both rely on offchain logic, but Merkl is mainly emissions accounting and routing rather than action-specific campaign design.

• votemarket is the narrower governance-incentives contrast, where the paid behavior is voting power rather than a broader menu of sponsor-defined actions.

• Last reviewed: 2026-06-01 UTC