Saucerswap Labs SCA Audit | Saucerswap Labs

Summary

100% of all REPORTED Findings have been addressed

About this report

Assessment Type

Assurance Assessment

Date of Engagement

May 4th, 2026 - May 18th, 2026

Source Code

universal-router permit2 UniswapX

Assessed Commit ID

b10bc56 d949604 aae8ca2

Severity Breakdown

6Not Applicable
16Risk Accepted
5Solved
27All Findings

Critical0
High0
Medium2
- 1N/A
- 1Risk A.
Low15
- 9Risk A.
- 4N/A
- 2Solved
Informational10
- 6Risk A.
- 3Solved
- 1N/A

Introduction#

Saucerswap Labs engaged Halborn to perform a security assessment of their smart contracts from May 4th, 2026 to May 18th, 2026. The assessment scope was limited to the smart contracts provided to Halborn, commit hashes and additional details are available in the Scope section of this report.

SaucerSwap is a decentralized exchange and DeFi protocol built on Hedera. The audited codebase extends several upstream Uniswap components for the Hedera environment, including a fork of Permit2, a fork of the Universal Router, and a custom UniswapX partial-fill settlement stack. The scoped contracts introduce Hedera-specific support for HTS tokens, native HBAR flows, Permit2 authorization, Universal Router execution, partial-fill limit orders, fee tiers, executor callbacks, and filler validation.

The assessment focused on correctness across these cross-repository boundaries, especially where EVM assumptions interact with Hedera-specific native balance, token association, precompile, wallet-signing, and block-metadata behavior. As an additional scope item, Halborn reviewed the newly introduced Hedera personal-signing path in Permit2 and UniswapX, including compatibility with Hedera Account Service signature verification and coexistence with the existing EIP-712 flow; this additional review was limited to Hedera compatibility and the opt-in personal-signing changes.

Assessment Summary#

Halborn was allocated 10 business days for this engagement and assigned 1 full-time security engineer to conduct a comprehensive review of the smart contracts within scope. The engineer is an expert in blockchain and smart contract security, with advanced skills in penetration testing and smart contract exploitation, as well as extensive knowledge of EVM smart contracts, DeFi protocols, and Hedera-specific smart contract behavior.

The objectives of this assessment were to:

Identify potential security vulnerabilities within the smart contracts.
Verify that the smart contract functionality operates as intended.
Assess the correctness of the Hedera-specific adaptations, including HTS and HBAR accounting, Permit2 authorization, HAS and wallet-signing behavior, Universal Router execution, and partial-fill settlement logic.

In summary, Halborn identified several areas for improvement to reduce the likelihood and impact of security risks, some of which were addressed by the Saucerswap Labs team. The primary recommendations were:

Replace full-balance native HBAR reads with attributed per-call and per-command accounting so residual router or reactor balances cannot be drained, bridged, or counted as unrelated settlement output.
Remove permissionless allowance and full-balance executor reserve patterns, and bind executor-held balances to the settlement leg that created them before allowing Permit2 or router consumption.
Use Hedera-compatible priority-fee and auction calculations that do not rely on block.basefee, which is unavailable on Hedera, and prefer timestamp-based logic where block-number cadence differs from Ethereum assumptions.
Replace live xSAUCE balance reads for fee-tier discounts with checkpointed, time-weighted, or minimum-holding-duration logic so temporary balances cannot qualify for higher fee tiers within a single transaction.
Separate fill-state semantics for taker-only and maker-side fills, and avoid shared principalFilled state from letting dust maker fills permanently block takerOnce orders.

Risk Methodology#

Every vulnerability and issue observed by Halborn is ranked based on two sets of Metrics and a Severity Coefficient. This system is inspired by the industry standard Common Vulnerability Scoring System.

The two Metric sets are: Exploitability and Impact. Exploitability captures the ease and technical means by which vulnerabilities can be exploited and Impact describes the consequences of a successful exploit.

The Severity Coefficients is designed to further refine the accuracy of the ranking with two factors: Reversibility and Scope. These capture the impact of the vulnerability on the environment as well as the number of users and smart contracts affected.

