Actions and recipes
ActionAdapter, the registry, the built-in adapters and the two recipes.
ActionAdapter<P>
Prop
Type
BuildResult
Prop
Type
Contexts
ActionContext gives account, pub(chainId), policyFor(chainId, target, selector) (live on-chain lookup) and now(). ExecutionContext adds plan, step and, for CCTP relays, the fetched attestation.
Registry
| Function | Purpose |
|---|---|
registerAction(adapter) | add or replace the adapter for a kind |
getAction(kind) | look one up; built-ins register lazily on the first miss |
listActions() | all registered kinds |
registerBuiltinActions() | register the seven built-ins explicitly |
Built-in adapters
| Export | Kind | Params |
|---|---|---|
compoundSupplyBorrow | supply_borrow | { amountUsdc6, wethWei?, targetHealth?, borrowAprPct? } |
compoundRepay | repay | { amountUsdc6, withdrawWethWei? } |
cctpBurn | bridge_burn | { amountUsdc6, fromChainId, toChainId } |
cctpRelay | bridge_relay | { fromChainId, toChainId } (direct step; resolves the attestation at execution) |
pay | pay | { to, amountUsdc6, chainId?, mode?: "native" | "erc20" } |
scheduleRepayment | schedule_repayment | { amountUsdc6, dueAt, venue? }; records the created id in params.repaymentId |
markRepaid | mark_repaid | { repaymentId } |
All bigint params accept strings too, because plans round-trip through JSON.
ActionRequest
interface ActionRequest<P = any> { kind: StepKind; params: P }client.plan(requests, { intent, venueId, venueExplanation }) builds a Plan from a list of them, in order.
Recipes
import { recipes } from "@yashjain99/mandate-sdk";| Recipe | Steps |
|---|---|
recipes.liquidity(client, intent, opts?) | supply_borrow → bridge_burn (Base→Arc) → bridge_relay → pay (if recipient) → schedule_repayment |
recipes.repayment(client, repayIntent, opts?) | bridge_burn (Arc→Base, only for the shortfall Base cannot cover, plus fee headroom) → bridge_relay → repay → mark_repaid (if repaymentId) |
opts carries venueId, venueExplanation, borrowAprPct and an optional id. Recipes read balances from exactly one source per chain and derive requiresGuardian from the live policy.
The repayment split is the pure function splitRepayment({ requested, debt, baseUsdc, arcUsdc }): it repays from Base when Base holds enough, otherwise bridges the shortfall from Arc with headroom for the CCTP fee, and when both chains together cannot cover the request it repays what is available and says so in venueExplanation instead of drafting a step that would revert.