Understanding Chainlink DECO: A Privacy-Preserving Oracle
TechFlow Selected TechFlow Selected
Understanding Chainlink DECO: A Privacy-Preserving Oracle
Web3 reshapes the value of data, but the blockchain's distributed structure is a closed deterministic system.
Navigating Web3 tides with focused insightsAuthor: kokii.eth, Qiming Venture Partners Intern
0. Intro
Web3 reshapes data value, but decentralized blockchains are closed deterministic systems. Smart contracts lack the ability to make external API calls, giving rise to oracles—mechanisms that enable smart contracts to access off-chain data.
Bringing off-chain data on-chain is not technically difficult; the real challenge lies in using technology and mechanism design to produce trust. The oracle problem involves establishing trust across the entire pipeline—from data source, through processing, to price feeding.
A fundamental requirement for a publicly accepted oracle is decentralization—ensuring no single point of failure and enabling data verification. A common off-chain solution is to use multiple data nodes forming a decentralized oracle network, where each node collects data, reaches consensus, and feeds it into blockchain-based smart contracts.
Chainlink Architecture
Currently, the primary use of oracles is providing Price Feeds for DeFi, securely and accurately updating prices of underlying assets in real time. According to DefiLlama data, Chainlink is one of the largest oracle solutions in the market, securing approximately $11B in total value at the time of writing—accounting for 46% of the entire market.
Oracle Market Data
As blockchain evolves, demand for off-chain data grows stronger. Merely providing price feeds for DeFi can no longer meet developers’ needs. Most real-world and Web2 data are not publicly accessible, yet essential for building innovative Web3 applications (credit lending, social platforms, DID, KYC/AML, etc.). Therefore, next-generation oracles must allow smart contracts to support complex use cases involving sensitive data while preserving privacy.
DECO is Chainlink’s solution in this direction: leveraging zero-knowledge proof (ZKP) technology to let users generate proofs of off-chain private data for smart contracts, without revealing the data to the public or even to oracle nodes themselves.
DECO can integrate with existing APIs—even those requiring end-user authentication (e.g., logging in to retrieve bank account balance)—without requiring any modifications from API providers. It has currently reached alpha stage and is testing proof-of-concept implementations with several partners.
1. Background
This section provides essential background on TLS and ZKP—the foundational protocols upon which DECO is built.
1.1 TLS
TLS (Transport Layer Security) is a robust, widely-deployed security protocol, formerly known as SSL. It ensures privacy and data integrity in internet communications, operating between application protocols and TCP/IP layers, primarily used to encrypt communication between web applications and servers.
Communication over HTTP occurs in plain text, making it vulnerable to eavesdropping, tampering, and spoofing. With TLS, all HTTP data sent from users to websites (clicks, form submissions, etc.) and vice versa is encrypted. Recipients must use a key to decrypt the data. HTTPS implements TLS encryption over HTTP and is now standard practice. Websites must install a TLS certificate on their origin server; browsers mark all non-HTTPS sites as insecure.
Non-HTTPS Website
The core idea of TLS is based on public-key cryptography: the website's publicly shared TLS/SSL certificate contains the public key, while the private key resides on the origin server and is controlled by the site owner. The client first requests the server’s public key certificate, uses it to encrypt messages, and the server then decrypts them using its private key.
However, public-key encryption is computationally expensive. To reduce session overhead, both client and server generate a "session key" during each session to encrypt data. Since session keys use symmetric encryption, they are much faster. The server’s public key is only used to encrypt the session key itself, minimizing computational cost.
Thus, the TLS protocol consists of two main layers:
-
Handshake Protocol: Conducted in plaintext initially, this phase uses asymmetric encryption to authenticate each party, negotiate encryption algorithms, and establish a shared session key for the Record Protocol.
-
Record Protocol: The core of the protocol, responsible for confidentiality and integrity of data transmission using symmetric encryption.
TLS Protocol Stack
The TLS CipherSuite combines four cryptographic algorithms:
-
Authentication: Verifies identity authenticity, commonly using RSA/DSA/ECDSA.
-
Key Exchange: Negotiates the encryption key between parties, typically using ECDHE.
-
Encryption: Symmetric encryption for data transfer, trending toward GCM mode.
-
MAC (Message Authentication Code): Ensures data integrity and detects tampering, commonly using SHA256/SHA384/SHA1.
Despite its strength, TLS has one limitation: it does not allow users to prove to third parties that the data they accessed truly originated from a specific website. Because data is transmitted via symmetric encryption, both user and server have equal ability to sign data. For example, many websites store Alice’s identity information and can easily verify she is over 18, but Alice struggles to prove this to Bob. She could take a screenshot, but screenshots are easily forged—and even if proven authentic, they leak excessive information (her exact birthdate), rather than just the fact that she is over 18.
Oracles need to provide decentralized (not relying on a single server) proof of provenance for off-chain private data, enabling smart contracts to use such data without compromising privacy. Zero-knowledge proofs can help achieve these goals.
1.2 ZKP
Zero-Knowledge Proofs (ZKP) have gained significant attention in blockchain, primarily applied in ZK-Rollups (which compromise on full zk properties for scalability efficiency, producing validity proofs rather than true ZK proofs) and privacy technologies (genuine zk). ZKPs allow a Prover to convince a Verifier that they know a witness solving a computational statement, without revealing any additional information about the witness.
A typical ZK system comprises two parts:
-
Frontend: A compiler that converts the statement to be verified into a domain-specific language (DSL), then compiles it into a ZK-friendly format like arithmetic circuits;
-
Backend: A proof system—an interactive argument system that verifies circuit correctness, e.g., Marlin, Plonky2, Halo2.
ZK System
Constructing interactive protocols in open systems like blockchains is complex. Since anyone should be able to verify proofs at any time, ZK systems in blockchain applications are typically non-interactive. Interactive proofs can be converted to non-interactive ones using the Fiat–Shamir heuristic.
2. How DECO Works
DECO extends HTTPS/TLS protocols, allowing usage without requiring modifications from servers.
The core idea of DECO is to establish a novel three-party handshake protocol among the Prover (user or DApp running the DECO Prover), Verifier (Chainlink oracle running the DECO Verifier), and Server (data provider).
-
Provenance: When the Prover queries a web server, the Verifier witnesses the interaction and receives a commitment created by the Prover over the TLS session data, enabling verification of the data’s authentic origin;
-
Privacy: If data privacy is not required, the Prover can directly share the decryption key with the Verifier for inclusion in DApps. If privacy is needed, the Prover generates a zero-knowledge proof that reveals nothing about the data itself, allowing developers to incorporate it safely.
DECO Example
Specifically, the DECO protocol consists of three phases:
-
Three-party handshake: Prover, Verifier, and Server establish a specially formatted session key to ensure data cannot be forged;
-
Query execution: Prover sends a query containing her private parameters θs (e.g., login credentials, API key) to the Server to retrieve data;
-
Proof generation: Prover proves that the response satisfies required conditions.
DECO Architecture
2.1 Three-party Handshake
Note: The following explanation assumes AES-CBC-HMAC cipher suite. TLS 1.3 retains only AEAD ciphers, using a single key for both encryption and MAC, eliminating the need for a separate MAC key. However, due to TLS 1.3’s key separation property, a similarly complex three-party handshake can still be constructed.
The Prover P must not be allowed to commit after obtaining the MAC key, otherwise he could forge or alter data. Hence, the idea is to treat both Prover P and Verifier V as joint TLS clients, establishing a shared MAC key with the TLS server S. The MAC key k is split between client-side participants: P holds kp, V holds kv, such that k = kp + kv. Meanwhile, P also holds the symmetric encryption key k^Enc. As long as the Verifier is honest, this three-party handshake ensures data cannot be forged.
2.2 Query Execution
After the handshake, since the MAC key is secretly shared, P and V execute an interactive protocol (two-party secure computation) using private parameter θs to construct an encrypted TLS query message Q. Then P, acting as a standard TLS client, sends Q to S. During this process, only P communicates with S; no query details are revealed to V.
Upon receiving the response R from S, P sends the ciphertext R̂ to V as a commitment to the session, and receives kv from V to verify the authenticity of response R.
2.3 Proof Generation
Next, P must prove that the plaintext R corresponding to ciphertext R̂ satisfies certain properties. If privacy is not required, P can simply reveal the encryption key k^Enc. When privacy is required, zero-knowledge proofs are used.
Suppose the plaintext consists of several blocks R=(B1,...,Bn). DECO uses Selective Opening to generate zero-knowledge proofs:
-
Reveal only specific data rows: Prove that the i-th block of R is Bi, without revealing other blocks.
-
Hide rows containing private data: Prove that R_{-i} equals R except with Bi removed.
However, often the Verifier needs to confirm that the revealed substring appears in the correct context—methods above do not fully protect contextual integrity. To address this, DECO employs a technique called Two-stage Parsing: the Prover parses session data locally and determines the minimal substring sufficient to convince the Verifier, then sends only that data. This achieves strong privacy.
Non-Interactive Zero-Knowledge (NIZK) proofs usually impose high computational and memory costs on the Prover. Since DECO’s Verifier is designated (Chainlink oracles), more efficient interactive ZK proofs can be used—offering smaller memory footprint, no trusted setup, and cheaper computation.
In the current Alpha Test, DApps still act as Provers. Future iterations plan to support local deployment by end-users (e.g., mobile devices) or within Trusted Execution Environments (TEE).
3. Applications
DECO enables verification of users’ off-chain identity information while preserving data privacy, unlocking numerous innovative Web3 use cases spanning finance and social applications.
- Self-custody social recovery/legal identity proof (who you are): Using DECO, institutions with mature identity systems (banks, social media) can serve as one of the guardians in a self-custody wallet’s social recovery scheme.
- Credit lending/funds verification (how much money you have): Teller is a DeFi credit lending protocol using DECO to prove that a user’s off-chain bank account balance exceeds dynamically set minimum thresholds for loans.
-
Fan verification/interaction proof (who you interact with): Clique is a social oracle developing solutions to deeply analyze users’ off-chain influence, loyalty, and contributions across various social platforms (e.g., via Twitter API).
-
Digital identity/social account ownership proof (you own an online account): PhotoChromic is a digital identity solution using DECO to bind Web3 users to their Twitter or Discord accounts without exposing underlying personal data, enabling apps to filter genuine users.
-
Sybil resistance in DAOs, SBTs, KYC/AML, etc.
4. Other Players
-
Axiom builds ZK oracles for Uniswap TWAP, sourcing verifiable data entirely from on-chain data—more akin to indexing (e.g., Hyper Oracle). Axiom complements rather than competes with DECO: as more economic activity moves on-chain, purely on-chain oracles are one path; as more off-chain data needs integration, privacy-preserving off-chain oracles represent another.
-
Empiric Network uses zk computations to move the entire oracle on-chain, eliminating off-chain infrastructure through which data must flow—diverging fundamentally from DECO’s approach.
5. Conclusion
As the dominant oracle provider today, Chainlink—with DECO—enables vast amounts of off-chain private data to be securely accessed by on-chain smart contracts under privacy preservation, unlocking diverse applications from finance and identity to social platforms.
Potential concerns include the speed of proof generation by the Prover and the centralization risk associated with the Verifier.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
