2.2 Contract Map

This section conducts an in-depth analysis of the interaction topology at the smart contract level. To demonstrate the team's professionalism in contract architecture design (Gas optimization, upgradability, security), OmniPact adopts the "Hub-and-Spoke" and "Singleton Vault" models for description. This aligns with the design trends of the most advanced DeFi protocols currently (such as Uniswap V4, Balancer V2).

---

2.2 Contract Map & Interaction Topology

The core protocol of OmniPact consists of a set of tightly coupled smart contracts with clear responsibilities. We have adopted a Hub-and-Spoke architecture, where Registry serves as the core router, Vault centrally manages assets, and Factory is responsible for dynamically expanding business logic.

2.2.1 Interaction Diagram

The following diagram shows the calling relationships and permission control flows between various core contract components:

Code segment

graph TD
    User[End User / Client]
    DAO[Governance DAO]

    subgraph "Core Protocol (L2)"
        Factory[OmniFactory (EIP-1167)]
        Registry[OmniRegistry (The Hub)]
        Vault[OmniVault (Singleton Asset Manager)]
        
        subgraph "Escrow Instances (Clones)"
            OES_A[OES Instance A (OTC)]
            OES_B[OES Instance B (Gig)]
        end
    end

    subgraph "External"
        Token[ERC-20 / NFT Assets]
        DAN[DAN Controller]
    end

    %% Flow: Governance
    DAO -->|1. Configure Parameters| Registry
    DAO -->|2. Whitelist Strategy| Factory

    %% Flow: Creation
    User -->|3. createEscrow()| Factory
    Factory -->|4. Deploy Clone| OES_A
    Factory -->|5. Record ID| Registry

    %% Flow: Asset Lock
    User -->|6. Approve & Deposit| Vault
    Vault -.->|7. Accounting Mapping| OES_A

    %% Flow: Execution
    OES_A -->|8. Request Settlement| Vault
    Vault -->|9. Transfer Funds| User
    
    %% Logic Link
    OES_A -.->|Read Config| Registry
    OES_A -.->|Trigger Dispute| DAN

2.2.2 Component Breakdown

A. OmniRegistry (The Source of Truth)

Role: The "brain" and "DNS server" of the system.

• Function:

  • Address resolution: Maintain the latest address mappings of all valid components (Factory, Vault, DAN).

  • Whitelist management: Store legal items that have been audited by DAO Implementation(Transaction Template) address.

  • Parameter control: Global rate（Protocol Fee）and the storage location for system parameters such as the minimum pledge threshold.

• Interaction: All OES instances must call before executing critical logic. Registry.getConfig() Validate parameters to ensure the consistency of the system state.

B. OmniFactory (The Scaler)

Role: A standardized "money-printing machine".

• Technical implementation:

  • Adopt the EIP-1167 (Minimal Proxy Standard) standard.

  • Instead of repeatedly deploying the complete bytecode, the Factory deploys extremely lightweight Clones (proxy contracts) that point to the pre-deployed Implementation Logical contract.

• Advantage: Reduce the Gas cost of deploying a new guarantee contract by more than 90% (only about 45k Gas), making high-frequency small-value transactions economically feasible.

C. OmniVault (The Strongbox)

Role: Singleton Asset Manager.

• Design Philosophy:

  • OmniPact does not create a separate deposit contract for each order (this would lead to extreme asset fragmentation and high Gas costs).

  • On the contrary, we maintain a global OmniVault Contract, where all users' funds are pooled.

• Internal Accounting Book (Internal Accounting)：

  • Vault internal maintenance mapping(bytes32 escrowId => uint256 balance)Account book.

  • Flash Loan Defense：Supports the ERC-3156 flash loan standard, uses idle funds to earn passive income for the protocol (this part of the income is used to repurchase $PACT), but through ReentrancyGuard Strictly prevent reentrancy attacks.

• Permission control: only the status is Active and only OES instances that have been registered in the Registry are authorized to call Vault'stransfer Function.

D. Governance (The Controller)

Role: Decentralized administrator.

• TimelockController：

  • All management operations on the Registry and Vault (such as upgrading contracts and withdrawing fees) must go through a TimeLock contract.

  • Delayed effect: After a proposal is passed, it takes 48 hours to be executed. This gives the community the right to check the code or withdraw funds during this window period to prevent "Governance Attack".

2.2.3 Critical Interaction Lifecycle

To more clearly illustrate how contracts collaborate with each other, the following is a call stack trace of a standard transaction:

1. Setup:

   • User call OmniFactory.createEscrow(TemplateID, Params)。

   • Factory usage Clones.clone() Deploy a new OES instance and assign a unique one to it. EscrowID。

   • Factory call OmniRegistry.register(EscrowID) Filing for record.

2. Locking:

   • Users' views on OmniVault perform ERC-20 approve()。

   • The user invokes the OES instance. deposit()。

   • OES instance callback OmniVault.depositFrom(User, Amount)。

   • OmniVault Transfer assets from the user to oneself and record the transaction in the internal ledger:balances[EscrowID] += Amount。

3. Settlement:

   • When the conditions are met (such as the buyer confirming receipt of the goods), the status of the OES instance changes toFinalized。

   • OES OmniVault.withdrawTo(Seller, Amount)。

   • OmniVault Verify that the caller is a legitimate OES instance and that the account balance is sufficient.

   • OmniVault Execute the underlying ERC-20 transfer to send the funds to the seller's wallet.

---

This architectural design (Singleton Vault + Proxy Factory) represents the highest current industrial standard in Ethereum development, and can convey to readers the project team's ultimate pursuit of fund security and Gas optimization.