The final score is a value between 0-10 rounded up to 1 decimal place and 10 corresponding to the highest security risk. This provides an objective and accurate rating of the severity of security vulnerabilities in smart contracts.

The system is designed to assist in identifying and prioritizing vulnerabilities based on their level of risk to address the most critical issues in a timely manner.

3.1 EXPLOITABILITY

Attack Origin (AO):

Captures whether the attack requires compromising a specific account.

Attack Cost (AC):

Captures the cost of exploiting the vulnerability incurred by the attacker relative to sending a single transaction on the relevant blockchain. Includes but is not limited to financial and computational cost.

Attack Complexity (AX):

Describes the conditions beyond the attacker’s control that must exist in order to exploit the vulnerability. Includes but is not limited to macro situation, available third-party liquidity and regulatory challenges.

Metrics:

EXPLOITABILITY METRIC ( $m_e$ )	METRIC VALUE	NUMERICAL VALUE
Attack Origin (AO)	Arbitrary (AO:A)	1
Attack Origin (AO)	Specific (AO:S)	0.2
Attack Cost (AC)	Low (AC:L)	1
	Medium (AC:M)	0.67
	High (AC:H)	0.33
Attack Complexity (AX)	Low (AX:L)	1
	Medium (AX:M)	0.67
	High (AX:H)	0.33

Exploitability

E

is calculated using the following formula:

$E = \prod m_e$

3.2 IMPACT

Confidentiality (C):

Measures the impact to the confidentiality of the information resources managed by the contract due to a successfully exploited vulnerability. Confidentiality refers to limiting access to authorized users only.

Integrity (I):

Measures the impact to integrity of a successfully exploited vulnerability. Integrity refers to the trustworthiness and veracity of data stored and/or processed on-chain. Integrity impact directly affecting Deposit or Yield records is excluded.

Availability (A):

Measures the impact to the availability of the impacted component resulting from a successfully exploited vulnerability. This metric refers to smart contract features and functionality, not state. Availability impact directly affecting Deposit or Yield is excluded.

Deposit (D):

Measures the impact to the deposits made to the contract by either users or owners.

Yield (Y):

Measures the impact to the yield generated by the contract for either users or owners.

Metrics:

IMPACT METRIC ( $m_I$ )	METRIC VALUE	NUMERICAL VALUE
Confidentiality (C)	None (C:N)	0
	Low (C:L)	0.25
	Medium (C:M)	0.5
	High (C:H)	0.75
	Critical (C:C)	1
Integrity (I)	None (I:N)	0
	Low (I:L)	0.25
	Medium (I:M)	0.5
	High (I:H)	0.75
	Critical (I:C)	1
Availability (A)	None (A:N)	0
	Low (A:L)	0.25
	Medium (A:M)	0.5
	High (A:H)	0.75
	Critical (A:C)	1
Deposit (D)	None (D:N)	0
	Low (D:L)	0.25
	Medium (D:M)	0.5
	High (D:H)	0.75
	Critical (D:C)	1
Yield (Y)	None (Y:N)	0
	Low (Y:L)	0.25
	Medium (Y:M)	0.5
	High (Y:H)	0.75
	Critical (Y:C)	1

Impact

I

is calculated using the following formula:

$I = max(m_I) + \frac{\sum{m_I} - max(m_I)}{4}$

3.3 SEVERITY COEFFICIENT

Reversibility (R):

Describes the share of the exploited vulnerability effects that can be reversed. For upgradeable contracts, assume the contract private key is available.

Scope (S):

Captures whether a vulnerability in one vulnerable contract impacts resources in other contracts.

Metrics:

SEVERITY COEFFICIENT ( $C$ )	COEFFICIENT VALUE	NUMERICAL VALUE
Reversibility ( $r$ )	None (R:N)	1
	Partial (R:P)	0.5
	Full (R:F)	0.25
Scope ( $s$ )	Changed (S:C)	1.25
Scope ( $s$ )	Unchanged (S:U)	1

Severity Coefficient

C

is obtained by the following product:

$C = rs$

The Vulnerability Severity Score

S

is obtained by:

$S = min(10, EIC * 10)$

