Audit of onlyswaps and dcipher (BLS signatures)

Randa-mu • September 19th, 2025 • Technical Report

Introduction

On September 8th, 2025, zkSecurity was commissioned to perform a security audit of Randa-mu’s cross-chain OnlySwaps protocol and the BLS threshold signatures implementation. For the next two weeks, one consultant reviewed the code in search of bugs. A number of observations and findings have been reported to the Randa-mu team. The findings are detailed in the latter section of this report. The codebase was found to be of high quality, accompanied by thorough tests and documentation.

Scope

The scope of the audit was divided into three distinct parts:

onlyswaps-solidity: containing the main on-chain logic of the protocol (commit: 7607614bcff8ee2bd843f303db1b32c5f5c3f4e5)
bls-solidity: a library implementing BLS verification in Solidity (commit: 9e10df92d631fab9c46f0ce9cd5c445f857bedcb)
Parts of the dcipher repo: implementing the off-chain logic written in Rust (commit: e08602de2d1543c508914b2ca9ddbcb647fb7bcf). Specifically focusing on:
- onlyswaps-verifier: main agent for verifying cross-chain swap fulfillments and creating threshold signatures
- omnievent: listens to events from chains
- signer: threshold signing
- crates/network: wrapping functionality of libp2p used by the signer
- crates/utils: utility functions for hash_to_curve, dst, and serialize (for the pairing operations)

The distributed key generation codebase was not part of this engagement. Furthermore, the main dependencies such as libp2p and ark are considered to be secure.

Protocol Overview

OnlySwaps is a protocol for cross-chain token swaps that are fulfilled by solvers. An off-chain committee produces BLS threshold signatures verifying that a solver has fulfilled a request from a user in a destination chain. The signature is then submitted in the source chain to release the funds to the solver.

The following figure demonstrates an end-to-end example of OnlySwaps.

Overview

The main functions in the Router.sol contract that handle the on-chain activity are:

requestCrossChainSwap: Called by a user in the source chain, it creates and saves a requestId with the passed parameters and emits an event about this request. With this function call, the user also sets the solver reward and sends the funds to the Router.
relayTokens: Called by a solver in the destination chain, it fulfills a request by sending the funds to the user-specified address. It further updates the state of the Router in the destination chain and emits an event.
rebalanceSolver: When a committee member has a BLS threshold signature that verifies that a requestId has been fulfilled correctly, they can submit the signature by calling this function in the source chain. It first verifies the signature, then updates the state, sends the solver reward to the solver, and emits an event. The BLS signature verification happens by calling the verifySignature function from bls-solidity.
updateSolverFeesIfUnfulfilled: A user can call this function in the source chain to update the solver fee to incentivize solvers to fulfill their request. Importantly, this function can only increase the fee.

On the off-chain part, an onlyswaps-verifier agent queries all supported blockchains for detecting new events. When it detects a new event that requires verification (e.g., a receipt event), it calls the evaluate_and_send function. This function is responsible for:

Querying both the source chain and the destination chain to get the transfer params and the transfer receipt, respectively
Calling the reconcile_transfer_params function that checks that the funds were sent and received in the correct chains, that the correct tokens were used, and that the correct amount was passed
Starting the signing process, which by communicating with other committee members using libp2p, generates a BLS threshold signature. The logic of the signing process is in the signer directory
Optionally, when having a correct threshold signature, the committee member can call the rebalanceSolver function in the source chain to verify the signature on-chain and pay back the solver

Threat Model

The OnlySwaps protocol operates with the following trust assumptions and administrative controls:

Administrative Roles

Router Admin:

setVerificationFeeBps: Modify the verification fee in basis points
setMinimumContractUpgradeDelay: Set the minimum delay for contract upgrades
permitDestinationChainId: Allow a new destination chain for swaps
blockDestinationChainId: Block a destination chain from receiving swaps
setTokenMapping: Configure token mappings across chains
removeTokenMapping: Remove existing token mappings
withdrawVerificationFee: Withdraw accumulated verification fees

Upgrade Validator Committee:

scheduleUpgrade: Schedule a future contract upgrade
cancelUpgrade: Cancel a scheduled upgrade
setContractUpgradeBlsValidator: Update the BLS validator for contract upgrades
setSwapRequestBlsValidator: Update the BLS validator for swap requests

Swap Validator Committee:

rebalanceSolver: Reimburse solvers with valid threshold signatures

