Skip to content
Quantix Security Labs

Arbalest Bridge

Bridge Security Assessment of Arbalest Bridge, a bridge protocol on Ethereum, Base, Arbitrum covered by Quantix Protocol Research. Lock-and-mint bridge contracts on Ethereum, Base and Arbitrum: gateway, message verification, validator set, token vault, wrapped token and rate limiter.
ResearchUnder ReviewQX-TSA-2026-005 · v0.9
QUANTIX SECURITY LABSQX-TSA-2026-005

TECHNICAL SECURITY ASSESSMENT

Arbalest Bridge

Bridge Security Assessment · Bridge

REPORT ID QX-TSA-2026-005 · v0.9

QUANTIX RESEARCH ASSESSMENT

Lock-and-mint bridge contracts on Ethereum, Base and Arbitrum: gateway, message verification, validator set, token vault, wrapped token and rate limiter.

Document status
Draft, under review
Review ended
6 Oct 2026

FINDINGS BY SEVERITY8 findings

Critical

1

High

2

Medium

3

Low

1

Info

1

Quantix research assessment of Arbalest Bridge (Protocol Research). Not a client engagement or a certification.

DRAFT
Draft QX-TSA-2026-005 v0.9 · issued when the review closes

Risk summary

State at remediation commit e7afa329553d

Findings
8
Critical and high
3
Open or partial
3
Remediation
69%

Findings by severity

  • Critical1
  • High2
  • Medium3
  • Low1
  • Informational1

Remediation statusAnalysis

  • Resolved4
  • Partially resolved1
  • Acknowledged1
  • Open2

Arbalest Bridge

Bridge

Document
QX-TSA-2026-005 · v0.9
Type
Bridge Security Assessment
Review
21 Sept 2026 – 6 Oct 2026
Status
Remediation review in progress
Ecosystems
EthereumBaseArbitrum
Languages
Solidity
Risk Index
B67.0
Assessment contents · 12 sections

01

Assessment overview

Arbalest locks tokens on Ethereum and mints wrapped representations on Base and Arbitrum once a threshold of validators has signed the transfer message. The security of every wrapped token reduces to one question: can a message that the validator set did not intend be accepted on the destination chain?

Eight findings were reported. The critical issue allowed the same validator signature to be counted several times, so a single compromised key could reach the threshold alone. Two high-severity issues concerned what the validators sign: the digest omitted the destination chain and receiver contract, and validator-set updates could be replayed after a rotation.

The critical and one high finding are fixed and verified. The validator-set replay fix is partial, two medium findings remain open, and the remediation review is ongoing. This document is under review and will be versioned 1.0 when the review closes.

02

Technical analysis: protocol architecture

Users lock a canonical token in TokenVault through BridgeGateway on Ethereum. The gateway emits a transfer message with a nonce, source chain, token, amount and recipient.

Validators observe the message off-chain and sign its digest. A relayer submits the message and signatures to MessageReceiver on the destination chain, which checks that at least threshold distinct members of the current ValidatorSet signed, marks the nonce as consumed, and mints WrappedToken.

The reverse path burns wrapped tokens and releases canonical tokens from the vault. RateLimiter caps the value that can leave the vault or be minted per asset per window, bounding the loss from a key compromise.

Trusted· 6

Assumed to behave as specified; compromise is out of the threat model.

  • BridgeGatewayLocks and releases canonical tokens; emits messages
  • MessageReceiverSignature threshold check and message execution
  • ValidatorSetMembership, threshold and rotation
  • TokenVaultHolds locked canonical tokens
  • WrappedTokenMint and burn on destination chains
  • RateLimiterPer-asset outflow caps
trust boundary

Semi-trusted· 1

Trusted for liveness or within bounds; misbehaviour is partly modelled.

  • ValidatorsSign transfer messages off-chain
trust boundary

Untrusted· 1

May act adversarially; every input is validated.

  • RelayerSubmits messages and signatures
Components grouped by trust level. Calls that cross a trust boundary are where the review concentrated input validation and authorisation checks.

