Is SKY Governance Token (SKY) Safe? Smart Contract Security Analysis

Security Findings

2 High2 Med1 Info

High

`permit` Function Front-Running Vulnerability

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

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

FixThe `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.

StatusUnresolved

High

Centralized Control Over Token Supply (Mint/Burn)

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

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

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

StatusUnresolved

Medium

Centralized Access Control (Wards System)

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

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

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

StatusUnresolved

Medium

Lack of Decentralized Governance

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.

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

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

StatusUnresolved

Info

Theoretical `totalSupply` or Balance Overflow in `mint`

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.

IssueThe `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.

FixWhile 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`.

StatusUnresolved

Category Ratings

TechnicalMedium6/10

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

GovernanceHigh1/10

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

UpgradesHigh3/10

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.

Security Checklist

2/5 checks passed

Contract VerifiedPass

Ownership Renounced?

No Mint FunctionFail

Liquidity LockedFail

Not a ProxyPass

HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

90.5% in top 10

6.3% in wallets84.2% in contracts

Effective Concentration40.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

$12.35M across 8 pairs

Uniswap v4WBTCanalysed$7.75M Uniswap v4USDC$2.61M Uniswap v3WETH$1.19M Uniswap v4ETH$744.1K Uniswap v4USDC$29.2K Uniswap v3DAI$10.3K

Show 2 more pairsShow less

Uniswap v3WETH$7.9K Uniswap v4LINK$96

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 Holder39.1%

Top-3 Unlocked81.3%

Key Addresses

11 addresses

Deployer

0x4ec2…cfb8

Unlocked LP Held By

0x6df1…ac720x26fc…65b50xfc36…8ebc0xb48e…26440xdd67…6f4c0x3fb4…a8e40x1cea…e0440x08cd…a4a60xbc5e…6e330x386e…c279

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

What Raised This Score

7 factors

Ownership status UNKNOWN (owner could not be resolved)
Mintable supply — no cap found, dilution unbounded
Top-10 concentration > 30% (90.5% total → 40.0% effective; 6.3% in EOAs, 84.2% in contracts — moderate)
Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
LP top3 unlocked holders = 81.3% (independent LP — depth risk, pool = 63% of DEX liquidity)
2 High finding(s) from audit
2 Medium 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

Is SKY Governance Token Safe?

Security Findings

`permit` Function Front-Running Vulnerability

Centralized Control Over Token Supply (Mint/Burn)

Centralized Access Control (Wards System)

Lack of Decentralized Governance

Theoretical `totalSupply` or Balance Overflow in `mint`

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 SKY Governance Token?