🧠 System Architecture

Components

Kaspa L1

• Network: UTXO-based Kaspa mainnet/testnet.

• Assets: KRC-20 inscriptions (tokens encoded in transactions).

• Deposit Mechanism: Uses the EXTRA link blob to encode bridge metadata.

• Finality: Bridge logic waits for sufficient confirmations before acting.

Kasplex EVM L2

• Network: EVM-compatible based rollup on Kaspa.

• Assets: ERC-20 equivalents of bridged KRC-20s.

• Bridge Contract: Mint/burn contract, accepts threshold deposit attestations from relayers.

• Transparency: Contract address and ABI published in Transparency & Audits.

Relayer Set (5 Independent Servers)

• Deployment: Five relayers run in separate datacenters, providers, and geographies.

• Operators: Each is managed by a distinct individual; no shared administrative domain.

• Autonomy: Relayers do not rely on each other to function; each observes the chains and contributes signatures independently.

• Responsibility:

  • Monitor both Kaspa L1 and Kasplex L2 via custom chain listeners.

  • Validate bridge events after block confirmations.

  • Generate partial FROST signatures for deposits/withdrawals.

• Isolation: Each relayer stores its state in its own Postgres instance; enabling duplication, decentralized verification, and improved disaster response.

Coordinator Application

• Role: Collects partial FROST signatures from relayers and assembles the final group signature.

• Deployment: Runs on a separate system from the five relayers, with its own operators and safeguards.

• Function:

  • Enforces nonce commitments and binding factors (to prevent rogue key attacks).

  • Rejects incomplete or inconsistent rounds.

  • Submits only valid group signatures to the appropriate chain / contract.

Custom Chain Listeners

• Kaspa Listener: Observes L1 for KRC-20 inscriptions with the bridge’s EXTRA blob. Emits standardized events after N confirmations.

• EVM Listener: Observes L2 for ERC-20 bridge contract burn events. Emits standardized events after M block confirmations.

• Design: Written in-house for efficiency, auditability, and fine-grained control.

• Output: Events flow directly into relayers, bypassing third-party indexers.

Postgres Databases

• Schema: Track deposits, withdrawals, signature shares, nonces, and health status.

• Isolation: Each relayer has its own Postgres instance (no replication or central DB).

• Verification: Each database instance in the logic flow is regularly validated against on chain data for consistency and security by an independent worker service.

• Durability: Implemented with WAL + backups per service operator policy.

---

Component Diagram

flowchart TB
    subgraph KaspaL1[Kaspa L1]
        TX[Deposit TX + EXTRA Blob]
        L1Listener[Custom L1 Listener]
    end

    subgraph L2[Kasplex zkEVM L2]
        Contract[Bridge Contract (ERC-20)]
        L2Listener[Custom L2 Listener]
    end

    subgraph Relayers[5 Independent Relayers]
        R1[Relayer 1]
        R2[Relayer 2]
        R3[Relayer 3]
        R4[Relayer 4]
        R5[Relayer 5]
        DB1[(DB 1)]
        DB2[(DB 2)]
        DB3[(DB 3)]
        DB4[(DB 4)]
        DB5[(DB 5)]
    end

    subgraph Coordinator[Coordinator Application]
        Agg[Signature Aggregator]
    end

    TX --> L1Listener
    L1Listener --> R1
    L1Listener --> R2
    L1Listener --> R3
    L1Listener --> R4
    L1Listener --> R5

    Contract --> L2Listener
    L2Listener --> R1
    L2Listener --> R2
    L2Listener --> R3
    L2Listener --> R4
    L2Listener --> R5

    R1 --> DB1
    R2 --> DB2
    R3 --> DB3
    R4 --> DB4
    R5 --> DB5

    R1 --> Agg
    R2 --> Agg
    R3 --> Agg
    R4 --> Agg
    R5 --> Agg

    Agg --> Contract
    Agg --> KaspaL1

---

Invariants & Assumptions

• Independent Operators: No single entity controls >1 relayer.

• Finality: Only confirmed events on chain are processed.

• No Shared Secrets: Each relayer holds only its FROST share.

• Coordinator Independence: Coordinator cannot forge signatures; it only assembles valid shares.

• Replay Protection: Each bridge request has a unique nonce; duplicates are invalid.

• Transparency: All contract addresses, ABI definitions, and signer commitments are public.