Prepared by:
HALBORN
Last Updated 03/18/2026
Date of Engagement: February 3rd, 2026 - February 3rd, 2026
100% of all REPORTED Findings have been addressed
All findings
5
Critical
1
High
0
Medium
0
Low
1
Informational
3
Halborn was engaged by Trace team to conduct a one-day security assessment of the BRLT smart contract on February 3rd, 2026. The review focused on the core token logic, access control mechanisms, blacklist enforcement, and upgradeability design, with relevant commit hashes and scope details documented in the Scope section of this report.
The BRLT contract is an upgradeable ERC20 token representing a Brazilian Real–denominated asset and includes role-based controls for minting, burning, pausing, upgrading, and blacklisting. The design leverages the UUPS upgrade pattern and incorporates permit-based approvals and pausability to support administrative control and emergency handling.
A full-time security engineer was assigned by Halborn to perform a targeted review of the smart contracts in scope. The engineer is a blockchain and smart contract security specialist with advanced penetration - testing and smart - contract auditing skills, and extensive knowledge of multiple blockchain protocols.
The purpose of the assessment was to:
Identify potential security issues within the smart contracts.
Confirm that smart contract functionality operates as intended.
In summary, Halborn identified several areas for improvement to minimize both the likelihood and potential impact of security risks, which were addressed by the Trace team. The primary issues include:
Adjusted burn authorization logic to ensure tokens held by normal (non-blacklisted) users can be burned as intended.
Prevented the zero address from being blacklisted to avoid disruptions to mint and burn operations.
Halborn performed a combination of manual code review and automated security testing to balance efficiency, timeliness, practicality, and accuracy in regard to the scope of this assessment. While manual testing is essential to uncover flaws in logic, process, and implementation, automated testing techniques enhance coverage of smart contracts and can quickly identify issues that do not follow security best practices.
The following phases and associated tools were used throughout the assessment:
Research into the architecture, purpose, and use of the platform.
Manual code review and walkthrough of the smart contracts to identify potential logic issues.
Manual testing of all core functions, including deposit, withdraw, repay, and borrow, to validate expected behavior and identify edge-case vulnerabilities.
Local testing to simulate contract interactions and validate functional and security assumptions.
Local deployment and testing with Foundry.
| 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
1
High
0
Medium
0
Low
1
Informational
3
| Security analysis | Risk level | Remediation Date |
|---|---|---|
| System Does Not Allow Burning Tokens Held by Normal Users | Critical | Solved - 02/23/2026 |
| Blacklist function allows redundant blacklisting without state validation | Low | Solved - 02/23/2026 |
| Zero address can be blacklisted, causing token mint operations to break | Informational | Solved - 02/23/2026 |
| Unblacklist function lacks zero address and state validation | Informational | Solved - 02/23/2026 |
| Blacklist checks are bypassed for approve and permit operations | Informational | Solved - 02/23/2026 |
//Critical
//Low
//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
BRLT EVM
* Use Google Chrome for best results
** Check "Background Graphics" in the print settings if needed
