On-chain security analysis — is it a scam or legit?
EthereumThe Sky token contract implements an ERC-20-like token with EIP-2612 permit functionality and a custom wards access control system.
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
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
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.
0x6df1…ac720x26fc…65b50xfc36…8ebc0xb48e…26440xdd67…6f4c0x3fb4…a8e40x1cea…e0440x08cd…a4a60xbc5e…6e330x386e…c279No privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.
permit Function Front-Running Vulnerabilitypermit function increments the nonce for the owner *before* validating the signature (unchecked { nonce = nonces[owner]++; }). This allows an attacker to front-run a legitimate permit transaction by simply calling permit with the same owner address (even with an valid signature or different parameters). The attacker's transaction would increment the nonce, causing the legitimate permit transaction to fail due to an incorrect nonce value in the signed message. This effectively allows an attacker to grief users attempting to use the permit functionality (7.2).H-01The permit function increments the nonce for the owner *before* validating the signature (unchecked { nonce = nonces[owner]++; }). This allows an attacker to front-run a legitimate permit transaction by simply calling permit with the same owner address (even with an valid signature or different parameters). The attacker's transaction would increment the nonce, causing the legitimate permit transaction to fail due to an incorrect nonce value in the signed message. This effectively allows an attacker to grief users attempting to use the permit functionality (7.2).
The nonce increment should occur *after* the signature validation and *before* the state change (i.e., allowance update). A common pattern is to increment the nonce only after a successful signature verification.
Unresolved
mint and burn functions are protected by the auth modifier, which relies on the wards mapping. The initial deployer is the sole ward, and they can add or remove other wards via rely and deny. This grants a small set of authorized addresses (initially just the deployer) complete control over the token's total supply. This centralized control introduces a significant economic risk, as these addresses can arbitrarily inflate or deflate the supply, potentially devaluing existing tokens or manipulating market dynamics (7.4, 7.3).H-02The mint and burn functions are protected by the auth modifier, which relies on the wards mapping. The initial deployer is the sole ward, and they can add or remove other wards via rely and deny. This grants a small set of authorized addresses (initially just the deployer) complete control over the token's total supply. This centralized control introduces a significant economic risk, as these addresses can arbitrarily inflate or deflate the supply, potentially devaluing existing tokens or manipulating market dynamics (7.4, 7.3).
Implement a more decentralized governance mechanism for critical functions like mint and burn, such as a time-locked multi-signature wallet or a community-driven DAO. If centralized control is intended, clearly document this risk and ensure robust operational security for the controlling addresses.
Unresolved
wards mapping and an auth modifier for access control. The deployer is initially the only authorized address and can grant or revoke authorization to others using rely and deny. This creates a single point of failure: if the controlling addresses are compromised, malicious actors could gain full control over the token's administrative functions, including minting new tokens and managing other authorized users (7.3).M-01The contract uses a wards mapping and an auth modifier for access control. The deployer is initially the only authorized address and can grant or revoke authorization to others using rely and deny. This creates a single point of failure: if the controlling addresses are compromised, malicious actors could gain full control over the token's administrative functions, including minting new tokens and managing other authorized users (7.3).
Consider implementing a multi-signature scheme for the wards management functions (rely, deny) to distribute control and reduce the risk associated with a single point of failure.
Unresolved
wards (7.5). This design choice, while simple, may not align with the principles of decentralization often associated with blockchain projects and could lead to community distrust or perceived unfairness.M-02The contract lacks a robust, decentralized governance mechanism. All administrative decisions, including the ability to mint/burn tokens and manage authorized users, are concentrated in the hands of the wards (7.5). This design choice, while simple, may not align with the principles of decentralization often associated with blockchain projects and could lead to community distrust or perceived unfairness.
Explore integrating a decentralized governance framework (e.g., Compound's Governor Bravo, OpenZeppelin's Governor) to allow token holders to propose and vote on significant protocol changes and administrative actions. This would enhance transparency and community involvement.
Unresolved
totalSupply or Balance Overflow in mintmint function, while using unchecked blocks for balanceOf[to] = balanceOf[to] + value and totalSupply = totalSupply + value, does not explicitly check for potential overflows if balanceOf[to] or totalSupply were to approach type(uint252).max. In a scenario where totalSupply or an individual balanceOf is already extremely high (near type(uint256).max), a subsequent mint operation could theoretically cause an overflow, leading to a wrap-around to zero or a small number (7.2). This is a theoretical edge case for standard ERC-20 tokens, as type(uint256).max is a very large number.I-01The mint function, while using unchecked blocks for balanceOf[to] = balanceOf[to] + value and totalSupply = totalSupply + value, does not explicitly check for potential overflows if balanceOf[to] or totalSupply were to approach type(uint252).max. In a scenario where totalSupply or an individual balanceOf is already extremely high (near type(uint256).max), a subsequent mint operation could theoretically cause an overflow, leading to a wrap-around to zero or a small number (7.2). This is a theoretical edge case for standard ERC-20 tokens, as type(uint256).max is a very large number.
While highly unlikely to occur in practice for typical token economics, consider adding explicit checks (require(balanceOf[to] + value >= balanceOf[to], "Overflow") or require(totalSupply + value >= totalSupply, "Overflow")) within the mint function if the token's design anticipates extremely large supplies or individual balances that could approach type(uint256).max.
Unresolved
The Sky token contract implements an ERC-20-like token with EIP-2612 permit functionality and a custom wards access control system. The audit identified a high-severity front-running vulnerability in the permit function and significant centralization risks related to token supply management and access control. While the code quality is generally good, these issues pose considerable security and economic risks.
The contract demonstrates good technical practices, including robust EIP-712 and EIP-1271 signature validation and careful use of unchecked blocks after necessary checks (7.2). However, a high-severity front-running vulnerability exists in the permit function due to the nonce being incremented before signature validation, allowing attackers to grief users (7.2). The _isValidSignature function correctly uses staticcall to prevent reentrancy during external calls (7.6).
The contract employs a centralized wards system for access control, where the deployer initially holds all administrative power and can manage other authorized users (7.3). This system grants a small set of addresses complete control over critical functions like mint and burn, posing a high economic risk due to potential arbitrary supply inflation/deflation (7.4). The absence of a decentralized governance mechanism further concentrates decision-making authority (7.5).
The contract is not designed with upgradeability in mind, meaning its logic is immutable once deployed (7.7). This eliminates risks associated with upgrade mechanisms, such as proxy implementation vulnerabilities or improper upgrade paths. However, any future feature enhancements or bug fixes would necessitate a new contract deployment and a migration process for existing token holders.
Prioritize addressing the permit function's front-running vulnerability by reordering the nonce increment.
Evaluate the project's long-term vision regarding decentralization; consider implementing a multi-signature wallet for wards management and exploring a decentralized governance framework for critical functions like mint and burn to mitigate centralization risks and enhance community trust.
Free for any token on the record. It links to this page and always shows the current score and the date it was checked.
Score changes are recorded as dated snapshots — history is append-only and cannot be edited.
The SKY Governance Token (SKY) contract on Ethereum is 0x56072c95faa701256059aa122697b133aded9279. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.
Quantum Audit's risk score for SKY Governance Token is 70/100 (High risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Mint: Mintable; Liquidity lock: Not locked; Upgradeability: Fixed code; Honeypot: None found; Buy / sell tax: 0% / 0%. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.
Liquidity lock: Not locked (as of Sep 4, 2026). Total DEX liquidity: $12.35M.
As of Sep 4, 2026, the 10 largest holders own 90.5% of the supply. The Holders section on this page shows who they are by holder type.
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
