Resolve hooks in SDK operations
Keep hook policy in external packages while preparing authenticated lifecycle context.
A hookless pool is valid. When a pool has a hook, the direct client requires a matching GraplHookResolver. The resolver belongs to the hook's external package; the core SDK does not embed an allowlist, trading window, reward scheme, or dynamic-fee policy.
Match the pool's contract
Each resolved plan binds the configured hook program, ABI version 4, per-operation payload, access descriptors, and account metas. Dependencies carry explicit expected ownership and executable status. Missing resolvers, unknown programs, or incompatible dependencies reject preparation.
The generated TypeScript declarations define the exact resolver interface. Read Hook ABI and permissions before providing an implementation.
Compose rules inside one hook
One hook can combine several policies. Resolve all declared dependencies in the expected order and preserve each account's permitted access by phase. An allowlist proof does not replace caller authentication, and a time policy must use the authenticated on-chain clock.
Policy composition explains the program side. Wallet context distinguishes the transaction signer, operation actor, source authority, and destination owner, especially for routers or sponsors.
Prepare and verify
Pass the resolver through the client configuration according to its current types. The transaction preparation step preserves hook payload and account ordering, then simulates the complete operation. On-chain callback authentication and permission checks remain authoritative.
A rejected callback can roll back the operation; network fees may still be charged. The SDK resolver is not an independent security review or proof that an arbitrary hook can be routed by Jupiter.
For large proofs or account lists, read Address Lookup Tables. Never shorten a proof, remove required accounts, or disable a callback just to fit a transaction.