Oracle·EVM · Aptos · Sui · Multi-chain
Supra
Multi-chain oracle (DORA V2) with both push and pull delivery, native VRF, automation, and a Layer 1 (MoveVM + EVM). Pull mode delivers signed S-Values via Web2 then verifies them on-chain for ultra-low latency; push feeds are deployed across 70+ chains.
- 01low-latency pull feeds across many EVM and non-EVM chains
- 02traditional push price feeds on long-tail chains
- 03verifiable randomness (Supra VRF)
- 04Move-based chains (Aptos, Sui, Movement, Supra L1)
- 05perps / derivatives needing tight price latency
- pnpm add @supra-oracles/oracle-pull-evm
- forge install Entropy-Foundation/dora-interface
| Variable | Scope | Description |
|---|---|---|
| SUPRA_PULL_ORACLE_ADDRESS | Client | Supra Pull Oracle contract address (`ISupraOraclePull`) on the target chain. See docs.supra.com pull-oracle networks page. |
| SUPRA_STORAGE_ADDRESS | Client | Supra Storage / SValueFeed contract address (`ISupraSValueFeed`) for push feeds on the target chain. |
| SUPRA_GRPC_ENDPOINT | Server | Supra gRPC endpoint for fetching signed pull payloads off-chain (e.g. `https://prod-kline-rest.supra.com`). Pin a paid endpoint for production. |
PUSH model: import `ISupraSValueFeed` and call `supra.getSvalue(uint256 _pairIndex)` for one pair or `getSvalues(uint256[])` for many — returns `(priceData, decimals, timestamp, round)`; for derived pairs use `getDerivedSvalue(pairId1, pairId2, operation)`. PULL model: off-chain fetch a signed payload via the Supra gRPC/REST endpoint (`oracle-pull-example` repo), then on-chain call `ISupraOraclePull.verifyOracleProof(bytes _bytesProof)` which returns `(pairs[], prices[], decimals[], timestamps[], round[])` after verifying signatures from the Supra committee — pass `priceData[i]` into your business logic. For VRF use `ISupraRouterContract.generateRequest(...)` and consume in `_supraVRFCallback`.
- ⚑Pull oracle requires every consuming tx to include the signed `_bytesProof` and call `verifyOracleProof` first — forgetting it OR passing a stale proof reverts; the off-chain gRPC fetch must happen in the same request flow as the tx.
- ⚑Push vs pull are SEPARATE products with DIFFERENT contract addresses (`ISupraSValueFeed` vs `ISupraOraclePull`) and DIFFERENT pair indices/IDs — mixing them up reads the wrong feed.
- ⚑Decimal scaling: each pair has its own `decimals` value returned alongside the price; hardcoding 8 or 18 silently breaks long-tail pairs (always read `decimals` from the response and scale).
- ⚑Always staleness-check `timestamp` from the response and reject if older than your market's tolerance — push feeds have per-pair heartbeats and pull responses can replay an old proof if you don't pin to a recent round.
- ⚑Network fees: pull verification adds significant gas (signature verification + storage), so batch reads via `getSvalues` / multi-pair proofs when reading more than one pair in the same tx.
- ⚑Pair indices differ across chains and between push and pull — copy the index/ID from the per-chain Supra docs page, never hardcode by guessing.
- ⚑Public gRPC endpoint is rate-limited and best-effort; production apps should provision a paid endpoint and add retry + signer-set validation server-side.
- ⚑Move-based receivers (Aptos, Sui, Supra L1) use a different module API than EVM — the EVM `ISupra*` interface does not translate.