Deep Dive Nest Oracle
This page documents the technical architecture, security model, performance profile, and integration mechanics of Canary Nest Oracle.
Canary Nest Oracle is a ground-up implementation of the most secure, performant, and transparent oracle architecture available today. It is purpose-built for real-world asset protocols and stablecoins that require deterministic, auditable, and crypto-economically secured data feeds.
Nest Oracle leverages Canary’s proprietary SecureWing infrastructure to bring off-chain data on-chain with minimal trust assumptions. Every feed is generated, verified, and attested using Trusted Execution Environments (TEEs), with full verifiability at both the source and execution layer.
Nest is not a fork, wrapper, or governance-heavy middleware — it is a vertically integrated oracle stack designed to support institutional primitives from first principles.
Core Design Principles
Zero-Trust Architecture: The oracle assumes the host operating system, cloud layer, and network stack are untrusted. Only data and execution verified inside TEEs are accepted.
Cryptographic Verifiability: Every data feed published by Nest includes hardware-backed attestations from Intel SGX, AMD SEV, or AWS Nitro Enclaves. These prove the integrity of the binary, runtime, and TLS connection used during data retrieval and processing.
Deterministic Execution: Feed logic is compiled and sealed inside a reproducible enclave. All nodes execute the same logic on the same input, producing identical outputs that are threshold-signed across a quorum (K-of-N) of TEE nodes.
Source Integrity via SSL Pinning: All HTTPS requests are pinned within the enclave to specific certificate chains. This guarantees data is fetched directly from the intended source, not via proxy or compromised intermediate services.
On-Chain Attestation: Each data publication includes a signed attestation report, enabling on-chain consumers to verify that the data was fetched and computed under strict verifiable conditions, without reliance on external governance or oracles.
System Architecture
Nest Oracle is composed of the following layered subsystems:
1. TEE Node Cluster
Each Nest validator operates one or more enclave-secured containers responsible for:
TLS-bound data retrieval from source APIs
Execution of feed logic and schema validation
Generation of signed NAVReport (or equivalent) payload
Embedding of SGX/Nitro/SEV attestation reports
Signing of results using enclave-held keys
Enclaves are deployed with reproducible builds using reproducible compilers and deterministic configurations. All binaries are measured and hashed at launch, forming the basis of the remote attestation proof.
2. SecureWing Attestation Layer
This is the cryptographic root of trust. Each enclave generates a hardware-bound attestation proof using Intel’s EPID/DCAP (for SGX) or AWS Nitro’s vsock-based attestation. This proof contains:
Enclave measurement (MRENCLAVE)
Measurement of the public key used for signing
Quote from the attestation provider (Intel, AMD, AWS)
TLS certificate hash for the origin endpoint
Timestamp and nonce to prevent replay
These proofs are published with the oracle output and verifiable using on-chain or off-chain tools.
3. K-of-N Consensus Engine
To ensure resilience and avoid single-point compromise, Nest uses a threshold quorum architecture. The final output of the oracle is accepted if a minimum quorum of TEE nodes report consistent results and attestations.
Consensus includes:
Canonicalization of feed inputs
BLS threshold aggregation (or ECDSA multisig in early versions)
Slashing of misreporting or missing participants via EigenLayer mechanisms
4. On-Chain Consumer Interface
The Nest Oracle feeds conform to standard AggregatorV3Interface formats (compatible with Chainlink consumers), but with additional metadata fields:
Consumers may choose to perform lightweight checks (e.g., staleness and deviation) or full attestation verification directly on-chain or via a verifier contract.
5. Institutional Curator Layer
Nest Oracle introduces a formal mechanism for institutional curation, enabling protocol-aligned entities to enforce additional safeguards over sensitive price feeds. This layer does not replace cryptographic guarantees but augments them with programmable governance over exceptional conditions.
At its core is a deviation-based approval threshold system:
Every oracle feed can be assigned a deviation threshold (e.g., 5%)
If the latest reported value exceeds this deviation relative to the previous confirmed value, additional curator approvals are required
The number of required approvals scales linearly with the magnitude of the deviation
For example, if the deviation threshold is 5% and the oracle detects a 6% change in NAV, the system will enforce one additional approval before publishing the feed. A 10% deviation would require two, and so forth. This allows real-world events such as sudden market movements or rebalancing to be absorbed while preventing anomalous updates from going live without oversight.
The curator set is composed of pre-authorized high reputable entities that must co-sign such high-deviation reports. All approvals are tracked on-chain, and curator misbehavior is subject to slashing via the same EigenLayer-based staking infrastructure.
This design prevents:
Fat finger mistakes in source APIs
Misconfigurations or upstream failures from triggering unintended liquidations
Cascading effects due to false-positive volatility signals
Curators do not have control over baseline reporting. They are only invoked when protective thresholds are breached.
6. Performance Profile
Canary Nest Oracle is designed for real-time, latency-critical applications. This includes stablecoin rebalancing, RWA index tracking, and time-sensitive liquidations. Unlike legacy oracles that rely on periodic polling or batched submissions, Nest supports continuous updates with sub-10 millisecond responsiveness.
Current production performance:
Median end-to-end latency: 5ms
Peak throughput: >1000 updates per second across distributed clusters
Target latency (Q4 roadmap): 5ms end-to-end, from source API fetch to on-chain publication
Latency is defined from the moment the source data is available over TLS to the moment a signed, attested update is submitted on-chain. Canary optimizes this through enclave-local TLS stacks, zero-copy serialization, and concurrent threshold aggregation pipelines.
Such low-latency guarantees make Nest suitable for use cases previously gated to centralized infrastructure (e.g., FX feeds, real-time NAV, synthetic index tracking) — now enabled with cryptographic verifiability and no trusted operators.
Last updated