Quantum Audit Logo

Is AEGIS X Safe?

On-chain security analysis — is it a scam or legit?

Is this your token? Publish your own audit on this page →

AEGIS X AGX
0xe766…a077
BNB Chain
Not verifiedThis record has not gone through deep verification and is not being monitored. The score is a dated snapshot — the token’s risk can change at any time.Own this token? Put it under verification →
Last checked 7d ago 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

The AegisXToken contract implements an ERC20 token with advanced defense mechanisms against price drops and large sell-offs, including dynamic sell taxes and a crash fuse. The contract leverages OpenZeppelin libraries for standard functionalities and access control. While the architecture incorporates several protective features, a critical vulnerability related to oracle manipulation from the PancakeSwap V2 pair was identified, which could undermine the core defense mechanisms. Additionally, significant centralization of control and potential economic instability due to high defense taxes pose considerable risks.

1 Critical1 High1 Medium1 Low2 Informational
Volume 24h
$3.05M
Liquidity
$49.59M
Price
$55.0790
Token Age
1mo
Top 10 Holders
99.4%

Security Findings

1 Crit1 High1 Med1 Low2 Info
Critical

Critical: Oracle Manipulation via Spot Price from AMM

C-01The contract relies on `IPancakePair.getReserves()` to determine the token's price and pool reserves in functions like `_getPoolPrice()`, `_poolReserves()`, `_snapshotPrice()`, `_checkDefenseFuse()`, and `_recordBlockSell()`. Spot prices from AMM pairs are highly susceptible to manipulation within a single block using flash loans or large swaps. An attacker could temporarily skew the reported price or reserves to bypass high sell taxes, trigger defense mechanisms incorrectly, or manipulate the `snapshotPrice` to their advantage, leading to significant financial loss or protocol instability.
IssueThe contract relies on `IPancakePair.getReserves()` to determine the token's price and pool reserves in functions like `_getPoolPrice()`, `_poolReserves()`, `_snapshotPrice()`, `_checkDefenseFuse()`, and `_recordBlockSell()`. Spot prices from AMM pairs are highly susceptible to manipulation within a single block using flash loans or large swaps. An attacker could temporarily skew the reported price or reserves to bypass high sell taxes, trigger defense mechanisms incorrectly, or manipulate the `snapshotPrice` to their advantage, leading to significant financial loss or protocol instability.
FixImplement a time-weighted average price (TWAP) oracle or integrate with a robust, decentralized oracle solution (e.g., Chainlink) that aggregates data from multiple sources and is resistant to single-block manipulations. This is crucial for all price-sensitive operations, especially those triggering defense mechanisms or calculating taxes.
StatusUnresolved
High

High: Centralized Control over Critical Parameters

H-01The `governance` address has extensive control over critical protocol parameters, including `sellRatio`, `extraSellBP`, `crashThresholdBP`, `feeReceiver`, `rbs`, `transferStatus`, and the ability to whitelist addresses. While the `owner` (a 20/32 multisig) can update the `governance` address, the `governance` role itself, if compromised or misused, could severely impact the protocol's integrity and user funds. This high degree of centralization introduces a single point of failure for operational security.
IssueThe `governance` address has extensive control over critical protocol parameters, including `sellRatio`, `extraSellBP`, `crashThresholdBP`, `feeReceiver`, `rbs`, `transferStatus`, and the ability to whitelist addresses. While the `owner` (a 20/32 multisig) can update the `governance` address, the `governance` role itself, if compromised or misused, could severely impact the protocol's integrity and user funds. This high degree of centralization introduces a single point of failure for operational security.
FixEnsure the `governance` address is controlled by a robust, multi-signature wallet with a high threshold or a well-designed decentralized autonomous organization (DAO). Consider implementing timelocks for changes to critical parameters to provide transparency and allow community review before changes become effective, mitigating risks from hasty or malicious actions.
StatusUnresolved
Medium

Medium: Economic Instability Risk from High Defense Tax

M-01The `extraSellBP` is set to 3000 (30%), which is applied as a sell tax when the `crashFuseActive` or `blockSellLimitExceeded` conditions are met. While intended as a defense mechanism against rapid price depreciation, such a high tax can create strong disincentives for legitimate sellers. This could exacerbate sell-offs during periods of stress, potentially leading to a 'death spiral' where users rush to sell before the tax applies, or avoid selling into the pool entirely, undermining the token's liquidity and stability.
IssueThe `extraSellBP` is set to 3000 (30%), which is applied as a sell tax when the `crashFuseActive` or `blockSellLimitExceeded` conditions are met. While intended as a defense mechanism against rapid price depreciation, such a high tax can create strong disincentives for legitimate sellers. This could exacerbate sell-offs during periods of stress, potentially leading to a 'death spiral' where users rush to sell before the tax applies, or avoid selling into the pool entirely, undermining the token's liquidity and stability.
FixConduct thorough economic modeling and simulations to assess the impact of the 30% `extraSellBP` under various market conditions. Consider if this magnitude of tax is sustainable or if it might lead to unintended adverse user behavior. Explore alternative or dynamically adjustable tax mechanisms that provide defense without excessively penalizing legitimate market activity.
StatusUnresolved
Low

Low: Whitelist Bypass for DEAD Address During Disabled Transfers

