PaperlayerView exact revision on arXiv

Source-linked AI summary

IntentFuzz: A Protocol-Aware Fuzzer for Automated Invariant Violation Detection in Intent-Based Cross-Chain Bridges

André Augusto, Christof Ferreira Torres, André Vasconcelos, Miguel Correia

arXiv:2609.13004v1cs.CR

TL;DR

Intent-based bridges use solver fulfillment and off-chain settlement, making correctness consequential in a bridge ecosystem with more than $3.2 billion in losses. IntentFuzz recovers intent structures and deposit/fill roles from unannotated Solidity and synthesizes multi-step fuzz tests; on a 9-protocol benchmark, it achieves 100% struct-recovery and function-classification recall with 82% combined precision.

  • Problem

    Intent-based bridges use solver fulfillment and off-chain settlement, making correctness consequential in a bridge ecosystem with more than $3.2 billion in losses.

    Source: §1 · p. 1

  • Method

    IntentFuzz extracts intent structures and deposit/fill roles from unannotated Solidity, then builds multi-step deposit-to-fulfillment fuzz templates.

    Source: §1 · p. 2

  • Results

    On a 9-protocol benchmark, IntentFuzz recovers the correct struct in all nine and achieves 100% recall on deposit- and fill-function classification, at 82% combined precision.

    Source: §5.3.2 · p. 8

  • Takeaways & Limitations

    Its taxonomy separates six on-chain invariants from properties legitimately delegated to the settlement layer.

    Source: §1 · p. 2

    Fill-side coverage is limited in some deployments by unconstructable calls, access-control gates, or a fork-specific chain-ID check that input generation cannot supply.

    Source: §5.6.2 · pp. 11–12

Abstract

from arXiv · show

Cross-chain bridges move value between blockchains. Intent-based bridges are a variant where a solver fulfills a user's declared outcome and an off-chain settlement layer later reconciles the fill against the deposit. Existing smart-contract fuzzers and static analyzers only flag known-bad code patterns or require protocol-specific hand-written assertions. This work formalizes a taxonomy separating invariant violations, safety properties a contract must enforce locally, from settlement exposures legitimately delegated to the off-chain settlement layer, and proposes IntentFuzz: a protocol-aware fuzzer that recovers a bridge's intent structure and deposit/fill function roles directly from unannotated Solidity source, then synthesizes multi-step fuzz sequences using an LLM-based fallback to help build call arguments. IntentFuzz recovers the correct intent structure in 9/9 benchmark protocols and classifies deposit and fill functions with 100% recall and 82% combined precision; across a corpus of 77 manually labeled contracts, it reaches 79.5% bridge-classification precision and 97.2% recall, and among confirmed bridges, struct selection reaches 88.6% precision and recall while deposit and fill classification each reach 100% recall. On 23 planted-bug mutants, IntentFuzz attains 100% recall and 100% precision, executing 273 templates (507 transactions in a median of 14ms per template). Across 24 real-world deployments, it confirms 17 genuine invariant violations under heuristic-only input generation, rising to 22 with its LLM-assisted tier enabled, spanning eight vulnerable GitHub repositories, each finding reproducible against public, deployed bytecode.

1 Introduction

Intent-based bridges change the security model through solver-driven fulfillment, while existing fuzzers struggle with their cross-chain semantics and multi-step flows. This paper distinguishes on-chain invariant violations from settlement exposures and presents IntentFuzz to recover bridge structure and synthesize tests from Solidity source.

1 Introduction

  • Intent-based bridges have a high-stakes security context: cross-chain bridge losses exceed $3.2 billion, and solver-driven designs change the security model.ERC-7683’s proposal as a standard interface and the paper’s corpus independently indicate growing adoption.Source: §1 · p. 1
  • Existing fuzzers typically test transactions or short on-chain sequences and cannot reliably infer bridge semantics spanning chains, solvers, and settlement.Relevant failures include replay across chains and partial or delayed settlement.Source: §1 · p. 1
  • The taxonomy separates locally enforceable invariant violations from settlement exposures that the off-chain layer is meant to catch.A contract may omit checks for recipient, token, or amount matching because those properties are delegated to settlement.Source: §1 · pp. 1–2
  • IntentFuzz uses static analysis on unannotated Solidity to recover intent structures and deposit/fill roles, then synthesizes multi-step fuzz sequences.Its plan includes cross-step value binding and separate tampering of ERC-7683 envelopes and encoded payloads.Source: §1 · p. 2
  • On 9 benchmark protocols, IntentFuzz recovers the correct struct in 9/9 cases and classifies deposit and fill functions with 100% recall and 82% combined precision.Its LLM-assisted recovery is invoked after unexpected call failures; in an ablation, step-0 execution success rises from 167/307 (54.4%) to 261/307 (85.0%), surfacing 5 additional genuine violations.Source: §1 · p. 2

