AI Advisory
Strategic guidance for secure AI adoption
Prepared by:
HALBORN
Last Updated 08/07/2026
Date of Engagement: July 6th, 2026 - July 21st, 2026
100% of all REPORTED Findings have been addressed
All findings
19
Critical
0
High
0
Medium
2
Low
9
Informational
8
tZERO engaged Halborn to perform a security assessment of their smart contracts starting on July 6th, 2026 and ending on July 21st, 2026. 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 t0kenizer codebase in scope consists of modular, composable ERC-20 smart contract modules for tZERO's platform for issuing tokenized real-world assets (regulated securities) on EVM-compatible chains, featuring ERC-7943-aligned compliance controls (whitelist, blacklist, freeze, forced transfer), corporate-action modules (stock splits, dividends, capped supply, vesting), and dual standard/UUPS-upgradeable variants composed via Solidity inheritance.
Halborn was allocated 12 days 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 are to:
Identify potential security vulnerabilities within the smart contracts.
Verify that the smart contract functionality operates as intended.
In summary, Halborn identified several areas for improvement to reduce the likelihood and impact of security risks, which were fully addressed by the tZERO team. The main recommendations were:
Add _onlyCorp() to both closeGrant implementations so the cleanup crank is restricted to CORPORATE_ACTIONS_ROLE, matching every other grant-lifecycle mutator.
Change the strict comparison to inclusive so the guard fires when the snapshot falls on the revocation block.
In T0kenDividendClaim.cancelSameTokenAndReturnAmount(), cap the returned amount at the contract's actual balance, mirroring the existing guard in reclaimUnclaimed().
| Security analysis | Risk level | Remediation |
|---|---|---|
| closeGrant lacks the _onlyCorp() guard its sibling lifecycle functions have, letting anyone de-whitelist a spent vesting wallet and DoS the beneficiary's pending same-token dividend claim | Medium | Solved - 07/24/2026 |
| Overlapping same-token dividends dilute holders via unclaimed float in the denominator | Medium | Solved - 07/24/2026 |
| Strict comparison in post-revocation dividend routing misclassifies the revocation block, misrouting vested dividends to treasury | Low | Solved - 07/26/2026 |
| Missing balance cap in cancelSameTokenDividend bricks same-token dividend cancellation after split rounding | Low | Solved - 07/16/2026 |
| Missing dividend-contract override in VestingWallet.claimDividend() strands vesting-wallet dividends after a pointer rotation | Low | Solved - 07/17/2026 |
| createOtherTokenDividend / createSameTokenDividend accept a maturity in the past | Low | Solved - 07/24/2026 |
| Same-token dividend record date lags creation by only one block, enabling dividend front-running via a forced block delay | Low | Solved - 07/24/2026 |
| Global holder, volume, and transfer-count caps are griefable | Low | Solved - 07/30/2026 |
| Velocity controls lack the exclusion carve-out that the holder-count control has, so routine issuer operations (dividend and vesting funding) consume the global volume and transfer-count budgets and cannot be exempted | Low | Solved - 07/27/2026 |
| Same-token dividend claimedAmount is undercounted by integer truncation on small claims, letting reclaimUnclaimed over-extract from concurrent dividends' funds | Low | Solved - 07/24/2026 |
| Other-token dividend creatable mid-split anchors to a half-applied split snapshot | Low | Solved - 07/24/2026 |
| Lossy unit conversion in vesting release can stall released-progress tracking under low-decimal compositions | Informational | Solved - 07/26/2026 |
| Unreachable external function addToAllocation() in VestingWallet is dead code | Informational | Solved - 07/26/2026 |
| Transfer-count control counts zero-value transfers, diverging from the volume and holder controls | Informational | Solved - 07/27/2026 |
| Reusing a CREATE2 salt under the same admin collides on the beacon and dividend-claim sub-deploys, reverting the deployment with an unattributable error | Informational | Solved - 07/30/2026 |
| Reverse-split cap asymmetry: the supply cap is not tightened after a reverse split | Informational | Solved - 07/27/2026 |
| Front-running of blacklist additions is undocumented | Informational | Solved - 07/27/2026 |
| Post-revocation same-token dividend accruals bypass the frozen vesting clock at the vest-end sweep | Informational | Solved - 07/26/2026 |
| Beneficiary reassignment without prior settlement breaks the vested-payout guarantee upheld by revocation | Informational | Solved - 07/24/2026 |
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
Tokenized Project EVM Assessment
* Use Google Chrome for best results
** Check "Background Graphics" in the print settings if needed
