Staking Vault - Noon Capital (Stablecoin)

Prepared by:

HALBORN

Last Updated 04/02/2025

Date of Engagement: March 26th, 2025 - March 27th, 2025

Summary

100% of all REPORTED Findings have been addressed

All findings

Critical

High

Medium

Low

Informational

1. Introduction
2. Assessment summary
3. Test approach and methodology
4. Risk methodology
5. Scope
6. Assessment summary & findings overview
7. Findings & Tech Details

7.1 Cross-chain token loss due to insufficient validation
7.2 Excess eth refund in cross-chain operations

8. Automated Testing

1. Introduction

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.

2. Assessment Summary

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.

3. Test Approach and Methodology

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)

4. 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.

4.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) 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

Exploitability

E

is calculated using the following formula:

$E = \prod m_e$

4.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 (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

Impact

I

is calculated using the following formula:

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

4.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) Partial (R:P) Full (R:F)	1 0.5 0.25
Scope ( $s$ )	Changed (S:C) Unchanged (S:U)	1.25 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.

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

5. SCOPE

Files and Repository

(a) Repository: Noon-Core-Audit

(b) Assessed Commit ID: 38a1437

contracts/StakingVaultOFTUpgradeableHyperlane.sol
contracts/StakedUSNBasicOFTHyperlane.sol

Out-of-Scope: Third party dependencies and economic attacks.

Remediation Commit ID:

3918ba6
0eefdb6

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

6. Assessment Summary & Findings Overview

Critical

High

Medium

Low

Informational

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

7. Findings & Tech Details

7.1 Cross-Chain Token Loss Due to Insufficient Validation

Medium

Description

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.

BVSS

AO:A/AC:L/AX:M/R:N/S:U/C:N/A:N/I:N/D:H/Y:N (5.0)

Recommendation

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
}

Remediation Comment

SOLVED: The suggested mitigation was implemented by the Noon Capital team.

Remediation Hash

3918ba6da3580e59c3d693c2571be5b2249d3e68

7.2 Excess ETH Refund in Cross-Chain Operations

Low

Description

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.

BVSS

AO:A/AC:L/AX:M/R:N/S:U/C:N/A:N/I:N/D:M/Y:N (3.4)

Recommendation

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");
    }
    
    //...
}

Remediation Comment

SOLVED: The suggested mitigation was implemented by the Noon Capital team.

Remediation Hash

0eefdb601b5382609e2cbdc958182314b562d871

8. Automated Testing

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.

1. Introduction
2. Assessment summary
3. Test approach and methodology
4. Risk methodology
5. Scope
6. Assessment summary & findings overview
7. Findings & Tech Details

7.1 Cross-chain token loss due to insufficient validation
7.2 Excess eth refund in cross-chain operations

8. Automated Testing

// Download the full report

Staking Vault

* Use Google Chrome for best results

** Check "Background Graphics" in the print settings if needed

Staking Vault

Noon Capital (Stablecoin)

Table of Contents

1. Introduction

2. Assessment Summary

3. Test Approach and Methodology

4. RISK METHODOLOGY

4.1 EXPLOITABILITY

Attack Origin (AO):

Attack Cost (AC):

Attack Complexity (AX):

Metrics:

4.2 IMPACT

Confidentiality (C):

Integrity (I):

Availability (A):

Deposit (D):

Yield (Y):

Metrics:

4.3 SEVERITY COEFFICIENT

Reversibility (R):

Scope (S):

Metrics:

5. SCOPE

6. Assessment Summary & Findings Overview

7. Findings & Tech Details

7.1 Cross-Chain Token Loss Due to Insufficient Validation

Description

BVSS

Recommendation

Remediation Comment

Remediation Hash

7.2 Excess ETH Refund in Cross-Chain Operations

Description

BVSS

Recommendation

Remediation Comment

Remediation Hash

8. Automated Testing

Table of Contents