Skip to main content

​
Your application depends on data it cannot see

Smart contracts need information from outside their blockchain: prices, reserve balances, ownership records, or events on another chain. Oracles bring that information on-chain so applications can act on it. A manipulated input can trigger an incorrect payment, an undercollateralized loan, or an improper liquidation. The path from source to contract is part of your application’s security. A common approach uses a decentralized network of oracle operators. Operators observe data and participate in a reporting protocol that produces a value for the receiving contract. For market prices, aggregation across sources helps establish a shared reference value, while an operator quorum authenticates the report.
Representative decentralized oracle architecture: data sources feed independent operators, which aggregate observations and sign a report for an oracle contract.
Representative off-chain reporting architecture. Implementations vary.

​
Build around your data and your release cycle

Many applications bring a different kind of information on-chain: a fund administrator’s official NAV, a custodian’s reserve report, a warehouse’s receipt of goods, or an issuer’s record of an asset. Each of these data types originates from a single off-chain authority. The application needs an authenticated path from that source to its contract, including any calculations in between. With Turnkey Verifiable Cloud (TVC), you build that path as an application you control. Your code connects to the source, validates and processes the response, and publishes the result. TVC provides verifiable execution, and Turnkey policies constrain the application’s transaction authority. You can introduce a new data type without having a feed added to an external oracle network’s catalog. Adding an API, changing a formula, or adjusting a publication trigger follows your own development and quorum-approved deployment process. That reduces coordination with an additional provider and lets the oracle evolve alongside the application that uses it. You control three parts of the solution:
  • The inputs. Use one authoritative API, combine several feeds, or reconcile records across providers. Define how the application handles missing, stale, or conflicting observations.
  • The computation. Normalize units, reject outliers, calculate medians or weighted averages, derive collateral ratios, or implement a custom index. Your reviewed code defines the methodology, rounding, and acceptance rules.
  • The publication schedule. Publish on a fixed interval, when a value crosses a threshold, or in response to an event. Choose a cadence that fits your source limits, transaction throughput, and gas budget.
TVC supports replicated applications with high availability and SLAs so you can be confident your oracle stays operational.

​
How a TVC oracle works

An oracle application runs inside a TVC trusted execution environment (TEE). It fetches and validates inputs, applies your computation, and prepares a transaction. A Turnkey wallet signs permitted transactions, and the application submits them to the destination blockchain. The transaction signing key stays in Turnkey.
TVC oracle architecture: HTTPS sources connect to an attested application that fetches, computes, and submits; a separate Turnkey wallet enforces signing policy, and the destination contract validates and stores the result.
Code and configuration changes follow the deployment quorum’s approval process. Routine data updates follow the approved application logic, without requiring agreement across independent oracle nodes for each report. The same underlying data can reach your contract through different architectures. The distinction is how it is processed, authenticated, and published. Representative architectures; implementations vary. In either model, authenticating a report does not independently establish the accuracy of its underlying source data.

​
Why the path is verifiable

  • Authenticate the source connection. Fetch over HTTPS with TLS termination and certificate and hostname validation inside the enclave. If a publisher also signs its observations, verify and preserve those signatures for downstream verification. Learn about TVC’s TLS verification.
  • Verify the code and configuration. Reproducible builds and an attested deployment manifest let reviewers identify the application that processes the data. Code changes require the configured operator quorum’s approval. Learn how TVC establishes code identity and controls upgrades.
  • Limit publication authority. Give the application a dedicated Turnkey identity. Scope its signing policy to the intended network, destination contract, function, and applicable value and fee limits.
  • Enforce acceptance on-chain. The receiving contract checks the authorized updater, feed identity, freshness, and replay rules before recording a result. Keep administrative changes separate from routine publication authority.
Anyone can independently verify the oracle’s code. Third parties can retrieve the enclave’s Boot Proof through Turnkey’s public API, validate its AWS Nitro attestation and deployment manifest, and compare the attested application digest with a reproducible build of the published source. This lets consumers and auditors check which code and configuration the enclave runs and which operators approved it. See Proofs and verification for public endpoints and open-source verification tools.
Output authentication: The verification mechanism depends on the application. A publisher signature can authenticate an original observation. For unsigned HTTPS inputs or calculated results, an oracle-specific App Proof can bind the output to the TVC application that produced it. Its payload should identify the result, sources and timestamps, input commitments, and intended destination, with appropriate replay protection. A verifier checks that App Proof against the enclave’s Boot Proof and expected application identity. Enforcing this verification on-chain requires an explicit contract integration; emitting an App Proof alone does not provide it. See Proofs and verification. These checks establish provenance and execution. The source remains responsible for the accuracy of its underlying data, and consuming applications should check whether a stored observation is still fresh enough for their use.

​
What you can build

​
Spotlight: Private inputs, verifiable conditions

A lender may need to confirm that a borrower has enough eligible receivables to support a requested draw without publishing customer names, invoice amounts, or outstanding debt. A TVC oracle can retrieve accounting and loan-servicing records, exclude overdue or disputed invoices, and apply advance rates and concentration limits inside the enclave. It publishes only whether the draw qualifies, tied to the request and observation time. An App Proof can bind that decision to the reviewed calculation. With verification integrated into the receiving contract, the facility can authorize the draw while keeping the underlying financial records confidential.

​
See it in practice: an ETH/USD oracle

Explore the TVC oracle example for the application code, Solidity contract, tests, and build instructions. The demo implements this architecture with a single source and a daily publication schedule on Ethereum Sepolia. It retrieves CoinGecko’s API3-compatible signed ETH/USD observations and publishes the source price directly. Signed inputs are a choice for this example; TVC applications can also use ordinary HTTPS APIs and compute new values from their inputs.

​
From observation to on-chain price

  1. Check whether an update is due. The application reads the contract’s current state to avoid an unnecessary transaction before the configured interval has elapsed.
  2. Fetch and validate. It retrieves the signed observation, checks CoinGecko’s signer certification, and verifies the observation signature.
  3. Request a permitted signature. It builds an updatePrice call carrying the feed template, source timestamp, encoded price, and original signature. The Turnkey policy restricts signing to the intended Sepolia contract and function, the expected template, zero ETH value, and bounded gas fees.
  4. Submit and confirm. The application broadcasts the signed transaction, waits for a successful receipt, and retries transient failures.
  5. Verify and record. The contract independently checks the updater, template, publisher signature, positive price, and acceptable timestamp. It rejects replayed or older observations, then stores the price, source timestamp, recording time, and provenance hashes.
  6. Read the result. The dashboard reads the canonical value from the contract, including the timestamps consumers need to assess freshness.
The contract administrator can rotate the trusted publisher signer or updater address. The updater cannot change either setting. The daily interval is a demo configuration choice; freshness checks at submission do not keep the stored price fresh indefinitely. The example demonstrates publisher-signature verification on-chain. Its sample App Proof endpoint does not yet bind each oracle update to the TVC application. A valid CoinGecko signature establishes the observation’s origin and integrity, rather than independently establishing the price’s economic correctness. View the live oracle dashboard to inspect the latest published price, or explore the verified demo contract source on Sepolia Etherscan.

​
Build your own

Bring the sources your application needs, the calculation you want to run, and the contract that will consume the result. Define source authentication, output verification, publication triggers, and signing policy together. Start with the oracle example’s setup and configuration instructions to run and adapt the application. Contact us to discuss your oracle design, or follow the TVC quickstart to deploy your first application.