2 Background

Intent-based bridges coordinate deposits, solver fills, and retrospective settlement across chains. ERC-7683 standardizes key interfaces, while leaving protocol-specific intent data encoded in an opaque payload.

2.1 The Intent-Bridge Model

  • A user deposits assets and intent parameters on the origin chain; solvers fulfill the intent on the destination chain and front their own funds.The settlement layer later compares the fill with the deposit and authorizes reimbursement, but cannot block a fill before execution.Source: §2.1 · pp. 2–3

2.2 The ERC-7683 Standard

  • ERC-7683 defines origin-chain deposit entry points open and openFor, and the destination fill receives the same encoding as originData.The envelope variants carry fillDeadline, orderDataType, and orderData; the gasless variant also carries fields including nonce, originChainId, and openDeadline.Source: §2.2 · p. 3, Figure 2 · p. 3
  • Protocol-specific assets, amounts, and recipients reside inside orderData, an ABI-encoded payload whose internal layout ERC-7683 does not standardize.Decoding it requires knowledge of the issuing protocol; recovering its structure from source enables protocol-agnostic fuzzing.Source: §2.2 · p. 3

3 Invariant Taxonomy

The taxonomy distinguishes contract defects from properties intentionally delegated to off-chain settlement by asking whether a property is locally decidable at call time.

3 Invariant Taxonomy

  • A property is locally decidable when it can be checked using only state resident on the chain executing the call.Failure to enforce such a property is an invariant violation, regardless of solver behavior or later settlement conclusions.Source: §3 · p. 3
  • The taxonomy identifies six invariant violations that bridge contracts must enforce locally.Table 1 lists the six targeted violations.Source: §3 · p. 3, Table 1 · p. 4
  • Recipient, output-token, and output-amount matching are settlement exposures, not invariant violations, because a destination contract cannot access origin-deposit state during the fill.Source: §3 · pp. 3–4

4 System Design

IntentFuzz statically recovers intent schemas and deposit/fill roles, then uses the results to detect invariant violations through multi-step fuzzing. Its pipeline also checks for centralized signer dependency and handles cross-step bindings, protocol-specific inputs, and tamper-detection confounds.

4 System Design

  • The three-phase pipeline recovers intent structure and key functions, checks for centralized signer dependency, then executes invariant-targeting fuzz sequences.Phase 3 can invoke an LLM feedback loop when deposit or fill calls fail unexpectedly.Source: §4 · p. 4, Figure 3 · p. 5

4.1 Phase 1: Recovering Intent Structure

  • IntentFuzz scores structs using field names and types, then classifies deposit and fill functions from transfer direction, state writes, and emitted events.Its inspectable rule-based struct score is used because no labeled cross-protocol corpus exists; permissive function heuristics prioritize recall over precision.Source: §4.1 · p. 4

4.2 Phase 2: Detecting Centralized Signer Dependency (AC)

  • Three static detectors flag fill functions gated by a stored authority, a signature checked against one authority, or a centrally managed role modifier.The detectors address access-control patterns identifiable in Slither AST/IR or, for some libraries, by modifier name and argument.Source: §4.2 · p. 5

4.3.1 Fuzz Plan Synthesis

  • Fuzz-plan templates are selected from intent field types, targeting replay, chain-mismatch, and deadline invariants across deposit and later sequence steps.UNIQUENESS fields trigger replay templates; chain fields trigger chain-tamper templates; TEMPORAL fields trigger deadline-boundary templates.Source: §4.3.1 · p. 5

4.3.2 Cross-Step Parameter Binding

  • Later steps bind parameters to earlier inputs or emitted event values, matching fields statically by name and falling back to schema-derived arguments when correspondence is unavailable.Event values are used when logged; byte-for-byte struct arguments instead bind to recorded input because events may expose only selected fields.Source: §4.3.2 · pp. 5–6, Figure 4 · p. 6

