Bridge Contracts - Bitso

Prepared by:

HALBORN

Last Updated 08/20/2025

Date of Engagement: August 12th, 2025 - August 12th, 2025

Summary

100% of all REPORTED Findings have been addressed

All findings

Critical

High

Medium

Low

Informational

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

7.1 Suboptimal token transfer pattern
7.2 Public function can be marked external

8. Automated Testing

1. Summary

Bitso engaged Halborn to perform a security assessment of their smart contracts on August 12th, 2025. 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 Bitso codebase in scope consists of smart contracts enabling cross-chain transfers of ERC20 tokens via LayerZero OFT adapters with custom mint and burn logic.

2. Assessment Summary

Halborn was allocated 1 day 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 multiple blockchain protocols.

The objectives of this assessment were to:

Identify potential security vulnerabilities within the smart contracts.
Verify that the smart contract functionality operates as intended.

In summary, Halborn did not identify any significant security risks. However, some enhancements were recommended to improve code clarity, consistency, or maintainability. These were completely addressed by the Bitso team:

Consider importing and using OpenZeppelin's SafeERC20 library for ERC20 transfers.
Modify the public function not used within the contract with the external visibility modifier.

3. Test Approach and Methodology

Halborn conducted a combination of manual code review and automated security testing to balance efficiency, timeliness, practicality, and accuracy within the scope of this assessment. While manual testing is crucial for identifying flaws in logic, processes, and implementation, automated testing enhances coverage of smart contracts and quickly detects deviations from established security best practices.

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

Research into the platform's architecture, purpose and use.
Manual code review and walkthrough of smart contracts to identify any logical issues.
Comprehensive assessment of the safety and usage of critical Solidity variables and functions within scope that could lead to arithmetic-related vulnerabilities.
Local testing using custom scripts (Foundry).
Fork testing against main networks (Foundry).
Static security analysis of scoped contracts, 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

REPOSITORY

(a) Repository: juno-bridge-smart-contracts

(b) Assessed Commit ID: 0a5eb67

contracts/FiatTokenMintBurnOFTAdapter.sol
contracts/interfaces/IFiatTokenV1.sol
node_modules/@layerzerolabs/oft-evm/contracts/MintBurnOFTAdapter.sol

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

Remediation Commit ID:

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
Suboptimal token transfer pattern	Informational	Solved - 08/19/2025
Public function can be marked external	Informational	Solved - 08/19/2025

7. Findings & Tech Details

7.1 Suboptimal token transfer pattern

Informational

Description

The FiatTokenMintBurnOFTAdapter._debit() function uses innerToken.transferFrom(_from, address(this), amountSentLD) to transfer tokens from the user to the adapter contract. However, not all tokens are fully ERC20 compliant, and some tokens do not return a boolean value or may revert on failure, causing silent failures or unexpected behavior.

BVSS

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

Recommendation

Consider importing and using OpenZeppelin's SafeERC20 library for ERC20 transfers.

Remediation Comment

SOLVED: The Bitso team solved this finding in the specified commit by following the mentioned recommendation.

Remediation Hash

https://github.com/bitsoex/juno-bridge-smart-contracts/commit/62abe5cddd2a4104e9dc1c5913b93fe783ff6068

7.2 Public function can be marked external

Informational

Description

The approvalRequired() function in the FiatTokenMintBurnOFTAdapter contract is currently defined with the public visibility modifier, even though the function is not called from within the contract, potentially resulting in higher gas costs than necessary.

BVSS

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

Recommendation

Modify the public function not used within the contract with the external visibility modifier.

Remediation Comment

SOLVED: The Bitso team solved this finding in the specified commit by following the mentioned recommendation.

Remediation Hash

https://github.com/bitsoex/juno-bridge-smart-contracts/commit/e89edd81be138ef94414666c8ae495c66f069dd1

8. Automated Testing

Description

Halborn used automated testing techniques to increase coverage of specific areas within the smart contracts under review. Among the tools used was Slither, a Solidity static analysis framework. After Halborn successfully verified the smart contracts in the repository and was able to compile them correctly into their ABI and binary formats, Slither was executed against the contracts. This tool performs static verification of mathematical relationships between Solidity variables to identify invalid or inconsistent usage of the contracts' APIs throughout the entire codebase.

The security team reviewed all findings reported by the Slither software; however, findings related to external dependencies have been excluded from the results below to maintain report clarity.

Output

All findings identified by Slither were proved to be false positives and therefore were not added to the issue list in this report.

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. Summary
2. Assessment summary
3. Test approach and methodology
4. Risk methodology
5. Scope
6. Assessment summary & findings overview
7. Findings & Tech Details

7.1 Suboptimal token transfer pattern
7.2 Public function can be marked external

8. Automated Testing

// Download the full report

Bridge Contracts

* Use Google Chrome for best results

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