The Router Is Not the Pool
I used to think that when I found a STON.fi Router in a transaction, I had found the contract that actually executed the swap.
Not quite.
Think of the Router as the traffic controller. It receives the swap instructions and directs them to the right liquidity pool.
The Pool is where the actual AMM swap happens.
For a simple v2 swap, the flow is roughly:
Wallet → Router → Pool → Output
That distinction matters when you're investigating what actually happened on TON.
A transaction that looks like one swap from the user's perspective can involve several messages between your wallet, Jetton wallets, the Router, the Pool, and the receiving address.
So don't stop at the first STON.fi contract you see. Follow the messages.
And sometimes it's not even one pool.
You might think you're swapping A → C, while the actual route is:
A → B → C
Pool 1 handles A → B.
Pool 2 handles B → C.
That's one swap from the interface, but a multi-pool route on-chain.
For a completed transaction, I like to verify three things:
→ Transaction trace: Did the Router actually call this address?
→ Pool state: Does the contract identify the expected Router and token wallets?
→ STON.fi data: Is the address indexed as the relevant liquidity pool?
This is also where the STON.fi API and pool-address getter become useful. They can help identify possible pools and routes.
But remember:
Possible pool ≠ executed pool.
And there are a few easy mistakes to avoid:
❌ Router ≠ Pool
❌ Token ticker ≠ unique asset identity
❌ One swap ≠ necessarily one pool
❌ Pool list ≠ proof of execution
❌ One transaction ≠ one smart-contract interaction
For v2 investigations, the swap opcode 0x6664de2a can also help identify the relevant swap message, while historical v1 transactions use different formats.
The bigger lesson is simple:
Don't just ask, “What did I swap?”
Ask, “Which contract actually handled my trade?”
Find the Router.
Follow its message.
Identify the Pool.
Then verify the contract.
#STONfi #TON
I used to think that when I found a STON.fi Router in a transaction, I had found the contract that actually executed the swap.
Not quite.
Think of the Router as the traffic controller. It receives the swap instructions and directs them to the right liquidity pool.
The Pool is where the actual AMM swap happens.
For a simple v2 swap, the flow is roughly:
Wallet → Router → Pool → Output
That distinction matters when you're investigating what actually happened on TON.
A transaction that looks like one swap from the user's perspective can involve several messages between your wallet, Jetton wallets, the Router, the Pool, and the receiving address.
So don't stop at the first STON.fi contract you see. Follow the messages.
And sometimes it's not even one pool.
You might think you're swapping A → C, while the actual route is:
A → B → C
Pool 1 handles A → B.
Pool 2 handles B → C.
That's one swap from the interface, but a multi-pool route on-chain.
For a completed transaction, I like to verify three things:
→ Transaction trace: Did the Router actually call this address?
→ Pool state: Does the contract identify the expected Router and token wallets?
→ STON.fi data: Is the address indexed as the relevant liquidity pool?
This is also where the STON.fi API and pool-address getter become useful. They can help identify possible pools and routes.
But remember:
Possible pool ≠ executed pool.
And there are a few easy mistakes to avoid:
❌ Router ≠ Pool
❌ Token ticker ≠ unique asset identity
❌ One swap ≠ necessarily one pool
❌ Pool list ≠ proof of execution
❌ One transaction ≠ one smart-contract interaction
For v2 investigations, the swap opcode 0x6664de2a can also help identify the relevant swap message, while historical v1 transactions use different formats.
The bigger lesson is simple:
Don't just ask, “What did I swap?”
Ask, “Which contract actually handled my trade?”
Find the Router.
Follow its message.
Identify the Pool.
Then verify the contract.
#STONfi #TON
