2.1 The Four-Layer Stack

The overall architecture of OmniPact follows the "Separation of Concerns" principle. We divide the protocol stack from bottom to top into: the settlement layer, the core protocol layer, the data privacy layer, and the interface layer. The following diagram shows the data flow and logical control relationships of this vertical architecture:

graph TD
    subgraph L4["L4: Interface Layer (Interface layer)"]
        SDK[Client SDK / UI]
        API[Relayer API]
        Graph[The Graph Indexer]
    end

    subgraph L3["L3: Data & Privacy Layer (Data and Privacy Layer)"]
        Oracle[Chainlink Oracles]
        IPFS[IPFS Storage]
        TEE[TEE / ZK-Circuits]
    end

    subgraph L2["L2: Core Protocol Layer (Core Protocol Layer)"]
        OES[OES Engine (FSM)]
        DAN[DAN Arbitration]
        Reputation[SBT Logic]
    end

    subgraph L1["L1: Settlement Layer (Settlement Layer)"]
        EVM[EVM Adapters (ETH/Arb...)]
        SVM[SVM Adapters (Solana)]
        Bridge[Cross-Chain Bridge]
    end

    L4 -->|Query/Tx| L2
    L4 -->|Read Data| L3
    L2 -->|State Update| L1
    L2 -->|Request Proof| L3
    L3 -->|Callback| L2

2.1 The Four-Layer Stack

L1: Settlement Layer

—— -- Multi-chain Adapters & Finality Anchoring

L1 is the physical foundation of the protocol, responsible for asset custody, transfer, and final confirmation of transaction status. OmniPact does not build its own public chain; instead, it is deployed as a set of smart contracts on existing high-performance blockchains.

  • Multi-chain Adapters: To achieve "chain agnosticism", we have designed the ISettlementAdapter abstract interface at the underlying layer. This interface eliminates the differences between underlying virtual machines:

    • EVM Adapter: Compatible with Ethereum, Arbitrum, BSC, Optimism and other chains based on Solidity/Vyper.

    • SVM Adapter: Adapt to parallel execution environments such as Solana (Rust).

    • WASM Adapter: Adapt to WASM environments such as Polkadot and Cosmos.

  • Asset Custody:

    L1 does not handle complex business logic and is only responsible for the most "foolish" yet critical task: Atomic Transfer. Funds are locked in decentralized Vault Contracts, and the transfer() operation is only executed upon receiving valid instructions from L2 (accompanied by correct cryptographic signatures or state roots).

  • Cross-Chain Bus:

    Using LayerZero or CCIP, L1 is responsible for handling the emission and reception of cross-chain messages, ensuring that funds locked on Chain A can be safely triggered for release on Chain B.


L2: Core Protocol Layer

—— -- Business Logic & State Management

L2 is the "brain" of OmniPact, containing the core smart contract logic of the protocol. All rules regarding the guarantee process, arbitration voting, and reputation calculation reside here.

  • OES Engine (Omni Escrow System):

    This is a deterministic finite state machine (FSM). It maintains a global guarantee contract registry (Registry) and the state of each order.($S_{locked}$, $S_{delivered}$, etc.)It defines the rules for fund flow but does not directly hold funds (funds are held by L1).

  • DAN Contracts (Decentralized Arbitration Network):

    Responsible for governance and judicial logic.

    • Sortition Module: Execute the VRF lottery algorithm to select arbitrators.

    • Voting Module: Process the Commit-Reveal voting process and calculate the game theory equilibrium results.

    • Incentive Module: Automatically allocate arbitration fees and implement slashing.

  • Logic Upgradeability :

    The OpenZeppelin UUPS (Universal Upgradeable Proxy Standard) proxy pattern is adopted. This allows us to fix logical vulnerabilities or optimize algorithms in L2 through DAO voting without migrating user funds (L1) and data (L3).


L3: Data & Privacy Layer

—— -- Off-Chain Compute & Verifiable Storage

Due to the high cost and public nature of blockchain storage itself, OmniPact has introduced L3 to handle data interactions involving large amounts of data, privacy-sensitive information, or those that need to connect to the real world.

  • Decentralized Storage (IPFS/Arweave):

    • Purpose: Store large unstructured data, such as contract PDFs, original design drafts, and arbitration evidence images. ◦ Mechanism: Only store the CID (Content Identifier) hash value of the file on the L2 chain. This ensures the immutability of the data while reducing Gas costs.

  • Oracles (Oracle Network):

    • Purpose: Obtain "off-chain truth".

    • Integration: Integrate Chainlink Functions and Automation. For example, automatically read the logistics status from the FedEx API, or monitor the longitude and latitude signals of IoT devices, which can serve as triggers for the flow of L2 state machines.

  • Privacy Compute (TEE & ZK):

    • TEE (Trusted Execution Environment): Use Intel SGX hardware enclaves to process extremely sensitive data (such as private key shards, unencrypted trade secrets).

    • ZK-Circuits : Used for zk-KYC and zk-Reputation. Without exposing the user's original data (such as passport number), generate a mathematical proof for L2 , proving that the user meets compliance requirements.


L4: Interface Layer

—— -- Developer Experience & Access Gateway

L4 is a portal for users and external applications to interact with protocols. It abstracts the underlying complex contract logic into easy-to-use APIs and SDKs.

  • OmniPact SDK (TypeScript/Python/Go):

    A code library encapsulated for developers. Developers do not need to directly write Solidity calls; they only need to call omnipact.createEscrow({...}) to integrate the escrow function. The SDK has built-in IPFS upload, data encryption, and wallet signature logic.

  • The Graph Subgraphs (Index Layer): Since querying historical data directly from blockchain nodes is extremely inefficient, we have deployed GraphQL Subgraphs.Function: Index all OES events (such as EscrowCreated, DisputeRaised)。

    • Purpose: Front-end DApps can obtain "all historical orders of a certain user" or "the list of cases currently in dispute" in milliseconds.

  • Relayer API (Relay Service):

    To support "Gasless Transactions (Gasless Tx)" and "Account Abstraction", L4 provides relay services. Users only need to sign the message (EIP-712), and the relayer is responsible for on-chain processing and paying Gas fees on their behalf (the fees are deducted from the collateral amount), which greatly lowers the entry barrier for Web2 users.


Through the organic combination of a four-layer architecture, OmniPact achieves the perfect integration of settlement security (L1), logical rigor (L2), data scalability (L3), and ease of use (L4).

Last updated