Is jesse Safe? Smart Contract Security Analysis

Security Findings

1 Crit1 Med1 Low2 Info

Critical

Architectural Misconfiguration: Upgradeable Pattern in Standalone Contract

C-01The `BaseCoin` contract, from which `CreatorCoin` inherits, utilizes OpenZeppelin's `Upgradeable` contracts (`ERC20PermitUpgradeable`, `ERC165Upgradeable`) and the `initializer` modifier in both its constructor and its `initialize` function. This pattern is exclusively designed for proxy-based upgradeable contracts (e.g., UUPS or Transparent proxies). However, the deployment context indicates `is_proxy: false`, meaning `CreatorCoin` is deployed as a standalone contract. When deployed directly, the contract's constructor runs once. The `initializer` modifier on the constructor will execute. Subsequently, the `initialize` function *must be called separately* to set up critical contract parame…

IssueThe `BaseCoin` contract, from which `CreatorCoin` inherits, utilizes OpenZeppelin's `Upgradeable` contracts (`ERC20PermitUpgradeable`, `ERC165Upgradeable`) and the `initializer` modifier in both its constructor and its `initialize` function. This pattern is exclusively designed for proxy-based upgradeable contracts (e.g., UUPS or Transparent proxies). However, the deployment context indicates `is_proxy: false`, meaning `CreatorCoin` is deployed as a standalone contract. When deployed directly, the contract's constructor runs once. The `initializer` modifier on the constructor will execute. Subsequently, the `initialize` function *must be called separately* to set up critical contract parame…

FixIf the contract is intended to be non-upgradeable, remove all `Upgradeable` base contracts and the `initializer` modifier. Move all initialization logic from the `initialize` function directly into the constructor. If the contract *is* intended to be upgradeable, it must be deployed behind a proxy contract (e.g., UUPS proxy), and the `is_proxy` flag in the deployment context should be `true`.

StatusUnresolved

Medium

Centralization Risk with MultiOwnable

M-01The `BaseCoin` contract uses the `MultiOwnable` pattern for critical administrative functions such as `setPayoutRecipient` and `setContractURI`. While `MultiOwnable` allows for multiple addresses to collectively control these functions, it still represents a centralized point of control. A compromise of a majority of the owner keys could lead to unauthorized changes to the contract's configuration, including redirecting the `payoutRecipient` to a malicious address, potentially impacting token distributions.

IssueThe `BaseCoin` contract uses the `MultiOwnable` pattern for critical administrative functions such as `setPayoutRecipient` and `setContractURI`. While `MultiOwnable` allows for multiple addresses to collectively control these functions, it still represents a centralized point of control. A compromise of a majority of the owner keys could lead to unauthorized changes to the contract's configuration, including redirecting the `payoutRecipient` to a malicious address, potentially impacting token distributions.

FixConsider implementing a timelock mechanism for critical administrative actions controlled by `MultiOwnable`. This would introduce a delay between the initiation and execution of sensitive changes, allowing for monitoring and potential intervention, thereby mitigating the immediate impact of a compromised owner key. Additionally, ensure robust key management practices for all owner addresses.

StatusUnresolved

Low

Lack of Event Emission for Critical Configuration Changes

L-01The `_setPayoutRecipient` and `_setContractURI` internal functions, which are called by external `onlyOwner` functions (`setPayoutRecipient`, `setContractURI`), do not emit events upon execution. While the `CreatorVestingClaimed` event is emitted for vesting claims, changes to core configuration parameters like the `payoutRecipient` or `contractURI` are not logged on-chain. This makes it challenging to monitor and audit changes to the contract's operational parameters, hindering transparency and off-chain analysis.

IssueThe `_setPayoutRecipient` and `_setContractURI` internal functions, which are called by external `onlyOwner` functions (`setPayoutRecipient`, `setContractURI`), do not emit events upon execution. While the `CreatorVestingClaimed` event is emitted for vesting claims, changes to core configuration parameters like the `payoutRecipient` or `contractURI` are not logged on-chain. This makes it challenging to monitor and audit changes to the contract's operational parameters, hindering transparency and off-chain analysis.

