Is OpenAI Safe? Smart Contract Security Analysis

Security Findings

2 Med1 Low3 Info

Medium

Centralized Admin Control

M-01The `_admin` role has significant control over critical token parameters, including the ability to update the token's image, metadata, and context strings. Furthermore, the `_admin` can transfer its own role to any address via `updateAdmin`. This high degree of centralization (7.3 Access Control, 7.5 Governance) means that a compromise of the `_admin`'s private key could lead to unauthorized changes to the token's public representation or even a malicious transfer of administrative control.

IssueThe `_admin` role has significant control over critical token parameters, including the ability to update the token's image, metadata, and context strings. Furthermore, the `_admin` can transfer its own role to any address via `updateAdmin`. This high degree of centralization (7.3 Access Control, 7.5 Governance) means that a compromise of the `_admin`'s private key could lead to unauthorized changes to the token's public representation or even a malicious transfer of administrative control.

FixConsider implementing a multi-signature wallet for the `_admin` role to require multiple approvals for sensitive operations like `updateAdmin`, `updateImage`, and `updateMetadata`. Alternatively, introduce a time-lock mechanism for `updateAdmin` to provide a window for community review or intervention before a new admin takes full control.

StatusUnresolved

Medium

Misleading `maxSupply_` Parameter in Constructor

M-02The constructor takes a `maxSupply_` parameter, which is used to mint an initial supply to `msg.sender` under a specific `block.chainid` condition. However, the `crosschainMint` function, controlled by `Predeploys.SUPERCHAIN_TOKEN_BRIDGE`, allows for additional minting without any explicit cap related to `maxSupply_`. This implies that `maxSupply_` is effectively an initial supply on the primary chain rather than a true global maximum supply. This discrepancy (7.4 Economic) can lead to confusion among users and investors regarding the token's total circulating supply and inflation mechanics.

IssueThe constructor takes a `maxSupply_` parameter, which is used to mint an initial supply to `msg.sender` under a specific `block.chainid` condition. However, the `crosschainMint` function, controlled by `Predeploys.SUPERCHAIN_TOKEN_BRIDGE`, allows for additional minting without any explicit cap related to `maxSupply_`. This implies that `maxSupply_` is effectively an initial supply on the primary chain rather than a true global maximum supply. This discrepancy (7.4 Economic) can lead to confusion among users and investors regarding the token's total circulating supply and inflation mechanics.

FixClarify the purpose of the `maxSupply_` parameter in the contract's documentation, explicitly stating that it refers to the initial supply on the designated chain and not a global hard cap. If a global hard cap is intended, implement a mechanism within `crosschainMint` to enforce it, or rename the parameter to `initialChainSupply` or similar for better clarity.

StatusUnresolved

Low

Single-Use `_originalAdmin` Role

L-01The `_originalAdmin` role is an immutable address set in the constructor, but its only function is to call `verify()` once. After `verify()` is successfully executed, the `_originalAdmin` address holds no further special privileges or responsibilities within the contract (7.3 Access Control, 7.8 Operations). While not a direct vulnerability, if this key were compromised *before* `verify()` is called, it could be used to prematurely verify the token, potentially against the project's intended timeline.

IssueThe `_originalAdmin` role is an immutable address set in the constructor, but its only function is to call `verify()` once. After `verify()` is successfully executed, the `_originalAdmin` address holds no further special privileges or responsibilities within the contract (7.3 Access Control, 7.8 Operations). While not a direct vulnerability, if this key were compromised *before* `verify()` is called, it could be used to prematurely verify the token, potentially against the project's intended timeline.

FixConsider if the `_originalAdmin` role is strictly necessary post-deployment, or if its functionality could be integrated into the `_admin` role with appropriate safeguards. If kept, ensure the `_originalAdmin` key is secured with the highest standards, especially prior to the `verify()` call. After `verify()` is called, the key can be safely archived or even burned if no other off-chain responsibilities are tied to it.

StatusUnresolved

Info

Non-Upgradeable Contract

I-01The `ClankerToken` contract is deployed as a standard, non-proxy implementation. This means that its logic cannot be modified or upgraded after deployment (7.7 Upgrades). Any future bug fixes, feature additions, or changes to the token's behavior would require deploying an entirely new contract and migrating all existing token holders and integrations, which can be a complex, costly, and disruptive process.

IssueThe `ClankerToken` contract is deployed as a standard, non-proxy implementation. This means that its logic cannot be modified or upgraded after deployment (7.7 Upgrades). Any future bug fixes, feature additions, or changes to the token's behavior would require deploying an entirely new contract and migrating all existing token holders and integrations, which can be a complex, costly, and disruptive process.

FixAcknowledge the implications of a non-upgradeable contract. For projects requiring long-term flexibility or potential for future enhancements, consider adopting an upgradeable proxy pattern (e.g., UUPS or Transparent Proxy) for future contract deployments. If non-upgradeability is a deliberate design choice, ensure all current functionalities are thoroughly tested and robust.

StatusUnresolved

Info

Reliance on External Superchain Token Bridge

I-02The `crosschainMint` and `crosschainBurn` functions are exclusively callable by `Predeploys.SUPERCHAIN_TOKEN_BRIDGE`. This design makes the token's cross-chain functionality entirely dependent on the security, availability, and correct operation of this external bridge (7.6 External). Any vulnerabilities or compromises within the `SUPERCHAIN_TOKEN_BRIDGE` could directly impact the integrity and supply of the ClankerToken across different chains.