L-01In the `_update` function, when `_from == targetPool` (a buy from the pool), the condition `if (!transferStatus && (_to != DEAD && !whitelist[_to])) revert Disabled();` allows transfers to the `DEAD` address even if `transferStatus` is `false` and the recipient is not whitelisted. While `DEAD` is a burn address, this specific bypass means tokens can always be burned from the pool, even when other transfers are intentionally restricted. This might not align with the intended behavior of a 'disabled' transfer state.
IssueIn the `_update` function, when `_from == targetPool` (a buy from the pool), the condition `if (!transferStatus && (_to != DEAD && !whitelist[_to])) revert Disabled();` allows transfers to the `DEAD` address even if `transferStatus` is `false` and the recipient is not whitelisted. While `DEAD` is a burn address, this specific bypass means tokens can always be burned from the pool, even when other transfers are intentionally restricted. This might not align with the intended behavior of a 'disabled' transfer state.
FixClarify if allowing transfers to the `DEAD` address when `transferStatus` is `false` is an intended feature. If not, consider removing the `_to != DEAD` condition from the `revert Disabled()` check to ensure consistency with the `transferStatus` setting.
StatusUnresolved
Info

Informational: Lack of Comprehensive Emergency Pause Mechanism

I-01The contract lacks a general emergency pause mechanism that could halt all transfers or critical functions. The existing `transferStatus` only affects buys from the `targetPool` for non-whitelisted users. In the event of an unforeseen vulnerability or exploit affecting other parts of the contract, the `governance` or `owner` would not have a direct, immediate way to halt all operations to prevent further damage or drain of funds.
IssueThe contract lacks a general emergency pause mechanism that could halt all transfers or critical functions. The existing `transferStatus` only affects buys from the `targetPool` for non-whitelisted users. In the event of an unforeseen vulnerability or exploit affecting other parts of the contract, the `governance` or `owner` would not have a direct, immediate way to halt all operations to prevent further damage or drain of funds.
FixConsider implementing a more comprehensive pause mechanism, such as inheriting from OpenZeppelin's `Pausable` contract. This would allow the `governance` or a designated emergency role to temporarily halt critical operations in an emergency, providing a crucial safety switch for unforeseen circumstances.
StatusUnresolved
Info

Informational: Zero Cooldown for Price Snapshot

I-02The `BALANCE_COOLDOWN_SECONDS` constant is set to `0`, which means the `_snapshotPrice()` function can be called in consecutive blocks without any delay. While this might be intentional for immediate price updates, it could potentially allow an attacker to quickly re-snapshot a manipulated price if they can control the timing of calls to this function, especially in conjunction with a flash loan attack.
IssueThe `BALANCE_COOLDOWN_SECONDS` constant is set to `0`, which means the `_snapshotPrice()` function can be called in consecutive blocks without any delay. While this might be intentional for immediate price updates, it could potentially allow an attacker to quickly re-snapshot a manipulated price if they can control the timing of calls to this function, especially in conjunction with a flash loan attack.
FixReview the rationale for setting `BALANCE_COOLDOWN_SECONDS` to `0`. If `_snapshotPrice()` is critical for defense mechanisms, consider introducing a short, non-zero cooldown period. While this wouldn't fully mitigate flash loan attacks, it could make rapid, repeated manipulation attempts more difficult or costly for an attacker.
StatusUnresolved

Category Ratings

TechnicalMedium5/10

The contract demonstrates a structured approach, utilizing OpenZeppelin libraries for ERC20 and Ownable functionalities (7.1 Architecture). The custom `_update` logic for transfers involving the `targetPool` is complex but generally well-structured, incorporating dynamic tax calculations and defense mechanisms (7.2 Code Security). However, a critical vulnerability exists in the reliance on a spot price oracle from PancakeSwap V2, making the protocol susceptible to flash loan attacks and manipulation of its core defense mechanisms (7.6 External). This significantly impacts the reliability of price-dependent functions like `_checkDefenseFuse` and `_recordBlockSell`.

GovernanceMedium5/10

The protocol's access control is managed by an `owner` (a 20/32 multisig) and a `governance` address, with the `owner` able to set the `governance` (7.3 Access Control). The `governance` role holds extensive power over critical parameters, including sell rates, defense thresholds, and whitelisting, indicating a high degree of centralization (7.5 Governance). The economic model features a high `extraSellBP` (30%) as a defense tax, which, while intended to protect against price drops, could lead to adverse market behavior or a 'death spiral' if frequently triggered (7.4 Economic).

UpgradesMedium4/10

The contract is not designed as an upgradeable proxy (7.7 Upgrades). This eliminates risks associated with upgradeability patterns, such as proxy implementation mismatches or storage collisions. However, it means that any discovered vulnerabilities or desired feature enhancements would require a new deployment and migration.

Security Checklist

3/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionFail
Liquidity LockedPass
Not a ProxyPass
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

99.4% in top 10
1.0% in wallets98.4% in contracts
Effective Concentration40.3%

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

$49.59M

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 Burned100.0% · ≈ permanent lock
LP Locked100.0% · Null Address

Key Addresses

2 addresses
Deployer
0x73c5…cde1
Unlocked LP Held By
0x0ed9…9706

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 NOT renounced — strong Multisig (20-of-32)
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 30% (99.4% total → 40.3% effective; 1.0% in EOAs, 98.4% in contracts — moderate)
  • 1 Critical finding(s) from audit
  • 1 High finding(s) from audit
  • 1 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

Related Audits

6 more on the record
Unibase (UB)High RiskCapHigh RiskVELOHigh RiskGriotHigh RiskSTABLEHigh RiskOLYHigh Risk

Would You Like a More Detailed Audit of AEGIS X?

Our AI-powered scanner gives you a deeper, real-time smart contract analysis — free, with every scoring factor shown.

Get Detailed Audit