Q1 2025 Web3 Security ReportAccess control failures led to $1.63 billion in losses
Discover report insights
  • Hacken
  • Audits
  • seedify-fund
  • [SCA] Seedify Fund / IDO & Linear Vesting / Apr2025
Seedify.fund logo

Seedify.fund

Audit name:

[SCA] Seedify Fund / IDO & Linear Vesting / Apr2025

Date:

Apr 14, 2025

Table of Content

→Introduction
→Audit Summary
→System Overview
→Potential Risks
→Findings
→Appendix 1. Definitions
→Appendix 2. Scope
→Appendix 3. Additional Valuables
→Disclaimer

Want a comprehensive audit report like this?

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 funds is a modular Initial DEX Offering (IDO) system integrated with a linear vesting mechanism to securely manage token sales, investor contributions, refunds, and post-sale token claims.

Document

NameSmart Contract Code Review and Security Analysis Report for Seedify.fund
Audited ByKaan Caglan
Approved ByAtaberk Yavuzer
Websitehttps://launchpad.seedify.fund/→
Changelog14/04/2025 - Preliminary Report
15/04/2025 - Final Report
PlatformEVM
LanguageSolidity
TagsDEX, Vesting, ERC20
Methodologyhttps://hackenio.cc/sc_methodology→

Review Scope

Repositoryhttps://github.com/Seedifyfund/seedify-era-contracts→
Zip File SHA1 Hash6106c5e3becf5285a51e44dda44dd42aaa32c6d8
Retesthttps://github.com/Seedifyfund/seedify-era-contracts→
Zip File SHA1 Hashecbb58778b74ce8ca607972c1dc85b2fada64c0e

Audit Summary

10Total Findings
6Resolved
0Accepted
4Mitigated

The system users should acknowledge all the risks summed up in the risks section of the report

Documentation quality

  • Functional requirements are partially missed

  • Technical description is not provided

  • Insufficient NatSpec

Code quality

  • Missing some of the best practices

  • The development environment is configured

Test coverage

The code coverage of the project is 100% (branch coverage)

  • Deployment and basic user interactions are covered with tests.

System Overview

Seedify Fund is a modular Initial DEX Offering (IDO) system integrated with a linear vesting mechanism to securely manage token sales, investor contributions, refunds, and post-sale token claims.

IDOWritable Abstract

Handles the user-facing logic for participating in the token sale.

  • Key Functionality:

    • buyTokens: Allows eligible users to invest in the IDO using a signed message.

    • Signature-based whitelisting using UserSignatureData.

    • Uses safe ERC20 transfers for collecting funds.

    • Validates contribution limits and tracks investment data.

IDOWritableRestricted Abstract

Provides administrative and security-restricted functions around the IDO process.

  • Key Functionality:

    • initialize: Sets up the sale, initializes roles, and EIP712 for typed data signatures.

    • withdrawFunds: Allows privileged withdrawals.

    • autoRefund: Enables refunding users under certain conditions.

    • setValidatorAddress, setUserSignatureHash: Manage signature validation parameters.

IDOReadable

Exposes view-only data for frontend or external contract use.

  • Key Functionality:

    • getSetUp: Returns setup configuration.

    • totalRaised: Total amount raised.

    • getUserDetails: Returns user-specific investment data.

    • getUserRefundEligibility: Checks if a user can be refunded.

LinearVestingWritableRestricted

Admin-facing logic for managing vesting schedules and token allocations.

  • Key Functionality:

    • initialize: Sets up the vesting contract with a token and ID.

    • update: Updates Merkle root and vesting schedule (TGE, cliff, end).

    • setRefundPeriod: Defines when refunds can occur.

    • withdrawFunds, addVestedTokens: Token management functions.

LinearVestingReadable

View-layer for the LinearVesting system.

  • Key Functionality:

    • Provides access to vesting timeline (startTime, cliff, endTime).

    • Tracks total vested and claimed tokens.

    • Exposes Merkle root and user claim data.

    • Returns the address of the vested token and vestingId.

LinearVestingWritableRestricted

Admin-facing logic for managing vesting schedules and token allocations.

  • Key Functionality:

    • initialize: Sets up the vesting contract with the token to be vested and a unique vesting ID.

    • update: Updates Merkle root and vesting schedule parameters including TGE percent, start time, cliff, end time, and optionally transfers tokens for vesting.

    • setRefundPeriod: Sets a specific time window during which refunds can be requested by users.

    • withdrawFunds: Allows privileged roles to withdraw tokens from the vesting contract.

    • addVestedTokens: Adds additional tokens to the vesting pool for future claims.

