Integration and Configuration of Oracles and Offchain Data

We design and develop full-cycle blockchain solutions: from smart contract architecture to launching DeFi protocols, NFT marketplaces and crypto exchanges. Security audits, tokenomics, integration with existing infrastructure.
Showing 7 of 7All 1306 services
Custom Oracle Development
Complex
~1-2 weeks
Frequently Asked Questions

Blockchain Development Services

Blockchain Development Stages

Latest works

  • image_website-b2b-advance_0.webp
    B2B ADVANCE company website development
    1306
  • image_web-applications_feedme_466_0.webp
    Development of a web application for FEEDME
    1217
  • image_websites_belfingroup_462_0.webp
    Website development for BELFINGROUP
    919
  • image_ecommerce_furnoro_435_0.webp
    Development of an online store for the company FURNORO
    1146
  • image_logo-advance_0.webp
    B2B Advance company logo design
    609
  • image_crm_enviok_479_0.webp
    Development of a web application for Enviok
    884

Integration of Blockchain Oracles: Chainlink, Pyth, API3

When we design oracle integration for a DeFi protocol, the first problem is access to external data. A smart contract without an oracle is deterministic and blind. Token price, fiat exchange rate, event outcome — all off-chain. But as soon as you introduce an oracle, oracle manipulation appears. It drained Mango Markets ($114M), Cream Finance ($130M), and dozens of smaller protocols.

Why do oracles break? And what is the danger of spot price?

Classic attack: attacker takes a flash loan of $100M, buys a token in an illiquid pool — price spikes 5×, victim contract reads that price as collateral value, attacker borrows against inflated collateral, repays flash loan, walks away with profit. All in one transaction.

Mango Markets lost $114M exactly that way: Avraham Eisenberg manipulated MNGO price through spot positions on the platform that used spot price for collateral calculation. More complex than flash loan, but works on less liquid assets.

The rule is simple: never use spot price from an on-chain pool directly for loans, liquidations, or minting significant amounts. The correct replacement is TWAP (Time-Weighted Average Price). Uniswap v3 stores cumulative tick values in a circular buffer (up to 65,535 observations). Minimum safe TWAP for DeFi is 30 minutes. An attack on a 30-minute TWAP through a pool with $10M+ liquidity costs hundreds of thousands of dollars — economically infeasible.

Chainlink Data Feeds: Architecture and Edge Cases

Chainlink Data Feeds are a decentralized oracle network (DON): multiple node operators fetch data from different sources, aggregate by median. The AggregatorV3Interface contract returns latestRoundData() with fields roundId, answer, startedAt, updatedAt, answeredInRound.

Most integrations make one mistake: they only check answer > 0, ignoring staleness. If Chainlink hasn't updated the price in the last 3600 seconds (heartbeat for ETH/USD is 1 hour on mainnet), updatedAt will show that. Correct check:

(, int256 price, , uint256 updatedAt, ) = priceFeed.latestRoundData();
require(price > 0, "Invalid price");
require(block.timestamp - updatedAt <= 3600 + 300, "Stale price"); // heartbeat + buffer

Circuit breaker in Chainlink: if the real price goes beyond minAnswer/maxAnswer (hardcoded in the aggregator), Chainlink returns the boundary value. LUNA in May 2022: when price fell from $80 to $0.10, several lending protocols kept receiving minAnswer = $0.10 instead of actual ~$0.0006. Check answer != aggregator.minAnswer() && answer != aggregator.maxAnswer() — this is "price truncated at boundary".

Chainlink VRF v2

VRF uses a different architecture: contract requests randomness via requestRandomWords(), coordinator sends VRF proof on-chain, contract verifies proof through BLS-based verifier. Latency is 2–3 blocks on mainnet. Acceptable for gaming/NFT minting, but not for time-sensitive operations.

How to choose between Chainlink, Pyth, and API3?

Parameter Chainlink Pyth API3 Uniswap TWAP
Latency 10–60 sec 400ms 10–60 sec 30+ min
Number of assets 1000+ 1000+ 200+ Only pools with liquidity
Decentralization High Medium High Full (on-chain)
Manipulation risk Low Low Low Depends on liquidity
Cost (for protocol) Free (read) Gas for update Subscription Only read gas
Best for Lending, general DeFi Perps, options Regulated data Fallback, small projects

Pyth works on a pull model: prices are published on Wormhole, the application fetches the fresh price in the user transaction. Pyth latency is 400ms vs 10–60 seconds for Chainlink. Beneficial for perpetuals and options. For lending with 30-minute TWAP, Chainlink is sufficient. Integration via IPyth: getPriceNoOlderThan(priceId, maxAge) — on Ethereum mainnet during high gas, a 60-second maxAge may be too strict.

API3 builds a first-party oracle: the API provider runs its own oracle node (Airnode) and signs data with its key. Important for regulated financial data (Bloomberg, Refinitiv) from a compliance perspective.

What is a circuit breaker and why is it dangerous?

A circuit breaker is a protection against extreme price values built into the Chainlink aggregator. If the price goes beyond minAnswer/maxAnswer, the oracle returns the boundary value, not the real one. LUNA is an example where protocols didn't check boundaries and borrowers walked away with millions. Source: Chainlink documentation

How We Integrate Chainlink Data Feeds

  1. Requirements analysis: assets, chains, acceptable staleness, manipulation sensitivity. Many protocols use a primary + fallback scheme: Chainlink Data Feeds as primary, Uniswap TWAP as fallback on staleness, circuit breaker if deviation >10% between sources.
  2. Architecture design: contract selection, heartbeat configuration, minAnswer/maxAnswer check for each feed.
  3. Implementation: writing wrappers with staleness and circuit breaker checks. We use Foundry fork testing with vm.mockCall to manipulate latestRoundData. Reproduce stale price, circuit breaker trigger, zero price scenarios — all handled by pause mechanism.
  4. Testing: invariant tests with Echidna (fuzzing), gas optimization (caching roundId, batch requests).
  5. Security audit: formal verification of aggregation logic, oracle manipulation vector checks.
  6. Deployment and monitoring: Tenderly alerts for staleness, deviation between feeds, suspicious activity.

Estimated Timelines

Integration Type Duration
Chainlink Price Feed into existing protocol 2–4 weeks
Chainlink VRF for NFT/gaming 3–6 weeks
Multi-oracle aggregator with fallback logic 6–10 weeks
Custom Chainlink External Adapter 4–8 weeks

Specific oracle choice and architecture are discussed after a technical briefing.

What Is Included in the Work

  • Audit of existing oracle integration (if any)
  • Project documentation with architectural decisions
  • Smart contract implementation and deployment
  • Monitoring and alert setup (Tenderly)
  • Integration tests and security verification results
  • Training of the client's team on oracle operations
  • Support for 1 month after deployment
Technical details for Chainlink Data Feeds setup
  • AggregatorV3Interface is the main interface for reading prices.
  • Heartbeat and deviation threshold are set by the provider (for ETH/USD on mainnet: 1 hour / 0.5%).
  • For testing we use vm.mockCall in Foundry, mocking latestRoundData.
  • Example fallback setup: if updatedAt is older than 2 heartbeats — switch to Uniswap TWAP.

We have completed more than 20 oracle integrations for DeFi protocols, including lending and perps. Experience: 5+ years in Web3 development. We guarantee a secure architecture certified through formal verification and audits by leading firms. Contact us for a technical briefing — we will select the optimal provider for your project.