# INTERCHAIN BRIDGE

**Basic Interchain Transaction Lifecycle**

<details>

<summary><mark style="color:blue;">1. User Initiates Action</mark></summary>

A user triggers an on-chain transaction on a zone chain (e.g., DeFiChain, Partisia or Polygon) such as transferring tokens, submitting a proposal, or interacting with a bridge. This initiates a multi-chain intent, which is captured by a registered Interchain operator.

</details>

Basic Interchain Transaction Lifecycle

#### <mark style="color:blue;">1. User Initiates Action</mark>

A user triggers an on-chain transaction on a zone chain (e.g., DeFiChain, Partisia or Polygon) — such as transferring tokens, submitting a proposal, or interacting with a bridge. This initiates a multi-chain intent, which is captured by a registered Interchain operator.

#### <mark style="color:blue;">2. Operator Prepares Partial Block</mark>

The operator (e.g., Crypto Factor Bridge) splits the transaction into logical execution parts — for example:

* Lock tokens on the source chain
* Release tokens on the destination chain

These are submitted to the partial chain mempool, ready for processing.

#### <mark style="color:blue;">3. Oracle Layer Fetches and Merges Mempools</mark>

The Oracle Layer, a distributed network of Nodes, collects partial blocks and submits them to the Interchain master mempool on Partisia Blockchain.

It includes:

* Zone chain block hashes
* Transaction proofs
* Execution metadata

This step ensures all zone data is traceable and cryptographically verifiable.

#### <mark style="color:blue;">4. Master Chain Proposes a Block</mark>

The Interchain Master Chain (on PBC) compiles a proposed block that includes all valid partial chain transactions.

This block:

* References zone chain IDs
* Includes Merkle roots of validated execution parts
* Sets up a unified state view for all connected chains

#### <mark style="color:blue;">5. Validation & ZK Signing</mark>

The proposed block undergoes multi-layer validation:

* EVM block verification
* Zone consensus checks
* Master chain validation

It is then signed using MPC-ZK signatures, ensuring zero-knowledge proof of validity without exposing sensitive details.

#### <mark style="color:blue;">6. Master Block is Finalised</mark>

The now signed and validated master block becomes the latest state of the Interchain.

It is:

* Immutable after confirmation threshold
* Stored on PBC
* The source of truth for all zone chains to derive execution updates

#### <mark style="color:blue;">7. Oracle Commits Partial Blocks Back to Zone Chains</mark>

Using Merkle proofs and ZK signatures, the Oracle Layer commits finalised Partial Blocks to their respective zone chains.

Each commitment includes:

* Block hash of the master chain
* Proof-of-finalisation for the partial block
* Timestamp and execution queue triggers

#### <mark style="color:blue;">8. Execution Queue is Triggered</mark>

Each zone chain activates its execution queue, which reads the confirmed execution parts and processes them:

* Token releases
* Governance updates
* State changes

Reverts are also handled if conditions were unmet or invalid.

#### <mark style="color:blue;">9. Operator Updates Protocol State</mark>

Operators update smart contract states to reflect the finalised transaction result. This could include:

* Emitting events
* Updating balances
* Triggering follow-up actions in the protocol logic

#### <mark style="color:blue;">10. User Receives Confirmation</mark>

The user’s wallet or interface reflects the result — such as tokens received or action confirmed — completing the cross-chain transaction cycle.

All steps are executed trustlessly, without central relayers or third-party dependencies.


---

# 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.crypto-factor.io/crypto-factor/interchain/interchain-bridge.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.