Quantum Audit Logo

Is A Society For AI Agents Safe?

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

A Society For AI Agents 1F916
0x9e00…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 7d ago 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

The audit covers the DopplerERC20V1 implementation contract, which functions as an ERC20 token with vesting capabilities, a balance limit mechanism, and a pool locking feature. The contract utilizes Solady libraries for efficiency and security. A significant economic risk was identified regarding the interpretation of pre-mint limits, potentially allowing for highly concentrated initial token distribution. Centralized control by the owner and controller roles also presents a medium risk. The core vesting logic was partially truncated in the provided source, limiting a full assessment of these critical functions.

1 High1 Medium1 Low2 Informational
Volume 24h
$356.3K
Liquidity
$585.9K
Price
$0.00003519
Token Age
1mo
Top 10 Holders
43.8%

Security Findings

1 High1 Med1 Low2 Info
High

High Pre-Mint Allocation Limits

H-01The constants `MAX_PRE_MINT_PER_ADDRESS_WAD` and `MAX_TOTAL_PRE_MINT_WAD` are defined as `0.8 ether`. In the `initialize` function, these are used to calculate `maxPreMintPerAddress` and `maxTotalPreMint` as `initialSupply * CONSTANT_WAD / WAD`. This calculation effectively sets the limits to 80% of the `initialSupply`. This means a single beneficiary can be allocated up to 80% of the total initial supply, and the total pre-minted amount across all beneficiaries can also be up to 80% of the initial supply. This could lead to an unintended highly concentrated initial token distribution, undermining decentralization goals or creating significant market manipulation risks (7.4 Economic).
IssueThe constants `MAX_PRE_MINT_PER_ADDRESS_WAD` and `MAX_TOTAL_PRE_MINT_WAD` are defined as `0.8 ether`. In the `initialize` function, these are used to calculate `maxPreMintPerAddress` and `maxTotalPreMint` as `initialSupply * CONSTANT_WAD / WAD`. This calculation effectively sets the limits to 80% of the `initialSupply`. This means a single beneficiary can be allocated up to 80% of the total initial supply, and the total pre-minted amount across all beneficiaries can also be up to 80% of the initial supply. This could lead to an unintended highly concentrated initial token distribution, undermining decentralization goals or creating significant market manipulation risks (7.4 Economic).
FixClarify the intended purpose of `MAX_PRE_MINT_PER_ADDRESS_WAD` and `MAX_TOTAL_PRE_MINT_WAD`. If these are meant to be absolute token amounts, they should be used directly without multiplying by `initialSupply` and dividing by `WAD`. If they are intended as percentages, consider if 80% is an appropriate and safe limit for initial distribution. Adjust these constants or the calculation logic to reflect the desired maximum allocation per address and total pre-minted amount.
StatusUnresolved
Medium

Centralized Control Over Critical Functions

M-01The contract grants significant control to single addresses for critical operations. The `owner` (an `Ownable` role) can `lockPool`, `unlockPool`, and `updateTokenURI`. The `controller` address, set during initialization, can `disableBalanceLimit`. These centralized roles represent single points of failure and could be exploited if the private keys are compromised, leading to potential manipulation of the token's operational state or economic parameters (7.3 Access Control, 7.5 Governance).
IssueThe contract grants significant control to single addresses for critical operations. The `owner` (an `Ownable` role) can `lockPool`, `unlockPool`, and `updateTokenURI`. The `controller` address, set during initialization, can `disableBalanceLimit`. These centralized roles represent single points of failure and could be exploited if the private keys are compromised, leading to potential manipulation of the token's operational state or economic parameters (7.3 Access Control, 7.5 Governance).
FixConsider implementing a multi-signature wallet (e.g., Gnosis Safe) for the `owner` and `controller` roles. This would require multiple approvals for critical actions, significantly reducing the risk associated with a single point of compromise. Alternatively, explore time-locks or community governance mechanisms for highly sensitive operations.
StatusUnresolved
Low

Reliance on block.timestamp for Vesting

L-01The vesting calculations and `balanceLimitEnd` rely on `block.timestamp`. While standard practice, `block.timestamp` can be manipulated by miners within a small window (up to 900 seconds on Ethereum, similar on other EVM chains) to slightly influence vesting schedules or the balance limit expiry. This could potentially be exploited for minor time-sensitive advantages (7.6 External).
IssueThe vesting calculations and `balanceLimitEnd` rely on `block.timestamp`. While standard practice, `block.timestamp` can be manipulated by miners within a small window (up to 900 seconds on Ethereum, similar on other EVM chains) to slightly influence vesting schedules or the balance limit expiry. This could potentially be exploited for minor time-sensitive advantages (7.6 External).
FixFor critical time-sensitive operations, consider using a decentralized oracle for time if precise, unmanipulable time is paramount. For vesting and balance limits, `block.timestamp` is generally acceptable, but acknowledge the inherent minor risk. Ensure that any time-sensitive actions do not have severe consequences if slightly delayed or accelerated by miner manipulation.
StatusUnresolved
Info

Truncated Core Vesting Logic

