# Process Flow ## **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: {% @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 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 Block Chain 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, 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: * 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 --- # Agent Instructions: 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/query-proof-and-verification/process-flow.md?ask= ``` 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.