On-chain security analysis — is it a scam or legit?
EthereumThe GMToken contract is an upgradeable ERC-20 token utilizing a Beacon proxy pattern.
Read the full analysisEach 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
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 Oct 16, 2026
The 19 remaining pairs hold $152.6K between them and are not listed. The risk score reads depth across every pair.
The LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.
0x1b26…9eb70xbf4b…328f0x0ef7…8abe0x896e…74580x78d6…0e130xaa6b…95190xe641…ff920x3b3f…ba0e0x35f9…82cfTransfers call an external contract whose address a privileged function can change. Whoever controls that setting controls what a transfer does. Functions: setCompliance, setTokenPauseManager. Restricted to: role.
Check who holds these functions and whether a timelock or multisig stands between them and holders.
Unresolved
A privileged function increases the total supply, diluting every holder. Functions: mint(address,uint256). Restricted to: role.
Check who holds these functions and whether a timelock or multisig stands between them and holders.
Unresolved
0.0% of the pool's LP is burned or time-locked. 100.0% is held, unlocked, by 5 address(es) other than the owner/deployer. One of them — a contract, 0x1b26…9eb7 — holds 64.6% and can remove that share at once; who controls it is not visible on-chain, so it is not treated as an independent provider. Some pools are concentrated-liquidity (V3/V4) positions; shares above are by position as GoPlus reports them. This assessment covers the main pool, which holds 23% of the token's DEX liquidity; the other pools were not assessed.
Check the lock's end date and beneficiary on the locker's own page before relying on it.
Acknowledged
The ten largest holders own 70.6% of supply. What remains: 53.5% in wallets, 17.1% in other contracts. 3,540 holders in total.
Watch the largest wallets that are not exchanges, pools or locks — those are the ones that can move the price.
Acknowledged
Listed on CoinGecko as Tesla (Ondo Tokenized Stock) (TSLAON), market cap $17M, rank #935. 3,540 holders.
Match the contract address against the project's official channels before trading.
Acknowledged
Liquidity $646K (DexScreener, all pools). 24h trading volume $2.3M (CoinGecko, all markets, daily snapshot). 24h trading volume $1.2M (DexScreener, all pools).
Size any position to the liquidity and daily volume shown — they set how much you can sell and at what price.
Acknowledged
A token backed by an off-chain asset (a stock, gold, treasury bills, a fund share) held by a named issuer or custodian. Issuance, redemption and transfer restrictions are the issuer's by design. The class itself adds no points; the contract and market facts decide the score. Basis: CoinGecko category: Tokenized Stocks. Tokenomics — Supply: mintable with no on-chain cap found. Control: an owner that could not be resolved. Code: upgradeable proxy. Fees: no buy or sell tax. Market: $646K of DEX liquidity across 29 pools. Launch: 394 days of market history.
Treat the issuer or custodian as the counterparty: check its custody reports and who may hold or redeem the token.
Acknowledged
The GMToken contract is an upgradeable ERC-20 token utilizing a Beacon proxy pattern. It incorporates access control for critical functions such as minting and setting external compliance and pause managers. The audit identified high and medium severity issues related to centralized control over token supply and critical external dependencies, which could significantly impact token holders if misused.
The GMToken contract is built upon OpenZeppelin's upgradeable ERC-20 and AccessControl standards, providing a solid foundation for token functionality and role-based permissions (7.1 Architecture). Standard ERC-20 transfer mechanisms are correctly implemented (7.2 Code Security). However, the contract's reliance on external compliance and tokenPauseManager contracts, whose addresses can be changed by a privileged role via setCompliance and setTokenPauseManager, introduces a significant technical risk (7.3 Access Control). This centralized control over critical external dependencies means that a single compromised role could redirect or halt all token transfers.
The economic model of GMToken is subject to centralized control, as a privileged role can mint new tokens at will, directly impacting the total supply and potentially diluting existing token holders (7.4 Economic). Furthermore, the ability of a privileged role to replace the compliance and tokenPauseManager contracts means that the rules governing token transfers, including potential fees or pausing mechanisms, can be altered without direct token holder consent (7.5 Governance). This concentration of power in specific roles presents a substantial governance risk, requiring robust operational security for the controlling addresses (7.8 Operations).
The GMToken contract is deployed as a Beacon proxy, allowing its implementation logic to be upgraded. This upgradeability provides flexibility for future enhancements or bug fixes (7.7 Upgrades). However, the power to upgrade the contract logic resides with a privileged role, meaning that a compromised upgrade key or malicious upgrade could introduce new vulnerabilities or alter contract behavior in unforeseen ways. Careful management of the upgrade process and associated roles is critical to maintain security.
It is crucial to implement stringent operational security measures for all privileged roles, especially those with the ability to mint tokens, change critical external dependencies, or initiate contract upgrades.
Consider implementing multi-signature wallets for these roles to prevent single points of failure. Additionally, establish clear governance procedures for any changes to critical parameters or contract logic, ensuring transparency and community oversight where appropriate to mitigate the risks associated with centralized control.
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
