Is Gensyn (AI) Safe? Smart Contract Security Analysis

Security Checklist

1/5 checks passed

Contract VerifiedPass

Ownership RenouncedUnknown

No Mint FunctionFail

Liquidity LockedFail

Not a ProxyFail

Audit History

2 audits on record

Jul 2386

Every audit run adds a dated snapshot — history is append-only and cannot be edited.

Audit Summary

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.

Final Recommendation: The most critical recommendation is to immediately verify the source code of the implementation contract (0x81cfa8f011a137ec93039694eeea40d4c5b56cbe). 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.

Category Ratings

TechnicalMedium

4/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. Howeve

GovernanceHigh

1/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 up

UpgradesHigh

1/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 `_au

Proxy Upgrade Controls

Proxy TypeEip1967 Uups

ImplementationVerified source

Upgrades (30d)0 · stable

LP Distribution

Top-1 Unlocked Holder100.0%

Top-3 Unlocked100.0%

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% (87.7% total → 84.5% effective; 82.5% in EOAs, 5.2% 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 = 95% of DEX liquidity)
LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 95% 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 Findings

5 total

1 High 1 Medium 1 Low 2 Info

H-01HighUnresolved

Unverified Implementation Contract

The proxy contract (0x4d7078ddd6ccfed2f85db5b7d3ff16828d378d48) delegates all calls to an implementation contract (0x81cfa8f011a137ec93039694eeea40d4c5b56cbe) 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.

Recommendation: Immediately verify and publish the source code for the implementation contract (0x81cfa8f011a137ec93039694eeea40d4c5b56cbe) on block explorers. Conduct a thorough security audit of the implementation contract to identify and mitigate any potential vulnerabilities.

M-01MediumUnresolved

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.

Recommendation: 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.

L-01LowUnresolved

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.

Recommendation: 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.

I-01InformationalResolved

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.

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

I-02InformationalUnresolved

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.

Recommendation: 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.

Is Gensyn Safe? AI