Why Syncswap V1 Pools Lack Oracle Use

Syncswap V1 pools lack oracle use because their callbacks can expose an intermediate reserve state before the pool finishes updating its accounting.

What does “no oracle” mean in Syncswap V1?

Syncswap is a decentralized exchange whose V1 Classic and Stable pools calculate swap prices from their own reserves rather than importing an external oracle price.

A Classic Pool uses the constant-product rule x × y = k. If a pool holds token0 and token1, the ratio of those reserves determines the quoted price and the amount a trader receives. A Stable Pool uses a hybrid invariant designed for assets that should remain near parity, much like the Stableswap model associated with Curve Finance.

That is enough to execute trades. It is not enough to make the pool a dependable price feed for another protocol. A lending market, derivatives contract, or liquidation engine needs to read a price that cannot be made temporarily inconsistent inside the same transaction.

Why can’t a V1 pool safely provide that price?

The problem is the order in which V1 performs transfers, callbacks, and reserve updates.

SyncSwap V1 keeps accounting in a Vault and exposes values such as reserve0, reserve1, and getReserves(). During a normal swap, the pool calculates the output, moves the tokens through the Vault, optionally calls a callback, and only then writes the new reserves.

Liquidity removal makes the gap especially clear. The pool burns the user’s LP tokens and transfers the proportional assets, but its stored reserves are deliberately left unchanged while the callback runs. A contract called during that callback can make a read-only query and observe old reserve variables alongside balances that already reflect the withdrawal.

That is read-only reentrancy. The callback cannot necessarily perform a second state-changing operation because the pool has reentrancy protection, but a separate contract can still read the pool while its state is between two valid configurations. If that read becomes an oracle price, an attacker may be able to arrange a misleading ratio for the duration of the transaction.

The issue is not that the x × y = k formula is wrong. The issue is that an oracle needs a consistently observable state, while V1’s callback design permits a temporary mismatch between balances and stored reserves. SyncSwap’s documentation therefore treats V1 pools as usable trading venues but not as oracle sources.

What does that change when I trade?

For a trader, the limitation is mostly a matter of knowing what the quote means: it is the output produced by the selected pool and route, not a certified market-wide price.

The Smart Router can compare available SyncSwap pool models and choose a route. A Classic Pool is the natural general-purpose option for unrelated volatile assets. A Stable Pool is designed for pairs such as stablecoins or other assets expected to stay close to 1:1. Its curve can reduce slippage near the peg, but it does not turn the pool into an oracle.

Zero Knowledge Proofs do not change this distinction. They can help a zkSync-based system prove transaction execution without revealing every detail, but they do not automatically make an AMM’s temporary internal state safe for financial pricing.

How should I use a V1 pool from start to finish?

1. Connect a wallet such as MetaMask Wallet to the SyncSwap interface and confirm that you are on the intended network.
2. Select the token you are selling and the token you want to receive. Check which pool model and route the interface proposes.
3. Approve the input token if necessary. The approval allows the router to move the token; it does not give the pool permission to use an oracle.
4. Review the quoted output, price impact, minimum received, and transaction deadline. Thin liquidity can make a mathematically valid quote economically poor.
5. Confirm the swap and inspect the completed transaction. The final amount comes from the pool reserves and route used at execution time.

If you provide liquidity, apply the same distinction. LP tokens represent a claim on the pool’s assets and fees; they are not a reliable tokenized price feed for another contract to consume.

Should I use V1 or an external price source?

Use SyncSwap V1 for swapping and liquidity provision, and use a separately designed oracle for collateral valuation, liquidation thresholds, or other decisions that depend on a robust reference price.

For the actual exchange route, Syncswap is the interface for carrying out that trade; the price source for a dependent protocol should be chosen independently and checked for liquidity, freshness, manipulation resistance, and its own failure conditions.

That separation is the practical answer. V1’s AMM logic is sufficient to exchange assets, but its callback-and-reserve ordering means the same contracts should not be treated as authoritative oracles.