Trust Assumptions

The committee operating the threshold signature scheme maintains an honest majority (at least t honest members out of n total)
The Router Admin is a trusted entity that will not act maliciously
Solvers are untrusted but economically incentivized to fulfill swaps correctly
Users trust the protocol’s verification mechanism to ensure proper swap execution
t honest nodes create valid partial and at least one of them aggregate them into a valid signature and submit it on-chain

BLS Threshold Signatures

The OnlySwaps protocol uses BLS (Boneh-Lynn-Shacham) threshold signatures to verify cross-chain swap fulfillments. This cryptographic scheme allows a distributed committee to collectively sign messages while requiring only a threshold number of participants.

BLS Signature Implementation

The implementation provides both standard BLS signatures and threshold signature capabilities through the following components:

Core BLS Operations: The system implements the standard BLS signature scheme over the BN254 and BLS12-381 curves. Signatures are created by computing $σ = H (m)^{s k}$ where $H$ is a hash-to-curve function that maps messages to elliptic curve points.

Signature verification uses bilinear pairings to check the equation $e (σ, g_{2}) = e (H (m), p k)$ , ensuring that only the holder of the private key (or the shared private key) corresponding to the public key could have generated the signature.

Domain Separation: Following RFC 9380 standards, the implementation uses comprehensive domain separation tags (DSTs) to prevent signature reuse across different contexts. The DST format includes:

Application identifier (e.g., “swap-v1” for OnlySwaps)
Curve specification (BN254G1 or BLS12381G1)
Hash function and expansion method (XMD:KECCAK-256 or XMD:SHA-256)
Mapping algorithm (SVDW for BN254, SSWU for BLS12-381)
Chain ID to prevent cross-chain replay attacks

For OnlySwaps, a typical DST looks like: swap-v1-BN254G1_XMD:KECCAK-256_SVDW_RO_0x[chain_id]_

Threshold Signature Protocol

The threshold signature scheme allows any t out of n committee members to produce a valid signature:

Secret Sharing: The system assumes that private keys have been distributed using Shamir Secret Sharing, where each committee member $i$ holds a share $s k_{i}$ of the master secret. The corresponding verification key is $v k_{i} = g^{s k_{i}}$ .

Partial Signature Generation: When a swap needs verification, each committee member independently:

Computes their partial signature: $σ_{i} = H (m)^{s k_{i}}$
Broadcasts this partial signature to other committee members via libp2p
Verifies received partial signatures against the sender’s public key

Signature Aggregation: Once t valid partial signatures are collected, any committee member can reconstruct the full signature using Lagrange interpolation:

σ = \prod_{i \in S} σ_{i}^{λ_{i}}

where $λ_{i}$ are the Lagrange coefficients computed for the set $S$ of participating members.

Network Protocol

The threshold signing protocol operates through a distributed network using libp2p:

Event Detection: The onlyswaps-verifier agent monitors blockchain events through the omnievent system
Verification Request: When a swap receipt is detected, the agent queries both source and destination chains to verify the swap parameters
Partial Signature Exchange: Committee members compute and broadcast their partial signatures using CBOR serialization
Aggregation: When exactly t partial signatures are collected, the full signature is computed
On-chain Submission: The aggregated signature can be submitted to the Router contract’s rebalanceSolver function

Implementation Architecture

The Rust implementation is organized into modular components:

BlsPairingSigner: Handles individual BLS signing and verification operations
BlsThresholdSigner: Coordinates the distributed threshold signature protocol
signer/src/bls/filter.rs: Manages domain separation and DST generation
signer/src/bls/aggregation.rs: Implements Lagrange interpolation for signature reconstruction
crates/utils: Provides utility functions for hash-to-curve and serialization

The system supports both BN254 and BLS12-381 curves, with flexible configuration for different applications beyond OnlySwaps.

Additional Differential Testing

To ensure the correctness of the BLS implementation in Solidity, beyond manual code review, we performed extensive differential testing between the bls-solidity library and a reference Rust implementation. Each test category was executed with at least one million randomly generated test cases to provide high confidence in the implementation’s correctness.

Testing Methodology

The differential testing framework consists of a Rust program that accepts various test parameters and computes reference outputs for comparison with the Solidity implementation. The testing covered:

BLS Signature Generation and Verification:

BN254 curve signatures using Keccak256 hashing
BLS12-381 curve signatures using SHA256 hashing
Public key generation and signature creation
Full signature verification flow

