Oracles on TON: RedStone, Pyth and Alternatives 2026

Oracles are the infrastructure that delivers off-chain market prices to on-chain smart contracts. Without them, lending, perp DEXs, options, insurance, and anything depending on “what does TON cost in USDT right now” cannot exist. On Ethereum the oracle market is mature — Chainlink, Pyth, RedStone, API3 cover thousands of assets. On TON the landscape took shape later: major providers arrived in 2024, and in 2026 we have a working but less crowded scene.

This piece covers who actually operates on TON, how push and pull models differ, which protocols use which oracles, and where the manipulation risks live.

Why oracles are needed

Any DeFi logic tied to price needs an on-chain source for that price. Examples:

• Lending (EVAA, DAOlama). To value collateral (e.g., in TON or jUSDT) and decide whether to liquidate.
• Perpetual DEX (Storm Trade). Mark price for PnL accounting and liquidation triggers.
• Options and structured products. Settlement at expiry price.
• CDP stablecoins. Collateral ratio evaluation.
• Insurance / depeg coverage. Payout trigger.

The blockchain itself knows nothing about off-chain prices. The oracle is the bridge.

Who operates on TON in 2026

The main names:

1. Pyth Network. Live on TON since late 2024. Pull model: prices are signed by providers off-chain, consumers pull them when needed. Coverage — major pairs (TON/USD, USDT, BTC, ETH, large jettons), sub-second latency at pull time, source-side update frequency around 400 ms.
2. RedStone. Integrated with TON in 2024. Also a pull model with attestation: signed price packets are delivered on-chain via a dedicated service, the consumer verifies the signature. A distinguishing feature — strong long-tail asset support through a modular architecture.
3. Stork. Third notable provider on TON, focused on low latency for perp DEXs. Less widespread but used as a secondary feed in several integrations.
4. Native / protocol oracles. Some protocols ship their own oracles for their own logic. Example — pool-based TWAP oracles (reading price from liquid DEX pools at STON.fi / DeDust). Cheap and native, but vulnerable to manipulation at thin liquidity.

Multi-oracle aggregation is also common: a lending protocol takes prices from 2–3 sources and applies a median, reducing dependence on a single provider.

Push vs pull: how it works

Two main architectures:

Push model

The oracle publishes prices on-chain on a schedule (every N seconds) or on a significant change (heartbeat / deviation threshold).

• Pros. Price is always available on-chain, no extra messages needed.
• Cons. More expensive long-term — every update costs gas, paid by protocol or oracle. On TON this is especially visible due to forward fees on every message.

Chainlink is the classic push example. On TON push oracles are easier to implement for native protocol-specific feeds than for universal providers.

Pull model

Price lives off-chain as signed packets. The consumer (e.g., EVAA during a liquidation) pulls a fresh price exactly when needed and pays for that update.

• Pros. Cheap for infrequent reads. Always “fresh” at query time.
• Cons. Complicates UX — every operation requires an extra step. Latency between off-chain signature and on-chain confirmation opens a front-run window.

Pyth works this way. RedStone uses an attestation variant: packets are signed by network validators, and on-chain only the signature is verified, not the source.

Which protocols use which oracles

Real picture in TON DeFi as of May 2026:

Not every protocol uses the same stack — different problems demand different latency, accuracy, and resilience tradeoffs.

Oracle manipulation: where the real risk is

Oracle manipulation is among the most frequent exploit classes in DeFi. The basic pattern:

1. Attacker finds a thin jetton priced via DEX TWAP in the oracle.
2. Makes a large buy, pumping the pool price.
3. TWAP slowly catches up to the new “price.”
4. Attacker posts this jetton as collateral on a lending protocol, borrows against the inflated valuation.
5. Dumps the collateral, abandons the loan. The protocol writes off bad debt.

Defenses applied on TON:

• Multi-source median. Lending uses 2–3 independent feeds and takes the median. Attacking one window in two places is harder.
• Time-Weighted Average Price (TWAP). Price is averaged over a window (usually 5–30 minutes), making an instant pump useless — the attacker must hold the manipulated price for the whole window, which costs capital.
• Circuit breakers. On sharp deviation (e.g., +30% in a minute) the protocol pauses feed use until corroboration from other sources.
• Allowlists. EVAA and DAOlama accept as collateral only assets with deep liquidity on major DEXs. Thin long-tail jettons are either rejected or accepted with a very high haircut.

