Quantum Audit Logo

Is Field Atlas a Scam?

Early-stage security check — honeypot & rug-pull analysis

Field Atlas ATLAS
0xb462…7ba3
Base
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.
Last checked today 1 audit on record New Launch · 10h old
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

The DopplerERC20V1 contract implements an ERC20 token with vesting functionalities and a balance limit mechanism. The audit identified a Medium overall risk level, primarily due to hardcoded tokenomic parameters, centralized control over the balance limit, and potential upgrade safety concerns related to storage slot management. The contract leverages Solady libraries, demonstrating good code quality and adherence to upgradeability patterns, but specific design choices introduce inflexibility and single points of control.

1 High2 Medium1 Low1 Informational
! Early-stage analysis. This token has limited on-chain history (10h old). New tokens carry elevated risk — data may change rapidly. Always verify independently before investing.
Volume 24h
$660.3K
Liquidity
$82.7K
Price
$0.000001671
Token Age
10h
Top 10 Holders
62.4%

Security Findings

1 High2 Med1 Low1 Info
High

Inflexible Hardcoded Constants for Tokenomics

H-01The contract utilizes several hardcoded constants for critical tokenomic parameters, including `MAX_PRE_MINT_PER_ADDRESS_WAD`, `MAX_TOTAL_PRE_MINT_WAD`, and `MIN_VESTING_DURATION`. Additionally, `maxBalanceLimit` is set during initialization and cannot be subsequently modified. This design choice significantly limits the protocol's flexibility to adapt to evolving market conditions, adjust token distribution strategies, or modify vesting terms without requiring a full contract upgrade (7.4 Economic).
IssueThe contract utilizes several hardcoded constants for critical tokenomic parameters, including `MAX_PRE_MINT_PER_ADDRESS_WAD`, `MAX_TOTAL_PRE_MINT_WAD`, and `MIN_VESTING_DURATION`. Additionally, `maxBalanceLimit` is set during initialization and cannot be subsequently modified. This design choice significantly limits the protocol's flexibility to adapt to evolving market conditions, adjust token distribution strategies, or modify vesting terms without requiring a full contract upgrade (7.4 Economic).
FixConsider making critical tokenomic parameters configurable by the owner or a governance mechanism. This could involve adding setter functions for `maxBalanceLimit` (with appropriate access control and potentially a timelock) and allowing for the creation of new vesting schedules with different `MIN_VESTING_DURATION` or other parameters. For pre-mint caps, if flexibility is desired, they could be made adjustable or removed if no longer necessary.
StatusUnresolved
Medium

Centralized Control by Controller Role

M-01The `controller` address possesses the sole authority to call `disableBalanceLimit()`, which completely deactivates the balance limit mechanism. If this `controller` address is compromised or acts maliciously, it can bypass a core security feature designed to restrict token holdings, potentially leading to unintended token distribution or market manipulation (7.3 Access Control, 7.5 Governance). While the `owner` is a multisig, the `controller`'s ownership is not specified as such.
IssueThe `controller` address possesses the sole authority to call `disableBalanceLimit()`, which completely deactivates the balance limit mechanism. If this `controller` address is compromised or acts maliciously, it can bypass a core security feature designed to restrict token holdings, potentially leading to unintended token distribution or market manipulation (7.3 Access Control, 7.5 Governance). While the `owner` is a multisig, the `controller`'s ownership is not specified as such.
FixEnhance the security of the `controller` role. It is strongly recommended to assign this role to a multi-signature wallet or a time-locked contract to introduce a delay or require multiple approvals for critical actions, thereby mitigating the risk of a single point of failure.
StatusUnresolved
Medium

Potential Storage Collision with LibTransient for Persistent State

M-02The `LibTransient` library is used to track persistent state (`_hasTransientSchedule`) via a fixed storage slot (`HAS_SCHEDULE_TRANSIENT_SLOT`). While `LibTransient` is typically intended for transient (single-transaction) data, its application here for persistent tracking of beneficiary schedules introduces a risk. In an upgradeable proxy environment, if a future contract upgrade introduces a new state variable that happens to occupy the same storage slot as `HAS_SCHEDULE_TRANSIENT_SLOT`, it could lead to a storage collision, corrupting data or causing unexpected contract behavior (7.7 Upgrades).
IssueThe `LibTransient` library is used to track persistent state (`_hasTransientSchedule`) via a fixed storage slot (`HAS_SCHEDULE_TRANSIENT_SLOT`). While `LibTransient` is typically intended for transient (single-transaction) data, its application here for persistent tracking of beneficiary schedules introduces a risk. In an upgradeable proxy environment, if a future contract upgrade introduces a new state variable that happens to occupy the same storage slot as `HAS_SCHEDULE_TRANSIENT_SLOT`, it could lead to a storage collision, corrupting data or causing unexpected contract behavior (7.7 Upgrades).
FixRe-evaluate the use of `LibTransient` for persistent state. For persistent data, it is safer to use standard Solidity state variables or a dedicated storage pattern that guarantees unique storage slots. If `LibTransient` must be used, ensure that the chosen slot is explicitly reserved and documented, and that all future upgrades are meticulously checked for potential storage collisions with this slot.
StatusUnresolved
Low

