The trust assumptions under crosschain settlement nobody examines

I was tracing a failed settlement during testnet stress testing when the timeout arithmetic stopped making sense. The timelock had expired on the EVM side but the corresponding Bitcoin transaction was still unconfirmed, sitting in a mempool that had no obligation to include it. The counterparty's refund window and our claim window overlapped. Not because of a bug. Because Bitcoin's block production is a random process, and the contract's safety margins assumed it wasn't.

That single incident unraveled a thread I've been pulling for two years. The HTLC pattern everyone treats as the gold standard for trustless exchange carries trust assumptions hiding in the timestamps, the miner incentive structures, and the gap between crosschain finality models. The academic literature mapped these problems years ago. Practitioner content still hasn't caught up.

The Promise of Trustless#

HTLC (Hash Time Locked Contract), the primitive under most trustless crosschain settlement, is elegant on a whiteboard. Alice locks funds with a hash. Bob locks matching funds on another chain with the same hash. Alice reveals the preimage to claim Bob's funds, which gives Bob the preimage to claim Alice's. If either party disappears, timelocks guarantee refunds.

"Trustless" is the word that sells this pattern. No intermediary. No custodian. No counterparty risk. The cryptography enforces the settlement or it doesn't happen. This is the version that appears in every protocol whitepaper, every educational thread, and every pitch deck that promises crosschain interoperability without the bridge risk.

The textbook version makes four implicit promises: that block production is predictable enough for timeout arithmetic to work, that block producers are neutral, that counterparties won't exploit the asymmetric lockup structure, and that the cryptographic link between chains doesn't compromise user privacy.

Across 14.2 million settlements in testnet stress testing on the protocol I architected at Portal to Bitcoin, every one of those promises hit edge cases the documentation didn't prepare us for. Stress testing exposed the gap between what HTLCs guarantee on a whiteboard and what they deliver when real timing variance and adversarial incentives collide.

Trust Assumption #1: Synchronized Clocks#

Bitcoin block intervals follow an exponential distribution with a mean of 10 minutes. Here's the part most developers miss: the standard deviation is also 10 minutes. That's not a tight bell curve with occasional outliers. It's an exponential curve where 63% of blocks arrive within 10 minutes (not 50%, as Gaussian intuition suggests) but the tail is long and fat.

How fat? Jameson Lopp measured the first 670,000 Bitcoin blocks: 190 of them took longer than 106 minutes to produce. That's a block every ~3,500 blocks that takes more than ten times the expected interval.

Ethereum, post-Merge, produces slots every 12 seconds with full finalization in 12 to 13 minutes. Jump Crypto observed approximately 90 reorgs on its nodes since the Merge, none deeper than 1 block. Predictable. Reliable. A completely different timing model.

When you build HTLC settlement across these two chains, you need timeout windows that account for the slower chain's worst case. Set the Bitcoin side timeout too tight, and a slow block sequence lets both parties claim. Set it too loose, and you've given the counterparty a free speculation window measured in hours.

Our first calibration treated the 10 minute average as if it were a guarantee. The windows derived from it looked safe on paper. Under real block time distributions they produced exactly the claim/refund overlap I opened with. The fix wasn't a bigger number, it was a different denomination. We calibrated the timeouts asymmetrically, each timelock in the unit its chain actually controls: 144 blocks on the Bitcoin side, 172,800 seconds (two days) on the EVM side. The EVM window is deliberately the longer of the two: the second party to lock funds must be guaranteed time to claim after the first party reveals, so the windows are staggered by design, not set equal. Block height where wall clock time is a random variable. Seconds where block production is metronomic. That recalibration went in as part of the redesign that took our stress test failure rate from 12% to 0.03%.

A 144 block lock is roughly a day. That's the honest price of keeping the refund and claim windows disjoint across a chain with fat tailed block times. For a primitive marketed as a trustless instant swap.

Trust Assumption #2: Honest Miners#

The textbook HTLC model assumes block producers are neutral transaction processors. They see valid transactions, they include them. This assumption was shaky in 2019. In 2026, it's fiction.

Timelocked bribing, where a dishonest party pays miners to censor the counterparty's claim transaction until the timelock expires, has a clean game theoretic result: full miner cooperation is a Nash equilibrium, and can be made a dominant strategy for a bribe that scales with the smallest miner's share. (All miners-honest is an equilibrium too, which is what makes this a coordination problem rather than a certainty.)

This isn't theoretical. Flashbots and MEV relay infrastructure already facilitate miner validator user collusion at billion dollar scale. The infrastructure for selective transaction inclusion exists, runs in production, and processes the majority of Ethereum blocks. A 2025 measurement study counted 242,535 crosschain arbitrages totaling $868.64M in volume between September 2023 and August 2024, with activity growing 5.5x over the window and surging after Dencun. The only missing piece is someone packaging an HTLC specific bribe into the existing MEV pipeline. The tooling and the incentives are already there.

Researchers have been chasing fixes. MAD-HTLC proposed that miners extract value from both parties when cheating is detected, creating a deterrent. Then He-HTLC patched a reverse bribing vulnerability in MAD-HTLC. The CCS 2024 paper by Aumayr et al. proved that Lightning channels resist timelocked bribing only under two assumptions: parties constantly monitor the mempool, and channels never fully deplete. Each fix adds an assumption. The trust stack grows.

