How STON.fi Pool Reserves Work: reserve0, reserve1 and Real AMM Accounting
STON.fi pools keep trading liquidity in reserve0 and reserve1 inside the Pool contract. These values drive every swap and liquidity calculation and are not the same as whatever Jettons sit at the Pool address.
đ„ What the Reserves Actually Track
- reserve0 holds the accounted amount of token 0 in basic units
- reserve1 holds the accounted amount of token 1 in basic units
- get_pool_data returns both together with total_supply and fee trackers
- They form the internal inventory the AMM logic trusts
⥠Architecture That Makes the Difference
The Router owns Jettons moving through the DEX while each Pool stores pair-specific data and runs the math. When a swap finishes the Pool updates its reserves and tells the Router to pay the output. That separation keeps accounting clean and lets developers rely on pool state instead of raw balances.
đ§ What Changes the Numbers
- Swaps move value from one reserve to the other after fee allocation
- Successful liquidity provision increases reserves and expands LP supply
- Liquidity withdrawal burns LP tokens and shrinks the matching reserves
- LP fees remain inside the pool and raise the value behind existing shares
đŹ Why This Matters for Users
Protocol fees, referral Vaults and the 0.01 TON storage balance live in separate buckets. Mixing them with reserve0 or reserve1 produces the wrong picture of active liquidity. Always start from get_pool_data, confirm token identity and decimals, then read the fee fields.
The clean takeaway: STON.fi reserve accounting is deliberate AMM bookkeeping, not a simple wallet balance check.
Would you treat reserve0 and reserve1 as the first source of truth for a STON.fi pair? đ
Tell us which part of the reserve model you want explained next.
Not investment advice - research on your own! đ
$GRAM @STONfi DEX
STON.fi pools keep trading liquidity in reserve0 and reserve1 inside the Pool contract. These values drive every swap and liquidity calculation and are not the same as whatever Jettons sit at the Pool address.
đ„ What the Reserves Actually Track
- reserve0 holds the accounted amount of token 0 in basic units
- reserve1 holds the accounted amount of token 1 in basic units
- get_pool_data returns both together with total_supply and fee trackers
- They form the internal inventory the AMM logic trusts
⥠Architecture That Makes the Difference
The Router owns Jettons moving through the DEX while each Pool stores pair-specific data and runs the math. When a swap finishes the Pool updates its reserves and tells the Router to pay the output. That separation keeps accounting clean and lets developers rely on pool state instead of raw balances.
đ§ What Changes the Numbers
- Swaps move value from one reserve to the other after fee allocation
- Successful liquidity provision increases reserves and expands LP supply
- Liquidity withdrawal burns LP tokens and shrinks the matching reserves
- LP fees remain inside the pool and raise the value behind existing shares
đŹ Why This Matters for Users
Protocol fees, referral Vaults and the 0.01 TON storage balance live in separate buckets. Mixing them with reserve0 or reserve1 produces the wrong picture of active liquidity. Always start from get_pool_data, confirm token identity and decimals, then read the fee fields.
The clean takeaway: STON.fi reserve accounting is deliberate AMM bookkeeping, not a simple wallet balance check.
Would you treat reserve0 and reserve1 as the first source of truth for a STON.fi pair? đ
Tell us which part of the reserve model you want explained next.
Not investment advice - research on your own! đ
$GRAM @STONfi DEX