Prepared by:
HALBORN
Last Updated 04/24/2025
Date of Engagement: March 28th, 2025 - April 2nd, 2025
100% of all REPORTED Findings have been addressed
All findings
7
Critical
0
High
0
Medium
1
Low
1
Informational
5
Smitthi engaged Halborn to conduct a security assessment on their Vesting program beginning on April 2nd, 2025 and ending on April 7th, 2024. The security assessment was scoped to the smart contracts provided in the GitHub repository smitthi_vesting_contract, commit hashes, and further details can be found in the Scope section of this report.
The Smithii team is releasing their smithii_vesting_contract Solana program. This program allows for the creation of vesting/locking schedules and claiming of SPL tokens based on time or Merkle proofs.
Halborn was provided 4 days for the engagement and assigned one full-time security engineer to review the security of the Solana Programs in scope. The engineer is a blockchain and smart contract security expert with advanced smart contract hacking skills, and deep knowledge of multiple blockchain protocols.
The purpose of the assessment is to:
Identify potential security vulnerabilities within the codebase.
Verify the correctness of the core token locking, vesting schedule calculations, and claiming logic.
Assess access control mechanisms ensuring only authorized parties can perform sensitive actions.
Evaluate the security of state management, including initialization, updates, and potential data inconsistencies.
Analyze the implementation and usage of Merkle proofs for claim verification.
Identify potential edge cases or logical flaws that could lead to unexpected behavior, denial of service, or irrecoverable fund lockups.
Assess adherence to Solana development best practices regarding security, resource management (rent and compute), and CPI handling.
In summary, Halborn identified some improvements to reduce the likelihood and impact of multiple risks, which were mostly addressed by the Smithii team. The main ones were the following:
When setting up a vesting schedule for multiple recipients using the advanced verification feature, require the creator to choose how the tokens will be split.
Do not allow setting up a new vesting schedule if the amount of tokens to be locked is zero, as this wastes fees.
Halborn performed a combination of manual review and security testing based on scripts to balance efficiency, timeliness, practicality, and accuracy in regard to 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 the security best practices. The following phases and associated tools were used during the assessment:
Research into architecture and purpose.
Differences analysis using GitLens to have a proper view of the differences between the mentioned commits
Graphing out functionality and programs logic/connectivity/functions along with state changes
| 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
0
High
0
Medium
1
Low
1
Informational
5
| Security analysis | Risk level | Remediation Date |
|---|---|---|
| Potential Denial of Service for Claimants Due to Inconsistent Merkle Distribution Logic | Medium | Solved - 04/17/2025 |
| Lack of Zero Amount Check in Initialization Allows Creation of Useless Vesting Schedules | Low | Solved - 04/17/2025 |
| Precision Loss in Periodic Vesting Calculation Leaves Residual Funds | Informational | Partially Solved - 04/17/2025 |
| Initialization Does Not Validate End Dates Are in the Future | Informational | Solved - 04/17/2025 |
| Initialization Ignores Merkle Root if receiver_count is Zero | Informational | Solved - 04/22/2025 |
| Redundant Check if fee != 0 in Initialization Functions | Informational | Solved - 04/17/2025 |
| Use of unwrap on Optional Parameters May Cause Panics in Initialization | Informational | Solved - 04/17/2025 |
//Medium
//Low
//Informational
//Informational
//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
Vesting
* Use Google Chrome for best results
** Check "Background Graphics" in the print settings if needed