4.3.3 Dual-Layer Tamper Detection

  • For three ERC-7683 fields that may occur in both envelope and encoded payload, separate templates tamper each copy to identify which copy the contract validates.The method is specific to the envelope/payload split; ordinary deadline fields use the existing deposit- and fill-side templates.Source: §4.3.3 · p. 6

4.3.4 Input Generation

  • Inputs come from a shared session-intent anchor, type-aware boundary sampling, and LLM-assisted recovery when an untampered call unexpectedly reverts.The LLM receives revert reasons and proposes corrected arguments over bounded retries; successful recovery is cached per function, and the tier does not decide whether a violation occurred.Source: §4.3.4 · pp. 6–7

4.3.5 Execution and Oracles

  • Execution oracles flag successful replay, chain-tamper, or deadline calls only when the intended identifier or tampered field actually reaches the transaction.The replay oracle checks that repeated calls produced the same identifier; unattached tampering is marked inconclusive to avoid false positives.Source: §4.3.5 · p. 7

5 Evaluation

The evaluation measures Phase 1 recovery at benchmark and corpus scales, using synthetic ground truth and manually reviewed labels.

5.1 Corpus Construction

  • The corpus pipeline filtered GitHub candidates by path, keyword threshold, standalone-contract status, and compilation, leaving 77 manually labeled contracts.Of 102 contracts remaining after filtering, 25 failed to compile for reasons external to IntentFuzz.Source: §5.1 · pp. 7–8, Figure 5 · p. 8

5.2 Coverage Measurement

  • Guard-JUMPI coverage counts visited JUMPI sites guarding REVERT regardless of outcome, measured per entry point over reachable guards.The method identifies guards on deployed bytecode and uses EVM step traces to measure visitation.Source: §5.2 · p. 8

5.3.1 Evaluation Setup

  • The benchmark pairs five real-world bridges with four synthetic deposit/fill mocks to provide unambiguous ground truth.The corpus evaluation instead uses labels established through manual review.Source: §5.3.1 · p. 8, §5.1 · p. 8

5.3.2 Results

  • 9/9 protocols had correct struct selection; deposit/fill classification reached 100% recall and 82% combined precision.The benchmark included five real-world bridges and four synthetic mocks.Source: §5.3.2 · p. 8, Table 2 · p. 8, §5.3.1 · p. 8
  • Corpus-scale false positives mainly were adapter/forwarder contracts at bridge level and cross-chain message-handler callbacks at function level.These callbacks resemble user- or solver-facing functions because they write state, move funds, and emit events.Source: §5.3.2 · p. 9
  • IntentFuzz prioritizes function-classification recall because missed functions never enter fuzz plans, while false positives cost only a sequence filtered by the execution oracle.The two false-positive populations are mainly adapters/forwarders and cross-chain message-handler callbacks.Source: §5.3.2 · p. 9
  • At both benchmark and corpus scale, IntentFuzz recovers the correct intent struct and every genuine deposit/fill function with 100% recall.The corpus-scale table reports Phase 1 accuracy over the 77 manually labeled contracts.Source: §5.3.2 · pp. 8–9, Table 3 · p. 9

5.4 Phase 2: Centralized Signer Dependency Detection

Phase 2 detects fill functions gated on a single stored authority, testing synthetic examples and a real-world corpus without executing code.

5.4.1 Evaluation Setup

  • The synthetic set covered three centralized-authority gates and four secure baselines; the real-world evaluation represented 35 registrations but 21 unique contract sources.Repeated deployments of the same source were counted once.Source: §5.4.1 · p. 9

5.4.2 Results

  • IntentFuzz flagged all three vulnerable synthetic variants and none of four baselines; 4/21 real-world contracts had manually verified centralized-signer findings.The findings were checked against deployed source.Source: §5.4.2 · p. 9, Table 4 · p. 9
  • The detectors matched stored-authority signature checks, direct stored-address comparisons, and permissioned-role modifiers.They operate statically, without executing code.Source: §5.4.2 · p. 9

5.5 Phase 3: Detection Accuracy on the Synthetic Dataset

