Process Flow

This section explains the flow of how queries are processed, proofs are generated, and verification occurs in the Creditcoin Decentralized Oracle

Overview

The query-prove-verify 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.

The following diagram details the process flow:

Phase 1: Query Phase

A query specifies what needs to be proven:

• Source Chain: Which blockchain the transaction occurred on (identified by chainKey)

• Block Height: Which block contains the transaction

• Transaction: The specific transaction to verify (identified by transaction index or hash)

Example: "Prove that transaction at index 5 in block 18,000,000 on Ethereum mainnet actually occurred."

This query information is used to:

• Locate the transaction on the source chain

• Determine which source chain blocks need to be fetched

• Identify which attestations are needed for continuity proof

Phase 2: Proof Generation Phase

The Proof Generation API (or direct proof generation) creates two complementary proofs that together prove the transaction is legitimate.

2.1 Generating Merkle Proofs

The API requests the block at the specified height from a source chain RPC node. All transactions in the block are hashed to form a Merkle tree, with the Merkle root stored in the block header. The Merkle proof consists of:

• The Merkle root (from block header)

• Array of sibling hashes with position information

• The transaction bytes themselves

By providing the sibling hashes and the transaction bytes, anyone can reconstruct the path to the Merkle root. If the computed root matches the block header's root, the transaction is proven to be in that block.

2.2 Generating Continuity Proofs

The API locates upper (lowest attestation/checkpoint after query block) and lower (highest attestation/checkpoint before query block) attestation bounds and requests attestations stored on-chain in the Creditcoin attestation pallet. It gets source chain blocks between these bounds and constructs the continuity proof starts at queryHeight - 1 and extends to the next attestation/checkpoint. Each block's digest is computed using: digest = hash(block_number, merkle_root, previous_digest). This creates a cryptographic chain where each block's digest depends on the previous block. The continuity proof consists of:

• The digest of the block before the continuity chain starts (lowerEndpointDigest)

• Array of continuity blocks (each consisting of a digest)

• Block numbers are inferred from the query height and block indices

The API locates upper (lowest attestation/checkpoint after query block) and lower (highest attestation/checkpoint before query block) attestation bounds and queries indexed attestation data on Creditcoin. It gets source chain blocks between these bounds and constructs the continuity proof starting from queryHeight and extending to the next attestation/checkpoint. Each block's digest is computed using: digest = hash(block_number, merkle_root, previous_digest). This creates a cryptographic chain where each block's digest depends on the previous block. The continuity proof consists of:

• The digest of the block before the continuity chain starts (lowerEndpointDigest)

• Array of Merkle roots (digests are computed on-chain from these roots)

Block numbers are inferred from the query height and block indices (roots[0] is at queryHeight)

The continuity proof creates an unbroken cryptographic chain from the last attested block to the query block. If any block in this chain is modified, all subsequent digests change, making tampering detectable.

The Proof Generation API returns:

• Merkle Proof: Proves transaction inclusion in the block

• Continuity Proof: Proves the block is part of the finalized chain

• Encoded Transaction: The full transaction bytes (transaction + receipt data)

These three components together provide complete cryptographic proof that the transaction occurred on the source chain.

Phase 3: Verification Phase

The off-chain worker (or user) calls the USC contract function with the proofs and encoded transaction bytes. The USC contract then calls the native query verifier precompile to verify the proofs.

3.1 Merkle Proof Verification process:

• Start with: leafHash = hash(transaction_bytes)

• For each sibling: combine with sibling hash (left or right based on position)

• Final step: computedRoot == merkleRoot (from continuity proof roots array)

3.2 Continuity Proof Verification process:

• For each block in continuity chain: computedDigest = hash(block_number, merkleRoot, previousDigest)

• Verify: computedDigest matches the digest computed from the continuity proof structure

• Final step: finalDigest == onChainAttestationDigest

The verification happens synchronously in the same transaction execution.

• No Waiting: Results are available within seconds

• Atomic: Either all verification steps succeed (transaction continues) or all fail (transaction reverts)

• No Intermediate State: No query storage, no async processing, no waiting for finalization

USC contracts can use verified data immediately in the same transaction, enabling complex cross-chain logic without multi-step async flows.

Phase 4: Data Extraction Phase

After verification succeeds, the USC contract extracts the data it needs from the verified transaction bytes. The encodedTransaction bytes contain the full transaction data. It can be used to decode the transaction type, common fields, type-specific fields and the receipt fields.

Once data is extracted, the USC contract:

• Validates the extracted data (e.g., receipt status = success, expected event found)

• Executes business logic based on the verified cross-chain data

• Updates contract state or triggers additional actions

Example: A bridge contract might:

1. Verify a Transfer event showing tokens were burned on Ethereum

2. Extract the from, to, and value from the event

3. Mint equivalent tokens on Creditcoin to the to address