Prepared by:
HALBORN
Last Updated 04/02/2025
Date of Engagement: March 26th, 2025 - March 27th, 2025
100% of all REPORTED Findings have been addressed
All findings
2
Critical
0
High
0
Medium
1
Low
1
Informational
0
Noon Capital
engaged Halborn to conduct a security assessment on smart contracts beginning on March 26th, 2025 and ending on March 27th, 2025. The security assessment was scoped to the smart contracts provided to the Halborn team. Commit hashes and further details can be found in the Scope section of this report.
The team at Halborn dedicated 2 days for the engagement and assigned one full-time security engineer to evaluate the security of the smart contract.
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:
Verify secure integration of Hyperlane with contracts in-scope
Ensure that smart contract functions operate as intended.
Identify potential security issues with the smart contracts.
In summary, Halborn identified some improvements to reduce the likelihood and impact of risks, which were completely addressed by the Noon Capital team
. The main ones were the following:
Strengthen the validations when sending tokens through Hyperlane.
Return any excess ETH sent by the user to cover cross-chain fees.
Halborn performed a combination of manual, semi-automated and automated security testing to balance efficiency, timeliness, practicality, and accuracy regarding the scope of this assessment. While manual testing is recommended to uncover flaws in logic, process, and implementation; automated testing techniques help enhance coverage of the code 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 architecture and purpose.
Smart contract manual code review and walk-through.
Manual assessment of use and safety for the critical Solidity variables and functions in scope to identify any vulnerability classes
Manual testing by custom scripts.
Static Analysis of security for scoped contract, and imported functions. (Slither
)
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 (I:N) Low (I:L) Medium (I:M) High (I:H) Critical (I: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
0
High
0
Medium
1
Low
1
Informational
0
Security analysis | Risk level | Remediation Date |
---|---|---|
Cross-Chain Token Loss Due to Insufficient Validation | Medium | Solved - 04/01/2025 |
Excess ETH Refund in Cross-Chain Operations | Low | Solved - 04/01/2025 |
//
The sendTokensViaHyperlane
function in StakedUSNBasicOFTHyperlane.sol
and StakingVaultOFTUpgradeableHyperlane.sol
lacks critical validation checks before burning or locking tokens. This creates a vulnerability due to validation asymmetry between source and destination chains.
The implementation in StakedUSNBasicOFTHyperlane.sol
demonstrates the issue:
// In sendTokensViaHyperlane (source chain):
function sendTokensViaHyperlane(uint32 _destinationDomain, address _recipient, uint256 _amount) external payable {
if (!hyperlaneEnabled) revert HyperlaneNotEnabled();
if (_amount == 0) revert InvalidAmount();
// Missing zero address check for _recipient
// Missing blacklist check for _recipient
bytes32 remoteToken = remoteTokens[_destinationDomain];
if (remoteToken == bytes32(0)) revert RemoteTokenNotRegistered();
// Burn tokens first - BEFORE ANY RECIPIENT VALIDATION
_burn(msg.sender, _amount);
// ...message encoding and dispatch...
}
While the contract correctly enforces blacklisting in the _update
function:
function _update(address from, address to, uint256 amount) internal virtual override {
if (blacklist[from] || blacklist[to]) revert BlacklistedAddress();
super._update(from, to, amount);
}
This creates a vulnerability with two main failure modes:
Zero Address Recipients: If a user sends tokens to address(0), the tokens are burned on the source chain, but the destination's handle()
function will revert with if (recipient == address(0)) revert InvalidRecipient();
Blacklisted Recipients: If a user sends tokens to a blacklisted address, the tokens are burned on the source chain, but when the destination chain tries to mint them via _mint(recipient, amount)
, it will internally call _update()
which will revert with BlacklistedAddress()
due to the blacklist check.
In both cases, tokens are permanently removed from circulation on the source chain, but never minted on the destination chain. This results in permanent loss of funds with no recovery mechanism.
Implement comprehensive validation in the sendTokensViaHyperlane function before burning any tokens:
function sendTokensViaHyperlane(uint32 _destinationDomain, address _recipient, uint256 _amount) external payable {
if (!hyperlaneEnabled) revert HyperlaneNotEnabled();
if (_amount == 0) revert InvalidAmount();
if (_recipient == address(0)) revert InvalidRecipient();
if (blacklist[_recipient]) revert BlacklistedAddress();
bytes32 remoteToken = remoteTokens[_destinationDomain];
if (remoteToken == bytes32(0)) revert RemoteTokenNotRegistered();
// ... rest of the function
}
SOLVED: The suggested mitigation was implemented by the Noon Capital team.
//
In StakedUSNBasicOFTHyperlane
and StakingVaultOFTUpgradeableHyperlane
, the sendTokensViaHyperlane
function collects ETH from users to pay for cross-chain message fees. However, when users send more ETH than required, the excess amount is not refunded:
The function calculates the required fee with requiredFee = mailbox.quoteDispatch(_destinationDomain, remoteToken, messageBody)
It checks if the sent value is sufficient with if (msg.value < requiredFee) revert InsufficientInterchainFee()
It forwards the entire msg.value
to the Mailbox with mailbox.dispatch{value: msg.value}(_destinationDomain, remoteToken, messageBody)
This means that any excess ETH sent by the user (beyond what's needed for the fee) is not returned to the user. This behavior could lead to users overpaying for cross-chain transactions without any mechanism to recover the excess funds.
Modify the sendTokensViaHyperlane
function to calculate and refund any excess ETH:
function sendTokensViaHyperlane(uint32 _destinationDomain, address _recipient, uint256 _amount) external payable {
//...
// Fee handling with refund
uint256 requiredFee = mailbox.quoteDispatch(_destinationDomain, remoteToken, messageBody);
if (msg.value < requiredFee) revert InsufficientInterchainFee();
uint256 excessFee = msg.value - requiredFee;
// Send only the required fee amount
mailbox.dispatch{value: requiredFee}(_destinationDomain, remoteToken, messageBody);
// Refund excess ETH if any
if (excessFee > 0) {
(bool success, ) = msg.sender.call{value: excessFee}("");
require(success, "ETH refund failed");
}
//...
}
SOLVED: The suggested mitigation was implemented by the Noon Capital team.
Halborn used automated testing techniques to enhance the coverage of certain areas of the smart contracts in scope. Among the tools used was Slither, a Solidity static analysis framework. After Halborn verified the smart contracts in the repository and was able to compile them correctly into their ABIs and binary format, Slither was run against the contracts. This tool can statically verify mathematical relationships between Solidity variables to detect invalid or inconsistent usage of the contracts' APIs across the entire code-base.
The security team conducted a comprehensive review of findings generated by the Slither static analysis tool. All the issues identified by the Slither tool were false positives.
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
Staking Vault
* Use Google Chrome for best results
** Check "Background Graphics" in the print settings if needed