Is Stonx Safe? Smart Contract Security Analysis

Security Findings

1 High2 Med3 Info

High

Incomplete Source Code Provided for Audit

H-01The provided source code for the `DopplerERC20V1` contract is truncated. Critical functions related to the core vesting release logic (`_available`, `_releaseFor`, `_releaseAllFor`) and potentially the enforcement of the balance limit (`_beforeTokenTransfer` if overridden) are missing. This prevents a comprehensive security assessment of the contract's primary functionalities.

IssueThe provided source code for the `DopplerERC20V1` contract is truncated. Critical functions related to the core vesting release logic (`_available`, `_releaseFor`, `_releaseAllFor`) and potentially the enforcement of the balance limit (`_beforeTokenTransfer` if overridden) are missing. This prevents a comprehensive security assessment of the contract's primary functionalities.

FixProvide the complete and untruncated source code for all relevant contracts to enable a thorough security audit. Without the full code, the reliability of this audit is significantly limited, and undetected vulnerabilities may exist in the missing sections.

StatusUnresolved

Medium

Centralization Risk with Controller Role

M-01The `controller` role has the authority to call `disableBalanceLimit()`, which permanently deactivates the balance limit feature. While the `owner` role is managed by a multi-signature wallet (as per prefill data), the `controller` is a single address. This introduces a single point of failure and a centralization risk, as a compromise of this address could lead to an unauthorized disabling of a key economic control mechanism.

IssueThe `controller` role has the authority to call `disableBalanceLimit()`, which permanently deactivates the balance limit feature. While the `owner` role is managed by a multi-signature wallet (as per prefill data), the `controller` is a single address. This introduces a single point of failure and a centralization risk, as a compromise of this address could lead to an unauthorized disabling of a key economic control mechanism.

FixConsider implementing a multi-signature wallet or a time-locked mechanism for the `controller` role, especially for critical functions like `disableBalanceLimit()`. This would enhance the security and decentralization of the protocol by requiring multiple approvals or introducing a delay for sensitive operations.

StatusUnresolved

Medium

Potential Gas Limit Issues with Unbounded Array Iteration

M-02The `_scheduleIdsOf[beneficiary]` mapping stores an array of schedule IDs for each beneficiary. The `computeAvailableVestedAmount(address beneficiary)` function iterates over this array to sum up available vested amounts across all schedules. If a beneficiary accumulates a very large number of vesting schedules, this array could grow indefinitely, leading to increased gas costs for the `computeAvailableVestedAmount` function and potentially causing transaction failures or denial-of-service for that beneficiary due to block gas limits.

IssueThe `_scheduleIdsOf[beneficiary]` mapping stores an array of schedule IDs for each beneficiary. The `computeAvailableVestedAmount(address beneficiary)` function iterates over this array to sum up available vested amounts across all schedules. If a beneficiary accumulates a very large number of vesting schedules, this array could grow indefinitely, leading to increased gas costs for the `computeAvailableVestedAmount` function and potentially causing transaction failures or denial-of-service for that beneficiary due to block gas limits.

FixImplement a mechanism to limit the number of vesting schedules a single beneficiary can have, or consider paginating the `getScheduleIdsOf` function and requiring clients to sum amounts off-chain. Alternatively, optimize the `computeAvailableVestedAmount` function to avoid iterating over potentially large arrays on-chain, perhaps by storing a pre-calculated total available amount.

StatusUnresolved

Info

Vested Beneficiaries Excluded from Balance Limit

I-01During initialization and when allocating vesting, beneficiaries are automatically added to the `isExcludedFromBalanceLimit` mapping. This design choice means that any address receiving vested tokens will not be subject to the `maxBalanceLimit` or `balanceLimitEnd` restrictions, allowing them to transfer any amount of tokens regardless of the active balance limit.

IssueDuring initialization and when allocating vesting, beneficiaries are automatically added to the `isExcludedFromBalanceLimit` mapping. This design choice means that any address receiving vested tokens will not be subject to the `maxBalanceLimit` or `balanceLimitEnd` restrictions, allowing them to transfer any amount of tokens regardless of the active balance limit.

