How Does Orbiter Finance Work?
Orbiter Finance is a ZK-assisted cross-rollup bridge with a genuinely novel security model: Market Makers front user capital on the destination chain, a Maker Deposit Contract holds collateral, and disputes are resolved via SPV + ZK proofs against on-chain events. Over 4M users, $15B+ cumulative volume, and a clean security record since 2022 is real track record. But Orbiter has deployed MDC contracts across 70+ chains (including zkSync, Linea, Scroll, Starknet) — and per-chain deployment configuration is the dominant bridge-exploit vector of 2026, as KelpDAO's April $292M incident just demonstrated.
TVL
—
Sector
Bridge
Risk Grade
C
Value Grade
D+
Core Mechanisms
8.1.2 Liquidity pool bridges
NovelMaker Deposit Contract (MDC) with SPV + ZK proof dispute path
Market Makers deposit collateral into an MDC on each chain. Users send funds to the Maker on source chain; Maker fronts funds on destination chain. If Maker misbehaves (doesn't send, sends wrong amount, etc.), user files a dispute backed by SPV proofs and ZK verification, claiming the MDC collateral.
8.4.3 Watcher/guardian incentives
NovelOptimistic + ZK-arbitrated dispute resolution
For fast, low-value transfers Orbiter uses an optimistic trust model. For disputes/arbitration it falls back to ZK proofs against on-chain events. Novel hybrid design.
8.4.2 Oracle network incentives
NovelEvent-Bound Contract (EBC) for user/maker commitment framing
The EBC encodes rules about what constitutes valid user/maker behavior, which the SPV/ZK arbitration uses to determine dispute outcomes.
2.1.2 Percentage-based fee
Maker spread + protocol fee
Makers charge a spread; Orbiter takes a share. Has produced ~$50M cumulative revenue per public disclosures.
5.4.1 Multisig override
Team multisig for contract upgrade + emergency pause
Core contracts controlled by team multisig. Upgrade authority is a centralization vector.
How the Pieces Interact
Makers must keep sufficient inventory on all supported chains. Under high flow or market stress, a Maker can become under-collateralized on a specific chain, and an MDC-dispute outcome may not fully cover affected users.
Dispute filing requires SPV proofs and ZK verification. Filing cost and technical complexity means most users will not dispute small losses — creating opportunity for Makers to engage in low-value misbehavior.
The optimistic design assumes griefing is uneconomic. An attacker willing to absorb small losses to create FUD or manipulate Maker inventory could exploit the design.
Orbiter deployed MDC contracts across 70+ chains. Each deployment is configuration surface. A single misconfigured MDC on a new chain could create a KelpDAO-style exploit vector.
What Could Go Wrong
- Maker-based liquidity model — Market Makers front user capital and later reconcile via SPV + ZK proof; relies on Makers remaining solvent and the SPV/ZK arbitration layer actually being invoked correctly
- Optimistic/fast-path design assumes Makers behave honestly by default — honesty is enforced via collateral forfeiture, which depends on MDC contract correctness and timely dispute filing
- 4M+ users and $15B+ lifetime volume means Orbiter is a high-value target; despite a clean record since 2022 the attack surface grows with volume
Maker Insolvency + Under-collateralized MDC
ModerateTrigger: High cross-chain flow combined with a single-chain outage or liquidation event leaves one or more Makers short on inventory; MDC collateral proves insufficient to cover dispute outcomes
- 1.Market event triggers unusually high unidirectional flow — Maker inventory drains on one chain faster than can be replenished
- 2.Maker fails to send fronted funds on destination; users initiate dispute — MDC collateral consumed
- 3.If disputes exceed MDC collateral, residual users unpaid — Users who did not dispute quickly face losses
- 4.Orbiter team negotiates Maker-level remediation and dispute prioritization — Partial recovery; reputational hit
Risk Profile at a Glance
Overall: C (45/100)
Lower score = safer