Mutation testing evaluates whether Phase 3 detects invariant violations after individual enforcement guards are removed from synthetic bridge contracts.

5.5 Phase 3: Detection Accuracy on the Synthetic Dataset

  • Each mutant removed exactly one invariant-enforcing require() guard while retaining the underlying state write.Examples include replay-protection and chain-identifier checks.Source: §5.5 · p. 9
  • The 23 mutants came from four mock baselines; ERC-7683 native-ETH contributed eight, while each of the other three contributed five.The ERC-7683 native-ETH group alone included dual-layer envelope/payload variants.Source: §5.5 · p. 9
  • 23 mutants produced 100% recall and 100% precision, with zero violations reported on the four unmutated baselines.Table 5 presents recall by invariant.Source: §5.5 · p. 9, Table 5 · p. 10

5.6 Phase 3: Real-World Evaluation

IntentFuzz evaluates 24 live deployments by forking their deployed state and confirms reproducible invariant violations across multiple repositories. The evaluation also reports deployment-specific coverage constraints and execution costs.

5.6.1 Evaluation Setup

  • 24 protocol/chain deployments were tested on forks of live chain state under heuristic-only and LLM-assisted input-generation configurations.Addresses were drawn from repository deploy artifacts and checked for deployed bytecode; some deposits also required token funding, approvals, or external-dependency workarounds.Source: §5.6.1 · p. 10

5.6.2 Results

  • 17 genuine invariant violations were confirmed across eight vulnerable GitHub repositories, with each finding reproducible against public deployed bytecode.The evaluation correctly treated Across SpokePool’s 12 flagged instances as a documented architectural choice.Source: §5.6.2 · p. 10, §5.6.3 · p. 12
  • Examples include deposits accepted with elapsed deadlines that permanently lock funds and identical GhostGateway deposits that overwrite the same order record.The deadline omissions appeared in multiple deployments; GhostGateway’s deterministic order identifier allowed a second identical deposit to replace the first record.Source: §5.6.2 · pp. 10–11
  • The 17 baseline violations comprised 4 deposit-replay instances, 4 deposit-side non-envelope tamper instances, and 9 envelope-only tamper instances.Table 6 presents the category breakdown; the listed deployment-level counts are reported in the accompanying text.Source: Table 6 · p. 11, §5.6.2 · p. 11
  • Across SpokePool’s 12 flagged instances were documented protocol choices, with 82.9% of deposit-side and 91.4% of fill-side guards reached on both chains.Manual review found that its deadline handling and unsafeDeposit behavior were anticipated design choices.Source: §5.6.2 · p. 11
  • Low or unmeasured fill coverage reflected unconstructible calls for four codebases and access-control gates for Omni SolverNet and Relay Depository.Relay Depository’s execute() required a valid EIP-712 signature from its stored allocator authority, which the evaluation could not forge.Source: §5.6.2 · p. 11
  • Other fill-coverage limits included Portal’s undispatched Route-struct functions, dormant deployments with unreconstructed protocol state, and deBridge’s fork-specific chain-ID check.The deBridge check caused many calls to revert before reaching invariant checks; LLM-assisted recovery did not supply the fork-specific identifier.Source: §5.6.2 · pp. 11–12

5.6.3 Performance Metrics

  • Phase 3 took a median 26.4 seconds per real-world deployment, compared with 0.88 seconds per contract for end-to-end Phases 1–3 on mock contracts.The real-world evaluation averaged 1.7 seconds per template and 0.9 seconds per transaction, largely due to public RPC round-trips and debug_traceTransaction calls.Source: §5.6.3 · p. 12

5.7 Contribution of LLM Feedback Loop

The LLM-assisted recovery tier improves execution success and surfaces additional invariant violations in real-world deployments. Its gains concentrate on deposit calls requiring protocol-specific values, while fill-side reachability changes less broadly.

