Engineering

AERE goes pull-oracle, industry-standard price feeds live

On May 31, 2026 AERE Network deployed two contracts that finally upgrade our oracle stack from the bootstrap-grade single-reporter AereOracle to an industry-standard pull-oracle architecture, the AERE Oracle Network. AerePyth implements the standard IPyth pull-oracle interface; AereOracleAdapter gives every dApp on AERE one address and one signature for all price reads.

What this changes for developers: code written against any standard IPyth-interface pull-oracle SDK runs unchanged on AERE. IPyth.getPrice(id) works. updatePriceFeeds(updateData) works. As the AERE Oracle Network expands its publisher set, the same AerePyth contract accepts additional signed updates with no migration, applications keep working without redeploy.

The two contracts

ContractAddressWhat it does
AerePyth 0xb7F3354C1E0C5ef89D8b1072a3CEa7FFEf2FfE3F IPyth-interface-compatible pull oracle. Implements getPrice, getPriceUnsafe, getEmaPrice, getPriceNoOlderThan, updatePriceFeeds, getUpdateFee, getValidTimePeriod, every method from the industry-standard pull-oracle interface. Updates are publisher-signed (ECDSA, same scheme as AereMessenger) with configurable threshold N-of-M. Owner-tunable update fee, currently 0.
AereOracleAdapter 0xb28A23dc177794DEC2Cacd2738fCc6c5C1Fc4Fe6 Unified quote(symbol) interface that routes AerePyth → legacy AereOracle fallback. Apps register pull-oracle feed IDs per symbol via registerPythFeed(symbol, feedId). Symbols without pull-oracle coverage continue to read from the existing multi-reporter AereOracle. Returns (price1e8, updatedAt, source) with source = "aerepyth" or "legacy".

Why pull-oracle matters

The original AereOracle deployed at genesis has three real weaknesses: single reporter, two feeds (BTC/USD + ETH/USD), 90-second updates. AereLending died from these (its $0.10 fallback price was a tell). AereSwap intents from Tier 1.5 need real prices for solvers to bid sensibly. Any future stablecoin partner needs trustless USD pricing.

The pull-oracle model fixes all of this. Instead of a few reporters writing prices on a schedule (push), publishers continuously update prices off-chain, and consumers include a recent signed attestation as calldata when they need a fresh price (pull). The on-chain contract verifies threshold signatures and serves the price within the same transaction. Three properties:

How a contract uses it

Two ways. Way 1 (standard pull-oracle pattern), include a recent signed update as calldata:

// Recent signed price update fetched from the AERE Oracle Network off-chain mirror.
bytes[] memory updateData = new bytes[](1);
updateData[0] = priceAttestationCalldata;

// 1. Submit update (pay update fee)
IPyth oracle = IPyth(0xb7F3354C1E0C5ef89D8b1072a3CEa7FFEf2FfE3F);
uint256 fee = oracle.getUpdateFee(updateData);
oracle.updatePriceFeeds{value: fee}(updateData);

// 2. Read the price
PythPrice memory btc = oracle.getPrice(BTC_USD_FEED_ID);
// btc.price is signed int64, scaled by btc.expo (negative for fractional)

Way 2 (AERE simplified pattern), read through the adapter for a unified interface:

// Most AERE dApps want this, one address, no pull-oracle-specific knowledge.
IAereOracleAdapter adapter = IAereOracleAdapter(0xb28A23dc177794DEC2Cacd2738fCc6c5C1Fc4Fe6);
(uint256 price1e8, uint256 updatedAt, string memory source) = adapter.quote(keccak256("BTC/USD"));
// price1e8 always scaled to 1e8 (e.g. $30,000.12 = 3_000_012_000_000)
// source tells you whether it came from AerePyth or legacy AereOracle

Migration plan for existing dApps

The existing AereOracle deployed at 0xf0A13823A4bFa86358Fe30aaf1f44A36AcbCf399 remains operational. Dapps using it directly continue to work. The recommended migration:

  1. Point new contracts at AereOracleAdapter, not at AereOracle directly.
  2. As Foundation registers pull-oracle feed IDs per symbol, the adapter automatically routes those reads to AerePyth, no app code change.
  3. Symbols not yet covered by the AERE Oracle Network (initially AERE/USD) continue to flow through legacy AereOracle.
  4. As the AERE Oracle Network adds publishers, Foundation calls setPyth(newPullOracleAddress) and the adapter routes to the expanded network.

What's still pending for full AERE Oracle Network operation

  1. Foundation expands publisher set. Bootstrap is the existing oracle-reporter address (single publisher, threshold 1). Roadmap: add 2 additional publishers and raise threshold to 2-of-3, then 3-of-5 once partnerships are confirmed.
  2. Existing oracle-reporter container is updated to push price updates to AerePyth via updatePriceFeeds() in addition to (or eventually replacing) the legacy AereOracle path.
  3. Cross-chain registry onboarding (planned, not yet live). Registering AERE chain 2800 with the broader pull-oracle ecosystem. Once merged, AerePyth verifies the expanded publisher signature set and AERE inherits the full catalog of public feeds.
  4. Foundation registers feed IDs in AereOracleAdapter for the major symbols (BTC/USD, ETH/USD, USDC/USD, USDT/USD, EUR/USD, GBP/USD, SOL/USD, BNB/USD, MATIC/USD, ARB/USD, etc.).
  5. AERE/USD listing is gated on meaningful CEX liquidity. Currently MEXC only; Bitget/KuCoin/Gate listings (separate workstream) unblock this.

What this composes with

What's next

The price-data layer is now real. Tier 1.7 ships drand verifiable randomness, the cryptographic primitive for fair lotteries, NFT trait reveals, randomized airdrops, on-chain games. Tier 1.8 wires AereFeeBurnVault into the validator coinbase, making the whitepaper §3.3 "37.5% of fees obliterated" claim measurably true on chain. Tier 1.9 adds batch-auction settlement to AereSwap for native MEV-resistant trading.

AERE's foundational layer is now complete: modern EVM, smart wallets, gasless UX, cross-chain messaging, intent-based bridging, and real-time prices. The work moves up the stack.

← Back to all posts