ConConAI Info
People research with AI - but only a fraction let it complete a purchase, while most are open to it. That guided, trusted middle is exactly where ConConAI lives.
TrustNet Score
The TrustNet Score evaluates crypto projects based on audit results, security, KYC verification, and social media presence. This score offers a quick, transparent view of a project's credibility, helping users make informed decisions in the Web3 space.
Real-Time Threat Detection
Real-time threat detection, powered by Cyvers.io,
is currently not
activated
for this project.
This advanced feature provides continuous monitoring and instant alerts to safeguard your assets from potential security threats. Real-time detection enhances your project's security by proactively identifying and mitigating risks.
For more information, click here.
Security Assessments
Summary and Final Words
No crucial issues found
The contract does not contain issues of high or medium criticality. This means that no known vulnerabilities were found in the source code.
Ownership is not renounced
The owner retains significant control, which could potentially be used to modify key contract parameters.
Contract is not upgradeable
The contract does not use proxy patterns or other mechanisms to allow future upgrades. Its behavior is locked in its current state.
Scope of Work
This audit encompasses the evaluation of the files listed below, each verified with a SHA-1 Hash. The team referenced above has provided the necessary files for assessment.
The auditing process consists of the following systematic steps:
- Specification Review: Analyze the provided specifications, source code, and instructions to fully understand the smart contract's size, scope, and functionality.
- Manual Code Examination: Conduct a thorough line-by-line review of the source code to identify potential vulnerabilities and areas for improvement.
- Specification Alignment: Ensure that the code accurately implements the provided specifications and intended functionalities.
- Test Coverage Assessment: Evaluate the extent and effectiveness of test cases in covering the codebase, identifying any gaps in testing.
- Symbolic Execution: Analyze the smart contract to determine how various inputs affect execution paths, identifying potential edge cases and vulnerabilities.
- Best Practices Evaluation: Assess the smart contracts against established industry and academic best practices to enhance efficiency, maintainability, and security.
- Actionable Recommendations: Provide detailed, specific, and actionable steps to secure and optimize the smart contracts.
A file with a different Hash has been intentionally or otherwise modified after the security review. A different Hash may indicate a changed condition or potential vulnerability that was not within the scope of this review.
Final Words
The following provides a concise summary of the audit report, accompanied by insightful comments from the auditor. This overview captures the key findings and observations, offering valuable context and clarity.
Smart Contract Analysis Statement
Contract Analysis
The ConConAI Presale contract implements a phased, book-then-claim token sale for the already-issued $CON token, accepting USDC, USDT and ETH, recording each buyer's allocation on purchase and paying it out only after the team opens claiming. It sells across five fixed-price phases with a per-phase base cap and a global cap, prices ETH through a Chainlink feed that is checked for zero, negative, stale and incomplete answers, and awards a one-time, stacking purchase bonus that is always kept within the global cap. The code is defensively written: it follows a strict checks-effects-interactions order, guards every value-moving entry point against reentrancy, uses safe token transfers throughout, emits an event on every state change, uses a pull-pattern claim, and fixes its configuration permanently at deployment with no setters. The review found no critical, high, or medium severity issues; the observations are low severity and informational.
Ownership Privileges
The ownership of the contract has been assigned to the treasury address at deployment and is transferable only through a two-step handover. The owner retains full privileges including:
- Starting or switching the active sale phase (which sets the live price) and adjusting or ending phase timers.
- Permanently ending the presale and, independently, permanently opening claiming - both one-way actions that can never be reversed.
- Pausing and unpausing buying in an emergency, while claiming always remains available.
- Withdrawing the raised USDC, USDT and ETH, and sweeping only the surplus $CON that exceeds outstanding claims once the sale has ended.
- The owner cannot mint, since no mint path exists anywhere, and can never change a buyer's recorded allocation or reverse a claim.
- The owner can never withdraw the buyers' $CON; withdrawals of that token are explicitly blocked, and only true surplus can be swept.
- Raised funds and swept surplus can only ever be sent to the treasury address fixed at deployment, not to an arbitrary destination, even after ownership changes hands.
- There is no timelock on administrative actions, so changes take effect immediately; using a multisig for the owner and treasury is recommended, and the ability to renounce ownership should be disabled so buyer claims can never be stranded.
Security Features
The contract implements several positive security features:
- Strict checks-effects-interactions ordering with a reentrancy guard on every function that moves value, and safe token transfers used throughout.
- Immutable configuration with no setters for the token, payment assets, oracle and treasury, plus one-way lifecycle flags the owner can never unset.
- A robust price feed read that rejects zero, negative, stale and incomplete oracle answers before any ETH purchase is priced.
- Accounting that provably keeps total sold within the global cap, keeps each phase within its cap, and keeps outstanding claims fully backed, confirmed by symbolic proofs and extensive property and fuzz testing.
Note - This Audit report consists of a security analysis of the ConConAI Presale smart contract. This analysis did not include economic analysis of the contract's tokenomics. Moreover, we only audited the main contract for the ConConAI Presale team. Other contracts associated with the project were not audited by our team. We recommend investors do their own research before investing.
Files and details
Findings and Audit result
low Issues | 5 findings
Resolved
#1 low Issue
Buyers have no execution-price protection against phase changes
The two buy functions price a purchase entirely off whatever phase is active at execution time, and the admin can switch the active phase (and therefore the price, which ranges from 0.005 to 0.009 USD) at any moment. A buyer had no way to bound the price they accept, so an honest phase advance or a deliberate reordering between submission and mining could silently reduce the tokens received for the same spend. This was a transaction-ordering exposure (SWC-114) and a buyer-protection gap rather than a theft vector.
Resolved
#2 low Issue
renounceOwnership can permanently strand buyer allocations
The contract inherited the standard renounceOwnership function and did not disable it. Opening claims, ending the presale, withdrawing raised funds and sweeping surplus are all owner-only, so if the owner renounced before opening claiming, every booked allocation could become permanently unclaimable and the funding token locked in the contract with no way out.
Resolved
#3 low Issue
Payment-token decimals and fee-on-transfer assumptions are not enforced
The pricing math assumes the stablecoins have exactly 6 decimals and settle one-to-one with no transfer fee, and that the sold token has 18 decimals, but none of this was verified on-chain and the amount actually received on a stablecoin transfer was never checked. A future fee-on-transfer switch on a payment token could credit a buyer for more than the treasury received.
Resolved
#4 low Issue
Claim solvency depends on off-chain funding with no on-chain guard
Booking a purchase never checked that the contract actually held enough of the sold token to cover it; solvency relied on the treasury funding the full presale cap out of band. Claims pay out first-come-first-served, so opening claims while under-funded would let early claimers succeed and later claimers revert.
Acknowledged
#5 low Issue
ETH proceeds can be permanently locked if the treasury cannot receive ETH
Withdrawing ETH sends the whole contract balance to the immutable treasury and reverts the entire call if that transfer fails. The treasury address is fixed at deployment and there is no other route for ETH to leave the contract, so a treasury that cannot accept plain ETH would permanently trap every ETH purchase. This is specific to ETH; stablecoin withdrawals are unaffected.
optimization Issues | 4 findings
Acknowledged
#1 optimization Issue
Per-phase cap duplicates a constant in storage
The phase struct stores a cap value, but every phase cap is set to the same constant and nothing ever changes it, costing a storage slot per phase for no benefit.
Acknowledged
#2 optimization Issue
Fixed phase prices could avoid dedicated storage
Phase prices are constant for the life of the contract but are written into per-phase storage and read from storage on every purchase; a pure index-to-price function would remove those slots and reads.
Acknowledged
#3 optimization Issue
Bounded loops can skip overflow checks
Several loops iterate over small constant bounds (five phases, at most three bonus tiers). The counter increments are still checked; an unchecked counter increment would save a little gas.
Acknowledged
#4 optimization Issue
Phase struct could be packed into fewer slots
The phase struct occupies four storage slots; the amounts fit in narrower integer types, allowing tighter packing and cheaper per-purchase writes, if the redundant cap and price fields are retained.
informational Issues | 9 findings
Acknowledged
#1 informational Issue
Centralized admin control with no timelock
A single owner controls the sale lifecycle: which phase (and therefore which price) is active, all phase timers, ending the presale, opening claims, pausing buys, and withdrawing raised funds. There is no timelock, so these take effect immediately.
Acknowledged
#2 informational Issue
Withdrawals always route to the immutable treasury, not the current owner
The treasury that receives withdrawn funds and swept surplus is fixed at deployment and cannot be changed, while ownership can be handed over. A new owner can trigger withdrawals but funds always go to the original treasury address.
Resolved
#3 informational Issue
Unused constant left in the code
A USD scaling constant was declared but never referenced anywhere in the contract; the stablecoin math relies on the payment amounts already being at the 6-decimal scale.
Acknowledged
#4 informational Issue
Oracle staleness window and bounds should be confirmed for mainnet
The ETH price read validates that the answer is positive, the round is complete, and the answer is no older than one hour. The maximum-age value is a hard-coded assumption about the feed heartbeat, and the code intentionally trusts the aggregator answer without an absolute floor or ceiling.
Resolved
#5 informational Issue
Floating pragma and EVM target should be fixed for deployment
The source used a floating compiler pragma, leaving ambiguity between the audited and deployed compiler. The configured EVM target also produces PUSH0-based bytecode, which is correct for mainnet.
Acknowledged
#6 informational Issue
ETH refund requires the buyer to accept ETH
When an ETH purchase produces a refund (from cap clamping or rounding), the contract sends the excess back and reverts the whole purchase if that send fails. A contract buyer without a payable fallback would be unable to complete a refund-bearing purchase; externally owned accounts are unaffected.
Acknowledged
#7 informational Issue
Bonus is best-effort near the global cap
Bonus tokens are drawn from the same global cap as base sales and are clamped to whatever remains, so a buyer who unlocks a tier when the sale is almost sold out can receive a reduced bonus or none, even though the tier counter is marked awarded. This is deliberate and keeps total booked amount within the cap.
Resolved
#8 informational Issue
Reentrancy guard is not the first modifier on two admin functions
On the withdraw and sweep functions the reentrancy guard was declared after the owner-only modifier. Best practice lists the reentrancy guard first so it wraps everything else; the original ordering was harmless because the access-control check makes no external call.
Acknowledged
#9 informational Issue
Dependency and deployment-config verification before mainnet
All external addresses are immutable and set once in the constructor, so verifying them against authoritative sources at deployment is essential. Keeping the OpenZeppelin dependency at the latest patch and monitoring advisories is good hygiene, and auditing a frozen commit lets the reviewed and deployed code be proven identical.