Quantum Audit Logo

Is Gensyn Safe?

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

Is this your token? Publish your own audit on this page →

Gensyn AI
0x4d70…8d48
Ethereum Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Critical Risk
Executive SummaryAI Copilot

This audit focuses on an ERC1967Proxy contract, which is a standard UUPS proxy implementation from OpenZeppelin. While the proxy contract itself is well-audited and robust, the associated implementation contract (0x81cfa8f011a137ec93039694eeea40d4c5b56cbe) is not source-verified. This lack of transparency for the underlying logic introduces significant technical, governance, and upgradeability risks, as the actual behavior and security of the system cannot be fully assessed.

1 High1 Medium1 Low2 Informational
Volume 24h
$16.6K
Liquidity
$252.0K
Price
$0.01944
Token Age
1mo
Top 10 Holders
84.8%

Security Findings

1 High1 Med1 Low2 Info
High

Unverified Implementation Contract

H-01The proxy contract (0x4d70…8d48) delegates all calls to an implementation contract (0x81cf…6cbe) for which the source code is not publicly verified. This makes it impossible to audit the actual business logic, security, and behavior of the system, introducing an opaque trust assumption. Any vulnerabilities in the unverified implementation could directly impact the funds or functionality controlled by the proxy.
IssueThe proxy contract () delegates all calls to an implementation contract () for which the source code is not publicly verified. This makes it impossible to audit the actual business logic, security, and behavior of the system, introducing an opaque trust assumption. Any vulnerabilities in the unverified implementation could directly impact the funds or functionality controlled by the proxy.
FixImmediately verify and publish the source code for the implementation contract () on block explorers. Conduct a thorough security audit of the implementation contract to identify and mitigate any potential vulnerabilities.
StatusUnresolved
Medium

Reliance on Unverified Implementation for Upgrade Authorization

M-01As a UUPS proxy, the authorization logic for upgrades resides within the implementation contract. Since the implementation contract's source code is unverified, the mechanism by which upgrades are authorized and executed is unknown. This could lead to unauthorized upgrades if the implementation's `_authorizeUpgrade` function is missing, flawed, or controlled by a single, unsecure entity, potentially allowing a malicious actor to deploy arbitrary code.
IssueAs a UUPS proxy, the authorization logic for upgrades resides within the implementation contract. Since the implementation contract's source code is unverified, the mechanism by which upgrades are authorized and executed is unknown. This could lead to unauthorized upgrades if the implementation's `_authorizeUpgrade` function is missing, flawed, or controlled by a single, unsecure entity, potentially allowing a malicious actor to deploy arbitrary code.
FixEnsure the implementation contract implements a secure and robust `_authorizeUpgrade` function. This function should enforce strict access control, ideally requiring a multi-signature wallet and/or a timelock for upgrade approvals. Once implemented, verify the source code and audit this logic.
StatusUnresolved
Low

Payable Constructor with Potential for Stuck Funds

L-01The `ERC1967Proxy` constructor is `payable`. While `ERC1967Utils.upgradeToAndCall` includes a check (`_checkNonPayable()`) to revert if `msg.value > 0` when `data` is empty, if `data` is provided and `msg.value > 0`, the funds are delegated to the implementation. If the implementation's constructor or initialization function does not explicitly handle or consume `msg.value`, these funds could become permanently stuck in the proxy contract.
IssueThe `ERC1967Proxy` constructor is `payable`. While `ERC1967Utils.upgradeToAndCall` includes a check (`_checkNonPayable()`) to revert if `msg.value > 0` when `data` is empty, if `data` is provided and `msg.value > 0`, the funds are delegated to the implementation. If the implementation's constructor or initialization function does not explicitly handle or consume `msg.value`, these funds could become permanently stuck in the proxy contract.
FixEnsure that any initialization logic called via `data` in the constructor of the implementation contract explicitly handles or consumes any `msg.value` sent. Alternatively, avoid sending `msg.value` to the proxy constructor unless it is explicitly required and consumed by the implementation's initialization.
StatusUnresolved
Info

Use of Standard OpenZeppelin UUPS Proxy