Trust assumptions

  • Fewer than `threshold` validator keys are compromised at any time.
  • Validators sign only messages they observed in finalised source-chain blocks.
  • The relayer is untrusted: it may submit, delay, reorder or withhold messages.
  • Validator-set changes are governance actions and should be observable before they take effect.

03

Scope

Lock-and-mint bridge contracts on Ethereum, Base and Arbitrum: gateway, message verification, validator set, token vault, wrapped token and rate limiter.

Repository
github.com/example-org/arbalest-bridge
Review effort
Three reviewers, twelve working days; remediation review in progress
Reviewed commit
d9e6c02925a96e7df40560d6d3f82fd8cad9390b
Remediation commit
e7afa329553d52e1d6c6c7a36ba2c5d11f73116c
Files and components in scope
PathDescriptionnSLOC
contracts/BridgeGateway.solLocks canonical tokens and emits transfer messages on the source chain386
contracts/MessageReceiver.solVerifies validator signatures and executes inbound messages312
contracts/ValidatorSet.solValidator membership, threshold and rotation244
contracts/TokenVault.solCustody of locked canonical tokens and releases198
contracts/WrappedToken.solMintable representation on Base and Arbitrum126
contracts/RateLimiter.solPer-asset outflow caps per window142
Total6 items1,408

Out of scope

  • Off-chain validator software and key storage
  • Relayer infrastructure
  • Front end and SDK
  • Economic security of the validator set (stake and slashing are not part of the design)

04

Threat model

Each threat lists the actor, the vector and the mitigation, and links to the findings that realised it in the reviewed code.

Assets at risk

  • Canonical tokens locked in TokenVault
  • Wrapped token supply on Base and Arbitrum
  • Validator-set integrity

Actors

  • RelayerUntrustedSubmits arbitrary messages and signature arrays
  • Compromised validatorSemi-trustedSigns arbitrary digests with one or more keys
  • Bridge governanceTrustedRotates validators and changes threshold
  • Token issuerSemi-trustedMay use fee-on-transfer or rebasing behaviour
Threats, vectors, mitigations and related findings
ThreatActorVectorMitigationFindings
Threshold reached with fewer distinct signersCompromised validatorRepeating one signature in the arrayStrictly increasing signer orderAB-01
Message replayed on another chain or receiverRelayerDigest without destination domainDomain-separated digestAB-02
Old validator set restoredRelayerReplaying a signed set updateEpoch-bound updatesAB-03
Vault insolvencyToken issuerFee-on-transfer token accountingBalance-delta accountingAB-04
Losses beyond intended capCompromised validatorWindow-boundary drainingRolling-window limiterAB-05
Immediate takeover through set rotationCompromised validatorRotation with no delayDelayed activation with cancellationAB-08

05

Findings

Severity

8 findings

AB-01CriticalResolvedBridge message validation

Duplicate signatures are counted towards the threshold

contracts/MessageReceiver.sol:L84–L121

Likelihood
High
Impact
High
Weakness
CWE-347
Description

_verifySignatures loops over the submitted signatures, recovers each signer, checks validatorSet.isValidator(signer) and increments a counter. It never checks that signers are distinct.

A relayer can submit the same valid signature threshold times. A single validator key — or a single signature leaked from a legitimate message to the same digest — therefore satisfies a threshold intended to require several independent parties.

Preconditions
  • One validator key is compromised, or one validator signs a malicious digest
Exploit scenario
  1. 1.An attacker obtains one validator key.
  2. 2.They sign a mint message for an arbitrary amount to their address.
  3. 3.The relayer submits the signature repeated threshold times.
  4. 4.MessageReceiver counts threshold valid signers and mints the wrapped tokens.
Impact

Unbacked minting of wrapped tokens on every destination chain, or release of the entire vault on the return path, limited only by the rate limiter.

Recommendation

Require signatures sorted by strictly increasing signer address and revert when signer <= lastSigner. This rejects duplicates in O(n) without extra storage.