IssueThe `crosschainMint` and `crosschainBurn` functions are exclusively callable by `Predeploys.SUPERCHAIN_TOKEN_BRIDGE`. This design makes the token's cross-chain functionality entirely dependent on the security, availability, and correct operation of this external bridge (7.6 External). Any vulnerabilities or compromises within the `SUPERCHAIN_TOKEN_BRIDGE` could directly impact the integrity and supply of the ClankerToken across different chains.

FixEnsure that the `Predeploys.SUPERCHAIN_TOKEN_BRIDGE` is a highly secure and audited component. Maintain continuous monitoring of the bridge's operational status and security posture. Document the trust assumptions made regarding the bridge for users and integrators.

StatusUnresolved

Info

Chain-Specific Initial Minting Condition

I-03The constructor includes a condition `if (block.chainid == initialSupplyChainId_) { _mint(msg.sender, maxSupply_); }`. This means that the initial `maxSupply_` will only be minted if the contract is deployed on a specific, predefined chain (7.1 Architecture, 7.4 Economic). If deployed on any other chain, the initial supply will be zero, requiring `crosschainMint` operations to introduce tokens into circulation.

IssueThe constructor includes a condition `if (block.chainid == initialSupplyChainId_) { _mint(msg.sender, maxSupply_); }`. This means that the initial `maxSupply_` will only be minted if the contract is deployed on a specific, predefined chain (7.1 Architecture, 7.4 Economic). If deployed on any other chain, the initial supply will be zero, requiring `crosschainMint` operations to introduce tokens into circulation.

FixClearly document this chain-specific initial minting behavior to avoid confusion regarding token distribution and deployment strategies. Ensure that the `initialSupplyChainId_` is correctly set for the intended primary deployment chain.

StatusUnresolved

Category Ratings

TechnicalLow10/10

The ClankerToken contract demonstrates good technical architecture (7.1 Architecture) by extending standard ERC20 functionalities with `ERC20Permit`, `ERC20Votes`, and `ERC20Burnable` from OpenZeppelin, which are well-audited and secure. Code security (7.2 Code Security) is strong, with no apparent reentrancy, integer overflows (due to Solidity 0.8.x), or other common vulnerabilities. The contract correctly implements `supportsInterface` for multiple ERC standards. A minor technical observation is the single-use nature of the `_originalAdmin` role after `verify()` is called, which could be simplified or removed post-verification.

GovernanceHigh3/10

The contract features a centralized `_admin` role (7.3 Access Control) that can update token metadata (image, context, metadata) and transfer the admin role itself. This centralization (7.5 Governance) introduces a single point of failure; compromise of this key could lead to reputational damage or manipulation of token representation. Economically (7.4 Economic), the `maxSupply_` parameter in the constructor is potentially misleading as `crosschainMint` allows minting beyond this initial value, implying it's an initial supply on a specific chain rather than a global hard cap. The reliance on `Predeploys.SUPERCHAIN_TOKEN_BRIDGE` for cross-chain operations (7.6 External) means the token's cross-chain integrity is dependent on the bridge's security.

UpgradesLow9/10

The ClankerToken contract is implemented as a standard, non-upgradeable contract (7.7 Upgrades). This means there is no inherent upgrade mechanism (e.g., proxy pattern) to modify its logic post-deployment. While this eliminates risks associated with upgrade mechanisms themselves, it also means that any future bug fixes, feature enhancements, or changes to the token's logic would necessitate deploying an entirely new contract and migrating existing token holders, which can be a complex and costly process.

Security Checklist

4/5 checks passed

Contract VerifiedPass

Ownership RenouncedPass

No Mint FunctionPass

Liquidity LockedFail

Not a ProxyPass

Holder Composition

100.0% in top 10

100.0% in wallets0.0% in contracts

Effective Concentration100.0%

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

$9.70M across 3 pairs

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

0x00aa…ce61

Unlocked LP Held By

0x170f…7cec

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

What Raised This Score

6 factors

Top-10 concentration > 70% (100.0% total → 100.0% effective; 100.0% in EOAs, 0.0% 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)
LP top3 unlocked holders = 100.0% (independent LP — depth risk)
2 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 recommended to implement a robust multi-signature wallet or a time-locked governance mechanism for the `_admin` role to mitigate the risks associated with centralized control.…

Read the verdictHide

Clearly document the intended behavior of the `maxSupply_` parameter, clarifying that it represents an initial supply on a specific chain rather than a global hard cap, to prevent economic misunderstandings. For long-term flexibility, consider a proxy-based upgradeable architecture for future token deployments, or acknowledge the implications of non-upgradeability for future maintenance and evolution.

Contract

TypeClankerToken

Audit History

1 audit on record

Aug 1417Sep 432

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

Is OpenAI Safe?

Security Findings

Centralized Admin Control

Misleading `maxSupply_` Parameter in Constructor

Single-Use `_originalAdmin` Role

Non-Upgradeable Contract

Reliance on External Superchain Token Bridge

Chain-Specific Initial Minting Condition

Category Ratings

Security Checklist

Holder Composition

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Related Audits

Would You Like a More Detailed Audit of OpenAI?