Step 2: Transaction Proving

The query-prove-verify process enables Universal Smart Contracts to trustlessly verify and use data from 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

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 x is part of block y
• Continuity Proofs: Prove that block y is part of the finalized source chain

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

Where are proofs generated, and where are they used?

• Proof Generation API Server (off-chain): Generates Merkle and continuity proofs on-demand
• Native Verifier Precompile (on-chain): Verifies proofs synchronously and extracts data

Full Process Summary

1. A dApp team or end user identifies a target transaction they want to verify. This is usually done via a Oracle Query Worker that listens for source chain events and submits proving requests.
2. The Oracle Query Worker requests proofs from the Proof Generation API Server via an endpoint like proof-by-tx/{chain_key}/{tx_hash} .
3. The Proof Generation API Server retrieves attestation data from Creditcoin and fetches source chain blocks.
4. The Proof Generation API Server then uses attestation and block data to construct a continuity proof and a merkle proof for the target tx. These proofs are returned to the Oracle Query Worker.
5. The Oracle Query Worker submits the target tx and its proofs to Creditcoin via a Universal Smart Contract call. There, the tx and proofs are passed to the Native Verifier Precompile
6. The Native Verifier Precompile verifies both proofs synchronously, flagging whether the target tx is valid or invalid.
7. Once verified, the transaction data can be decoded and used for dApp business logic