Complex Initialization Function

L-01The `initialize` function accepts a large number of parameters, including multiple arrays for vesting schedules, beneficiaries, and amounts. This complexity increases the likelihood of human error during deployment, potentially leading to incorrect initial configurations, misconfigured vesting schedules, or missed exclusions from the balance limit (7.1 Architecture, 7.8 Operations).
IssueThe `initialize` function accepts a large number of parameters, including multiple arrays for vesting schedules, beneficiaries, and amounts. This complexity increases the likelihood of human error during deployment, potentially leading to incorrect initial configurations, misconfigured vesting schedules, or missed exclusions from the balance limit (7.1 Architecture, 7.8 Operations).
FixConsider breaking down the initialization into smaller, more manageable functions if feasible, or provide comprehensive deployment scripts and clear documentation. Implement robust pre-deployment checks and simulations to verify the correctness of all parameters before actual deployment.
StatusUnresolved
Info

Unused `pool` Variable After Locking

I-01The `pool` address is set and `isPoolLocked` is activated in `lockPool()`, and the `pool` address is explicitly excluded from the balance limit. However, the `pool` variable itself is not directly referenced or utilized in any further internal logic within the provided contract code. While its exclusion from the balance limit is a functional effect, the variable's lack of direct interaction elsewhere might indicate incomplete functionality or a design choice where its purpose is purely external to this contract's internal logic (7.1 Architecture).
IssueThe `pool` address is set and `isPoolLocked` is activated in `lockPool()`, and the `pool` address is explicitly excluded from the balance limit. However, the `pool` variable itself is not directly referenced or utilized in any further internal logic within the provided contract code. While its exclusion from the balance limit is a functional effect, the variable's lack of direct interaction elsewhere might indicate incomplete functionality or a design choice where its purpose is purely external to this contract's internal logic (7.1 Architecture).
FixClarify the intended purpose and interaction of the `pool` variable. If it's solely for external reference and balance limit exclusion, this can be documented. If it's meant to be used internally, ensure all intended functionalities are implemented.
StatusUnresolved

Category Ratings

TechnicalLow8/10

The contract demonstrates good technical practices, utilizing battle-tested Solady libraries for ERC20, Ownable, and Initializable functionalities, which enhances code security (7.2 Code Security). Error handling is robust with custom errors, and key state changes are accompanied by events (7.8 Operations). However, the `initialize` function's extensive parameter list introduces complexity, increasing the potential for deployment errors (7.1 Architecture). Additionally, the use of `LibTransient` for persistent state tracking carries a risk of storage collision during future upgrades (7.7 Upgrades).

GovernanceHigh3/10

The protocol implements a vesting mechanism with configurable schedules, ensuring controlled token distribution (7.4 Economic). Access control for critical functions like pool locking and token URI updates is appropriately restricted to the `owner` (7.3 Access Control), which is a 3/6 multisig, mitigating centralization (7.5 Governance). However, the `controller` role, responsible for disabling the balance limit, represents a single point of failure if compromised (7.3 Access Control). Furthermore, several key tokenomic parameters, such as `maxBalanceLimit` and pre-mint caps, are hardcoded or set immutably during initialization, limiting future adaptability (7.4 Economic).

UpgradesLow7/10

The contract is designed as an upgradeable proxy implementation, correctly using Solady's `Initializable` and disabling its constructor (7.7 Upgrades). This pattern allows for future enhancements and bug fixes without redeploying the entire system. However, the reliance on `LibTransient` for persistent state tracking via a fixed storage slot introduces a potential for storage collisions if future upgrades introduce new state variables at the same slot (7.7 Upgrades). Careful storage slot management is crucial for safe upgrades.

Security Checklist

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

Holder Composition

62.4% in top 10
11.2% in wallets51.2% in contracts
Effective Concentration31.7%

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

$82.9K across 4 pairs
Uniswap v4WETHanalysed$82.7K99.8%Uniswap v4USDC$1080.1%Uniswap v4USDC$230.0%Uniswap v4ETH$100.0%

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 Holder22.9%
Top-3 Unlocked55.0%

Key Addresses

11 addresses
Deployer
0x2fbf…ec65
Unlocked LP Held By
0x2b43…ae980xc796…6c470x873f…03490x63e5…4cb60xa6f3…e1680x72b5…5a230xc43a…d5160x5c9b…0a8b0xe19a…5a740xaae8…b145

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 — owner is a contract (governance/executor, not an EOA)
  • Top-10 concentration > 30% (62.4% total → 31.7% effective; 11.2% in EOAs, 51.2% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • Token age < 24h (brand new — bot activity, unproven)
  • 1 High finding(s) from audit
  • 2 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
AUTONOMOPOLY (AUTONO)High RiskSolana (SOL)High RiskTAOTHigh RiskCheckmate (CHECK)High RiskSoSoValue (SOSO)High RiskSally (A1C)High Risk

Would You Like a More Detailed Audit of Field Atlas?

This token is brand new. Run a deeper AI-powered analysis of the contract code — free and instant.

Get Detailed Audit