> 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/creditcoin-usc/readability/step-2-transaction-proving.md).

# 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**](/creditcoin-usc/architecture.md#native-query-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