An attacker could pass user holding accounts owned by a malicious token
program. Since chained calls are dispatched to the program_owner of the
user holding account, a fake program could accept the transfer instruction
without actually moving tokens.
Add assertions in add_liquidity, remove_liquidity, swap_exact_input, and
swap_exact_output that user_holding_a and user_holding_b must share the
same program_owner as vault_a. The vault accounts are PDA-verified via
their account_id, making vault_a's program_owner the authenticated
reference. new_definition already validated that both user holdings use
the same program.
Adds 8 regression tests covering the wrong-program case for each
operation and each user holding slot.
Closes#69
Remove the `active: bool` field from `PoolDefinition` and replace it with an
implicit invariant: a pool is considered active when
`liquidity_pool_supply >= MINIMUM_LIQUIDITY`.
BREAKING CHANGE: `PoolDefinition` Borsh serialization format has changed.
Existing on-chain pool accounts encoded with the `active` field are
incompatible with this version.
Closes#25
- accept a supported fee tier in pool creation
- store fee tiers in AMM pool state and validate them
- update AMM tests and IDL for the new pool creation argument
Permanently lock `MINIMUM_LIQUIDITY` (1_000) LP tokens in a dedicated
LP-lock holding PDA on pool creation, following the Uniswap v2 "dead
shares" pattern. The pool creator receives `initial_lp - MINIMUM_LIQUIDITY`
tokens instead of the full initial_lp amount.
Adds `compute_lp_lock_holding_pda` and `LP_LOCK_HOLDING_PDA_SEED` to
amm_core, updates new_definition to emit two sequential chained calls
(create LP definition + lock holding, then mint user share), and adjusts
remove liquidity to account for the permanently locked floor.
BREAKING CHANGE: NewDefinition instruction requires an additional LP-lock
holding account derived via `compute_lp_lock_holding_pda(amm_program_id, pool_id)`.
