Quantum Audit Logo
Launch App

On-chain security analysis — is it a scam or legit?

Is jesse Safe?

JESSEBase
Not verified This record has not gone through deep verification and is not being monitored. The score is a dated snapshot — the token’s risk can change at any time.Own this token? Put it under verification →
Last checked Sep 4, 2026 · 1 audit on record
Chart
Medium RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical7/10Governance1/10Upgrades1/10Checks passed4 of 7Findings1 Critical · 1 Medium · 1 Low · 2 Info5
SummaryAI Copilot

The audit of the CreatorCoin and BaseCoin contracts identified a critical architectural misconfiguration related to the use of upgradeable patterns in a standalone deployment, which could lead to an uninitialized or exploitable state if not handled correctly.

Read the full analysis
What raised the score
  • Ownership status UNKNOWN
  • Proxy contract
  • Non-standard proxy storage
  • Top-10 concentration > 30%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 98.8%
  • LP top3 unlocked holders = 100.0%
  • 1 Critical finding(s) from audit
  • 1 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact 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

Security Checklist

as of audit · Sep 44 of 7 checks passed
Contract verifiedVerified
OwnershipUnknown
MintNo mint
Liquidity lockNot locked
UpgradeabilityUpgradeable
HoneypotNone found
Buy / sell tax0% / 0%

Holders

as of audit · Sep 4, 2026
72.0%Contracts5.4%22.6%Everyone else
72.0%Contracts5.4%22.6%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
77.4%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking72.0%
  • Walletsanonymous holders, free to sell5.4%
  • Everyone elsethe rest of the supply22.6%
Effective concentrationwhat the score reads34.2%
How holder types affect the score

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.

Holder balances as recorded by the audit of Sep 4, 2026

Liquidity

as of audit · Sep 4$563.2K across 20 pairs
Show 4 more pairs

The 10 remaining pairs hold $32 between them and are not listed. The risk score reads depth across every pair.

LP tokensNot locked

The LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.

Analysed pool$553.9KShare of depth98.4%
Top-1 Unlocked Holder98.8%
Top-3 Unlocked100.0%
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.

Security Findings

1 Critical1 Medium1 Low2 Info
Critical

Architectural Misconfiguration: Upgradeable Pattern in Standalone Contract

The 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…C-01

Issue

The 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…

Fix

If 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.

Status

Unresolved

Medium

Centralization Risk with MultiOwnable

The 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.M-01

Issue

The 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.

Fix

Consider 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.

Status

Unresolved

Low

Lack of Event Emission for Critical Configuration Changes

The _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.L-01

Issue

The _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.

Fix

Emit 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.

Status

Unresolved

Info

Reliance on Hardcoded Constants

The 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.I-01

Issue

The 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.

Fix

For 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.

Status

Unresolved

Info

Potential for Vesting Dust Amounts Due to Integer Division

The _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.I-02

Issue

The _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.

Fix

While 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.

Status

Unresolved

Analysis

AI Copilotas of audit · Sep 4
Executive SummaryWhat the contract is and what the review found

The audit of the CreatorCoin and BaseCoin contracts identified a critical architectural misconfiguration related to the use of upgradeable patterns in a standalone deployment, which could lead to an uninitialized or exploitable state if not handled correctly. Additionally, the system exhibits centralization risks through its MultiOwnable pattern and lacks event emissions for key configuration changes. The vesting mechanism appears robust, and the code quality is generally high, leveraging OpenZeppelin standards. Addressing the critical architectural issue is paramount for the secure operation of the protocol.

Technical7/10Low risk

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).

Governance1/10High risk

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).

Upgrades1/10High risk

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).

Final RecommendationWhat to do about this score

It is critical to resolve the architectural misconfiguration regarding the use of upgradeable patterns in a standalone contract.

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 & Record

1 audit on record
TypeStaking, Router, Token
NetworkBase
Token age9mo
Contract0x50f8…0d59
Deployer0x8d47…b123
Proxy Upgrade Controls
Proxy TypeEtherscan Detected Custom
ImplementationVerified source
Upgrades (30d)0 · stable
Badge for your website
jesse security record badge

Free for any token on the record. It links to this page and always shows the current score and the date it was checked.

Audit History
  1. Sep 4, 202663Medium
  2. Aug 31, 202672High

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

Frequently Asked Questions

What is the JESSE contract address?

The jesse contract on Base is 0x50f88fe97f72cd3e75b9eb4f747f59bceba80d59. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.

Is jesse a scam?

Quantum Audit's risk score for jesse is 63/100 (Medium risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Mint: No mint; Liquidity lock: Not locked; Upgradeability: Upgradeable; Honeypot: None found; Buy / sell tax: 0% / 0%. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.

Is JESSE liquidity locked?

Liquidity lock: Not locked (as of Sep 4, 2026). Total DEX liquidity: $563.2K.

Who holds JESSE?

As of Sep 4, 2026, the 10 largest holders own 77.4% of the supply. The Holders section on this page shows who they are by holder type.

Related Audits

6 more on the recordAll audits
VelvetBase63MediumDiemBase63MediumRipe DAO Governance TokenRIPE · Base63MediumUmiaBase63MediumLiskLSK · Base63MediumLotto CoinLOTTO · Base63Medium

Would You Like a More Detailed Audit of jesse?

Our AI-powered scanner gives you a deeper, real-time smart contract analysis — free, with every scoring factor shown.

Get Detailed Audit Is this your token? Publish your own audit on this page