The score is rounded up to 1 decimal places.

Critical	High	Medium	Low	Informational
9 - 10	7 - 8.9	4.5 - 6.9	2 - 4.4	0 - 1.9

Scope#

(a) Repository:universal-router

(b) Assessed Commit ID:b10bc562f91cac2c8e91d165aa36f1afd3f2af1d

29 files

contracts

29 files

base

4 files

Dispatcher.sol

solidity

HtsAssociation.sol

solidity

Lock.sol

solidity

RouteSigner.sol

solidity

deploy

1 file

UnsupportedProtocol.sol

solidity

interfaces

4 files

external

3 files

IERC20Wrapper.sol

solidity

IHRC.sol

solidity

Additional scope:08dcb7320fb579afa8a39c0a649f7e66e0fa9497

(a) Repository:permit2

(b) Assessed Commit ID:d949604e6452a776b0071f95f88d6cb866205794

13 files

permit2 / src

13 files

base

1 file

HTSInteractable.sol

solidity

libraries

7 files

Allowance.sol

solidity

HederaAccountService.sol

solidity

HederaTokenService.sol

solidity

Permit2Lib.sol

solidity

PermitHash.sol

solidity

SafeCast160.sol

solidity

SignatureVerification.sol

solidity

AllowanceTransfer.sol

solidity

Additional scope:cc82cb0d26a58f60ef7578b14a64543de195d242

(a) Repository:UniswapX

(b) Assessed Commit ID:aae8ca2f0e10b47cee90703e5b1d396ed0714118

34 files

UniswapX-feat-principal-fee-separation / src

34 files

external

2 files

ISwapRouter02.sol

solidity

IUniversalRouter.sol

solidity

fee-controllers

1 file

PartialFillFeeController.sol

solidity

interfaces

9 files

IArbSys.sol

solidity

IPartialFillFeeController.sol

solidity

IPartialFillLimitOrderReactor.sol

solidity

IPartialFillUniversalRouterExecutor.sol

solidity

IPartialFillValidationCallback.sol

solidity

Additional scope:08dcb7320fb579afa8a39c0a649f7e66e0fa9497

9bcb4248c41d369e2aeb0ed5f8a7c83a484f66c9 f44f1034018a35629dd59e5a219d2b7092b5e724 6ef6c5981ff4c3967fdcdc720b4ffeb8e641e7d2 806043571e79ef02bb26d8aae187fd3cb5277a13 072f21a9e709eb34f87276a868b1b62255dc3f30

Out-of-Scope: New features/implementations after the remediation commit IDs.

Assessment Summary & Findings Overview#