TOKEN ATTRIBUTES

IDO Payment Token (from SetUp.paymentToken)

  • Token used by investors to contribute.

  • ERC20-compliant (upgradeable).

  • Transferred into the IDO contract upon contribution.

Vested Token (from LinearVestingTypes.SetUp.vestedToken)

  • Token distributed post-IDO through vesting.

  • Released based on parameters like startTime, cliff, endTime, and tgePercent.

PRIVILEGED ROLES

DEFAULT_ADMIN_ROLE

  • Can pause/unpause IDO.

  • Sets validator address and signature hash.

  • Executes autoRefund.

DEFAULT_WITHDRAW_ROLE

  • Can withdraw contributed funds from the IDO.

LinearVesting: DEFAULT_WITHDRAW_ROLE

  • Can withdraw excess/remaining tokens from vesting contract.

Potential Risks

Single Points of Failure and Control: The project is fully or partially centralized, introducing single points of failure and control. This centralization can lead to vulnerabilities in decision-making and operational processes, making the system more susceptible to targeted attacks or manipulation.

Administrative Key Control Risks: The digital contract architecture relies on administrative keys for critical operations. Centralized control over these keys presents a significant security risk, as compromise or misuse can lead to unauthorized actions or loss of funds.

External Merkle Tree Dependency: The vesting contract relies on an off-chain generated Merkle root for allocation validation. Any issue with Merkle tree generation, distribution, or synchronization could result in eligible users being unable to claim tokens or unauthorized claims being processed.

Scope Definition and Security Guarantees: The audit does not cover all code in the repository. Contracts outside the audit scope may introduce vulnerabilities, potentially impacting the overall security due to the interconnected nature of smart contracts.

Flexibility and Risk in Contract Upgrades: The project's contracts are upgradable, allowing the administrator to update the contract logic at any time. While this provides flexibility in addressing issues and evolving the project, it also introduces risks if upgrade processes are not properly managed or secured, potentially allowing for unauthorized changes that could compromise the project's integrity and security.

Findings

Code
―
Title
Status
Severity
F-2025-9650Users Can Be Blocked From Refunds on Multiple Contributions
mitigated

Medium
F-2025-9647Malicious Owner Can Drain Contract Funds, Blocking User Claims
mitigated

Medium
F-2025-9649refundStart Can Be Set After refundEnd
fixed

Low
F-2025-9648Owner Can Arbitrarily Modify Vesting Terms and Impact User Balances
mitigated

Low
F-2025-9761Incorrect Dev Documentation in _autoRefund Function
fixed

Observation
F-2025-9654Unused Error Definition
fixed

Observation
F-2025-9653Unused struct
fixed

Observation
F-2025-9652Unused State Variables
fixed

Observation
F-2025-9651Non Disabled Implementation Contract
mitigated

Observation
F-2025-9650Events Declared But Not Used
fixed

Observation
1-10 of 10 findings

Identify vulnerabilities in your smart contracts.

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

Repositoryhttps://github.com/Seedifyfund/seedify-era-contracts→
Zip File SHA1 Hash6106c5e3becf5285a51e44dda44dd42aaa32c6d8
Retesthttps://github.com/Seedifyfund/seedify-era-contracts→
Zip File SHA1 Hashecbb58778b74ce8ca607972c1dc85b2fada64c0e
WhitepaperN/A
RequirementsN/A
Technical RequirementsN/A

ScopeAssetsList

Type