I-01The contract utilizes the ERC1967Proxy from OpenZeppelin, implementing the UUPS (Universal Upgradeable Proxy Standard) pattern. This is a widely adopted and well-audited proxy standard, providing a secure and flexible mechanism for contract upgradeability while maintaining a consistent address.
IssueThe contract utilizes the ERC1967Proxy from OpenZeppelin, implementing the UUPS (Universal Upgradeable Proxy Standard) pattern. This is a widely adopted and well-audited proxy standard, providing a secure and flexible mechanism for contract upgradeability while maintaining a consistent address.
FixNo specific recommendation, as this is a best practice. Continue to leverage well-vetted libraries like OpenZeppelin for core infrastructure components.
StatusResolved
Info

Solidity Compiler Version Compatibility

I-02The provided source code uses `pragma solidity ^0.8.22;` while the prefill data indicates a compiler version of `0.8.30`. This is compatible as `^0.8.22` allows compilation with any version from `0.8.22` up to (but not including) `0.9.0`. Using a specific, fixed compiler version (e.g., `pragma solidity 0.8.30;`) can help ensure deterministic bytecode generation and avoid potential issues with future compiler versions.
IssueThe provided source code uses `pragma solidity ^0.8.22;` while the prefill data indicates a compiler version of `0.8.30`. This is compatible as `^0.8.22` allows compilation with any version from `0.8.22` up to (but not including) `0.9.0`. Using a specific, fixed compiler version (e.g., `pragma solidity 0.8.30;`) can help ensure deterministic bytecode generation and avoid potential issues with future compiler versions.
FixConsider pinning the Solidity compiler version to the exact version used for deployment (e.g., `pragma solidity 0.8.30;`) to ensure consistent compilation results across different environments and prevent unexpected behavior from future compiler updates.
StatusUnresolved

Category Ratings

TechnicalMedium4/10

The provided contract is a standard OpenZeppelin ERC1967Proxy, which is a battle-tested and secure proxy pattern (7.1 Architecture, 7.2 Code Security). It correctly implements delegatecall logic and storage slot separation for implementation and admin addresses, preventing storage collisions. However, the primary technical risk stems from the unverified implementation contract (), which means the actual business logic and its security cannot be assessed (7.6 External). This lack of visibility makes it impossible to verify the absence of common vulnerabilities like reentrancy or access control flaws in the delegated logic.

GovernanceHigh1/10

The UUPS proxy pattern delegates upgrade authorization to the implementation contract, meaning the governance and economic control over upgrades reside within the unverified implementation (7.5 Governance). Without source code for the implementation, it is impossible to determine who can initiate upgrades, if there are any timelocks, or if there are any multisig requirements. This introduces a high governance risk, as an attacker or malicious actor could potentially upgrade the contract to arbitrary malicious code if the implementation's upgrade logic is flawed or compromised (7.4 Economic).

UpgradesHigh1/10

The contract utilizes the UUPS (ERC-1967) proxy pattern, which is a robust and widely adopted upgrade mechanism (7.7 Upgrades). The proxy itself correctly handles the upgradeToAndCall logic. However, the security of the upgrade process is entirely dependent on the implementation contract's `_authorizeUpgrade` function, which is responsible for enforcing upgrade permissions. Since the implementation contract is not source-verified, the integrity and security of this critical upgrade authorization logic are unknown, posing a significant risk of unauthorized or malicious upgrades.

Security Checklist

1/5 checks passed
Contract VerifiedPass
Ownership Renounced?
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyFail

Proxy Upgrade Controls

Proxy TypeEip1967 Uups
ImplementationVerified source
Upgrades (30d)0 · stable

Holder Composition

84.8% in top 10
77.0% in wallets7.8% in contracts
Effective Concentration80.1%

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

$280.2K across 2 pairs
Uniswap v3USDCanalysed$252.0K89.9%Uniswap v4ETH$28.2K10.1%

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 Holder100.0%
Top-3 Unlocked100.0%

Key Addresses

2 addresses
Deployer
0x712c…ab92
Unlocked LP Held By
0xfc15…ad1e

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)
  • Mintable supply — no cap found, dilution unbounded
  • Proxy contract (upgradeable — admin can replace logic)
  • Top-10 concentration > 70% (84.8% total → 80.1% effective; 77.0% in EOAs, 7.8% in contracts — extreme)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 100.0% (independent LP — depth risk, pool = 90% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 90% of DEX liquidity)
  • 1 High 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

Related Audits

6 more on the record
Eden Token (EDEN)Critical RiskZK Coin (ZKC)Critical RiskCOTICritical Riskdmt-natCritical RiskAllora (ALLO)Critical RiskRe Protocol reUSD (REUSD)Critical Risk

Would You Like a More Detailed Audit of Gensyn?

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

Get Detailed Audit