Peeking Under the Hood of STONfi V2 - More Contracts Than I Expected
I used to think a liquidity pool was just one smart contract doing everything. After digging into STONfi V2, I found the work is actually divided across four specialized contracts, each focused on one responsibility. That design made the whole swap process much easier to understand.
⚙ Four Core Components
- Router - the coordinator that receives requests and forwards them to the correct Pool.
- Pool - the AMM engine where reserves, pricing and swap calculations live.
- LP Account - a temporary place where liquidity deposits wait before joining the active pool.
- Vault - a separate contract that stores referral fees for one owner and one token.
Instead of one massive contract, the protocol spreads work across smaller pieces that communicate through messages.
🔗 Why It Works This Way
TON processes one incoming message per account at a time. Because of that, a swap is a sequence of messages moving between contracts rather than one giant contract call. Even the transfer notification from a jetton wallet becomes part of that flow.
🔄 What Happens During a Swap
1. The app loads pool data through the SDK.
2. The Router forwards the request.
3. The Pool updates balances and calculations.
4. The Router completes the transfer and returns unused GRM.
🛠 Why Developers Should Care
- New Pool types can be added without rebuilding the Router.
- Always obtain Router addresses from the API instead of hardcoding them.
- Indexers should follow complete message traces, not only swap events.
💭 My Takeaway
The architecture is more complex than I expected, but every contract has one clear purpose. That separation makes upgrades easier while keeping the protocol flexible. The complexity is mostly hidden from users, yet it helps the system evolve without redesigning everything.
$AEON
I used to think a liquidity pool was just one smart contract doing everything. After digging into STONfi V2, I found the work is actually divided across four specialized contracts, each focused on one responsibility. That design made the whole swap process much easier to understand.
⚙ Four Core Components
- Router - the coordinator that receives requests and forwards them to the correct Pool.
- Pool - the AMM engine where reserves, pricing and swap calculations live.
- LP Account - a temporary place where liquidity deposits wait before joining the active pool.
- Vault - a separate contract that stores referral fees for one owner and one token.
Instead of one massive contract, the protocol spreads work across smaller pieces that communicate through messages.
🔗 Why It Works This Way
TON processes one incoming message per account at a time. Because of that, a swap is a sequence of messages moving between contracts rather than one giant contract call. Even the transfer notification from a jetton wallet becomes part of that flow.
🔄 What Happens During a Swap
1. The app loads pool data through the SDK.
2. The Router forwards the request.
3. The Pool updates balances and calculations.
4. The Router completes the transfer and returns unused GRM.
🛠 Why Developers Should Care
- New Pool types can be added without rebuilding the Router.
- Always obtain Router addresses from the API instead of hardcoding them.
- Indexers should follow complete message traces, not only swap events.
💭 My Takeaway
The architecture is more complex than I expected, but every contract has one clear purpose. That separation makes upgrades easier while keeping the protocol flexible. The complexity is mostly hidden from users, yet it helps the system evolve without redesigning everything.
$AEON