Quantum Audit Logo
Launch App

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

Is Gensyn Safe?

AIEthereum
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
Critical RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical4/10Governance1/10Upgrades1/10Checks passed1 of 5Findings1 High · 1 Medium · 1 Low · 2 Info5
SummaryAI Copilot

This audit focuses on an ERC1967Proxy contract, which is a standard UUPS proxy implementation from OpenZeppelin.

Read the full analysis
What raised the score
  • Ownership status UNKNOWN
  • Mintable supply — no cap found, dilution unbounded
  • Proxy contract
  • Top-10 concentration > 70%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 100.0%
  • LP top3 unlocked holders = 100.0%
  • 1 High 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)
  • 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

Security Checklist

as of audit · Sep 41 of 5 checks passed
Contract verifiedVerified
OwnershipUnknown
MintMintable
Liquidity lockNot locked
UpgradeabilityUpgradeable

Holders

as of audit · Sep 4, 2026
7.8%77.0%Wallets15.2%Everyone else
7.8%77.0%Wallets15.2%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
84.8%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking7.8%
  • Walletsanonymous holders, free to sell77.0%
  • Everyone elsethe rest of the supply15.2%
Effective concentrationwhat the score reads80.1%
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$280.2K across 2 pairs

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$252.0KShare of depth89.9%
Top-1 Unlocked Holder100.0%
Top-3 Unlocked100.0%
Unlocked LP held by
0xfc15…ad1e

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

Security Findings

1 High1 Medium1 Low2 Info
High

Unverified Implementation Contract

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

Issue

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

Fix

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

Status

Unresolved

Medium

Reliance on Unverified Implementation for Upgrade Authorization

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

Issue

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

Fix

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

Status

Unresolved

Low

Payable Constructor with Potential for Stuck Funds

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

Issue

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

Fix

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

Status

Unresolved

Info

Use of Standard OpenZeppelin UUPS Proxy

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

Issue

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

Fix

No specific recommendation, as this is a best practice. Continue to leverage well-vetted libraries like OpenZeppelin for core infrastructure components.

Status

Resolved

Info

Solidity Compiler Version Compatibility

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

Issue

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

Fix

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

Status

Unresolved

Analysis

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

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.

Technical4/10Medium risk

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.

Governance1/10High risk

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

Upgrades1/10High risk

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.

Final RecommendationWhat to do about this score

The most critical recommendation is to immediately verify the source code of the implementation contract ().

A comprehensive audit of the implementation contract is essential to understand its functionality, identify potential vulnerabilities, and ensure the integrity of the upgrade mechanism. Implement robust access control for upgrade functions within the implementation, ideally using a multi-signature wallet and a timelock for critical operations.

Contract & Record

1 audit on record
TypeERC1967Proxy
NetworkEthereum
Token age1mo
Contract0x4d70…8d48
Deployer0x712c…ab92
Proxy Upgrade Controls
Proxy TypeEip1967 Uups
ImplementationVerified source
Upgrades (30d)0 · stable
Badge for your website
Gensyn 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. Jul 23, 202686Critical

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

Related Audits

6 more on the recordAll audits
SparkSPK · Ethereum86CriticalCircle Wrapped BitcoinCIRBTC · Ethereum86CriticalEden TokenEDEN · Ethereum85CriticalZK CoinZKC · Ethereum85CriticalRender TokenRNDR · Ethereum85CriticalCOTIEthereum88Critical

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 Is this your token? Publish your own audit on this page