How to Identify a STON.fi Pool as V1 or V2
A STON.fi pool is V1 or V2 according to its DEX contract generation. Follow the pool address to its Router and read major_version. Pair names, APR, liquidity, and pool age do not prove the version.
đ„ Why Pair Names Are a Weak Clue
- TOKEN/USDT or TOKEN/TON only names the assets.
- constant_product is a pool type, not proof of V1.
- TVL, volume, and popularity measure activity, not architecture.
- A failed V2-only getter is also not enough on its own.
đ The Router Workflow
1. Copy the pool contract address, not the ticker.
2. Call GET /v1/pools/{POOL_ADDRESS} and take router_address.
3. Call GET /v1/routers/{ROUTER_ADDRESS}.
4. Use major_version 1 for V1 and major_version 2 for V2.
STON.fi's SDK dexFactory uses the same Router metadata, including minor_version and router_type, to pick compatible contract classes.
đ§ Extra On-Chain Fingerprints
- V1 get_pool_data begins with reserves and includes ref_fee.
- V2 common pool data begins with is_locked, router_address, and total_supply.
- V2 Routers expose get_router_version with major, minor, and development fields.
đŹ Why Builders Should Care
V2 adds deadlines, single-sided liquidity, better unbalanced deposits, chained swaps, Vault-based referral fees from 0.01% to 1%, and extra pool types. V1 remains live, so software should not assume every STON.fi pool is V2.
My take: treat version as contract architecture. Confirm the Router first, then use getters only as a second check.
Which STON.fi check feels more reliable to you, the Router API or the pool getters? đ
Share the exact step that usually trips you up when classifying a pool.
Not investment advice - research on your own! đ
$GRAM @STONfi DEX
A STON.fi pool is V1 or V2 according to its DEX contract generation. Follow the pool address to its Router and read major_version. Pair names, APR, liquidity, and pool age do not prove the version.
đ„ Why Pair Names Are a Weak Clue
- TOKEN/USDT or TOKEN/TON only names the assets.
- constant_product is a pool type, not proof of V1.
- TVL, volume, and popularity measure activity, not architecture.
- A failed V2-only getter is also not enough on its own.
đ The Router Workflow
1. Copy the pool contract address, not the ticker.
2. Call GET /v1/pools/{POOL_ADDRESS} and take router_address.
3. Call GET /v1/routers/{ROUTER_ADDRESS}.
4. Use major_version 1 for V1 and major_version 2 for V2.
STON.fi's SDK dexFactory uses the same Router metadata, including minor_version and router_type, to pick compatible contract classes.
đ§ Extra On-Chain Fingerprints
- V1 get_pool_data begins with reserves and includes ref_fee.
- V2 common pool data begins with is_locked, router_address, and total_supply.
- V2 Routers expose get_router_version with major, minor, and development fields.
đŹ Why Builders Should Care
V2 adds deadlines, single-sided liquidity, better unbalanced deposits, chained swaps, Vault-based referral fees from 0.01% to 1%, and extra pool types. V1 remains live, so software should not assume every STON.fi pool is V2.
My take: treat version as contract architecture. Confirm the Router first, then use getters only as a second check.
Which STON.fi check feels more reliable to you, the Router API or the pool getters? đ
Share the exact step that usually trips you up when classifying a pool.
Not investment advice - research on your own! đ
$GRAM @STONfi DEX
