Zap Compatibilities

Zap has a fixed compatibility surface in the on-chain program. Use this page to check whether a user flow maps to one of Zap’s supported instructions.

Instruction Surface

Instruction	Purpose	Main constraint
`initialize_ledger_account`	Create the user ledger PDA.	`owner` and `payer` sign.
`set_ledger_balance`	Write token A/B or token X/Y amount into the ledger.	Ledger owner signs.
`update_ledger_balance_after_swap`	Record a post-swap balance delta, capped by `max_transfer_amount`.	Ledger owner signs.
`close_ledger_account`	Close the ledger and send rent to `rent_receiver`.	Ledger owner and rent receiver sign.
`zap_in_damm_v2`	Add DAMM v2 liquidity, optionally swap surplus through DAMM v2, then add again.	Existing DAMM v2 position; owner signs.
`zap_in_dlmm_for_uninitialized_position`	Initialize a new DLMM position and add liquidity through `rebalance_liquidity`.	Position account must be empty and sign.
`zap_in_dlmm_for_initialized_position`	Add liquidity to an existing DLMM position through `rebalance_liquidity`.	Ledger owner signs.
`zap_out`	Swap a percentage of a detected token balance increase.	Route must be whitelisted by program and discriminator; swap authority comes from the supplied route accounts.

Compatibility Matrix

Area	Supported	Important constraint
Program ID	`zapvX9M3uf5pvy4wRPAbQgdQsM1xmuiFnkfHKPvwMiz`	Same declared ID in the program.
DAMM v2 Zap In	Yes	Swaps only through DAMM v2 `swap2` inside the Zap In flow.
DLMM Zap In	Yes	Adds through DLMM `rebalance_liquidity`; Zap does not withdraw or claim in this instruction.
DLMM strategies	`Spot`, `Curve`, `BidAsk`	`min_delta_id <= max_delta_id`.
Zap Out routes	DAMM v2 swap, DLMM `swap2`, Jupiter v6 route, Jupiter v6 shared-account route	Route is checked by program ID plus 8-byte instruction discriminator.
Zap Out percentage	`1` to `100`	Values outside this range fail.
Ledger	User-owned PDA	Seeds are `["user_ledger", owner]`; ledger instructions require owner signature.
Token transfer fees	Partially supported	Zap In math uses transfer-fee-excluded amounts where it calculates liquidity or strategy amounts.

Whitelisted Zap Out Routes

Zap Out only invokes a swap if the supplied amm_program and the first 8 bytes of payload_data match one of the whitelisted pairs:

Route	Program-level check
DAMM v2 swap	DAMM v2 program plus DAMM v2 swap discriminator.
DLMM swap	DLMM program plus `swap2` discriminator.
Jupiter v6 route	Jupiter v6 program plus route discriminator.
Jupiter v6 shared-account route	Jupiter v6 program plus shared-account route discriminator.

Unsupported Jupiter instruction variants, custom routers, or arbitrary AMM instructions are rejected with AmmIsNotSupported.

Access Controls and Accounts

Action	Required authority
Initialize ledger	`owner` signer and `payer` signer.
Set ledger balance	Ledger `owner` signer.
Update ledger balance after swap	Ledger `owner` signer.
Close ledger	Ledger `owner` signer and `rent_receiver` signer.
DAMM v2 Zap In	Ledger `owner` signer, also used as DAMM v2 position owner.
DLMM Zap In	Ledger `owner` signer, plus `rent_payer` signer.
Zap Out	No owner signer is enforced by Zap itself; the invoked swap route must receive whatever signers/accounts it requires.

The ledger account has has_one = owner checks on mutable instructions. For uninitialized DLMM positions, the position account must be a signer, must be empty, and must not equal the owner or rent payer. Zap Out does not verify the token account owner; integrators should build the surrounding transaction so the route authority and token accounts are the intended user accounts.

Flow Constraints

Flow	Constraint
DAMM v2 Zap In	Zap calls DAMM v2 `add_liquidity` with `token_a_amount_threshold` and `token_b_amount_threshold` set to `u64::MAX`; price protection comes from `max_sqrt_price_change_bps` around the optional balancing swap.
DAMM v2 Zap In	If the surplus-side swap calculation fails or returns zero input/output, Zap returns successfully after the first add-liquidity attempt and leaves remaining amounts in the ledger.
DLMM Zap In	Strategy parameters are generated from the pair’s on-chain active bin at execution. The caller-supplied `active_id` is forwarded to DLMM with `max_active_bin_slippage`.
DLMM Zap In	Zap sets `should_claim_fee = false`, `should_claim_reward = false`, `min_withdraw_x_amount = 0`, `min_withdraw_y_amount = 0`, and `removes = []`.
Zap Out	`payload_data` must start with an 8-byte supported instruction discriminator, and `offset_amount_in` must point to the amount-in field to rewrite.

Token Compatibility

Zap In calculates transfer-fee-excluded amounts for token mints when it needs to reason about net deposit amounts. For Token 2022 mints without a transfer fee extension, the calculation is treated like a normal token amount.

Do not assume every Token 2022 extension is compatible with every underlying DAMM v2, DLMM, or Jupiter route. Zap can coordinate supported instructions, but the downstream program still defines whether a token behavior is valid.

Not a Fit

Use a direct integration instead of Zap when:

The target AMM is not DAMM v2 or DLMM.
The Zap Out route is not one of the four whitelisted instruction types.
The flow needs Zap In swaps through Jupiter or another external router inside the Zap instruction.
The DLMM flow needs Zap itself to withdraw liquidity, claim fees, or claim rewards.
The token behavior is unsupported by the underlying product or route.
The product copy needs to promise best execution, guaranteed output, or automatic route selection.

User Guides

Core Products

Helper Products

Legacy Products

Instruction Surface

Compatibility Matrix

Whitelisted Zap Out Routes

Access Controls and Accounts

Flow Constraints

Token Compatibility

Not a Fit

​Instruction Surface

​Compatibility Matrix

​Whitelisted Zap Out Routes

​Access Controls and Accounts

​Flow Constraints

​Token Compatibility

​Not a Fit

Instruction Surface

Compatibility Matrix

Whitelisted Zap Out Routes

Access Controls and Accounts

Flow Constraints

Token Compatibility

Not a Fit