Prepared by:
HALBORN
Last Updated 01/06/2026
Date of Engagement: December 15th, 2025 - December 18th, 2025
100% of all REPORTED Findings have been addressed
All findings
18
Critical
1
High
0
Medium
0
Low
6
Informational
11
Halborn was engaged by StartEngine to conduct a security assessment of the ERC-1450 Upgradeable Security Token. The assessment was performed from December 15th, 2025 to December 18th, 2025 with reviewed commit hashes and scope details documented in the Scope section of this report.
The ERC-1450 implementation provides a regulated security token framework designed for compliant issuance, transfer, and lifecycle management of tokenized securities. The system enforces restricted transfers through an RTA-controlled workflow, supports regulation-specific batch tracking, and integrates fee-based transfer requests with broker delegation. Upgradeability is implemented using the UUPS proxy pattern, while administrative control and governance are delegated to a multisignature RTA proxy to reduce single-key risk and enable controlled upgrades.
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 partially addressed by the StartEngine team. The primary issues include:
Enforce protocol-calculated fees and reject zero or user-defined fee amounts to prevent fee bypass across all tokens.
Enforce strict mutual exclusivity between ETH and ERC20 fee payments.
Replace all usages of '.transfer' with '.call' and explicitly handle the return value.
Enforce frozen account checks consistently across all token movement paths.
Introduce an explicit expiration or deadline mechanism for multisig operations.
Revert if the request is already rejected or executed.
Track reserved fees associated with pending transfer requests separately from withdrawable fees.
| Security analysis | Risk level | Remediation |
|---|---|---|
| User-controlled fee amount enables fee bypass and ambiguous multi-token fee enforcement | Critical | Solved - 12/22/2025 |
| Incorrect Fee Handling Allows Double Payment of Fees (ETH + ERC20) | Low | Risk Accepted - 12/17/2025 |
| Native ETH transfers use .transfer, causing refunds and withdrawals to fail | Low | Solved - 12/22/2025 |
| Inconsistent Frozen Account Enforcement Allows Transfers and Token Operations Involving Frozen Addresses | Low | Risk Accepted - 12/22/2025 |
| Stale multisig operations can be executed long after submission due to missing expiration | Low | Solved - 12/19/2025 |
| Missing request finalization check allows multiple fee refunds | Low | Solved - 12/22/2025 |
| Fee withdrawal can break future transfer fee refunds | Low | Risk Accepted - 12/22/2025 |
| Fee Type Enumeration Is Declared but Not Enforced | Informational | Acknowledged - 12/17/2025 |
| Inconsistent fee refund handling across transfer request rejection paths | Informational | Acknowledged - 12/17/2025 |
| Inconsistent batch cleanup during token burns leaves unused regulation entries | Informational | Solved - 12/22/2025 |
| Token transfers bypass regulation tracking and allow unregulated movement | Informational | Acknowledged - 12/30/2025 |
| Missing no-op state change validation allows redundant administrative updates | Informational | Acknowledged - 12/30/2025 |
| burnFrom lacks on-chain enforcement of regulation vs non-regulation token burns | Informational | Acknowledged - 12/30/2025 |
| Transfer agent becomes permanently immutable after being set to a contract address | Informational | Acknowledged - 12/17/2025 |
| Missing input validation during initialization allows invalid token configuration | Informational | Acknowledged - 12/30/2025 |
| Single-step ownership initialization limits safe ownership transfer | Informational | Acknowledged - 12/30/2025 |
| Redundant transfer agent existence check causes unnecessary logic complexity | Informational | Acknowledged - 12/22/2025 |
| Event declaration placement improves code readability | Informational | Acknowledged - 12/30/2025 |
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
ERC1450
* Use Google Chrome for best results
** Check "Background Graphics" in the print settings if needed