Example: EVAA liquidation through a Pyth feed

A walk-through to ground the mechanics:

1. Alice posts 10,000 TON as collateral on EVAA and borrows 30,000 USDT.
2. TON drops from $5.50 to $4.20 — her collateral ratio falls.
3. A liquidator bot pulls a fresh price from Pyth (pull): an off-chain signed packet is delivered to the EVAA contract.
4. EVAA verifies the signature and timestamp (e.g., not older than 60 seconds).
5. Alice’s position is confirmed eligible for liquidation.
6. The liquidator repays part of the debt and seizes collateral at a discount (say 5%).

Pyth here is the “ultimate truth” about TON’s price at liquidation. If Pyth served stale data or someone could inject a forged packet — the liquidation would proceed incorrectly. That’s why signature and timestamp verification is critical.

TWAP vs spot: when to use which

• Spot price. Current instantaneous price. Cheap, fresh, but manipulable in one block.
• TWAP (Time-Weighted Average Price). Mean over a window (5, 15, 30 minutes). More expensive to compute but much harder to manipulate — an attacker must hold the manipulated price for the full window, demanding capital.

Empirical rule in TON DeFi:

What this means for users

Practical takeaways:

1. If you post collateral in a lending protocol — check which oracle the protocol uses. EVAA, DAOlama, Storm Trade publish this in their docs.
2. If you use a long-tail jetton as collateral — be careful: the oracle may not behave as expected during sharp moves.
3. If you open a leveraged position — pay attention to “mark price” in the UI. That’s the oracle price that will liquidate you, not your entry.
4. If you build your own protocol — don’t launch without a multi-source feed and TWAP sanity checks. EVM history is full of exploits from slipshod oracle integration.
5. If you see a jetton swapping anomalously cheap/expensive — it might be a legitimate listing or an attack on someone’s oracle. Cross-check sources.

Oracle comparison: TON vs EVM

TON’s oracle scene is smaller and younger but rests on proven global players (Pyth and RedStone already battle-tested on other chains).

Latency and finality: a quiet but critical pair

An oracle isn’t only “where price comes from” but also “how fresh it is.” Important distinctions:

• Source latency. Time from a price move on off-chain markets (Binance, Coinbase) to a signed packet being published. Pyth runs ~400 ms.
• On-chain delivery latency. Time from signature to actual use in a smart contract. On TON this adds forward-message time + block (~5 seconds). On Ethereum — one block (12 seconds) for push, or half a block for pull.
• Oracle finality. When the price is “accepted” on-chain and can’t be overwritten. On TON message finality comes after block inclusion + cross-shard confirmation.

The total price life-cycle latency on TON is roughly 5–10 seconds from market move to usability in a smart contract. Fine for lending, borderline for high-frequency perps, insufficient for arbitrage.

This is why Storm Trade and similar platforms must combine oracle feeds with DEX spot prices plus mark-price smoothing — to avoid letting bots attack via oracle latency.

Regulation and transparency: what to expect in 2026

EU MiCA-style regulation introduces “benchmark provider” obligations — oracles may end up in that category. Pyth and RedStone are already working on compliance: methodology publication, packet auditing, source transparency. For users this means oracles will, in the medium term, stop being “black boxes.”

For TON protocols this creates a new selection criterion: how ready is the oracle to meet regulatory expectations of customer jurisdictions. Not a blocker, but a factor that will show up in 1–2 years in mature lending products with European user bases.

Conclusion

Oracles are the infrastructure without which DeFi can’t function, and simultaneously one of the most frequent points of failure for the whole system. On TON in 2026 the oracle market has matured: Pyth and RedStone provide baseline coverage, Stork adds low-latency, and native DEX-TWAPs cover the long tail with reasonable caution.

For users, one rule is simple: know which oracle you’re trusting when you post collateral or open leverage. Transparency is your best friend here.

For developers — multi-source, TWAP sanity, circuit-breakers, and caution with long-tail assets. EVM history shows that 60% of lending exploits trace back to oracle manipulation — TON has no immunity here.

For further reading, see our reviews of EVAA, Storm Trade, DAOlama, and TON on-chain activity metrics.