OptiBridge

In three numbers · Table 1

What the optimistic design buys

All gas figures are measured with Hardhat 2.17.4 and are the mean of three runs (standard deviation $<0.1\%$). Alba's figures are the published values from Alba (NDSS'25), the prior Lightning–Ethereum bridge.

The problem

A bridge needs to see the event. Lightning hides it.

A bridge applies a state change on one chain once something has happened on another. Conventional designs assume that event is public: a lock transaction everyone can see and prove. Lightning breaks that assumption. Channel updates happen off-chain between two peers, and nobody else ever sees them.

Why you would want such a bridge anyway (the paper's example): Alice must pay Carol over Lightning, but her channel to Bob has only 5 coins of outbound capacity. Alice has funds on Ethereum. She locks collateral worth $\alpha$ in an Ethereum contract, Bob extends her $\alpha$ coins of credit in their channel, and she routes the payment to Carol through Bob. Once Bob is repaid in the channel, the contract must return Alice's collateral.

The prior work, Alba (NDSS'25), solves this by changing Lightning. Every channel state carries extra data in an OP_RETURN output, and earlier states are timelocked until the Ethereum side settles. That needs a new BOLT specification and updated Lightning implementations. It also uses one monolithic Ethereum contract that contains all the dispute logic, so honest users pay to deploy it every time.

OptiBridge's idea. Bob picks a secret $r_{bridge}$ and commits to $h_{bridge} = H(r_{bridge})$ up front. When he is repaid, he simply hands $r_{bridge}$ to Alice, and the Ethereum contract releases her collateral against the preimage. Everything needed to settle a dispute lives in a second contract, fixed in advance by its hash and deployed only when cooperation fails.

Interactive · Table 1, summed per execution path

What each way of finishing costs on Ethereum

Pick how the bridge ends. Each bar is one on-chain call from Table 1, stacked as a running total. The legend separates calls that happen on every run from calls that exist only when there is a dispute. Branches (a)–(d) are the ones in Figure 1.

Show the numbers as a table

The paper reports per-call gas (Table 1) and does not sum it by path. The totals here add the Table 1 rows each path executes, following the call sequences in Figures 3–4. ⚑ marks setup (dispute) = 428,939: this is exactly the same as setup (bridge) and is suspected to be a copy error in the paper, so every dispute total includes a suspect value. The paper does not give Alba's call sequence for each dispute branch, so the dispute branches show no Alba total. Alba's matching per-call figures are in the table.

Interactive · Figures 1, 3 and 4

Step through the protocol, then break it

Alice is the prover, who borrows and repays. Bob is the verifier, who lends and holds the secret. Choose a path and step through it. The diagram, the asset readouts and the gas readout update at each step. On the optimistic path, the last step lets you try the contract's hash check yourself.

In the paper, $H$ is an abstract hash function. The demo computes SHA-256 in your browser only as an illustration. The paper does not say which hash the contract uses. Gas figures are Table 1's, under Table 1's function names (see the name mapping in Results).

Interactive · Figure 5 and Theorem 1

Why nobody wants the dispute path

Section 7.1 models the bridge as a game with perfect information: Alice (P) and Bob (V) take turns, and every move has an honest option, "go idle", or an attack. Play either side. Each ending shows what the paper's Figure 5 awards: who ends up with the loan (₿) and the collateral (Ξ), how many on-chain fee units it took, and how many time windows $\Delta$ it took. Theorem 1 says the green path is the unique subgame-perfect Nash equilibrium.

All twelve endings in Figure 5, as a table

Fees and delays are counts of the coin and clock icons in Figure 5. They rank outcomes; they are not gas or time measurements. Lettered regions (a)–(d) match the shaded sub-games in the figure. Section 4.1 notes that the game abstracts away mempool congestion, fee volatility and MEV. The incentive result relies on rationality, but safety and liveness do not: an irrational deviator pays more on-chain but cannot steal funds.

Interactive · Table 1, deployment rows

Pay for the dispute code only when you dispute

Alba puts the optimistic path and dispute resolution in one contract, so every bridge deploys all of it. OptiBridge's bridge contract only stores a commitment $h_{dispute} = H(C_{dispute})$ to the dispute contract's code. It deploys that code only when someone calls InitDispute. Switch the dispute on and off.

Show the numbers as a table

Contract	Deployed	Gas
Alba: monolithic contract	every run	4,513,248
OptiBridge: bridge contract	every run	1,215,315
OptiBridge: dispute contract	only on dispute	2,785,514

Deployment rows only. Setup and function calls are in the first chart. Provenance: the evaluation's "side-by-side" paragraph says OptiBridge "pays the 3.4 M-gas dispute deployment only when a dispute occurs". Table 1, the abstract and the conclusion all give 2,785,514. Even adding setup (dispute) gives 3,214,453, not 3.4M. This chart uses Table 1.

Guarantees

What OptiBridge claims, and where

"Not assessed" means this paper does not evaluate Alba on that property. It is not a claim that Alba lacks it. Safety and liveness assume the synchrony bound of §4.1: the dispute window must satisfy $T_{DISPUTE} > \delta_{BTC} + 2\,\delta_{ETH} + \Delta$. For example, with $\delta_{BTC}\approx$ 1 hour and $\delta_{ETH}\approx$ 15 minutes, the paper says $T_{DISPUTE}$ = 24 hours comfortably suffices. Like any Lightning user, honest parties must monitor the chain or delegate that job to a watchtower.

Measured results · Table 1

Gas usage, OptiBridge vs. Alba

Reproduced as published. "—" means the function does not exist in that system. OptiBridge: Hardhat 2.17.4, a fresh contract instance for every call, eth_estimateGas, mean of three runs. Alba: values from its public proof of concept and its Table II.

One function, several names

The table, the contract listing and the overview figure name the dispute functions differently. This page uses Table 1's names. The Fig. 2 "caller" checks are shown as printed. Two of them contradict the prose, as noted below.

Where the paper disagrees with itself

1. Dispute deployment. §6 says "3.4 M-gas". Table 1, the abstract and the conclusion say 2,785,514.
2. setup (dispute) = 428,939 is exactly the same as setup (bridge). It is suspected to be a copy error.
3. Headline comparison. The abstract compares OptiBridge's optimisticProof (40,107) with Alba's submitProof (253,566). §6 compares it with Alba's optimisticProof (48,027) and notes that Alba also needs submitProof. Both comparisons are reproduced here.
4. Caller checks in Fig. 2 contradict the protocol text for VerifierCloseCh and ResDisputeVerifier (see the mapping above).

Reference

Cite this work

@inproceedings{minaei2026optibridge,
  title     = {{OptiBridge}: A Trustless, Cost-Efficient Bridge Between
               the Lightning Network and Ethereum},
  author    = {Minaei, Mohsen and Le, Duc V. and Moreno-Sanchez, Pedro},
  booktitle = {Applied Cryptography and Network Security (ACNS)},
  year      = {2026}
}

Source code. The paper has no code or data availability statement and does not link an OptiBridge implementation. The only repository it cites is Alba's, whose Bitcoin transaction-verification contracts OptiBridge reuses for $DS.\mathsf{Vrfy}$: github.com/ALBA-blockchain/ALBA-Protocol.