Prepared by:
HALBORN
Last Updated 01/24/2026
Date of Engagement: January 6th, 2026 - January 9th, 2026
100% of all REPORTED Findings have been addressed
All findings
19
Critical
0
High
0
Medium
10
Low
9
Informational
0
Kickoff.fun engaged Halborn to conduct a security assessment on their smart contracts beginning on January 6th, 2026 and ending on January 9th, 2026. The security assessment was scoped to the smart contracts provided in the kickoff-contracts GitHub repository, provided to the Halborn team. Commit hash and further details can be found in the Scope section of this report.
The reviewed contracts implement a liquidity bootstrapping launchpad built on Aerodrome’s veAERO voting system. veAERO holders temporarily lock NFTs to direct gauge votes, after which rewards are claimed, swapped, and used to create permanently locked liquidity, while participants receive project tokens proportionally.
Halborn was provided with 4 days for this engagement and assigned a full-time security engineer to assess the security of the smart contracts in scope. The assigned engineer possesses deep expertise in blockchain and smart contract security, including hands-on experience with multiple blockchain protocols.
The objective of this assessment is to:
Identify potential security issues within the Kickoff.fun protocol smart contracts.
Ensure that smart contract of ````Kickoff.fun protocol functions operate as intended.
In summary, Halborn identified several areas for improvement to reduce the likelihood and impact of security risks, which were mostly addressed by the Kickoff.fun team. The main recommendations were:
Handle batch voting failures at the per‑NFT level to avoid single-point batch failures.
Require pool activation to be aligned with Aerodrome's epoch start.
Design liquidity finalization to safely handle pre‑existing pool state.
Provide a defined path for zero‑participant scenario to avoid project tokens becoming stranded in the pool.
Implement meaningful slippage protection when swapping reward tokens.
Halborn performed a combination of manual review of the code and automated security testing to balance efficiency, timeliness, practicality, and accuracy in regard to the scope of the smart contract assessment. While manual testing is recommended to uncover flaws in logic, process, and implementation; automated testing techniques help enhance coverage of smart contracts and can quickly identify items that do not follow security best practices.
The following phases and associated tools were used throughout the term of the assessment:
Research into the architecture and purpose of the Kickoff.fun protocol.
Manual code review and walkthrough of the Kickoff.fun in-scope contracts.
Manual assessment of critical Solidity variables and functions to identify potential vulnerability classes.
Manual testing using custom scripts.
Static Analysis of security for scoped contract, and imported functions. (Slither).
Local deployment and testing with (Foundry, Remix IDE).
| 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
10
Low
9
Informational
0
| Security analysis | Risk level | Remediation Date |
|---|---|---|
| NFTs with zero voting power can permanently DoS vote casting | Medium | Solved - 01/13/2026 |
| Deactivated veAERO NFTs can permanently DoS voting batches and trap funds | Medium | Solved - 01/13/2026 |
| Emergency withdrawals break core accounting invariants and can permanently deadlock the pool | Medium | Solved - 01/13/2026 |
| Kickoff pool can accept non-votable NFTs due to epoch-start mismatch between Kickoff and Aerodrome | Medium | Solved - 01/13/2026 |
| Pool creation can be front-run to steal privileged roles and block the intended launch | Medium | Solved - 01/13/2026 |
| Liquidity finalization can be DoSed due to manipulated pool ratios | Medium | Solved - 01/13/2026 |
| Pools can finalize with zero participants and permanently lock project tokens | Medium | Solved - 01/13/2026 |
| Unintended liquidity creation can permanently consume project tokens due to external WETH transfers | Medium | Solved - 01/13/2026 |
| Reward conversion may execute with unbounded slippage | Medium | Solved - 01/13/2026 |
| Kickoff finalization can occur before Aerodrome epoch completion, causing reward loss | Medium | Solved - 01/13/2026 |
| Gauge status change between vote batches can permanently brick voting and trap NFTs | Low | Solved - 01/13/2026 |
| Claim rounding leaves irrecoverable project token dust in the pool | Low | Solved - 01/18/2026 |
| Swap and liquidity operations lack meaningful deadline constraints | Low | Solved - 01/13/2026 |
| Rescue mechanism fails for tokens that do not return a boolean on successful transfers | Low | Solved - 01/13/2026 |
| Batch voting can span multiple Aerodrome epochs, leading to inconsistent reward attribution | Low | Solved - 01/16/2026 |
| Locking veAERO NFTs allows Kickoff to claim historical voting rewards | Low | Risk Accepted - 01/19/2026 |
| LPLocker fee distribution can be permanently DoSed by restrictive project token behavior | Low | Solved - 01/13/2026 |
| Leftover liquidity allocation tokens can become permanently stuck after adding liquidity | Low | Solved - 01/18/2026 |
| Early emergency exit can permanently lock allocated project tokens and allow new locks into an unusable pool | Low | Solved - 01/13/2026 |
//Medium
//Medium
//Medium
//Medium
//Medium
//Medium
//Medium
//Medium
//Medium
//Medium
//Low
//Low
//Low
//Low
//Low
//Low
//Low
//Low
//Low
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
Kickoff Protocol Contracts
* Use Google Chrome for best results
** Check "Background Graphics" in the print settings if needed
