In the context of decentralized oracle networks (DONs), a proof response is the cryptographically signed and verifiable result delivered back to a requesting smart contract. It is the output of a Chainlink oracle job, which is initiated by an on-chain request for data (like a price feed) or computation (like a verifiable random number). This response is not just raw data; it is packaged with cryptographic proofs that allow the receiving contract to validate its authenticity and integrity before accepting and acting upon it. This process is fundamental to creating tamper-proof connections between blockchains and external systems.
LABS
Glossary
Proof Response
A Proof Response is a message from a credential holder to a verifier containing a Verifiable Presentation that satisfies the requirements specified in a Proof Request.
Chainscore © 2026
definition
BLOCKCHAIN VERIFICATION
What is a Proof Response?
A proof response is the verifiable data packet returned by a decentralized oracle network, such as Chainlink, to a smart contract that has requested off-chain computation or data.
The structure of a proof response typically includes the requested data payload, a signature from the oracle node or committee that generated it, and often a proof of execution or attestation. For high-value requests, responses may be aggregated from multiple independent oracle nodes, with the final answer determined by a consensus mechanism. The receiving smart contract uses pre-configured logic, such as checking signatures against a known set of node operators or verifying a threshold signature, to validate the proof response. This ensures the data is not corrupted or provided by a malicious actor.
A common example is a price feed update. A decentralized application's smart contract requests the latest ETH/USD price. The DON's nodes fetch data from multiple premium data providers, aggregate the results, and submit a proof response containing the median price and signatures from a supermajority of nodes. The contract's consuming contract logic verifies the signatures and, if valid, updates its internal state with the new price. This mechanism provides strong guarantees that the data is accurate and has not been manipulated in transit, which is critical for DeFi protocols handling loans, derivatives, and stablecoins.
how-it-works
MECHANISM
How a Proof Response Works
A proof response is the verifiable output returned by a proving system after successfully generating a cryptographic proof, serving as the primary data structure for verification.
A proof response is the structured data object returned by a prover (e.g., a sequencer or a specialized proving service) after it has executed a computational task and generated a corresponding cryptographic proof. This response typically contains the proof itself—such as a STARK, SNARK, or Validity Proof—along with essential metadata. This metadata includes the public inputs to the computation, a commitment to the output state, and often a timestamp or batch identifier. The response is the critical artifact that allows any verifier to cryptographically confirm the correctness of the underlying execution without re-running it.
The core function of the proof response is to enable trustless verification. When a verifier, which could be a smart contract on a Layer 1 blockchain like Ethereum or an independent node, receives the proof response, it runs a lightweight verification algorithm. This algorithm checks the proof against the claimed public inputs and outputs. A successful verification, indicated by the algorithm returning true, provides cryptographic certainty that the prover performed the computation correctly and that the resulting state transition is valid. This mechanism is foundational for Layer 2 rollups (ZK-Rollups, Optimistic Rollups with fraud proofs) and proof aggregation services.
In practical systems, the proof response is often transmitted and stored on-chain. For a ZK-Rollup, the proof response is submitted to the L1 settlement layer in a calldata field or as a contract state update. The on-chain verifier contract then processes it to finalize the batch of transactions. Key properties of a robust proof response include succinctness (the proof is small and fast to verify), soundness (a false proof cannot be generated except with negligible probability), and non-interactivity (verification requires only the proof and public data).
Different proving architectures yield different proof response formats. A STARK proof response might include the proof and Merkle root commitments, while a SNARK proof response, like a Groth16 proof, consists of three elliptic curve points. Optimistic rollups use a variant where the proof response is only generated and submitted in the event of a challenge, containing the fraud proof and the specific step of execution in dispute. The design of the proof response directly impacts the cost of verification and the security assumptions of the system.
For developers and node operators, interacting with proof responses involves integrating with specific prover APIs and verifier smart contracts. The workflow typically involves: submitting a request with computational parameters to a prover service, awaiting the proof response, and then broadcasting that response to the relevant network or contract. Monitoring tools parse these responses to track proof generation times, verification gas costs on L1, and the overall health and latency of the proving infrastructure, which are critical metrics for system performance.
key-features
BLOCKCHAIN VERIFICATION
Key Features of a Proof Response
A Proof Response is the structured data returned by a verifier or oracle after cryptographically proving the state of a blockchain. This section details its core technical components.
01
Block Header Commitment
The response includes a cryptographic commitment (like a Merkle root) to the block header, proving the block's existence and integrity without transmitting the entire block. This is the foundational proof of state.
- Key Element: Block hash or Merkle root of header fields.
- Purpose: Enables verification of block inclusion and finality.
- Example: A Merkle-Patricia Trie root committing to the block's
stateRoot,transactionsRoot, andreceiptsRoot.
02
State Proof (Merkle Proof)
To prove specific on-chain data (e.g., an account balance or storage slot), the response contains a Merkle proof. This is a path of cryptographic hashes from the target data up to the committed root in the block header.
- Mechanism: A path of sibling hashes for a Merkle-Patricia Trie.
- Verification: The client hashes the proven data with the provided siblings to recompute and match the committed root.
- Use Case: Proving an ERC-20 token balance or a specific smart contract storage value.
03
Receipt & Log Proof
For proving that a transaction occurred and emitted specific events, the response includes a receipt proof. This proves the transaction receipt's inclusion in the receiptsRoot and contains the relevant log entries.
- Components: Merkle proof for the receipt and the parsed log data.
- Critical for: Cross-chain bridges and oracles that listen for on-chain events as triggers.
- Data Includes: Log topics (e.g., event signatures) and indexed/non-indexed data.
04
Verifier Signature & Attestation
The proof response is typically signed by the verifier node or committee attesting to the validity of the underlying cryptographic proofs. This signature provides accountability and trust in the proof's generation.
- Format: A cryptographic signature (e.g., ECDSA, BLS) over a digest of the proof data.
- Purpose: Prevents tampering during transmission and identifies the attesting entity.
- Advanced Systems: May use threshold signatures from a validator set for decentralized attestation.
05
Minimal & Verifiable Design
A core feature is data minimization. The response contains only the essential cryptographic proofs and data needed for verification, not the entire blockchain history. This makes it lightweight and gas-efficient for on-chain consumption.
- Principle: Provide the verification witness, not the raw data.
- Benefit: Reduces bandwidth and on-chain computation costs (gas).
- Contrast: Unlike an RPC call that returns raw data, a proof response returns the proof of that data.
06
Standardized Encoding
For interoperability, proof responses often follow standardized formats like EIP-3668 (CCIP Read) or the format used by light clients. This defines the structure of the proof payload for consistent on- and off-chain handling.
- Standards: EIP-3668, ICS-23 (IBC), or custom verifier ABI.
- Encoding: Often uses RLP or SSZ serialization for efficient packing.
- Importance: Ensures different proving systems and consuming contracts can understand the proof.
core-components
PROOF RESPONSE
Core Components of a Proof Response
A Proof Response is the structured data object returned by a proving system, containing cryptographic evidence that a computation was executed correctly. It is the primary output of a zero-knowledge proof or validity proof system.
01
Proof Itself
The core cryptographic string, often called the proof π (pi), is a succinct piece of data that attests to the validity of a statement. For zk-SNARKs, this is a short, constant-size string. For zk-STARKs, it is slightly larger but does not require a trusted setup. This component is what is verified by the verifier's algorithm.
02
Public Inputs
These are the non-secret data points that both the prover and verifier must agree upon. They are part of the statement being proven, such as:
- A new state root after a batch of transactions.
- A public account balance or commitment.
- A nullifier to prevent double-spends in privacy systems. The verifier uses these inputs, along with the proof, to check validity.
03
Verification Key
A reference to the cryptographic parameters needed to verify the proof. In trusted setup systems like Groth16, this is a specific key generated during a ceremony. In transparent systems like STARKs, this may be derived from public information. The verifier uses this key to run the verification algorithm against the proof and public inputs.
04
Circuit / Constraint System Reference
An identifier for the specific arithmetic circuit or R1CS (Rank-1 Constraint System) that defines the computation being proven. This ensures the proof is validated against the correct logical rules. In practice, this is often embedded within or referenced by the verification key.
05
Metadata
Additional contextual data that is not part of the cryptographic verification but is essential for system operation. This can include:
- Prover address or identifier.
- Timestamp of proof generation.
- Gas costs or computational metrics.
- A version number for the proving system.
06
Verification Result
While not part of the response from the prover, the ultimate output of processing a Proof Response is a boolean verification result (true/false). A true result cryptographically guarantees that the computation was executed correctly according to the public inputs and circuit, without revealing any private inputs.
ZKP DATA FLOW
Proof Request vs. Proof Response
A comparison of the initiating message and the resulting proof in a zero-knowledge proof (ZKP) protocol.
| Feature | Proof Request | Proof Response |
|---|---|---|
Primary Role | Query for proof of a specific statement | Proof of the requested statement |
Core Components | Public inputs, circuit/constraint system identifier, prover policy | Proof bytes, public outputs, optional verification key |
Initiated By | Verifier | Prover |
Data Direction | Verifier → Prover | Prover → Verifier |
Contains Secret/Witness Data | ||
Verification Input | Used to define what to verify | Used to perform the actual verification |
Format Example | JSON, Protocol Buffers | Binary blob, JSON with proof field |
On-Chain Use Case | Defining verification logic in a smart contract | Submitting proof for contract state change |
examples-protocols-formats
BLOCKCHAIN GLOSSARY
Protocols & Data Formats
A Proof Response is the structured data returned by a blockchain node or API to prove the existence, state, or validity of a specific piece of on-chain information. It is the core output of a verification protocol.
01
Core Definition & Purpose
A Proof Response is a cryptographically verifiable data package that serves as a formal answer to a query about blockchain state. Its primary purpose is to provide trust-minimized verification without requiring the verifier to sync the entire chain. Key components typically include:
- Block Headers: For establishing consensus and finality.
- Merkle Proofs: For proving inclusion of a transaction or state in a block.
- Receipts & Logs: For proving the outcome of a smart contract execution.
- State Proofs: For proving an account's balance or storage value at a specific block.
02
Verification Protocols (e.g., EthProof)
Proof Responses are generated by specific verification protocols that define the data format and proof construction rules. A prominent example is the EthProof protocol used by light clients and bridges. An EthProof response for a transaction includes:
- A header chain proof linking the block to a finalized checkpoint.
- A Merkle-Patricia Trie proof for the transaction and its receipt.
- The finality signal (e.g., consensus signatures) for the block. This standardized format allows any client to cryptographically verify the transaction's existence and success.
03
Data Structure & Serialization
Proof Responses are serialized into efficient, standardized formats for transmission and storage. Common formats include:
- RLP (Recursive Length Prefix): The native serialization method in Ethereum, used for encoding block headers and proofs.
- SSZ (Simple Serialize): Used in Ethereum's consensus layer (Beacon Chain) for its efficiency and Merkleization properties.
- Compact Binary Formats: Often used in cross-chain bridges for reduced payload size. The structure is designed to be deterministic, ensuring the same query always produces an identical, verifiable proof.
04
Use Cases: Light Clients & Bridges
Proof Responses are the foundational data layer for critical trust-minimized applications.
- Light Clients: Use proof responses to query and verify chain data (e.g., a wallet balance) without running a full node.
- Cross-Chain Bridges (Light Client Bridges): A bridge on Chain B uses a proof response from Chain A to verify that assets were locked before minting representations. This is more secure than relying on a multisig.
- Indexers & Oracles: Services like The Graph or Chainlink can provide verifiable proof responses about historical state to off-chain applications.
05
Proof Types: Inclusion vs. Non-Inclusion
Proof Responses can prove different types of statements about the chain.
- Inclusion Proof: Proves that a specific transaction or piece of data is contained within a block. This uses a Merkle proof path from the leaf to the known block root.
- Non-Inclusion Proof: Proves that a transaction or state key is not present in a block or trie. This is more complex, often requiring a proof that all possible paths at a location are empty.
- State Proof: Proves the value associated with a key in the state trie (e.g., an account's
nonce,balance,codeHash, orstorageRoot).
06
Verification Process & Gas Costs
Verifying a Proof Response on-chain (e.g., in a smart contract) involves executing cryptographic operations, which incurs gas costs. The process typically:
- Verifies the block header's consensus (e.g., checks a signature threshold).
- Validates the Merkle proof against the proven block header's root hash.
- Parses the proven data (e.g., transaction receipt). Gas-intensive steps include signature verification (e.g., ECDSA recovery, BLS verification) and hash operations. Optimized verification contracts are crucial for cost efficiency in applications like bridges.
security-considerations
PROOF RESPONSE
Security & Privacy Considerations
A Proof Response is the cryptographic evidence returned by a verifier, proving a user's data satisfies a specific condition without revealing the underlying data. This section details the security properties and privacy implications of this core ZK component.
01
Zero-Knowledge Property
The fundamental security guarantee of a Proof Response is that it reveals nothing beyond the validity of the statement. It does not leak the private inputs (witness) used to generate it. This is enforced by the underlying zero-knowledge proof system (e.g., zk-SNARKs, zk-STARKs), which mathematically ensures the proof is simulatable without knowledge of the secret.
02
Soundness & Fraud Prevention
A sound proof system guarantees that a valid Proof Response can only be generated if the underlying statement is true. The soundness error (probability of a false proof being accepted) is typically negligible (e.g., 2^-128). This cryptographic property prevents users from fraudulently claiming eligibility for rewards, access, or credentials they do not legitimately possess.
03
Privacy-Preserving Verification
The Proof Response enables verification against public criteria (the circuit) without exposing personal data. For example:
- Proving age > 18 without revealing birthdate.
- Proving a balance exceeds a threshold without revealing the amount.
- Proving membership in a group without revealing identity. This shifts the trust model from trusting the verifier with data to trusting the correctness of the public verification algorithm.
04
Replay Attack Mitigation
A critical consideration is preventing the reuse of a Proof Response. Verifiers must implement mechanisms to ensure proof freshness and uniqueness. Common techniques include:
- Incorporating a nonce or timestamp into the circuit statement.
- Using nullifier schemes to mark a proof as spent.
- Maintaining a registry of used proof commitments. Without this, a single proof could be reused maliciously.
05
Trusted Setup & Circuit Integrity
For proof systems requiring a trusted setup (e.g., Groth16 zk-SNARKs), the security of every Proof Response depends on the correct generation and secure disposal of toxic waste from that ceremony. If compromised, false proofs could be generated. Furthermore, the circuit logic itself must be correctly implemented and audited, as it defines what is being proven.
06
Front-Running & MEV Considerations
In blockchain applications, a Proof Response submitted in a public mempool can be vulnerable to front-running. A malicious actor can see the proof, copy it, and attempt to have their own transaction included first to steal the benefit (e.g., claiming an airdrop). Privacy-preserving transaction protocols or commit-reveal schemes are often needed to mitigate this.
PROOF RESPONSE
Frequently Asked Questions (FAQ)
Common questions about the Proof Response, the core data object that powers Chainscore's on-chain reputation and scoring system.
A Proof Response is a cryptographically verifiable data package generated by Chainscore's oracle network that contains a wallet's reputation score and supporting on-chain metrics. It works by aggregating raw blockchain data, processing it through a scoring algorithm, and producing a signed, tamper-proof result that any third-party application can trust without needing to recompute the analysis. The response includes the final score, the data points used (like transaction volume or DeFi interactions), and a cryptographic proof (like a Merkle proof) linking the result back to the source blockchain state, enabling off-chain verification of on-chain behavior.
ENQUIRY
Get In Touch
today.
Our experts will offer a free quote and a 30min call to discuss your project.
NDA Protected
Confidentiality24h Response
Time to ValueDirectly to Engineering Team
No Sales Fluff10+
Protocols Shipped
$20M+
TVL Overall