Security model
Understand which component is trusted to authorize, price, and settle an operation.
The core must enforce account ownership, authorization, user limits, and solvency for every caller. A helpful SDK cannot protect a program from transactions that bypass it.
Trust boundaries
| Boundary | Required enforcement |
|---|---|
| Client to core | Validate inputs, signers, mints, program owners, PDAs, and account relationships |
| Core to math | Validate numerical domains and checked results |
| Core to pool hook | Authenticate the callback; restrict accounts and accepted replies |
| Core to token program | Use the configured token program and actual vault/mint/authority |
| Snapshot to adapter | Verify layout/version and reject missing state or unsupported policy |
| Quote to execution | Apply user limits to the actual state and token movements |
Hooks have power within a contract
A hook can reject an operation, return a bounded fee where enabled, and mutate declared state within per-phase permissions. The core checks account classes, program/owner declarations, limits and protected aliases; the hook checks exact role-specific identities and state invariants. It must not borrow the user's signer or vault authority. Custom accounting needs a separate conservation and quote contract and is currently rejected.
An upgradeable hook or core introduces an upgrade authority into the trust model. An immutable binding does not freeze the code behind an address. No upgrade governance or emergency-exit guarantee should be inferred from the existence of an ABI.
Assets and identities
Keep signing secrets outside application logs and documentation. Separate transaction fee payment, token authority, hook authority, and program upgrade authority in your application’s trust model.
The trader, transfer authority, and output owner have distinct meanings. A real signer proves control of a key for the transaction; it does not prove civil identity or the final recipient of an arbitrary multi-hop route.
Evidence and review
No audit or production-readiness claim is made by this site. Security claims must identify the inspected revision, tested path, and remaining limitations. Continue with invariants and validation.