Summary
Implement the AMM fee system in two connected stages. Stage 1 introduces configurable fee tiers at pool creation and locks the fee selection into pool state. Stage 2 makes swap fees accrue to liquidity providers and preserves that accrued value when new liquidity is added later.
According to what's described here: https://github.com/logos-co/rfp/blob/master/RFPs/RFP-004-privacy-preserving-dex.md
Background
The AMM already stores a fees field in PoolDefinition, but the field is unused today. This work wires that field into the public instruction surface and then applies it to swap accounting so LPs earn fees through normal pool usage.
Dependency (Stage 0): #15
remove_liquidity currently pays out against tracked reserves (reserve_a and reserve_b) instead of the live token balances held in the vault accounts. Its delta_lp expression is also an identity that always collapses to the raw remove_liquidity_amount, so LP burn semantics already behave as "burn exactly what the caller requested." Once trading fees accumulate as surplus in the vaults, LP exits should receive their proportional share of the actual vault balances, not just the tracked reserves.
Stage 1: #18
Implement configurable fee tiers for the AMM supporting 0.01%, 0.05%, 0.3%, and 1% fee rates as required by RFP-004.
The fees: u128 field already exists in PoolDefinition but is unused. Wire it up so pool creators can select a fee tier at pool creation time.
Stage 2: #19
Implement trading fee accumulation so that liquidity providers earn a portion of each swap based on the pool's configured fee tier.
Fees accumulate as surplus in the pool vaults above the tracked reserves and are distributed to LPs proportionally when they remove liquidity.
Why The Stages Are Split
Stage 1 changes the public interface and persisted pool configuration. Stage 2 depends on that stored configuration to apply fee-aware swap math and LP accounting. Splitting the work keeps the API/state change reviewable on its own while preserving a direct path to the full fee system.
Summary
Implement the AMM fee system in two connected stages. Stage 1 introduces configurable fee tiers at pool creation and locks the fee selection into pool state. Stage 2 makes swap fees accrue to liquidity providers and preserves that accrued value when new liquidity is added later.
According to what's described here: https://github.com/logos-co/rfp/blob/master/RFPs/RFP-004-privacy-preserving-dex.md
Background
The AMM already stores a
feesfield inPoolDefinition, but the field is unused today. This work wires that field into the public instruction surface and then applies it to swap accounting so LPs earn fees through normal pool usage.Dependency (Stage 0): #15
remove_liquiditycurrently pays out against tracked reserves (reserve_aandreserve_b) instead of the live token balances held in the vault accounts. Itsdelta_lpexpression is also an identity that always collapses to the rawremove_liquidity_amount, so LP burn semantics already behave as "burn exactly what the caller requested." Once trading fees accumulate as surplus in the vaults, LP exits should receive their proportional share of the actual vault balances, not just the tracked reserves.Stage 1: #18
Implement configurable fee tiers for the AMM supporting 0.01%, 0.05%, 0.3%, and 1% fee rates as required by RFP-004.
The
fees: u128field already exists inPoolDefinitionbut is unused. Wire it up so pool creators can select a fee tier at pool creation time.Stage 2: #19
Implement trading fee accumulation so that liquidity providers earn a portion of each swap based on the pool's configured fee tier.
Fees accumulate as surplus in the pool vaults above the tracked reserves and are distributed to LPs proportionally when they remove liquidity.
Why The Stages Are Split
Stage 1 changes the public interface and persisted pool configuration. Stage 2 depends on that stored configuration to apply fee-aware swap math and LP accounting. Splitting the work keeps the API/state change reviewable on its own while preserving a direct path to the full fee system.