I-01The provided source code for the `DopplerERC20V1` contract was truncated, specifically omitting the full implementation of the `_available` and `_releaseAllFor` internal functions. These functions are critical for correctly calculating and releasing vested tokens. Without the complete code, a thorough security assessment of the core vesting logic cannot be performed, impacting the overall confidence in the audit of this functionality (7.2 Code Security).
IssueThe provided source code for the `DopplerERC20V1` contract was truncated, specifically omitting the full implementation of the `_available` and `_releaseAllFor` internal functions. These functions are critical for correctly calculating and releasing vested tokens. Without the complete code, a thorough security assessment of the core vesting logic cannot be performed, impacting the overall confidence in the audit of this functionality (7.2 Code Security).
FixProvide the complete, untruncated source code for all contract functions, especially those central to the contract's primary functionality (e.g., vesting calculations and releases). A full review of these functions is essential to ensure their correctness, prevent calculation errors, and identify potential reentrancy or other vulnerabilities.
StatusUnresolved
Info

Short Minimum Vesting Duration

I-02The constant `MIN_VESTING_DURATION` is set to `1 days`. This is a relatively short minimum duration for vesting schedules, meaning tokens can become available for release very quickly after the vesting start. While this might be an intentional design choice, it reduces the long-term holding incentive typically associated with vesting (7.4 Economic).
IssueThe constant `MIN_VESTING_DURATION` is set to `1 days`. This is a relatively short minimum duration for vesting schedules, meaning tokens can become available for release very quickly after the vesting start. While this might be an intentional design choice, it reduces the long-term holding incentive typically associated with vesting (7.4 Economic).
FixConfirm that a minimum vesting duration of 1 day aligns with the project's tokenomics and distribution strategy. If the intention is to encourage longer-term commitment or prevent immediate token dumps, consider increasing this minimum duration.
StatusUnresolved

Category Ratings

TechnicalLow8/10

The DopplerERC20V1 contract is built on robust Solady libraries, enhancing code quality and gas efficiency (7.2 Code Security). It correctly implements the Initializable pattern for proxy compatibility and uses custom storage slots for transient state (7.1 Architecture, 7.7 Upgrades). The contract demonstrates good error handling and adherence to Solidity best practices. However, the core vesting calculation logic (`_available`, `_releaseAllFor`) was truncated in the provided source, limiting a full security assessment of these critical functions (7.2 Code Security).

GovernanceMedium4/10

The contract features a vesting mechanism to distribute tokens over time and a temporary balance limit to manage initial token concentration (7.4 Economic). However, the interpretation of `MAX_PRE_MINT_PER_ADDRESS_WAD` and `MAX_TOTAL_PRE_MINT_WAD` as percentages of `initialSupply` allows for up to 80% of the total supply to be allocated to a single address or across all pre-minted beneficiaries, which could lead to highly centralized token distribution (7.4 Economic). Critical functions like `lockPool`, `unlockPool`, `updateTokenURI`, and `disableBalanceLimit` are controlled by a single `owner` or `controller` address, posing a centralization risk (7.3 Access Control, 7.5 Governance).

UpgradesLow7/10

The DopplerERC20V1 contract is designed as an upgradeable implementation using Solady's Initializable pattern, correctly disabling initializers in the constructor and using an `initialize` function (7.7 Upgrades). The use of custom storage slots for transient data (`HAS_SCHEDULE_TRANSIENT_SLOT`) helps prevent storage collisions in future upgrades (7.7 Upgrades). The storage layout appears to follow best practices for upgradeability, minimizing the risk of issues during future upgrades (7.7 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

43.8% in top 10
10.7% in wallets33.1% in contracts
Effective Concentration23.9%

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

$586.2K across 13 pairs
Uniswap v4WETHanalysed$585.9K99.9%Uniswap v4USDC$1850.0%Uniswap v4USDC$870.0%Uniswap v4USDC$160.0%Uniswap v4ETH$100.0%Uniswap v4USDC$50.0%
Show 4 more pairsShow less
Uniswap v4USDC$40.0%Uniswap v4USDC$30.0%Uniswap v4USDC$30.0%Uniswap v4USDC$20.0%

The 3 remaining pairs hold $1 between them and are not listed.

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 Holder54.4%
Top-3 Unlocked80.7%

Key Addresses

9 addresses
Deployer
0x6a6f…be41
Unlocked LP Held By
0xd1c6…a0c00x3662…ba860x72b5…5a230x3dd5…599d0x85f9…ea620x359a…63450xd952…36b00xb35e…c058

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

What Raised This Score

8 factors
  • Ownership NOT renounced — owner is a contract (governance/executor, not an EOA)
  • Top-10 concentration > 20% (43.8% total → 23.9% effective; 10.7% in EOAs, 33.1% in contracts — mild)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 54.4% (independent LP — depth risk)
  • LP top3 unlocked holders = 80.7% (independent LP — depth risk)
  • 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
Coinbase Wrapped Staked ETH (CBETH)High RiskThe Innovation Game (TIG)High RiskBasemateHigh RiskCAPACITRHigh RiskKAITOHigh RiskiPodHigh Risk

Would You Like a More Detailed Audit of A Society For AI Agents?

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

Get Detailed Audit