FixEnsure this behavior is an intentional design choice and is clearly documented. If the intention was for the balance limit to apply universally or under specific conditions for vested beneficiaries, the exclusion logic should be reviewed and adjusted.

StatusUnresolved

Info

Clarity on WAD Constant Usage for Percentage Calculations

I-02Constants like `MAX_PRE_MINT_PER_ADDRESS_WAD` and `MAX_TOTAL_PRE_MINT_WAD` are defined as `0.8 ether`. In the `initialize` function, these are used in calculations such as `initialSupply * CONSTANT / WAD`. Since `WAD` is typically `1 ether`, these calculations effectively represent 80% of the `initialSupply`. While mathematically correct, the use of `0.8 ether` as a constant name might be misinterpreted as an absolute value of 0.8 tokens rather than a percentage factor.

IssueConstants like `MAX_PRE_MINT_PER_ADDRESS_WAD` and `MAX_TOTAL_PRE_MINT_WAD` are defined as `0.8 ether`. In the `initialize` function, these are used in calculations such as `initialSupply * CONSTANT / WAD`. Since `WAD` is typically `1 ether`, these calculations effectively represent 80% of the `initialSupply`. While mathematically correct, the use of `0.8 ether` as a constant name might be misinterpreted as an absolute value of 0.8 tokens rather than a percentage factor.

FixConsider renaming the constants to reflect their percentage nature (e.g., `MAX_PRE_MINT_PERCENTAGE_WAD`) or adding comments to clarify that `0.8 ether` represents 80% when divided by `WAD` (1 ether). This improves code readability and reduces potential for misinterpretation.

StatusUnresolved

Info

Usage of LibTransient for Storage Optimization

I-03The contract utilizes `LibTransient` with `HAS_SCHEDULE_TRANSIENT_SLOT` to manage a boolean flag indicating if a schedule ID has been added to `_scheduleIdsOf` for a beneficiary. This is an advanced Solady pattern designed to optimize storage by using transient storage slots. While efficient, it's a less common pattern that might require specific understanding for future maintenance or audits.

IssueThe contract utilizes `LibTransient` with `HAS_SCHEDULE_TRANSIENT_SLOT` to manage a boolean flag indicating if a schedule ID has been added to `_scheduleIdsOf` for a beneficiary. This is an advanced Solady pattern designed to optimize storage by using transient storage slots. While efficient, it's a less common pattern that might require specific understanding for future maintenance or audits.

FixEnsure that the development team is fully aware of the implications and usage of `LibTransient` for state management. Document the rationale behind using this pattern and its expected behavior to facilitate future code reviews and maintenance.

StatusUnresolved

Category Ratings

TechnicalLow8/10

The DopplerERC20V1 contract leverages well-audited Solady libraries, contributing to a robust foundation and good code quality. It employs custom error types for clarity and gas efficiency. However, the provided source code was truncated, which prevented a comprehensive analysis of critical functions such as vesting release logic and balance limit enforcement (7.2 Code Security). A potential technical risk is the unbounded growth of the `_scheduleIdsOf` array, which stores vesting schedule IDs per beneficiary. Iterating this array in `computeAvailableVestedAmount` could lead to high gas costs and potential denial-of-service for beneficiaries with numerous schedules (7.2 Code Security).

GovernanceMedium5/10

The contract implements a dual-role access control system with an `owner` and a `controller`. While the `owner` (responsible for critical actions like pool locking/unlocking and upgrades) is noted to be a multi-signature address, the `controller` role, which has the power to disable the balance limit, is a single address, introducing a centralization risk (7.3 Access Control, 7.5 Governance). The vesting mechanism includes specific limits for pre-minted tokens per address and total pre-mint, calculated as a percentage of the initial supply, which is a clear economic design choice (7.4 Economic). Beneficiaries of vesting schedules are explicitly excluded from the balance limit, allowing them unrestricted token transfers (7.4 Economic).