FixEmit specific events (e.g., `PayoutRecipientUpdated(address oldRecipient, address newRecipient)` and `ContractURIUpdated(string oldURI, string newURI)`) whenever critical configuration parameters are changed. This will provide a clear, immutable record of all administrative actions on-chain, improving transparency and auditability.

StatusUnresolved

Info

Reliance on Hardcoded Constants

I-01The `CreatorCoin` contract relies heavily on hardcoded constants defined in `CoinConstants.sol` for critical parameters such as `CREATOR_COIN_MARKET_SUPPLY`, `TOTAL_SUPPLY`, `CREATOR_VESTING_DURATION`, and `CREATOR_COIN_CURRENCY`. While using constants ensures immutability and predictability, it removes flexibility for future adjustments or parameter tuning without requiring a full contract redeployment.

IssueThe `CreatorCoin` contract relies heavily on hardcoded constants defined in `CoinConstants.sol` for critical parameters such as `CREATOR_COIN_MARKET_SUPPLY`, `TOTAL_SUPPLY`, `CREATOR_VESTING_DURATION`, and `CREATOR_COIN_CURRENCY`. While using constants ensures immutability and predictability, it removes flexibility for future adjustments or parameter tuning without requiring a full contract redeployment.

FixFor parameters that might require future adjustments (e.g., vesting duration, supply caps), consider making them configurable by an authorized entity (e.g., `MultiOwnable` or governance) through setter functions, rather than hardcoding them. This would allow for greater adaptability to changing market conditions or protocol needs. If immutability is the explicit design choice, document this decision clearly.

StatusUnresolved

Info

Potential for Vesting Dust Amounts Due to Integer Division

I-02The `_calculateVestedAmount` function uses integer division: `(CoinConstants.CREATOR_COIN_CREATOR_VESTING_SUPPLY * elapsedTime) / CoinConstants.CREATOR_VESTING_DURATION`. If `CREATOR_COIN_CREATOR_VESTING_SUPPLY` is not perfectly divisible by `CREATOR_VESTING_DURATION`, or if the `elapsedTime` does not perfectly align with a full vesting period, there might be a small remainder (dust) that is truncated during the division. This could result in a tiny amount of tokens being perpetually locked or the final claim being slightly less than expected.

IssueThe `_calculateVestedAmount` function uses integer division: `(CoinConstants.CREATOR_COIN_CREATOR_VESTING_SUPPLY * elapsedTime) / CoinConstants.CREATOR_VESTING_DURATION`. If `CREATOR_COIN_CREATOR_VESTING_SUPPLY` is not perfectly divisible by `CREATOR_VESTING_DURATION`, or if the `elapsedTime` does not perfectly align with a full vesting period, there might be a small remainder (dust) that is truncated during the division. This could result in a tiny amount of tokens being perpetually locked or the final claim being slightly less than expected.

FixWhile generally negligible for large token amounts, consider using a fixed-point math library or adjusting the calculation to ensure that any remaining dust is accounted for, especially in the final vesting period. For example, ensure the last claim explicitly transfers any remaining balance up to `CREATOR_COIN_CREATOR_VESTING_SUPPLY - totalClaimed` to prevent dust from being locked.

StatusUnresolved

Category Ratings

TechnicalLow7/10

The technical architecture of CreatorCoin, inheriting from BaseCoin, is generally well-structured, leveraging OpenZeppelin contracts for ERC20 and access control. The vesting logic in CreatorCoin is clearly implemented and appears mathematically sound, preventing over-claiming (7.2 Code Security). However, a critical architectural misconfiguration arises from using upgradeable contract patterns (e.g., `initializer` modifier) in a contract deployed as standalone, which can lead to an uninitialized state if the `initialize` function is not called post-deployment (7.1 Architecture). Furthermore, the `MultiOwnable` pattern, while allowing multiple owners, centralizes control over critical parameters like `payoutRecipient`, posing a centralization risk (7.3 Access Control).