Then there's replacement cycling (CVE-2023-40231), disclosed in October 2023 by Antoine Riard. An adversary with channels on both sides of the victim repeatedly evicts the victim's HTLC timeout transaction from the mempool by replacing it with a higher fee conflicting transaction, which the attacker then replaces again before confirmation. The victim's valid claim never gets mined. Riard considered this a base layer issue and stepped down from Lightning Network development over it. When the person who discloses the vulnerability leaves the project because the fix requires changing Bitcoin's mempool policy, that's a signal worth reading carefully.

Trust Assumption #3: The Free Option Nobody Prices#

Han et al. demonstrated at ACM AFT'19 that an HTLC based atomic swap is mathematically equivalent to an American Call Option without a premium. The initiator can watch exchange rates move during the entire timeout window, then decide whether to complete the settlement or let it expire. Free optionality. Estimated value: 2 to 3% of the asset pair for typical crypto volatility.

The failure mode nobody warns you about is this: rational market makers won't touch HTLC settlement at par. The free option premium means the initiator always has an edge, and the responder always subsidizes it. This isn't a bug to patch. It's structural to the HTLC design.

The rational complement is griefing. The Lightning protocol caps routing at 483 HTLCs per direction per channel. Mizrahi and Zohar showed an attacker can lock up most of the network's liquidity for days by routing payments to themselves and never resolving them, at a cost under half a bitcoin. Griefing is cheap and unaccountable. Combined with the free option, this creates an environment where the attacker profits from volatility and the victim eats the opportunity cost of locked capital with no recourse.

Price in the option premium and the capital lockup that safe timeout windows demand, and HTLC settlement stops looking free. Someone is profiting from these timing asymmetries. It's not the casual user.

ERC-2266, proposed as a formal premium mechanism to compensate the responder for the free option, exists as a specification. Adoption has been minimal. The economic incentive to exploit the free option exceeds the incentive to fix it, because fixing it requires the initiator to voluntarily pay for a privilege they currently get for free.

Trust Assumption #4: Privacy Is a Feature, Not a Bug#

When Alice reveals the hash preimage on Chain A to claim funds, the same preimage appears on Chain B when Bob claims. Same hash, both chains, publicly visible. Deterministic onchain correlation.

Anyone watching both chains can link the two legs of every settlement with zero uncertainty. Chain analysis firms do this at scale. The "trustless" settlement creates a permanent, public, crosschain identity link.

PTLCs (Point Time Locked Contracts), the Schnorr based successor to HTLCs that breaks the crosschain hash correlation, fix this specific problem. They also eliminate wormhole attacks in Lightning routing. But PTLCs don't fix the American Call Option problem. They don't fix griefing. They don't fix timelocked bribing. They don't fix timing assumptions.

In production, what actually happens is that teams evaluate PTLCs, realize they solve one problem out of five, and defer adoption because the deployment cost doesn't justify the partial improvement. PTLCs need Schnorr support on every participating chain, and the EVM has no native Schnorr verification, which limits their applicability for BTC EVM settlement today. Even with full deployment, you've fixed the privacy layer while leaving the timing, economic, and miner incentive layers untouched. The hard problems remain.

What This Means for Crosschain Architecture#

Here's what the trust stack looks like in practice. The base HTLC assumes synchronized timing, honest miners, no optionality abuse, and privacy. MAD-HTLC adds the assumption that miners will act against their short term interest to preserve long term protocol health. He-HTLC adds the assumption that reverse bribing is detectable. CCS 2024 security proofs add constant mempool monitoring and nondepleted channels. PTLCs add Schnorr availability across all participating chains.

The fix to-assumption map is short and unflattering:

              timing    miners      free option   privacy
base HTLC     exposed   exposed     exposed       exposed
MAD-HTLC      exposed   mitigated   exposed       exposed   (+assumes no reverse bribe)
He-HTLC       exposed   mitigated   exposed       exposed   (+assumes detection holds)
ERC-2266      exposed   exposed     priced        exposed   (near zero adoption)
PTLC          exposed   exposed     exposed       fixed     (+needs Schnorr everywhere)

Every fix is a new assumption. Every assumption is a new trust surface.

The broader numbers provide context but not direct attribution. Crosschain bridges have been hacked for over $2.8 billion total, roughly 40% of all Web3 security losses. Those are bridge specific exploits, not HTLC failures. Lightning Network capacity sits around 5,600 BTC, and the measured Gini coefficient of node capacity has climbed to roughly 0.97. That concentration means a small number of nodes bear the majority of the routing risk from every vulnerability described above.

No headline grabbing HTLC specific exploit has caused catastrophic losses. Not yet. The risk is structural and underpriced, not catastrophic and proven. That distinction matters. It means the window for building defensively is still open, but only for teams that recognize what "trustless" actually requires.

The honest question for any crosschain architecture isn't "is this trustless?" It's "which trust assumptions can you live with, and which ones will you actively monitor?"

The Uncomfortable Conclusion#

The industry consensus is that trustless crosschain exchange is a solved problem. The academic literature says otherwise, and has said so since at least 2019. The gap between practitioner confidence and researcher concern is the widest I've seen in any area of protocol security.

HTLCs aren't broken. They're underexamined. The primitives work exactly as specified. The specifications just assume a world that doesn't exist: a world of predictable block times, neutral miners, counterparties who don't exploit free optionality, and transactions that can't be correlated across chains.

Every system has trust assumptions. Trustless systems just hide theirs better.