> For the complete documentation index, see [llms.txt](https://docs.creditcoin.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.creditcoin.org/usc/creditcoin-oracle-subsystems/readability/step-2-transaction-proving/steps-of-transaction-proving.md).

# 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:

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

## Transaction Proving Visualized

{% @mermaid/diagram content="
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.&#x20;

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](/usc/creditcoin-oracle-subsystems/readability/step-2-transaction-proving/continuity-proving-for-queries.md)

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:

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


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.creditcoin.org/usc/creditcoin-oracle-subsystems/readability/step-2-transaction-proving/steps-of-transaction-proving.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.