Prepared by:
HALBORN
Last Updated 04/06/2026
Date of Engagement: October 20th, 2025 - October 24th, 2025
100% of all REPORTED Findings have been addressed
All findings
21
Critical
2
High
0
Medium
0
Low
0
Informational
19
This security assessment was commissioned by SilentSwap, a privacy-focused, non-custodial cross-chain aggregator built on the Secret Network. Conducted by Halborn’s experienced security team, the review focused on the on-chain components in the silentswap-v2-cps and silentswap-v2-gateway repositories. The assessment covered all functionalities within both CPS and Gateway contracts from October 20, 2025 to October 24, 2025. As a non-custodial protocol, SilentSwap never takes possession of user funds, users retain full control of their assets throughout every interaction. The primary objective of this engagement was to identify potential vulnerabilities, verify module reliability, and enhance the overall security posture.
The team at Halborn assigned a full-time security engineer to verify the security of the smart contracts. The security engineer is a blockchain and smart-contract security expert with advanced penetration testing, smart-contract hacking, and deep knowledge of multiple blockchain protocols.
The purpose of this assessment is to:
Ensure that smart contract functions operate as intended
Identify potential security issues with the smart contract
In summary, Halborn identified some improvements to reduce the likelihood and impact of risks. The SilentSwap team remediated the major issues identified. The remaining informational findings have been acknowledged by the team. The main recommendations were the following:
Fix arguments order when invoking the sign_ecdsa_keccak_256 function.
Use compressed keys for all Cosmos/Secret semantics (address & Permit).
Implement a grace period in order to give the notary/claimer a buffer to land claims after expiry, or proof-commit mechanism to reduce operational risk of race conditions.
Bind the recipient and execution context in the signature.
An unwaveringly thorough multi-phase strategy was employed for this assessment. The process comprised the following major phases:
Scoping and threat modeling, including architectural review to identify systemic risk areas.
Manual line-by-line review of the smart contract source across all identified repositories.
Automated tooling and static/dynamic analysis to ensure full path coverage and surfacing of subtle runtime vulnerabilities.
Custom on-chain test case development and execution against all critical user, protocol, and edge-case flows, mapped against real-world threat models for DeFi, cross-chain, and privacy-centric systems.
Continuous cross-validation of findings among specialists to eliminate blind spots and false negatives.
Manual and automated review phases were balanced for maximum coverage: static analysis flagged issues rapidly, while targeted manual work validated logic, business invariants, and protocol integrations. Major frameworks and off-the-shelf industry toolkits were leveraged, supplemented by custom tests to validate crucial behaviors under adversarial conditions.
At the request of SilentSwap, we were tasked with determining whether the platform operates as a non-custodial system. Upon completion of our review, our determination is that SilentSwap’s architecture is non-custodial.
The findings documented in this report for the CPS codebase are based on the source code repository provided at the time of the security assessment. Following the conclusion of the assessment, the SilentSwap team shared a new repository containing an updated version of the codebase with fixes applied to the major reported issues. The originally assessed repository is no longer in active use.
The Solidity smart contracts audited in this engagement have been verified and deployed on BNB Smart Chain and Avalanche.
Contract | Address |
SilentSwapV2Gateway | 0xAAef732E8B327917BF44A7892102A5ED3Bd27842 |
SilentSwapDepositor | 0x02AcB3A073eF5625Ec0e30481df1cf8c4bD7a98E |
Both contracts are publicly verified on BscScan and Snowtrace at the links below:
https://bscscan.com/address/0xaaef732e8b327917bf44a7892102a5ed3bd27842
https://bscscan.com/address/0x02AcB3A073eF5625Ec0e30481df1cf8c4bD7a98E
https://snowtrace.io/address/0xAAef732E8B327917BF44A7892102A5ED3Bd27842/contract/43114/code
https://snowtrace.io/address/0x02AcB3A073eF5625Ec0e30481df1cf8c4bD7a98E/contract/43114/code
| EXPLOITABILITY METRIC () | METRIC VALUE | NUMERICAL VALUE |
|---|---|---|
| Attack Origin (AO) | Arbitrary (AO:A) Specific (AO:S) | 1 0.2 |
| Attack Cost (AC) | Low (AC:L) Medium (AC:M) High (AC:H) | 1 0.67 0.33 |
| Attack Complexity (AX) | Low (AX:L) Medium (AX:M) High (AX:H) | 1 0.67 0.33 |
| IMPACT METRIC () | METRIC VALUE | NUMERICAL VALUE |
|---|---|---|
| Confidentiality (C) | None (C:N) Low (C:L) Medium (C:M) High (C:H) Critical (C:C) | 0 0.25 0.5 0.75 1 |
| Integrity (I) | None (I:N) Low (I:L) Medium (I:M) High (I:H) Critical (I:C) | 0 0.25 0.5 0.75 1 |
| Availability (A) | None (A:N) Low (A:L) Medium (A:M) High (A:H) Critical (A:C) | 0 0.25 0.5 0.75 1 |
| Deposit (D) | None (D:N) Low (D:L) Medium (D:M) High (D:H) Critical (D:C) | 0 0.25 0.5 0.75 1 |
| Yield (Y) | None (Y:N) Low (Y:L) Medium (Y:M) High (Y:H) Critical (Y:C) | 0 0.25 0.5 0.75 1 |
| SEVERITY COEFFICIENT () | COEFFICIENT VALUE | NUMERICAL VALUE |
|---|---|---|
| Reversibility () | None (R:N) Partial (R:P) Full (R:F) | 1 0.5 0.25 |
| Scope () | Changed (S:C) Unchanged (S:U) | 1.25 1 |
| Severity | Score Value Range |
|---|---|
| Critical | 9 - 10 |
| High | 7 - 8.9 |
| Medium | 4.5 - 6.9 |
| Low | 2 - 4.4 |
| Informational | 0 - 1.9 |
Critical
2
High
0
Medium
0
Low
0
Informational
19
| Security analysis | Risk level | Remediation Date |
|---|---|---|
| Reversed parameters in ECDSA signing causes total notarization failure | Critical | Solved - 10/30/2025 |
| Inconsistent secp256k1 public key encoding breaks address derivation and Permits | Critical | Solved - 10/30/2025 |
| Unconstrained validation in verify_snip_result | Informational | Acknowledged - 10/30/2025 |
| Unpadded error responses create Query-Size side-channel | Informational | Acknowledged - 10/30/2025 |
| depositProxy2 allow a forward with residual funds | Informational | Acknowledged - 10/30/2025 |
| Order Expiration Policy Allows Refund and Claim Race After Payout on Destination Chain | Informational | Acknowledged - 10/30/2025 |
| EIP-712 domain incomplete missing verifyingContract allows cross-contract replay | Informational | Acknowledged - 10/30/2025 |
| Notary signature format incompatible with Solidity ECDSA.recover | Informational | Solved - 10/30/2025 |
| depositProxy2 forces “All-or-Nothing” Deposit (no partial amount) | Informational | Acknowledged - 10/30/2025 |
| Non-standard EIP-191 hashing | Informational | Acknowledged - 10/30/2025 |
| Claim signature doesn't bind recipient | Informational | Acknowledged - 10/30/2025 |
| Instantiation panics when VRF randomness is unavailable | Informational | Acknowledged - 10/30/2025 |
| Unbounded facilitator_public_keys decoding enables DoS in SNIP verification | Informational | Acknowledged - 10/30/2025 |
| Compiler version 0.8.20 has known several bugs | Informational | Acknowledged - 10/30/2025 |
| Direct low-level call used for EIP-3009 receiveWithAuthorization instead of using the imported interface | Informational | Acknowledged - 10/30/2025 |
| output.token is not validated in SNIP Flow | Informational | Acknowledged - 10/30/2025 |
| Missing event emission on claimsCap update | Informational | Acknowledged - 10/30/2025 |
| Unnecessary memory copy in claim() Loop | Informational | Acknowledged - 10/30/2025 |
| Incorrect or misleading comments / docstrings | Informational | Acknowledged - 10/30/2025 |
| State variables that could be declared immutable in SilentSwapDepositor.sol | Informational | Acknowledged - 10/30/2025 |
| Missing unit tests for Query-Based flows | Informational | Acknowledged - 10/30/2025 |
//Critical
//Critical
//Informational
//Informational
//Informational
//Informational
//Informational
//Informational
//Informational
//Informational
//Informational
//Informational
//Informational
//Informational
//Informational
//Informational
//Informational
//Informational
//Informational
//Informational
//Informational
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.
// Download the full report
V2 - CPS & Gateway
* Use Google Chrome for best results
** Check "Background Graphics" in the print settings if needed