Hash-to-Curve Mapping:

Shallue-van de Woestijne (SvdW) mapping for BN254
Field element to curve point conversion

Test Suites

Three comprehensive fuzz testing suites were developed:

BLSTestFuzz.sol:

testFfiBlsVerifyGenerated: Verifies BLS signature generation and verification on BN254 curve by comparing Rust-generated signatures with Solidity verification
testFfiMapToPointBN254: Tests the hash-to-curve mapping function, ensuring field elements map to the same curve points in both implementations

BLS2TestFuzz.sol:

Similar test structure to BLSTestFuzz but using the BLS12-381 curve
Validates signature operations with SHA256 hashing instead of Keccak256

ModExpFuzz.t.sol:

testFfiModExp1: Validates modular exponentiation against the BN254 field modulus
testFfiModExpInverse: Tests modular inverse computation
testFfiModExpSqrt: Verifies modular square root calculations

Testing Results

All differential tests passed successfully across millions of test cases, providing strong evidence that the Solidity BLS implementation correctly matches the reference Rust implementation using the arkworks library. This extensive testing gives high confidence in the cryptographic correctness of the bls-solidity library used in the OnlySwaps protocol.

Differential Testing Results

Findings

Below are listed the findings found during the engagement. High severity findings can be seen as so-called "priority 0" issues that need fixing (potentially urgently). Medium severity findings are most often serious findings that have less impact (or are harder to exploit) than high-severity findings. Low severity findings are most often exploitable in contrived scenarios, if at all, but still warrant reflection. Findings marked as informational are general comments that did not fit any of the other criteria.

High

#00 DoS Attack in relayTokens Through Malicious requestId Usage Router.sol

Medium

#01 Admin Can Delay Upgrades Indefinitely Router.sol #02 Missing Finality Checks Could Lead to Fund Loss During Chain Reorganizations dcipher/onlyswaps-verifier/

Low

#03 Missing Zero Address Check for Recipient in requestCrossChainSwap Router.sol #04 Inconsistent Destination Chain Validation in requestCrossChainSwap Router.sol #05 Byzantine Committee Members Can DoS Benign Nodes Through Signature Flooding dcipher/signer/

Informational

#06 Missing Timeout Mechanism for Unfulfilled Cross-Chain Swaps Router.sol #07 Eager Signing Mode Lacks Security Warnings dcipher/signer/

High · #00

DoS Attack in relayTokens Through Malicious requestId Usage

Router.sol

Description. The relayTokens function is permissionless and accepts requestId as a parameter without binding it to amountOut. This allows any user to perform a Denial of Service (DoS) attack by monitoring requestIds on the source chain and calling relayTokens with a minimal amount (e.g., 0.00...01) while using a valid requestId. Since the function checks if a requestId has already been fulfilled, legitimate calls will fail when attempting to use the same requestId, effectively blocking the proper execution of cross-chain swaps.

NOTE: The validators query both source and destination chains, map requestIds with SwapReceipts based on this logic (offchain), and if correct, they generate a signature. Hence, no funds would be lost, but they would be stuck in the contracts.

Impact. This vulnerability enables complete and extremely cheap DoS attacks on the protocol. While no funds would be lost, they would become stuck in the contracts as legitimate solvers cannot fulfill requests that have been maliciously marked as completed with incorrect amounts. The validation step by validators would correctly fail, but users’ funds would remain locked.

Recommendation. Modify relayTokens to accept all parameters needed to reconstruct the requestId (excluding dstChainId). The function should then reconstruct the requestId based on these parameters. This ensures that if a solver calls the function with a different amountOut, the resulting requestId will be different, preventing the DoS attack vector.

Client Response. We have addressed this issue by updating the relayTokens function to require all swap request parameters necessary to reconstruct the requestId on-chain. This ensures that the requestId is always derived from the actual parameters provided, preventing mismatches and mitigating the described denial-of-service vulnerability. See commit 895c60f829e014d8806fe01f33f97bc2ea56ea9d for details.

Medium · #01

Admin Can Delay Upgrades Indefinitely

Router.sol

Description. The upgrade mechanism at line 476 allows the admin to unilaterally delay upgrades indefinitely. This creates a centralization risk where a single admin account (or multisig) can prevent critical protocol upgrades from being executed, even if they have been properly scheduled and the timelock period has passed.