UpgradesLow7/10

The DopplerERC20V1 contract is designed as an implementation for a proxy, utilizing Solady's `Initializable` pattern. This is a standard and secure approach for upgradeability, ensuring that the contract can be updated without redeploying the proxy address. The constructor correctly calls `_disableInitializers()` to prevent re-initialization on the implementation contract itself. The `initialize` function handles the initial setup, ensuring proper state configuration upon deployment through the proxy (7.7 Upgrades). Assuming the proxy's upgrade mechanism is managed by a robust governance process, such as a multi-signature wallet for the `owner` role, the upgrade path appears secure.

Security Checklist

3/5 checks passed

Contract VerifiedPass

Ownership RenouncedFail

No Mint FunctionPass

Liquidity LockedFail

Not a ProxyPass

HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

50.5% in top 10

9.5% in wallets40.9% in contracts

Effective Concentration25.9%

Share held by contracts — treasury, vesting, bridge or staking — is discounted against share held by wallets when the score is computed: a contract cannot decide to sell the way an anonymous holder can, though it can still be drained or voted to sell. Effective concentration is the figure the risk score is actually calculated from.

Liquidity Depth

$42.9K across 10 pairs

Uniswap v4USDCanalysed$36.7K Uniswap v4USDC$4.3K Uniswap v4USDC$1.4K Uniswap v4USDC$580 Uniswap v4WETH$19 Uniswap v4ETH$1

Show 4 more pairsShow less

Uniswap v4USDC$1 Uniswap v4ETH$1 Uniswap v4ETH$1 Uniswap v4USDC$0

The risk score reads depth across every pair. The volume figure and the volume-to-liquidity ratio elsewhere on this page describe only the pair this audit analysed, so the two are not directly comparable.

LP Distribution

Top-1 Unlocked Holder21.2%

Top-3 Unlocked58.5%

Key Addresses

11 addresses

Deployer

0x1842…97e9

Unlocked LP Held By

0x4c12…da0a0x5bdd…bc8e0xc119…1fcd0x5004…4d870x996d…ad770x5833…63f50x0567…fc670xe380…61070x487f…bbc00x78ed…c383

No privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.

What Raised This Score

7 factors

Ownership NOT renounced — owner is a contract (governance/executor, not an EOA)
Top-10 concentration > 20% (50.5% total → 25.9% effective; 9.5% in EOAs, 40.9% in contracts — mild)
Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
Liquidity < $50k ($42,925 across 10 pairs — thin market)
Token age < 30 days (still settling)
1 High finding(s) from audit
2 Medium finding(s) from audit

Each factor is an on-chain fact recorded at the time of this analysis. The score is computed from them by a deterministic function, so the same contract returns the same score for anyone who runs the audit. How scores are computed

Final Recommendation

AI Copilot

It is strongly recommended to conduct a full audit with the complete and untruncated source code, particularly focusing on the vesting release logic and balance limit enforcement, to ensure no critical vulnerabilities are present.…

Read the verdictHide

To mitigate potential gas cost issues, consider implementing a mechanism to paginate or limit the number of vesting schedules a single beneficiary can have, or optimize the `computeAvailableVestedAmount` function. Review the `controller` role's single-address nature and assess if a multi-signature or time-locked mechanism would be more appropriate for critical administrative functions like disabling the balance limit, enhancing the protocol's decentralization and security posture.

Contract

TypeProxy, Token

Audit History

1 audit on record

Sep 1449

Score changes are recorded as dated snapshots — history is append-only and cannot be edited.

Not Signed In

Is Stonx Safe?

Security Findings

Incomplete Source Code Provided for Audit

Centralization Risk with Controller Role

Potential Gas Limit Issues with Unbounded Array Iteration

Vested Beneficiaries Excluded from Balance Limit

Clarity on WAD Constant Usage for Percentage Calculations

Usage of LibTransient for Storage Optimization

Category Ratings

Security Checklist

Holder Composition

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Related Audits

Would You Like a More Detailed Audit of Stonx?