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

The Boost Protocol, fundamentally, needs to be able to validate that certain actions have occured in order to allow users to claim incentives. So in order to make it simple to create Boosts and validate them, we publish @boostxyz/signatures which is a registry of known function and event signatures, their 32 byte selectors, and AbiEvents or AbiFunctions in an easy to consume JSON format.

You can use this library as you’re creating a Boost and building out action steps for use with the Event Actions. You’ll need to specify the function or event’s signature, which allows Boost’s validators to parse the event or function arguments, and compare them against the rest of the actions’ parameters.

So in order to simplify applications that would otherwise need to know the hex encoded 4 byte function selector, or 32 byte event selector, and their associated ABI items, you can instead use this library to save on code and complexity.

// you can import both events and functions registries
import { events, functions } from '@boostxyz/signatures'
// ...or individually
import events from '@boostxyz/signatures/events'
import functions from '@boostxyz/signatures/functions'

// both events and functions manifests have the following interface:
type eventsOrFunctionsRegistry = { abi: Record<(Hex | string), AbiItem>, selectors: Record<string, Hex> }
// where string keys are the signature ie: Transfer(address indexed,address indexed,uint256 indexed)

// the event signature we'll be using to compose the action
const knownSignature = "Transfer(address indexed,address indexed,uint256 indexed)"
const selector = events.selectors[knownSignature] // 0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef
const abiItem = events.abi[knownSignature] // {name:"Transfer",type:"event",inputs:[{type:"address",indexed:true},{type:"address",indexed:true},{type:"uint256",indexed:true}]}

// now you have everything you need to construct your event action
const filterOnReceiver: ActionStep = {
  chainid: 8453,
  signature: selector,
  signatureType: SignatureType.EVENT, // We're working with an event
  targetContract: targetContract, // Address of the contract emitting the `Transfer` event
  // We want to target the 'receiver' property on the Transfer event
  actionParameter: {
    filterType: FilterType.EQUAL, // Filter to check for equality
    fieldType: PrimitiveType.ADDRESS, // The field we're filtering is an address
    fieldIndex: 1, // We want to target the second argument (index 1) of the event signature
    filterData: '0xc0ffee', // Filtering based on the recipient's address
  },
};

If you’ve used a function or event signature from @boostxyz/signatures in the creation of your Boost, then you don’t have to do anything else for validation to work.

Otherwise, if you’re supplying a custom event signature unknown to @boostxyz/signatures and dealing with a Boost using a custom validator, you’ll need to additionally supply your own AbiEvent to validation methods so event logs can be correctly pulled off transactions.

await boostCore.validateActionSteps({
    ...,
    knownEvents: {
        '0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef': {
            name: "Transfer",
            type: "event",
            inputs: [
                { type: "address", indexed: true },
                { type: "address", indexed: true },
                { type: "uint256", indexed: true }
            ]
        }
    }
})

For more detailed examples, see sample use cases

Contributing new signatures

If using the default Boost validator, you also have the option of submitting your contract events and functions to openchain.xyz or 4byte.directory, but contributing to @boostxyz/signatures is preferred due to its approach as a static manifest as opposed to a third party API.

To integrate your contracts with the Boost V2 Protocol:

The Boost Protocol team will review the submission and promptly release a new version of the @boostxyz/signatures package so you can continue your Boost Protocol integrations.