Impact. A malicious or compromised admin could prevent important security patches, feature upgrades, or critical fixes from being deployed to the protocol. This could leave the protocol vulnerable to known issues or prevent it from evolving to meet user needs.

Recommendation. The upgrade delay should be handled by both the Admin and the BLS upgrade committee.

Client Response. The ability for the admin to indefinitely delay scheduled upgrades has been addressed. The onlyAdmin modifier has been replaced with a requirement for a BLS signature as an input parameter, which is now used to validate changes to minimumContractUpgradeDelay. See commit 27fee3c1c982fafe6b6c4a22578dc7221ad616b5 and af73e8a31b410fa392ebe14c7be3991c6eed7748 for details. The IScheduledUpgradeable.sol interface has also been updated in this commit b4ea44708a46853f48138dc280e0e15b15c659d7.

Medium · #02

Missing Finality Checks Could Lead to Fund Loss During Chain Reorganizations

dcipher/onlyswaps-verifier/

Description. The dcipher agents process verification requests by picking up requestIds through omnievent (which retrieves events from the latest blocks) or by querying the network_bus state. The evaluate_and_send method does not verify that blocks containing transfer and receive transactions have been finalized according to each chain’s finality rules. This creates a vulnerability where verifiers might generate threshold signatures based on transactions that could later be reverted due to chain reorganizations.

Impact. If a chain reorganization occurs on the destination chain after verifiers have already created and submitted a threshold signature on the source chain:

The solver receives funds on the source chain based on the threshold signature
The destination chain transaction gets reverted due to the reorganization
The user never receives their funds on the destination chain
The protocol suffers a loss as funds have been released to the solver without the corresponding delivery to the user

This scenario, while unlikely under normal conditions, could lead to significant fund losses and break the protocol’s security guarantees.

Recommendation. Modify the evaluate_and_send method to verify that blocks containing both transfer and receive transactions have reached finality according to each chain’s specific rules before generating threshold signatures. This approach maintains good UX for users while ensuring protocol safety:

Solvers can still provide fast service by fulfilling orders on the destination chain at their own risk
Solvers must wait for finality before receiving reimbursement on the source chain
Implement chain-specific finality checks (e.g., different confirmation requirements for different chains)

This ensures that threshold signatures are only generated for irreversible transactions, preventing fund loss due to reorganizations.

Client Response. The team acknowledged this as a potential issue, noting they haven’t addressed reorganizations yet due to their complexity. They agreed that waiting for finalization makes the most sense despite UX implications.

Low · #03

Missing Zero Address Check for Recipient in requestCrossChainSwap

Router.sol

Description. The requestCrossChainSwap function at line 115 does not validate that the recipient parameter is not the zero address. This is inconsistent with the rebalanceSolver function at line 183, which properly includes a zero address check for its recipient parameter. Without this validation, users could accidentally request cross-chain swaps to the zero address, resulting in permanently lost tokens.

Impact. If a user mistakenly provides the zero address as the recipient, the cross-chain swap would proceed normally but the tokens would be sent to an unrecoverable address on the destination chain. This would result in permanent loss of user funds due to a simple input error that could have been prevented with proper validation.

Recommendation. Add a zero address check for the recipient parameter in the requestCrossChainSwap function, similar to the validation already implemented in rebalanceSolver. This can be done by adding:

require(recipient != address(0), "Recipient cannot be zero address");

Client Response. A zero address check for the recipient parameter has been added to the requestCrossChainSwap function to prevent invalid recipient addresses. See commit bde64881211baf131098cb88173c43d59a036eea for details.

Low · #04

Inconsistent Destination Chain Validation in requestCrossChainSwap

Router.sol

Description. The requestCrossChainSwap function at line 124 only checks DestinationMapping to validate the destination chain but does not verify against AllowedDestination. This creates an inconsistency with the admin’s allow/disallow chain management logic. When an admin disallows a chain through the administrative functions, users and solvers can still interact with that chain if the token mapping is not removed from the DestinationMapping data structure.

Impact. This inconsistency undermines the admin’s ability to properly manage allowed destination chains. If an admin needs to urgently disable a destination chain (e.g., due to a security incident or chain issues), users can continue to request cross-chain swaps to that destination as long as the token remains in DestinationMapping.

Recommendation. Modify the requestCrossChainSwap function to also check AllowedDestination in addition to DestinationMapping. This ensures consistency with the admin’s chain management decisions. The validation should verify that:

