Skip to main content

Bridging

The wallet ships an in-app bridge UI for moving USDT between Arbitrum and Quantum L1. Quantum L1's bridge contract burns or mints qUSDT on the L1 side and locks or releases USDT on the Arbitrum side.

Supported pairs​

DirectionSource assetDestination assetSource chainDestination chain
InboundUSDT (ERC-20)qUSDT (native ERC-20 on Quantum L1)ArbitrumQuantum L1
OutboundqUSDTUSDT (ERC-20)Quantum L1Arbitrum

QBIT (the native asset of Quantum L1) is sent on Quantum L1 directly and is not bridged.

The flow at a glance​

Arbitrum                                            Quantum L1
┌──────────────────────────────┐                ┌──────────────────────────────┐
│  PQ Safe7579 wallet          │                │  PQ wallet on Quantum L1     │
│  (ML-DSA-signed UserOp)      │                │  (native PQ authorization)   │
└──────────────────────────────┘                └──────────────────────────────┘
            │                                              ▲
            │ approve + bridge.deposit(usdt, amount, dest) │
            ▼                                              │
┌──────────────────────────────┐                ┌──────────────────────────────┐
│  Bridge contract (Arb)       │   observed     │  Bridge contract (Q L1)      │
│  - locks USDT in custody     │  ───────────▶  │  - mints qUSDT to dest       │
│  - emits Deposit event       │                │  - emits Mint event          │
└──────────────────────────────┘                └──────────────────────────────┘

The reverse direction burns qUSDT on Quantum L1 and releases USDT from the bridge custody on Arbitrum.

What the user does​

From the wallet UI:

  1. Open the bridge tab.
  2. Choose direction (Arbitrum → Quantum, or Quantum → Arbitrum).
  3. Enter the amount.
  4. Confirm — the wallet builds a PQ-signed UserOp that calls the bridge contract on the source chain. Approval (ERC-20) is handled inline when needed.
  5. Watch the destination side mint or release once the source-side transaction is observed.

What's happening under the hood​

  • On the source chain, the wallet constructs a UserOp that calls the bridge's deposit(asset, amount, destinationChainId, recipient) function. The UserOp is signed with the user's ML-DSA key and validated by the PQValidatorModule.
  • The bridge contract holds custody on Arbitrum and is the issuer on Quantum L1. Both sides emit events that the bridge relayer set picks up.
  • On the destination chain, the relayer set submits a proof-of-deposit message. The bridge contract on the destination side verifies the message and mints (or releases) the corresponding asset to the recipient.

The PQ signature lives entirely on the source side — the bridge contract sees a regular msg.sender (the smart account address). The bridge's own security depends on the relayer set and the bridge contract logic; ML-DSA does not change those.

Security caveats​

These follow from Threat model and are worth re-stating in the bridge context.

  • The PQ signature protects the source side — i.e. that the deposit or burn was authorized by the holder of the ML-DSA key.
  • The PQ signature does not protect against bridge-contract bugs, relayer compromise, or destination-chain reorgs. Those risks are inherent to the bridge design, not to ML-DSA.
  • The destination address must be a wallet you control on the destination chain. The wallet UI defaults to your own PQ address on the destination chain but you can override.

Limits and fees​

SettingValue (current)
Minimum bridge amountSet by the bridge contract; surfaced in UI
Bridge feeSet by the bridge contract; surfaced in UI before confirmation
Confirmation timeDriven by the slower of (a) source-chain finality and (b) relayer pickup latency

Concrete limits and fees are not duplicated here because they change with bridge upgrades; the wallet UI is the source of truth at sign time.

Roadmap​

  • Bridge UX polish — better progress indicators, retry on relayer delay, surfaced reorg risk.
  • Additional asset pairs as supported chains are added (see Chain rollout criteria).
  • Paymaster-sponsored deposits so users don't need to pre-fund ETH on Arbitrum to bridge in.
  • Direct dApp targeting (e.g., Hyperliquid) once the wallet's connection layer (EIP-6963 / WalletConnect) is past MVP.