5.7 Contribution of LLM Feedback Loop

  • Step-0 success rose from 167/307 (54.4%) to 261/307 (85.0%), and confirmed invariant violations increased from 17 to 22.The tier used 81 recovery calls at a total cost of approximately $0.051.Source: §5.7 · p. 12
  • Five additional deposit-replay violations were reached through native-currency paths requiring fees or transfer amounts unavailable from the ABI alone.These included four Portal entry points and Relay Depository’s depositErc20 entry point.Source: §5.7 · p. 12
  • For deBridge DLN, step-0 success rose from 0% to 63%; for Portal, it rose from 31% to 100%.Deposit-side coverage also rose from 66.0% to 78.0% for deBridge and from 66.7% to 82.5% for Portal.Source: §5.7 · p. 12
  • Recovery gains concentrated on calls needing protocol-specific fees or costs; outside Across and Portal, fill-side guard-JUMPI coverage was unchanged.Many fill calls require structured values available only from the deposit transaction’s event log, rather than from the intent struct’s field types.Source: §5.7 · p. 12

6 Discussion

IntentFuzz’s remaining fill-side coverage gaps are mostly structural rather than argument-guessing problems. Protocol-specific fill functions with arguments absent from the recovered intent schema also remain out of reach without bespoke logic.

Coverage Only as a Measurement Tool.

  • LLM-assisted recovery leaves fill-side coverage unchanged across nearly every protocol family because residual gaps are structural, not argument-guessing problems.Most fill arguments are supplied through cross-step binding; other failures involve access control, unreconstructable on-chain state, or unmatched fill signatures.Source: §6 · pp. 12–13
  • A coverage-guided search loop would add overhead without expanding tested surface area when remaining fill calls fail for structural reasons.The listed barriers include access-control gates, on-chain state a generic fork cannot reconstruct, and fill signatures absent from the recovered schema.Source: §6 · p. 13

Fill Functions with Protocol-Specific Argument Shapes.

  • IntentFuzz cannot construct arguments for protocol-specific fill entry points whose parameters have no counterpart in the recovered intent schema.eco-routes’ proof-hash formula requires an exact byte-level preimage, which its LLM-assisted recovery tier cannot infer from revert reasons.Source: §6 · p. 13

7 Related Work

Existing fuzzers, static analyzers, and bridge-focused tools do not model the deposit/fill/settlement structure and invariants central to intent-based bridges. The related work also includes little research on intent-based bridges themselves.

Related work

  • Existing fuzzers require hand-written assertions for protocol properties, while static analyzers match known-bad patterns rather than absent invariant checks.Foundry fuzz also lacks multi-step deposit→fill→replay sequences and ERC-7683 envelope/inner-payload handling; [17],,, and [14] identify the cited tools.Source: §7 · p. 13
  • Cross-contract coverage and concolic fuzzers remain single-chain, without mechanisms for cross-chain replay or chain-binding sequences.The passage names EFCF and ConFuzzius [33].Source: §7 · p. 13
  • Bridge-specific tools target the original bridge model, not intent-based bridges or their deposit/fill/settlement structure.BridgeGuard, SmartAxe [23], and BridgeFuzz address relayer/oracle authentication, semantic inconsistencies, or balance and protocol errors.Source: §7 · p. 13
  • Intent-based bridge research remains scarce, with cited empirical work examining solver-liquidity exploitation [3].The authors do not attempt an empirical comparison because the preceding solutions do not model the relevant structure and invariants.Source: §7 · p. 13

8 Conclusion

IntentFuzz combines an invariant-versus-settlement-exposure taxonomy with automatic recovery of bridge structure and multi-step fuzzing. Across 24 production deployments, it finds 22 reproducible real invariant violations without hand-written or protocol-specific properties.

8 Conclusion

  • Across 24 production intent-based bridge deployments, IntentFuzz finds 22 real invariant violations reproducible against publicly deployed bytecode without hand-written or protocol-specific properties.The conclusion reports 100% struct-recovery and function-classification recall and 82% combined precision on a nine-protocol benchmark; corpus-scale bridge classification reaches 97.2% recall and 88.6% struct-selection recall, with 100% deposit/fill recall.Source: §8 · p. 13
  • IntentFuzz recovers intent structures and deposit/fill roles from unannotated Solidity, then synthesizes multi-step sequences with cross-step binding and dual-layer tampering.Its three-tier input-generation hierarchy is anchored on a shared session intent, uses boundary-value sampling, and falls back to LLM-assisted recovery.Source: §8 · p. 13
  • The paper formalizes a taxonomy separating on-chain invariant violations from settlement exposures delegated to the off-chain layer.The conclusion characterizes settlement exposures as out of scope.Source: §8 · p. 13
Loading 2609.13004v1…