#	Title	Severity	Score	Status
HAL-01	Priority-fee reactors miscompute scaling on Hedera because block.basefee is unavailable	Medium	6.3	Not Applicable05/26/2026
HAL-02	Shared principalFilled lets a 1-wei maker fill permanently brick a taker order using takerOnce	Medium	5.4	Risk Accepted05/26/2026
HAL-03	Reactor bypasses Permit2 for AMM-output pull, leaving HTS allowance ceiling fragile	Low	4.2	Risk Accepted05/27/2026
HAL-04	HBAR allowance preflight via callStatic returns wrong response code breaking quoter tooling	Low	3.8	Risk Accepted05/27/2026
HAL-05	Dutch decay and exclusivity windows elapse 10x faster on Hedera block cadence	Low	3.8	Not Applicable05/27/2026
HAL-06	Per-market fee override is ignored when market discount tiers are absent	Low	3.4	Risk Accepted05/27/2026
HAL-07	Anyone can delete expired order state and harvest storage refund, erasing cancellation history	Low	3.1	Risk Accepted05/27/2026
HAL-08	Missing recipient validation in claimFees allows operator typo to burn HBAR or zero bookkeeping	Low	3.1	Solved05/26/2026
HAL-09	Best-effort batch flag fails for most commands leaving user ETH stranded on revert	Low	3.1	Risk Accepted05/27/2026
HAL-10	Native HBAR deposits forwarded with wrong input token lock funds in Across bridge	Low	2.8	Not Applicable05/27/2026
HAL-11	Adversarial validation contract can DoS specific fillers and inflate gas costs via uncapped returndata	Low	2.5	Not Applicable05/27/2026
HAL-12	HAS reverts on malformed signatures and invalid accounts cause per-call DoS	Low	2.5	Risk Accepted05/27/2026
HAL-13	Callers can drain or miscredit unattributed HBAR balances	Low	2.5	Risk Accepted05/26/2026
HAL-14	Takers with tight Permit2 allowances repeatedly grief fillers by causing fee-pull settlement reverts	Low	2.5	Risk Accepted05/27/2026
HAL-15	Nested sub-plans can exhaust quoter simulation gas	Low	2.5	Not Applicable05/27/2026
HAL-16	Relayer captures all swap output when signed route uses MSG_SENDER recipient without sender verification	Low	2.2	Risk Accepted05/27/2026
HAL-17	Shared Sequencing Nonce Lets One Filler Invalidate Another Filler's Batch	Low	2.2	Solved05/24/2026
HAL-18	Cancellation callbacks lack explicit reentry protection	Informational	1.3	Risk Accepted05/27/2026
HAL-19	Protocol fee accrual writes no event, making off-chain treasury monitoring brittle and unreliable	Informational	1.1	Solved05/27/2026
HAL-20	Missing Dual-Ledger Documentation Causes Confusing Reverts for Integrators Using HBAR Permits	Informational	1.1	Solved05/27/2026
HAL-21	Permit2 signatures replay across sister ERC-1271 wallets that omit owner-binding	Informational	1.1	Risk Accepted05/27/2026
HAL-22	Deployment workflows expose keys and recovery gaps	Informational	1.1	Risk Accepted05/27/2026
HAL-23	Any caller can drain executor reserves via permissionless Permit2 allowance and full-balance accounting	Informational	0.8	Solved05/26/2026
HAL-24	Malformed inputs produce raw panics and incomplete diagnostics	Informational	0.8	Risk Accepted05/27/2026
HAL-25	Upstream Permit2 lockdown semantics let outstanding signatures re-arm reactor and Universal Router allowances simultaneously	Informational	0.0	Risk Accepted05/27/2026
HAL-26	Key Rotation Leaves a Race Window Where Revoked-Key Permits Remain Redeemable	Informational	0.0	Risk Accepted05/27/2026
HAL-27	Signed route context can mislead hook integrations	Informational	0.0	Not Applicable05/27/2026

Remediation Comment

Addressed in:

1.3AO:A/AC:M/AX:M/R:P/S:U/C:N/I:L/A:M/D:N/Y:NAO:A/AC:M/AX:M/R:P/S:U/C:N/I:L/A:M/D:N/Y:N

Description

Recommendation

Remediation Comment

HAL-19Solved

Protocol fee accrual writes no event, making off-chain treasury monitoring brittle and unreliable

Informational

1.1AO:A/AC:M/AX:M/R:N/S:U/C:N/I:L/A:N/D:N/Y:NAO:A/AC:M/AX:M/R:N/S:U/C:N/I:L/A:N/D:N/Y:N

Description

Recommendation

Remediation Comment

Addressed in:

6ef6c5981ff4c3967fdcdc720b4ffeb8e641e7d2

HAL-20Solved

Missing Dual-Ledger Documentation Causes Confusing Reverts for Integrators Using HBAR Permits

Informational

1.1AO:A/AC:M/AX:M/R:N/S:U/C:N/I:L/A:N/D:N/Y:NAO:A/AC:M/AX:M/R:N/S:U/C:N/I:L/A:N/D:N/Y:N

Description

Recommendation

References

Fix Commit: https://github.com/saucerswaplabs/UniswapX/commit/faa8965b6b8c56dbca3550cb7ed601fd770c6610

Remediation Comment

Addressed in:

Recommendation

Remediation Comment

Addressed in:

Remediation Comment

Disclaimer#

Halborn strongly recommends conducting a follow-up assessment of the project either within six months or immediately following any material changes to the codebase, whichever comes first. This approach is crucial for maintaining the project’s integrity and addressing potential vulnerabilities introduced by code modifications.