-
Notifications
You must be signed in to change notification settings - Fork 7
Open
Labels
SDKenhancementNew feature or requestNew feature or requestquestionFurther information is requestedFurther information is requested
Description
Description
Right now, SDK implementers creating Boosts with EventActions accept a non-zero amount of cognitive load and guesswork to build a correct ActionStep, including:
- Figuring out the
fieldIndexof the parameter to compare against, which is potentially error prone and only resolved by cancelling and recreating the boost - Figuring out how to properly encode the
filterData, which involves using viem utilities and right-sizing the bytes for the type, which can be error prone - for example:filterData: toHex(1n, { size: 1 })
Suggested Solution
If the signature is supported in @boostxyz/signatures, we should be able to utilize typescript generics and type inference to know the types of arguments at each index, what the fieldType is, and how to correctly encode the filterData given the ABI type, removing two potential sources of human error in Boost construction, and moving errors that would normally occur during validation, like FieldValueNotComparableError and InvalidNumericalCriteriaError, into the construction step.
In pseudo code, the API could work like:
const actionStep = buildActionStep({ chainId, signatureType, targetContract, signature }, filterType: FilterType, fieldIndexOrEventOrFunctionName: number | string, data?: T)
function buildActionStep(base, filterType, indexOrName, data): ActionStep {
const abi = knownEvents.abi[base.signature]
const field = typeof indexOrName === 'number' ? abi[field] : abi.inputs[indexOrName]
return {
...base,
actionParameter: {
filterType,
fieldIndex,
fieldType: fieldTypeFromAbiType(field.type),
filterData: encodeAbiItem(data, field.type)
}
}Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
SDKenhancementNew feature or requestNew feature or requestquestionFurther information is requestedFurther information is requested