./contracts/linearvesting/LinearVestingStruct.solSmart Contract
./contracts/linearvesting/LinearVestingTypes.solSmart Contract
./contracts/linearvesting/LinearVesting.solSmart Contract
./contracts/linearvesting/LinearVestingStorage.solSmart Contract
./contracts/linearvesting/readable/LinearVestingReadable.solSmart Contract
./contracts/linearvesting/writable/LinearVestingWritable.solSmart Contract
./contracts/linearvesting/writable/restricted/LinearVestingWritableRestricted.solSmart Contract
./contracts/ido/IDOTypes.solSmart Contract
./contracts/ido/IDOStorage.solSmart Contract
./contracts/ido/IDO.solSmart Contract
./contracts/ido/readable/IDOReadable.solSmart Contract
./contracts/ido/writable/IDOWritable.solSmart Contract
./contracts/ido/writable/restricted/IDOWritableRestricted.solSmart Contract
./contracts/factory/LinearVestingFactory.solSmart Contract
./contracts/factory/IDOFactory.solSmart Contract

  • ScopeAssetsList

    ./contracts/linearvesting/LinearVestingStruct.sol

    Type

    Smart Contract

    ScopeAssetsList

    ./contracts/linearvesting/LinearVestingTypes.sol

    Type

    Smart Contract

    ScopeAssetsList

    ./contracts/linearvesting/LinearVesting.sol

    Type

    Smart Contract

    ScopeAssetsList

    ./contracts/linearvesting/LinearVestingStorage.sol

    Type

    Smart Contract

    ScopeAssetsList

    ./contracts/linearvesting/readable/LinearVestingReadable.sol

    Type

    Smart Contract

    ScopeAssetsList

    ./contracts/linearvesting/writable/LinearVestingWritable.sol

    Type

    Smart Contract

    ScopeAssetsList

    ./contracts/linearvesting/writable/restricted/LinearVestingWritableRestricted.sol

    Type

    Smart Contract

    ScopeAssetsList

    ./contracts/ido/IDOTypes.sol

    Type

    Smart Contract

    ScopeAssetsList

    ./contracts/ido/IDOStorage.sol

    Type

    Smart Contract

    ScopeAssetsList

    ./contracts/ido/IDO.sol

    Type

    Smart Contract

    ScopeAssetsList

    ./contracts/ido/readable/IDOReadable.sol

    Type

    Smart Contract

    ScopeAssetsList

    ./contracts/ido/writable/IDOWritable.sol

    Type

    Smart Contract

    ScopeAssetsList

    ./contracts/ido/writable/restricted/IDOWritableRestricted.sol

    Type

    Smart Contract

    ScopeAssetsList

    ./contracts/factory/LinearVestingFactory.sol

    Type

    Smart Contract

    ScopeAssetsList

    ./contracts/factory/IDOFactory.sol

    Type

    Smart Contract

Assets in Scope

contracts
factory
IDOFactory.sol - contracts/factory/IDOFactory.sol
LinearVestingFactory.sol - contracts/factory/LinearVestingFactory.sol
ido
IDO.sol - contracts/ido/IDO.sol
IDOStorage.sol - contracts/ido/IDOStorage.sol
IDOTypes.sol - contracts/ido/IDOTypes.sol
readable
IDOReadable.sol - contracts/ido/readable/IDOReadable.sol
IIDOReadable.sol - contracts/ido/readable/IIDOReadable.sol
writable
IDOWritable.sol - contracts/ido/writable/IDOWritable.sol
IIDOWritable.sol - contracts/ido/writable/IIDOWritable.sol
restricted
IDOWritableRestricted.sol - contracts/ido/writable/restricted/IDOWritableRestricted.sol
IIDOWritableRestricted.sol - contracts/ido/writable/restricted/IIDOWritableRestricted.sol
linearvesting
LinearVesting.sol - contracts/linearvesting/LinearVesting.sol
LinearVestingStorage.sol - contracts/linearvesting/LinearVestingStorage.sol
LinearVestingStruct.sol - contracts/linearvesting/LinearVestingStruct.sol
LinearVestingTypes.sol - contracts/linearvesting/LinearVestingTypes.sol

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. Echidna →, 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, 4 invariants were tested over 5,000,000 runs. This thorough testing ensured that the system works correctly even with unexpected or unusual inputs.

Invariant

Test Result

Run Count

echidnavestedvs_claimedPassed1M+
echidnaclaimedle_allocationPassed1M+
echidna_totalRaisedPassed1M+
echidna_maxContributionPassed1M+

  • Invariant

    echidnavestedvs_claimed

    Test Result

    Passed

    Run Count

    1M+

    Invariant

    echidnaclaimedle_allocation

    Test Result

    Passed

    Run Count

    1M+

    Invariant

    echidna_totalRaised

    Test Result

    Passed

    Run Count

    1M+

    Invariant

    echidna_maxContribution

    Test Result

    Passed

    Run Count

    1M+

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.

Disclaimer