Query, Proof and Verification

The proving subsystem of the Creditcoin Oracle uses attestations and source chain blocks to prove that parts of a particular source chain transaction are included in a given source chain.

Overview

The query-prove-verify process enables Universal Smart Contracts to trustlessly verify and use data from external source chains. The process consists of four main phases:

  1. Query Phase: Identifying the target transaction for verification

  2. Proof Generation Phase: Creating Merkle and continuity proofs

  3. Verification Phase: Cryptographic verification of the proofs

  4. Data Extraction Phase: Extracting transaction data from verified bytes

Each phase builds on the previous one, creating a trustless verification chain from source chain transaction to Creditcoin smart contract execution.

Proof Types

To prove that a transaction occurred on a source chain, the system uses two complementary cryptographic proofs:

  • Merkle Proofs: Prove that a specific transaction is included in a particular block on the source chain

  • Continuity Proofs: Prove that the block containing the transaction is part of the finalized source chain (linked to attestations)

Together, these proofs provide cryptographic certainty that a transaction actually occurred on the source chain, enabling trustless cross-chain applications.

This process utilizes:

  • Proof Generation API Server (off-chain): Generates Merkle and continuity proofs on-demand

  • Native Query Verifier Precompile (on-chain): Verifies proofs synchronously and extracts data

The Proof Generation API queries indexed attestation and checkpoint data on Creditcoin and fetches source chain blocks from RPC nodes, then constructs continuity proofs using the computed roots and digests from the indexed data. For queries between checkpoints, the API queries all attestations in the checkpoint interval range. These proofs are submitted to Creditcoin via USC contracts, where the precompile verifies them synchronously. Once verified, transaction data is immediately available for use—no intermediate storage or async processing required.

The detailed process flow is explained in the next section.

Last updated