Steps of Transaction Proving

Overview

The transaction proving process enables Universal Smart Contracts to trustlessly verify and use data from source chains. The process consists of four main phases:

Query Phase: Identifying the target transaction for verification
Proof Generation Phase: Creating Merkle and continuity proofs
Verification Phase: Cryptographic verification of the proofs
Data Extraction Phase: Extracting transaction data from verified bytes

Transaction Proving Visualized

sequenceDiagram
participant User as Builder/User
participant SourceChain as Source Chain
participant ProofGen as Proof Generation API Server
box "Creditcoin (Runtime)"
participant AttestationPallet as Attestation Pallet (Storage)
participant USC as USC Contract
participant Precompile as Native Verifier Precompile
end
Note over User,Precompile: Query Preparation Phase
User->>SourceChain: 1. Fetch Block Data
SourceChain-->>User: Block + Transaction Data
User->>ProofGen: 2. Request Proofs
Note over User,Precompile: Proof Generation
ProofGen->>AttestationPallet: 3. Fetch Attestations/Checkpoints
AttestationPallet-->>ProofGen: Attestation Data
ProofGen->>SourceChain: 4. Fetch Source<br> Chain Blocks
SourceChain-->>ProofGen: Block Headers
ProofGen->>ProofGen: 5. Generate Merkle Proof
ProofGen->>ProofGen: 6. Build Continuity Proof
ProofGen-->>User: Merkle + Continuity Proofs
User->>USC: 7. Submit cross-chain USC call
Note over User,Precompile: Verification Phase
USC->>Precompile: 8. Call Precompile
Precompile->>AttestationPallet: 9. Read Attestations/Checkpoints
AttestationPallet-->>Precompile: Attestation Data
Precompile->>Precompile: 10. Verify Continuity Chain,<br> Merkle Proof, Query Block Digest
Precompile-->>USC: Return Result (bool + data)
Note over User,Precompile: Data Extraction Phase
USC->>USC: 11. Parse data and trigger business logic
USC-->>User: Return result and emit events

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:

Retrieve transaction data from 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 Proof Generation API server 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 Proof Generation API Server then takes our query block height and determines that query’s attestation bounds. Attestation bounds consist of the closest attestations above and below the query block height.

Next, the server fetches all the source chain blocks between our lower and upper attestation bounds. These blocks are used to form a continuity proof as detailed in our next section, Continuity Proving for Queries

Now that both proofs have been generated, our Proof Generation API returns the following:

Merkle Proof: Proves transaction inclusion in a block
Continuity Proof: Proves the block is part of the finalized source 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: Check computedRoot == merkleRoot (from continuity proof roots array)

3.2 Continuity Proof Verification process:

Starting from the back of the continuity chain, compute the following for each block: computedDigest = hash(block_number, merkleRoot, previousDigest)
Final step: Verify that 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:

Verify a Transfer event showing tokens were burned on Ethereum
Extract the from, to, and value from the event
Mint equivalent tokens on Creditcoin to the to address