The destination token exists in DestinationMapping (current check)
The destination chain is marked as allowed in AllowedDestination (missing check)

This can be implemented by adding an additional require statement:

require(AllowedDestination[dstChainId], "Destination chain not allowed");

Client Response. In addition to the check on the destination token mapping, we have added a validation for the destination chain id in requestCrossChainSwap. Please see commit cf80cf7a1944954d2bb65fd33effad49207c9c09 for details.

Low · #05

Byzantine Committee Members Can DoS Benign Nodes Through Signature Flooding

dcipher/signer/

Description. The recv_new_requests function is vulnerable to denial-of-service attacks from byzantine committee members who can flood the network with partial signatures. There is currently no rate limiting or message throttling mechanism to prevent a malicious node from overwhelming benign committee members with excessive signature requests, potentially degrading the performance of the entire threshold signature scheme.

Impact. A byzantine committee member could:

Overwhelm benign nodes with excessive partial signature flooding
Cause legitimate signature requests to be delayed or dropped
Degrade the overall performance of the threshold signature system
Force benign nodes to expend excessive computational resources verifying spam signatures

While the impact is limited because byzantine nodes can be identified and removed from the protocol, this still presents an operational challenge and could cause temporary service disruption.

Recommendation. Implement rate limiting and message management strategies.

Client Response. The team agreed that rate limiting would be beneficial and discussed investigating libp2p’s out-of-the-box support for peer rate limiting. They acknowledged the need for caching mechanisms that limit requests per node and rotate out older ones.

Informational · #06

Missing Timeout Mechanism for Unfulfilled Cross-Chain Swaps

Router.sol

Description. The requestCrossChainSwap function does not implement a timeout mechanism for unfulfilled swap requests. Once users initiate a cross-chain swap request and their tokens are locked in the contract, there is no built-in mechanism for them to reclaim their funds if solvers fail to fulfill the order within a reasonable timeframe. This creates a dependency on solver activity and could result in indefinite fund lockup if no solver is willing or able to complete the swap.

Impact. While this does not pose a direct security risk, it significantly impacts user experience and capital efficiency. Users’ funds could remain locked indefinitely if:

No solver finds the swap profitable enough to execute
Market conditions change making the swap uneconomical
There is low solver activity on certain routes
Technical issues prevent solvers from fulfilling requests

This could lead to user frustration and reduced protocol adoption.

Recommendation. Implement a timeout mechanism that allows users to cancel unfulfilled swap requests and reclaim their locked tokens after a reasonable period. Consider adding:

A configurable timeout period (e.g., 24-48 hours) per swap request
A cancelRequest function that users can call after the timeout expires
Proper event emission for cancelled requests to maintain transparency
Generate signatures accordingly and verify them on-chain.

Client Response. We’ve added support for users to cancel a swap request and claim a refund to a specified wallet address on the source chain if no solver fulfills the request. Cancellation occurs in two phases:

Stage Cancellation – Call stageSwapRequestCancellation(bytes32 requestId) to start the cancellation process. This opens a cancellation window, a grace period during which solvers can still fulfill the request.
Finalize & Refund – After the cancellation window has elapsed, call cancelSwapRequestAndRefund(bytes32 requestId, address refundRecipient) to complete the cancellation and receive the refund.

The length of the cancellation window can be updated only via a threshold signature by calling setCancellationWindow(uint256 newSwapRequestCancellationWindow, bytes calldata signature).

See commit bb2e7c8a3b3f2d44e112e84f53d9dee4d678f697 for details.

Informational · #07

Eager Signing Mode Lacks Security Warnings

dcipher/signer/

Description. The with_eager_signing function at line 311 enables a mode where the node automatically submits partial signatures upon receiving valid partial signatures from other nodes. When enabled, this functionality essentially treats all libp2p nodes as trusted entities and blindly signs any valid message received. While this feature is disabled by default (line 305), the function lacks clear documentation warning about the security implications of enabling this mode.

Impact. Developers using this library might inadvertently enable eager signing without fully understanding the trust assumptions and security implications. This could lead to nodes automatically signing malicious or unintended messages

While the feature itself may have legitimate use cases in trusted environments, the lack of clear warnings could lead to misuse.

Recommendation. Add comprehensive documentation and warnings to the with_eager_signing function.

Client Response. The team acknowledged that eager signing essentially treats other libp2p nodes as “trusted”, blindly signing their signature requests. They agreed to add warnings around the function.

← Back to Index