GovernanceHigh1/10

The economic model for CreatorCoin incorporates a vesting schedule for creator supply, with `_calculateVestedAmount` and `getClaimableAmount` functions designed to prevent over-claiming, ensuring a predictable release of tokens (7.4 Economic). However, the `MultiOwnable` pattern, while providing multi-signature control, still represents a centralized point of failure for administrative actions such as setting the `payoutRecipient` (7.5 Governance). The use of hardcoded constants for critical parameters like total supply and vesting duration limits the protocol's flexibility for future adjustments without requiring a full redeployment (7.4 Economic).

UpgradesHigh1/10

The `CreatorCoin` and `BaseCoin` contracts incorporate OpenZeppelin's `Upgradeable` components and the `initializer` modifier, which are standard for proxy-based upgradeable systems. However, the contract is deployed as a standalone implementation, as indicated by `is_proxy: false` (7.7 Upgrades). This architectural misconfiguration means the contract is not upgradeable, rendering the `Upgradeable` base contracts redundant and potentially misleading. More critically, it necessitates a two-step initialization process (constructor then `initialize` function call) that is susceptible to operator error, potentially leaving the contract in an uninitialized and vulnerable state if `initialize` is not called post-deployment (7.7 Upgrades).

Security Checklist

2/5 checks passed

Contract VerifiedPass

Ownership Renounced?

No Mint FunctionPass

Liquidity LockedFail

Not a ProxyFail

HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Proxy Upgrade Controls

Proxy TypeEtherscan Detected Custom

ImplementationVerified source

Upgrades (30d)0 · stable

Holder Composition

77.4% in top 10

5.4% in wallets72.0% in contracts

Effective Concentration34.2%

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

$563.2K across 20 pairs

Uniswap v4ZORAanalysed$553.9K AerodromeWETH$7.1K Uniswap v3WETH$859 AerodromeHERO$404 Uniswap v4ETH$375 Leetswap V2WETH$347

Show 4 more pairsShow less

Uniswap v4USDC$77 Uniswap v4USDC$31 Hydrex CLAMMWETH$15 0xB0C2…9C88BG$12

The 10 remaining pairs hold $32 between them and are not listed.

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 Holder98.8%

Top-3 Unlocked100.0%

Key Addresses

4 addresses

Deployer

0x8d47…b123

Unlocked LP Held By

0x5ca2…d75f0x531c…e46c0x6313…1a60

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

What Raised This Score

10 factors

Ownership status UNKNOWN (owner could not be resolved)
Proxy contract (upgradeable — admin can replace logic)
Non-standard proxy storage (Etherscan-confirmed)
Top-10 concentration > 30% (77.4% total → 34.2% effective; 5.4% in EOAs, 72.0% in contracts — moderate)
Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
LP top1 unlocked holder = 98.8% (independent LP — depth risk, pool = 98% of DEX liquidity)
LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 98% of DEX liquidity)
1 Critical finding(s) from audit
1 Medium finding(s) from audit
1 Low 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 critical to resolve the architectural misconfiguration regarding the use of upgradeable patterns in a standalone contract.…

Read the verdictHide

Either refactor the contract to remove all upgradeable components and move initialization logic to the constructor, or deploy it correctly behind a proxy contract if upgradeability is intended. Implement event emissions for all critical configuration changes to enhance transparency and auditability. Consider implementing a timelock for administrative actions controlled by `MultiOwnable` to mitigate centralization risks and provide a window for community review.

Contract

TypeStaking, Router, Token

Audit History

1 audit on record

Aug 3172Sep 463

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

Is jesse Safe?

Security Findings

Architectural Misconfiguration: Upgradeable Pattern in Standalone Contract

Centralization Risk with MultiOwnable

Lack of Event Emission for Critical Configuration Changes

Reliance on Hardcoded Constants

Potential for Vesting Dust Amounts Due to Integer Division

Category Ratings

Security Checklist

Proxy Upgrade Controls

Holder Composition

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Related Audits

Would You Like a More Detailed Audit of jesse?