Smart Contract Assessment - Saucerswap Labs

1. Summary

Saucerswap Labs engaged Halborn to conduct a security assessment on their smart contracts beginning and ending on July 21st 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.

The reviewed contracts comprise the newly introduced DelegationRegistry contract and the diff-scoped additions to PartialFillLimitOrderReactor contract, which together extend SaucerSwap's partial-fill settlement engine with account-to-account order delegation that enables a delegator to authorize a delegate to sign limit orders on the delegator's behalf, funded from the delegator's own Permit2 allowance, subject to per-token net-outflow caps. DelegationRegistry is a standalone, fund-less policy ledger that stores delegation grants and enforces per-token spending budgets through signed cumulative counters updated atomically on each fill; PartialFillLimitOrderReactor is the settlement engine, extended with a vault-authorized signature mode and an account-delegation mode that recovers the delegate's signature and coordinates with the registry to authorize each partial fill. Both contracts are non-upgradeable with immutable cross-references, owner-gated administration on the reactor, and registry authority scoped by the calling reactor's address as a namespace key.

2. ASSESSMENT SUMMARY

Halborn was provided with 1 day for this engagement and assigned a full-time security engineer to assess the security of the smart contracts in scope. The assigned engineer possesses deep expertise in blockchain and smart contract security, including hands-on experience with multiple blockchain protocols.

The objective of this assessment is to:

• Identify potential security vulnerabilities within the smart contracts.

• Verify that the smart contract functionality operates as intended.

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

• Persist the authorization mode on first fill and enforce it on every subsequent fill so that delegated orders cannot be downgraded to the signature-once path.

• Record actual transferred amounts using balance deltas rather than nominal values to ensure net-outflow accounting reflects real token movements.

• Register delegation-specific error selectors in the skip code classifier so that registry failures are attributed distinctly from maker validation errors.

3. CAVEATS

This assessment only covers the changes introduced between commit 6ef6c59 and commit ed4b604 for the smart contracts listed in the Scope section of this report. All other parts of the codebase are treated as black boxes, and it is assumed that any required security mechanisms are properly implemented elsewhere in the system. This includes, but is not limited to, input validation, business logic enforcement, and access control.

Differential audits focus on identifying security risks introduced or modified in a specific set of changes. While some components added in the diff may interact with each other or with existing logic, these interactions are only reviewed when they are explicitly visible within the diff itself. Implicit assumptions or cross-component dependencies may fall outside the scope unless clearly surfaced through changes or supporting context.

For a more complete understanding of the protocol's security posture and the behavior of interconnected components, a full-scope assessment is recommended.

4. TEST APPROACH AND METHODOLOGY

Halborn performed a combination of manual review of the code and automated security testing to balance efficiency, timeliness, practicality, and accuracy in regard to the scope of the smart contract assessment. While manual testing is recommended to uncover flaws in logic, process, and implementation; automated testing techniques help enhance coverage of smart contracts and can quickly identify items that do not follow security best practices.

The following phases and associated tools were used throughout the term of the assessment:

• Research into the architecture and purpose of the in-scope contracts.

• Manual code review and walkthrough of the in-scope contracts.

• Manual assessment of critical Solidity variables and functions to identify potential vulnerability classes.

• Manual testing using custom scripts.

• Static Analysis of security for scoped contract, and imported functions (Slither).

• Local deployment and testing with (Foundry, Remix IDE).