Initial SDK release

[sammccord]

• add @boostxyz/sdk, v0 structure, functionality for all protocol artifacts (except ERC1155Incentive)
• tsdoc comments + gha for automatic tsdoc release flow
• sdk integration tests using hardhat
• release pipeline

[linear]

BOOST-3883 Protocol V2 SDK Creation Flow

Create

• Pull this logic into a react hook
  • We need to update the useCreateQuestMutation

This is our current data structure for creation:

export const CreateQuestInputSchema = z.object({
  networkId: z.string().optional(), // used to specify the network when a task supports multiple
  projectId: z.string().uuid(),
  actionId: z.string().uuid().optional(), // this is actually taskId
  taskId: z.string().uuid().optional(),
  // TODO: update to support reward network like quests query
  actionParams: QuestActionParamsSchema,
  rewardTokenId: z.string(), // TODO: remove this in favor of rewardTokenAddress & rewardTokenNetworkId
  rewardTokenAddress: z.string(),
  rewardTokenNetworkId: z.string().optional(),
  rewardAmount: z.string(),
  participantLimit: z.number(),
  startTime: z.string().optional(),
  endTime: z.string(),
  accessList: z
    .object({
      allow: z.array(z.string()).optional(),
      deny: z.array(z.string()).optional(),
    })
    .optional(),
});

There's two different networks in play - the action network and the reward network. Assuming we're going to be using a node-based architecture with edges on each network we presumably don't need to monitor the chain-state.

Initially it probably makes sense for the contract network to be the reward network. In the new architecture we handle this by passing asset in instead of rewardTokenAddress POOL in for Strategy, reward in for rewardAmount and limit in for participationLimit

There isn't currently a notion of startTime or endTime in the contract system. A SimpleAllowList can work when the accessList is small, but it requires all the addresses to be passed on-chain so we may need a different solution near term. We could continue to rely on signatures for this, at which point we would need an on-chain allowlist that serves to store our backend identifiers for the off-chain allowlists.

This leaves all of the remaining fields that need to be represented on-chain in some fashion:

networkId: z.string().optional(), // used to specify the network when a task supports multiple
projectId: z.string().uuid(),
actionId: z.string().uuid().optional(), // this is actually taskId
taskId: z.string().uuid().optional(),
// TODO: update to support reward network like quests query
actionParams: QuestActionParamsSchema,

We need to create an Action that encodes all of this information.

[Quazia]

hell yeah this looking sexy af 🔥

[Quazia]

This is what I'm going to start working on today

[sammccord]

I like an AsyncGenerator for this to provide incremental updates to the calling context, you could potentially feed them into SSE or websockets for good feedback, and you have better clarity into how far the task got if something went wrong.