Overview
Learn about the role the Registry plays in the SDK
Under Construction The V2 Protocol, SDK, and these docs are under active development. You can find the latest testnet deployments here
In prerelease Currently the SDK and protocol only support Sepolia. Public API’s are stable, but could still change before our initial release. If you experience any bugs, please open a Github issue
Smart Contract
Read the smart contracts
Typedoc
SDK Implementation
See the source
The Boost Registry contract is a key touchpoint within the protocol, allowing users to initialize components they intend to re-use across multiple Boosts, like Budgets or AllowLists.
Unless you’re an advanced user, you will likely never need to deploy your own and registry
contract. The SDK
comes preconfigured with the correct contract addresses for all deployed core implementations.
The registry aspect to the Registry
is just that, a registry of valid Action
, AllowList
,
Budget
, Incentive
and Validator
implementations that can be utilized and
extended by clients of the protocol.
Going forward, the term component
in reference to a Boost, refers to any Action
, AllowList
, Budget
, Incentive
or Validator
.
As opposed to upgrading the source of the protocol contracts over time to add features, the Boost team will, as needed, register new implementations that adhere to Action
, AllowList
, Budget
, Incentive
or Validator
interfaces that can then be leveraged in the creation of new Boosts.
In most cases, you’ll be interacting with the registry to initialize budgets that you can then use and reuse in your Boosts. For example,
Ideally, you’ll store a record of your budgets in some database, but the registry does contain some helpers to retrieve information about components you’ve initialized. For example, you can retrieve the address of the budget initialized above with the following flow.
Any component you initialize through the registry can be retrieved this way as well by passing the address you used to interact with the registry.
What does it mean to clone
a base
implmentation?
Boost components aren’t instantiated traditionally, with parameters supplied to the contract’s constructor on deployment. Instead, to ensure each Boost component is compliant with a registered base implementation, and save on gas, components are either cloned from a deployed base contract and initialized ahead of time through registry before being referenced in Boost creation, or, for some components, initialized at time of Boost creation, like Incentives
.
A base implementation is any deployed contract registered with the registry, thus valid for use with Boost creation, that satisfies the interfaces for either Action
, AllowList
, Budget
, Incentive
or Validator
. For example, ManagedBudget is a base implementation that satisfies the Budget interface.