Fix
contracts/MessageReceiver.soldiff
   function _verifySignatures(bytes32 digest, bytes[] calldata sigs) internal view {+      address last;       uint256 valid;       for (uint256 i; i < sigs.length; ++i) {           address signer = ECDSA.recover(digest, sigs[i]);+          if (signer <= last) revert UnsortedOrDuplicateSigner();+          last = signer;           if (validatorSet.isValidator(signer)) ++valid;       }       if (valid < validatorSet.threshold()) revert InsufficientSignatures();
Resolution

Strict ordering enforced; fuzz tests with duplicated and permuted signatures added. INV-02 holds.

AB-02HighResolvedSignature replay

Message digest omits destination chain and receiver contract

contracts/MessageReceiver.sol:L52

Likelihood
Medium
Impact
High
Weakness
CWE-294
Description

The digest is keccak256(abi.encode(nonce, sourceChainId, token, amount, recipient)). It does not include the destination chain ID or the receiver contract address.

The same validator set secures both Base and Arbitrum, and nonces are tracked per receiver. A message signed for Base is therefore also valid on Arbitrum, and on any future receiver deployment that shares the validator set.

Preconditions
  • The same validator set secures more than one destination
  • A legitimate message has been signed
Exploit scenario
  1. 1.A user bridges 100,000 tokens to Base; validators sign the message.
  2. 2.The attacker copies the message and signatures from the Base transaction.
  3. 3.They submit it to the Arbitrum receiver, where the nonce is unused.
  4. 4.Wrapped tokens are minted on Arbitrum without a corresponding lock.
Impact

Every legitimate transfer can be replayed once per additional destination, creating unbacked wrapped supply.

Recommendation

Sign an EIP-712 typed struct whose domain includes the destination chain ID and the receiver contract, and include the destination chain ID in the message itself.

Fix
contracts/MessageReceiver.soldiff
-  bytes32 digest = keccak256(abi.encode(m.nonce, m.sourceChainId, m.token, m.amount, m.recipient));+  bytes32 structHash = keccak256(abi.encode(+      TRANSFER_TYPEHASH, m.nonce, m.sourceChainId, m.destChainId, m.token, m.amount, m.recipient+  ));+  // _hashTypedDataV4 binds block.chainid and address(this) through the EIP-712 domain+  bytes32 digest = _hashTypedDataV4(structHash);+  if (m.destChainId != block.chainid) revert WrongDestination();
Resolution

EIP-712 domain separation adopted; validator software updated to sign typed data. INV-01 holds.

AB-03HighPartially resolvedSignature replay

Signed validator-set updates can be replayed after rotation

contracts/ValidatorSet.sol:L66

Likelihood
Medium
Impact
High
Weakness
CWE-294
Description

updateValidators(newSet, threshold, sigs) accepts a new set signed by the current set. The signed payload contains the new members and threshold but no epoch or previous-set hash.

If the set rotates from A to B and later back towards a configuration signed earlier, any previously signed update remains valid whenever its signers are again a threshold of the current set. In particular, an update signed by set A that installs a set including compromised keys can be replayed if A is ever restored.

Preconditions
  • A past signed update exists
  • The current set again contains a threshold of that update’s signers
Exploit scenario
  1. 1.Set A signs update U1 installing set B.
  2. 2.Later, governance rotates back to a set overlapping A.
  3. 3.An attacker replays an older signed update installing a set they control.
Impact

Takeover of the validator set, after which all bridge funds are at risk within rate limits.

Recommendation

Include a monotonically increasing epoch and the hash of the current set in the signed payload, and reject updates for any epoch other than currentEpoch + 1.

Fix
contracts/ValidatorSet.soldiff
-  bytes32 digest = keccak256(abi.encode(newSet, newThreshold));+  bytes32 digest = _hashTypedDataV4(keccak256(abi.encode(+      UPDATE_TYPEHASH, epoch + 1, keccak256(abi.encode(validators)), keccak256(abi.encode(newSet)), newThreshold+  )));+  epoch += 1;
Resolution

Epoch added to the signed payload. The previous-set hash is not yet included, and the receivers on Base and Arbitrum do not yet read the epoch; re-review pending.

AB-04MediumOpenBusiness logic

Vault accounting assumes the full amount arrives

contracts/TokenVault.sol:L41

Likelihood
Medium
Impact
Medium
Weakness
CWE-682
Description

lock(token, amount) calls safeTransferFrom(user, vault, amount) and records amount in the outbound message. Tokens that charge a fee on transfer deliver less than amount, so the wrapped side mints more than the vault received.

The gateway has no allowlist preventing such tokens from being bridged, and some tokens can switch fee behaviour on after listing.

Preconditions
  • A fee-on-transfer or rebasing token is bridged
Exploit scenario
  1. 1.A token with a 1% transfer fee is bridged repeatedly.
  2. 2.Each lock mints 1% more wrapped supply than the vault holds.
  3. 3.The last users to bridge back cannot be paid.
Impact

Gradual insolvency of the vault for affected tokens; INV-03 fails.

Recommendation

Measure the vault balance before and after the transfer and bridge the delta, or restrict the gateway to an allowlist of tokens with standard transfer semantics.

Fix
contracts/TokenVault.soldiff
-  IERC20(token).safeTransferFrom(user, address(this), amount);-  return amount;+  uint256 before = IERC20(token).balanceOf(address(this));+  IERC20(token).safeTransferFrom(user, address(this), amount);+  return IERC20(token).balanceOf(address(this)) - before;
Resolution

Open. The team plans a token allowlist rather than balance-delta accounting; not yet implemented at the remediation commit.

AB-05MediumAcknowledgedBusiness logic

Fixed-window rate limiter allows double the cap at window boundaries

contracts/RateLimiter.sol:L29

Likelihood
Low
Impact
High
Description

The limiter resets its counter at fixed window boundaries. An attacker with mint capability can use the full cap just before a boundary and again just after, moving twice the intended amount in a short period.

Preconditions
  • The attacker can produce valid messages (for example, after a key compromise)
Exploit scenario
  1. 1.Drain the cap at the end of window N.
  2. 2.Drain it again at the start of window N+1, within minutes.
Impact

Worst-case loss during an incident is up to twice the configured cap before responders can pause.

Recommendation

Use a rolling window or a token-bucket that refills continuously.

Resolution

Acknowledged. Caps were halved so the worst-case two-window loss matches the original single-window budget.

AB-06LowResolvedCryptography

Signature recovery accepts malleable signatures

contracts/MessageReceiver.sol:L97

Likelihood
Low
Impact
Low
Weakness
CWE-347
Description

Signatures are recovered with raw ecrecover, which accepts both s and n − s. Each valid signature therefore has a second valid encoding. Combined with AB-01 this widened the duplicate-signature issue; on its own it affects anything that keys on signature bytes.

Preconditions
  • Any component that identifies signatures by their bytes
Exploit scenario
  1. 1.A relayer submits the malleated form of a signature to bypass a bytes-based deduplication check.
Impact

Low in isolation; removes a defence-in-depth layer.

Recommendation

Use OpenZeppelin ECDSA.recover, which rejects high-s values.

Resolution

Switched to ECDSA.recover.

AB-07InformationalResolvedCode quality

Pause and unpause emit no events

contracts/BridgeGateway.sol:L203

Likelihood
Low
Impact
Low
Description

The gateway’s custom pause flag changes without an event, so monitoring cannot alert on pause state changes on any chain.

Preconditions
  • None
Exploit scenario
  1. 1.An unpause during an incident goes unnoticed by monitoring.
Impact

Reduced observability during incidents.

Recommendation

Emit events for pause state changes or inherit OpenZeppelin Pausable.

Resolution

Inherits Pausable; events emitted.

AB-08MediumOpenGovernance manipulation

Validator rotation takes effect immediately

contracts/ValidatorSet.sol:L88

Likelihood
Low
Impact
High
Description

A successful updateValidators call replaces the active set in the same transaction. There is no delay during which watchers can observe the pending set or a guardian can cancel it.

If a threshold of keys is compromised, the attacker can rotate to a set of their own keys and begin minting in the next block, leaving the honest validators no recourse.

Preconditions
  • A threshold of current validator keys is compromised
Exploit scenario
  1. 1.The attacker signs an update installing their own keys.
  2. 2.They submit it and, in the next block, mint up to the rate limit on each destination.
Impact

Permanent loss of control over the bridge with no window to intervene.

Recommendation

Queue validator-set updates with an activation delay (for example 48 hours) and allow a separate guardian role to cancel a pending update.

Resolution

Open. A queued-update design is under discussion with the team.

06

Severity

8findings
  • Critical1 · 13%
  • High2 · 25%
  • Medium3 · 38%
  • Low1 · 13%
  • Informational1 · 13%

By vulnerability class

  • Business logic2
  • Signature replay2
  • Bridge message validation1
  • Code quality1
  • Cryptography1
  • Governance manipulation1

Likelihood and impact

Each finding placed by the likelihood of its preconditions and the impact of exploitation.

Findings by likelihood (columns) and impact (rows)
Impact ↓ / Likelihood →LowMediumHigh
High
Medium
0
0
Low
0
0

07

Remediation

4 of 8 findings are resolved, 1 acknowledged, 1 partially resolved and 2 open at remediation commit e7afa329553d.

Remediation progress69%

Resolved and acknowledged findings count fully; partially resolved findings count half.

69%remediated
  • Resolved4 · 50%
  • Partially resolved1 · 13%
  • Acknowledged1 · 13%
  • Open2 · 25%
Findings by severity and remediation status
SeverityResolvedPartially resolvedAcknowledgedOpenTotal
Critical10001
High11002
Medium00123
Low10001
Informational10001
All findings41128

Residual items

  • AB-03HighPartially resolvedEpoch added to the signed payload. The previous-set hash is not yet included, and the receivers on Base and Arbitrum do not yet read the epoch; re-review pending.
  • AB-04MediumOpenOpen. The team plans a token allowlist rather than balance-delta accounting; not yet implemented at the remediation commit.
  • AB-05MediumAcknowledgedAcknowledged. Caps were halved so the worst-case two-window loss matches the original single-window budget.
  • AB-08MediumOpenOpen. A queued-update design is under discussion with the team.
  • ResolvedFixed and verified in the remediation review.
  • Partially resolvedMitigated; the residual risk is documented.
  • AcknowledgedAccepted by the protocol team with a stated rationale.
  • OpenNot yet addressed at the reviewed remediation commit.

08

Formal verification

Formal verification was not part of this engagement. The following properties were checked with stateful fuzzing across rotation and transfer sequences; results reflect the remediation commit.

Tool: Foundry invariant testing

  • INV-01InconclusiveA message executes at most once across all destination chainsViolated on the original commit (AB-02); held after the fix across 500k sequences.
  • INV-02InconclusiveExecution requires signatures from at least threshold distinct current validatorsViolated on the original commit (AB-01); held after the fix.
  • INV-03ViolatedWrapped supply on all destination chains never exceeds locked canonical balanceFails with fee-on-transfer tokens until AB-04 is fixed.
  • INV-04InconclusiveA retired validator set cannot authorise messagesHolds for messages; set-update replay is only partially addressed (AB-03).

A proved property holds for every execution of the model under its stated assumptions. Fuzzing and property-based results are evidence, not proofs, and are recorded as inconclusive.

09

Recommendations

  1. 01

    Close the open items before increasing limits

    AB-04 and AB-08 should be fixed, and AB-03 completed on both destination chains, before rate limits are raised.

  2. 02

    Publish the validator set

    Document who operates each validator, how keys are stored and how rotation is decided, so users can evaluate the threshold assumption.

  3. 03

    Monitor for unexpected mints

    Alert when wrapped supply on any destination exceeds the locked balance, and when a validator-set update is submitted.

  4. 04

    Prepare a pause runbook

    Define who can pause each chain, how quickly, and how a pause is lifted after an incident.

10

Methodology and limitations

  1. 01Manual review of the message lifecycle from lock to mint and burn to release on each chain
  2. 02Digest construction review: every field that determines where and how a message executes must be signed
  3. 03Signature verification review: duplicates, malleability, ordering and threshold arithmetic
  4. 04Foundry fork tests across Ethereum, Base and Arbitrum, including validator rotation scenarios
  5. 05Remediation review of the fix commit (in progress at the time of this version)

Severity classification

Critical
Direct loss of funds or permanent loss of control is achievable with little or no precondition.
High
Material loss or protocol disruption is achievable under realistic conditions.
Medium
Limited loss, degraded functionality, or impact that depends on specific conditions.
Low
Minor impact, defence-in-depth gaps, or issues with unlikely preconditions.
Informational
Code quality, documentation or best-practice observations without direct security impact.

Limitations

  • This version precedes the end of the remediation review; statuses may change in version 1.0.
  • Off-chain validator software, key storage and relayer infrastructure were out of scope.
  • Economic security of the validator set was not assessed.

No assessment can show that a system is free of vulnerabilities. This research assessment reflects the code at the commits listed. Quantix methodology

11

Technical appendix

Tools

  • FoundryFork tests and invariant fuzzing across three chains
  • SlitherStatic analysis and inheritance review
  • Manual reviewDigest construction and signature verification
Reviewed files (SHA-256) · 6 files
SHA-256 hashes of reviewed files
FileSHA-256
contracts/BridgeGateway.sol30c65495d73ab6cd23da67190a3904176f9b85b9c0ed0123f4b4e7e7ed49c7de
contracts/MessageReceiver.sola9abe4b252758469f81933a11c8e2dd7972937a4117237aaa7ad20b6f30b38fc
contracts/ValidatorSet.sol8706d5d1bc0df349d122fd6d75a8a3ca688fbabc94def12f025e2b0e8a0c9487
contracts/TokenVault.soldfe7504110934e45acccb5b5cfe8ed4c87ecc359fe8942d8e4a126efdd7bbb2b
contracts/WrappedToken.sole8dcd2c724d67b01ecdbcc12a8e73ec501a5f4ead63ef554df75c5bc3e4b3b28
contracts/RateLimiter.sol61c72d9924cc4a10950b28aeed77df522d417c05b9c5cbaad9e0f3a3cf5210bc

Notes

  • Compiled with Solidity 0.8.26, optimizer 200 runs.
  • A downloadable report will be generated when the remediation review closes and the document is published.

Technical references

  1. 1.CWE-347: Improper Verification of Cryptographic Signature (opens in a new tab)
  2. 2.OpenZeppelin ECDSA library (opens in a new tab)
  3. 3.EIP-712: Typed structured data hashing and signing (opens in a new tab)
  4. 4.EIP-155: Simple replay attack protection (opens in a new tab)
  5. 5.CWE-294: Authentication Bypass by Capture-replay (opens in a new tab)
  6. 6.EIP-20: Token Standard (opens in a new tab)
  7. 7.CWE-682: Incorrect Calculation (opens in a new tab)
  8. 8.OpenZeppelin Contracts: Pausable and security utilities (opens in a new tab)
  9. 9.EIP-2: Homestead hard-fork changes (low-s signatures) (opens in a new tab)
  10. 10.SWC-117: Signature Malleability (opens in a new tab)
  11. 11.OpenZeppelin TimelockController (opens in a new tab)

Document QX-TSA-2026-005 is under review (version 0.9).

The remediation review is still open, so no report document has been generated. The record above reflects the state at the remediation commit; version 1.0 and its PDF are produced when the review closes.

12

Report history

  1. 21 Sept 2026Review openedReviewed commit d9e6c02925a9 in github.com/example-org/arbalest-bridge
  2. 6 Oct 2026Review closedThree reviewers, twelve working days; remediation review in progress
  3. After reviewRemediation reviewFixes checked at commit e7afa329553d
  4. After reviewVersion 0.9 under reviewQX-TSA-2026-005: the PDF is issued when the remediation review closes

Commission an assessment written to be verified.

Share the repository and the commit you plan to deploy. We reply with scoping questions and an estimate.