Is SKYAI Safe? Smart Contract Security Analysis

Security Findings

1 Low2 Info

Low

Allowance Race Condition in `approve()`

L-01The standard ERC20 `approve()` function is susceptible to a known front-running vulnerability. If a user approves an allowance for a spender, and then attempts to change that allowance by calling `approve()` again with a new amount, a malicious actor could front-run the second transaction. This could allow the attacker to spend the original allowance, and then also spend the new allowance, effectively doubling the amount they can spend (7.2 Code Security). OpenZeppelin mitigates this by providing `increaseAllowance()` and `decreaseAllowance()` functions, which are safer alternatives.

IssueThe standard ERC20 `approve()` function is susceptible to a known front-running vulnerability. If a user approves an allowance for a spender, and then attempts to change that allowance by calling `approve()` again with a new amount, a malicious actor could front-run the second transaction. This could allow the attacker to spend the original allowance, and then also spend the new allowance, effectively doubling the amount they can spend (7.2 Code Security). OpenZeppelin mitigates this by providing `increaseAllowance()` and `decreaseAllowance()` functions, which are safer alternatives.

FixAdvise users to primarily use `increaseAllowance()` and `decreaseAllowance()` instead of directly calling `approve()` when modifying existing allowances. If `approve()` must be used, users should first set the allowance to zero before setting a new value, though this still requires two transactions and introduces a small window of vulnerability.

StatusUnresolved

Info

Incomplete Source Code Provided

I-01The provided source code for the `ERC20.sol` contract is truncated, and the specific `SKYAIToken` contract, which is likely derived from `ERC20`, was not provided. This significantly limits the scope of the audit, as any custom logic, state variables, or function overrides within the complete `ERC20.sol` or `SKYAIToken` contract could not be analyzed for vulnerabilities (7.1 Architecture, 7.2 Code Security).

IssueThe provided source code for the `ERC20.sol` contract is truncated, and the specific `SKYAIToken` contract, which is likely derived from `ERC20`, was not provided. This significantly limits the scope of the audit, as any custom logic, state variables, or function overrides within the complete `ERC20.sol` or `SKYAIToken` contract could not be analyzed for vulnerabilities (7.1 Architecture, 7.2 Code Security).

FixProvide the complete and final source code for all contracts intended for deployment, including the full `ERC20.sol` and the `SKYAIToken` contract, to allow for a comprehensive security assessment.

StatusUnresolved

Info

Lack of Custom Functionality for Audit

I-02The audit was conducted on a base OpenZeppelin ERC20 implementation. Without the specific `SKYAIToken` contract's code, any custom functionalities such as minting, burning, pausing, fee mechanisms, or specific access control roles (7.3 Access Control, 7.8 Operations) could not be reviewed. This means that potential vulnerabilities related to the unique business logic of `SKYAIToken` are outside the scope of this report.

IssueThe audit was conducted on a base OpenZeppelin ERC20 implementation. Without the specific `SKYAIToken` contract's code, any custom functionalities such as minting, burning, pausing, fee mechanisms, or specific access control roles (7.3 Access Control, 7.8 Operations) could not be reviewed. This means that potential vulnerabilities related to the unique business logic of `SKYAIToken` are outside the scope of this report.

FixEnsure that any custom logic implemented in the `SKYAIToken` contract is thoroughly reviewed for common vulnerabilities such as reentrancy, access control bypasses, integer overflows/underflows, and logical errors. Consider a separate audit for the full custom implementation.

StatusUnresolved

Category Ratings

TechnicalLow10/10

The provided code utilizes battle-tested OpenZeppelin contracts (7.2 Code Security), which are known for their robust implementation and adherence to best practices. Standard ERC20 functions like `transfer` and `transferFrom` are implemented securely, including checks for zero addresses and sufficient balances. The `decreaseAllowance` function correctly uses `unchecked` after a `require` check to prevent underflow. However, the standard `approve` function (7.2 Code Security) still carries a known allowance race condition, though OpenZeppelin provides `increaseAllowance` and `decreaseAllowance` as safer alternatives.

GovernanceLow8/10

As a standard ERC20 token (7.4 Economic), the contract does not inherently include complex governance mechanisms or economic models beyond basic token transfers and allowances. There are no specific governance functions (7.5 Governance) or external economic dependencies (7.6 External) identified in the provided base code. Any custom economic logic or governance would reside in the unprovided `SKYAIToken` contract.

UpgradesLow10/10

The provided contract is a direct implementation of ERC20 and is not designed as an upgradeable proxy (7.7 Upgrades). Therefore, upgradeability risks such as storage collisions or incorrect initialization are not applicable to this specific deployment. Any future changes would require deploying a new contract and migrating assets, which is a standard practice for non-upgradeable tokens.

Security Checklist

5/5 checks passed

Contract VerifiedPass

Ownership RenouncedPass

No Mint FunctionPass

Liquidity LockedPass

Not a ProxyPass

Holder Composition

61.0% in top 10

52.3% in wallets8.7% in contracts

Effective Concentration55.8%

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

$6.85M across 8 pairs

Pancakeswap v2WBNBanalysed$6.70M Pancakeswap v3WBNB$101.1K Pancakeswap v3USDT$48.5K UniswapUSDT$2.3K Pancakeswap v3USDT$326 UniswapUSDT$82

Show 2 more pairsShow less

UniswapUSDT$4 Pancakeswap v2USDT$1

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

LP Burned99.9% · ≈ permanent lock

LP Locked99.9%

Key Addresses

10 addresses

Deployer

0xb779…22ea

Unlocked LP Held By

0x3ad4…4c0d0x7d8a…8d040xe2b0…24a90xf42d…40820x0ed9…97060x5833…79770x5105…f07c0xa628…bd590xa5cd…6a72

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

What Raised This Score

2 factors

Top-10 concentration > 50% (61.0% total → 55.8% effective; 52.3% in EOAs, 8.7% in contracts — heavy)
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

Not Signed In

Is SKYAI Safe?

Security Findings

Allowance Race Condition in `approve()`

Incomplete Source Code Provided

Lack of Custom Functionality for Audit

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 SKYAI?