- Hacken
- Audits
- seedify-fund
- [SCA] Seedify.fund | BondingCurve | Jul2025
Introduction
We express our gratitude to the Seedify.fund team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.
Seedify is a bonding curve system that has a decentralized token launch mechanism that implements a mathematical pricing curve for token sales.
Document | |
|---|---|
| Name | Smart Contract Code Review and Security Analysis Report for Seedify.fund |
| Audited By | Turgay Arda Usman, Khrystyna Tkachuk |
| Approved By | Ataberk Yavuzer |
| Website | https://launchpad.seedify.fund/→ |
| Changelog | 16/07/2025 - Preliminary Report |
| 29/07/2025 - Final Report | |
| Platform | Ethereum, BNB, Avalanche |
| Language | Solidity |
| Tags | Launchpad, Vesting |
| Methodology | https://hackenio.cc/sc_methodology→ |
Document
- Name
- Smart Contract Code Review and Security Analysis Report for Seedify.fund
- Audited By
- Turgay Arda Usman, Khrystyna Tkachuk
- Approved By
- Ataberk Yavuzer
- Changelog
- 16/07/2025 - Preliminary Report
- 29/07/2025 - Final Report
- Platform
- Ethereum, BNB, Avalanche
- Language
- Solidity
- Tags
- Launchpad, Vesting
- Methodology
- https://hackenio.cc/sc_methodology→
Review Scope | |
|---|---|
| Repository | https://github.com/Seedifyfund/seedify-era-contracts→ |
| Initial Commit | 7b054d9 |
| Final Commit | 1761ce3 |
Review Scope
- Initial Commit
- 7b054d9
- Final Commit
- 1761ce3
Audit Summary
The system users should acknowledge all the risks summed up in the risks section of the report
{FindingsVulnSeverityStatusTable}
Documentation quality
Functional requirements are provided.
Technical description is provided.
Code quality
The code mostly follows best practices and style guides:
For more information please advise informational findings
The development environment is configured.
Test coverage
Code coverage of the project is 38.52% (branch coverage).
Deployment and basic user interactions are covered with tests.
Negative cases coverage is missed.
Interactions by several users are not tested thoroughly.
System Overview
Seedify is a bonding curve system that has a decentralized token launch mechanism that implements a mathematical pricing curve for token sales. It has the following contracts:
BondingCurveFactory — a factory contract responsible for creating and managing bonding curve instances.
BondingCurveLibrary — contract implements an exponential bonding curve mechanism for token pricing and trading.
BondingCurve — the primary entry point that inherits from both readable and writable components.
BondingCurveTypes — contains all structs, enums, events, and errors used throughout the system.
BondingCurveStorage — implements diamond storage pattern for upgradeable contracts.
BondingCurveReadable —provides view functions for contract state queries.
BondingCurveWritable —handles all state-changing operations.
BondingCurveWritableRestricted —contains admin-only operations.
Privileged roles
The admin can initialize a contract with validation.
The admin can pause or unpause the system.
The admin can add liquidity to DEX upon completion.
The admin can withdraw LP tokens.
The admin can perform an emergency token withdrawal.
Potential Risks
The functioning of the system significantly relies on specific external contracts. Any flaws or vulnerabilities in these contracts adversely affect the audited project, potentially leading to security breaches or loss of funds.
The implemented liquidity addition logic highly depends on external contracts not covered by the audit. This reliance introduces risks if these external contracts are compromised or contain vulnerabilities, affecting the audited project's integrity.
The project iterates over large dynamic arrays, which leads to excessive gas costs, risking denial of service due to out-of-gas errors, directly impacting contract usability and reliability.
Findings
Code ― | Title | Status | Severity | |
|---|---|---|---|---|
| F-2025-1165 | Precision Loss in Bonding Curve Calculations | fixed | High | |
| F-2025-1161 | Users Can Perform New Tokens Purchase After autoRefund() Leading to Underflow in claim() | fixed | High | |
| F-2025-1176 | Inconsistent State Change in autoRefund() Affects TGE Unlock and Price Logic | fixed | Medium | |
| F-2025-1175 | Incorrect Fee Math Allows Users to Exceed Allocation | fixed | Medium | |
| F-2025-1174 | Incorrect Handling of reserveFee During dex() Execution | fixed | Medium | |
| F-2025-1173 | Incorrect Progressive-TGE Calculation Order Leads to Unintended Token Unlocks | fixed | Medium | |
| F-2025-1165 | Flawed Rounding Logic in calculateBuyAmount Leads to Loss of Funds | fixed | Medium | |
| F-2025-1174 | Incorrect Calculation Can Bypass Vesting Schedule | accepted | Low | |
| F-2025-1173 | Missing Validation on Critical Vesting Parameters | fixed | Low | |
| F-2025-1194 | Code Contains hardhat Import | fixed | Observation |
Appendix 1. Definitions
Severities
When auditing smart contracts, Hacken is using a risk-based approach that considers Likelihood, Impact, Exploitability and Complexity metrics to evaluate findings and score severities.
Reference on how risk scoring is done is available through the repository in our Github organization:
Severity | Description |
|---|---|
Critical | Critical vulnerabilities are usually straightforward to exploit and can lead to the loss of user funds or contract state manipulation. |
High | High vulnerabilities are usually harder to exploit, requiring specific conditions, or have a more limited scope, but can still lead to the loss of user funds or contract state manipulation. |
Medium | Medium vulnerabilities are usually limited to state manipulations and, in most cases, cannot lead to asset loss. Contradictions and requirements violations. Major deviations from best practices are also in this category. |
Low | Major deviations from best practices or major Gas inefficiency. These issues will not have a significant impact on code execution. |
Severity
- Critical
Description
- Critical vulnerabilities are usually straightforward to exploit and can lead to the loss of user funds or contract state manipulation.
Severity
- High
Description
- High vulnerabilities are usually harder to exploit, requiring specific conditions, or have a more limited scope, but can still lead to the loss of user funds or contract state manipulation.
Severity
- Medium
Description
- Medium vulnerabilities are usually limited to state manipulations and, in most cases, cannot lead to asset loss. Contradictions and requirements violations. Major deviations from best practices are also in this category.
Severity
- Low
Description
- Major deviations from best practices or major Gas inefficiency. These issues will not have a significant impact on code execution.
Potential Risks
The "Potential Risks" section identifies issues that are not direct security vulnerabilities but could still affect the project’s performance, reliability, or user trust. These risks arise from design choices, architectural decisions, or operational practices that, while not immediately exploitable, may lead to problems under certain conditions. Additionally, potential risks can impact the quality of the audit itself, as they may involve external factors or components beyond the scope of the audit, leading to incomplete assessments or oversight of key areas. This section aims to provide a broader perspective on factors that could affect the project's long-term security, functionality, and the comprehensiveness of the audit findings.
Appendix 2. Scope
The scope of the project includes the following smart contracts from the provided repository:
Scope Details | |
|---|---|
| Repository | https://github.com/Seedifyfund/seedify-era-contracts→ |
| Initial Commit | 7b054d9 |
| Final Commit | 1761ce3 |
| Whitepaper | N/A |
| Requirements | Provided as file |
| Technical Requirements | Provided as file |
Scope Details
- Initial Commit
- 7b054d9
- Final Commit
- 1761ce3
- Whitepaper
- N/A
- Requirements
- Provided as file
- Technical Requirements
- Provided as file
Assets in Scope
Appendix 3. Additional Valuables
Verification of System Invariants
During the audit of Seedify.fund, Hacken followed its methodology by performing fuzz-testing on the project's main functions. Foundry →, a tool used for fuzz-testing, was employed to check how the protocol behaves under various inputs. Due to the complex and dynamic interactions within the protocol, unexpected edge cases might arise. Therefore, it was important to use fuzz-testing to ensure that several system invariants hold true in all situations.
Fuzz-testing allows the input of many random data points into the system, helping to identify issues that regular testing might miss. A specific Echidna fuzzing suite was prepared for this task, and throughout the assessment, 10 invariants were tested over 100,000 runs. This thorough testing ensured that the system works correctly even with unexpected or unusual inputs.
Invariant | Test Result | Run Count |
|---|---|---|
totalProjectTokenSold cannot exceed tokenToSell | Passed | 10K+ |
amountClaimed cannot exceed amountToClaim | Passed | 10K+ |
raisedTokenAmount cannot exceed hardCap | Passed | 10K+ |
tgeAmount cannot exceed amountToClaim | Passed | 10K+ |
| Should claim initial claimable TGE amount on cliff period | Passed | 10K+ |
Should refund only if softCap not reached | Passed | 10K+ |
Should add liquidity when softCap is reached only if curve is end | Passed | 10K+ |
Should add liquidity once hardCap is reached | Passed | 10K+ |
Cost per token cannot exceed endingPrice | Passed | 10K+ |
| Should only create curves with unique names | Passed | 10K+ |
Invariant
totalProjectTokenSoldcannot exceedtokenToSellTest Result
- Passed
Run Count
- 10K+
Invariant
amountClaimedcannot exceedamountToClaimTest Result
- Passed
Run Count
- 10K+
Invariant
raisedTokenAmountcannot exceedhardCapTest Result
- Passed
Run Count
- 10K+
Invariant
tgeAmountcannot exceedamountToClaimTest Result
- Passed
Run Count
- 10K+
Invariant
- Should claim initial claimable TGE amount on cliff period
Test Result
- Passed
Run Count
- 10K+
Invariant
- Should refund only if
softCapnot reached Test Result
- Passed
Run Count
- 10K+
Invariant
- Should add liquidity when
softCapis reached only if curve is end Test Result
- Passed
Run Count
- 10K+
Invariant
- Should add liquidity once
hardCapis reached Test Result
- Passed
Run Count
- 10K+
Invariant
- Cost per token cannot exceed
endingPrice Test Result
- Passed
Run Count
- 10K+
Invariant
- Should only create curves with unique names
Test Result
- Passed
Run Count
- 10K+
Additional Recommendations
The smart contracts in the scope of this audit could benefit from the introduction of automatic emergency actions for critical activities, such as unauthorized operations like ownership changes or proxy upgrades, as well as unexpected fund manipulations, including large withdrawals or minting events. Adding such mechanisms would enable the protocol to react automatically to unusual activity, ensuring that the contract remains secure and functions as intended.
To improve functionality, these emergency actions could be designed to trigger under specific conditions, such as:
Detecting changes to ownership or critical permissions.
Monitoring large or unexpected transactions and minting events.
Pausing operations when irregularities are identified.
These enhancements would provide an added layer of security, making the contract more robust and better equipped to handle unexpected situations while maintaining smooth operations.