Comprehensive smart contract security review of the V3Launch protocol — covering V3TokenFactory (v6), V3Launch, and AcornOracle contracts deployed on Robinhood Chain.
The V3Launch protocol achieves a strong security posture through structural immutability, no admin privileges, and a no-rug architecture enforced at the contract level. All findings have been resolved or formally acknowledged. The protocol is safe for public use.
This review covers all smart contracts comprising the Launch by Acorn V3Launch system. The audit was performed with full access to contract source code, deployment scripts, and test suites.
collectFees().The V3Launch system consists of three contracts with clearly separated responsibilities and minimal external dependencies.
| Contract | Key Functions | Privileged Roles | Upgradeable |
|---|---|---|---|
| V3TokenFactory | createToken(name, symbol, ...metadata) |
None | No |
| V3Launch | collectFees() |
None | No |
| AcornOracle | updatePrice(price), getPrice() |
Keeper (price update only) | No |
| Token ERC-20 | Standard ERC-20 (transfer, approve, etc.) | None | No |
Total supply of 1,000,000,000 tokens is minted exactly once at creation and never changes. No mint or burn functions exist post-deployment.
The Acorn LP NFT is held by the V3Launch contract with no transfer or withdrawal path. Liquidity is structurally locked forever.
CREATOR_BPS = 8000, PLATFORM_BPS = 2000. These are compile-time constants. No function can alter them.
Fees are distributed exclusively as WETH via ERC-20 transfer, preventing ETH-rejection DoS attacks from malicious recipient contracts.
| ID | Title | Severity | Contract | Status |
|---|---|---|---|---|
| LA-M-01 | Fee distribution DoS via native ETH transfer | Medium | V3Launch (v1–v4) | Fixed |
| LA-M-02 | Oracle staleness allows stale-price token launches | Medium | AcornOracle | Fixed |
| LA-L-01 | Missing event emission on fee collection | Low | V3Launch | Fixed |
| LA-L-02 | No zero-address check for creator at construction | Low | V3Launch | Fixed |
| LA-L-03 | Oracle keeper role has no multi-sig enforcement | Low | AcornOracle | Acknowledged |
| LA-I-01 | Public collectFees() — no access control by design | Info | V3Launch | Acknowledged |
| LA-I-02 | Single-sided LP initial position — natural price impact | Info | V3Launch | Acknowledged |
In V3Launch contract versions v1 through v4, the collectFees() function distributed fees using native ETH transfers (address.call{value: amount}("")) to both the creator and the platform treasury. A malicious token creator could deploy a smart contract wallet that reverts on ETH receipt — for example, via a fallback function that always reverts — causing the entire collectFees() call to revert. This would permanently block the platform from collecting its 20% fee share from that token, as any call to collectFees() would revert.
This is a well-known DoS pattern in Solidity. While it does not endanger user funds or liquidity, it represents a griefing attack that harms platform revenue.
Fixed in V3Launch (v6): Fee distribution was changed to use WETH (ERC-20 transfers) exclusively. Since ERC-20 transfer() does not trigger a recipient's fallback function, a malicious creator contract cannot block distribution. The recipient cannot reject a WETH transfer by reverting. The current implementation calls IWETH(weth).transfer(creator, creatorAmount) and IWETH(weth).transfer(treasury, platformAmount), both of which are atomic and cannot be blocked by the recipient. Creators can unwrap WETH to ETH via any WETH contract or Acorn at any time.
The AcornOracle stores a single ETH/USD price updated by a permissioned keeper. In the initial implementation, the factory contract did not validate the age of the stored price before using it to compute the initial pool price. If the keeper failed to update the oracle for an extended period (due to a keeper outage, bug, or key compromise), new tokens could launch at a significantly incorrect FDV target — potentially launching at a very low or very high price relative to the actual ETH market price.
For example, if ETH price doubled while the oracle was stale, newly launched tokens would open at half their intended FDV. Conversely, if ETH price dropped by 50%, new tokens would open at double the intended FDV. Either scenario creates a poor user experience and potential for exploitation.
Fixed in AcornOracle (current): The oracle now stores a lastUpdatedBlock timestamp alongside the price. The factory's createToken() function checks that block.number - lastUpdatedBlock <= STALENESS_THRESHOLD where STALENESS_THRESHOLD = 92_200 blocks (approximately 24 hours at Robinhood Chain's block time). If the check fails, the factory reverts with a descriptive error, preventing token creation until the keeper refreshes the price. This ensures tokens can only be launched when the FDV target is based on a recent market price.
Early versions of the V3Launch contract did not emit a structured event when collectFees() was called and fees were distributed. This made it impossible to track fee distribution activity through event indexing alone — off-chain systems monitoring creator earnings had to parse raw ERC-20 transfer events and correlate them by transaction hash, which is fragile and complex.
Fixed in current V3Launch: A FeesCollected(address indexed creator, uint256 creatorAmount, uint256 platformAmount, uint256 totalWeth) event is now emitted on every successful collectFees() call. This provides a clean, indexed event stream for off-chain monitoring, analytics, and the Platform's fee-tracking dashboard.
In early contract versions, the V3Launch constructor accepted a creator address parameter without validating that it was not the zero address (address(0)). If the factory were called with a zero creator address — due to a bug in the factory or a direct factory call — the resulting V3Launch contract would permanently send 80% of all collected fees to address(0), burning them irreversibly. While practical exploitation required a factory-level bug (which was independently protected), defense-in-depth demands per-contract input validation.
Fixed in current V3Launch: The constructor now includes require(creator != address(0), "V3Launch: zero creator"). Additionally, the factory contract validates that msg.sender != address(0) before passing the creator address. Both layers of validation are in place in the current deployed system.
The AcornOracle's price update function is restricted to a single keeper address (onlyKeeper modifier). This creates a single point of failure: if the keeper's private key is lost or compromised, the oracle either stops updating (triggering the staleness protection and halting launches) or is used to post a manipulated price. A multi-signature wallet as the keeper would require multiple parties to authorize price updates, reducing this risk.
Acknowledged — Mitigated by Staleness Protection: The team acknowledges this finding. The staleness protection (92,200 block window) partially mitigates the risk: a compromised keeper that posts a manipulated price can only affect tokens launched within that window before the manipulation is detected and the keeper address is rotated. The team plans to migrate the keeper role to a multi-sig wallet in a future oracle deployment. All oracle price updates are publicly visible on-chain and can be monitored by any party.
The collectFees() function is callable by any address without restriction. An external actor (bot, aggregator, or anyone) can trigger fee distribution at any time. This means the creator does not need to call the function themselves — fees will be distributed regardless of creator action. However, it also means a bot could call collectFees() on very small accrued amounts, wasting gas without meaningful fee transfer. There is no minimum fee threshold before collection.
Acknowledged — By Design: Permissionless fee collection is an intentional design choice. It ensures fees are never permanently locked due to creator inaction and allows any keeper service to collect fees on the creator's behalf automatically. The gas cost of a sub-threshold call is borne entirely by the caller, not the creator or platform — there is no economic incentive to call collectFees() on negligible balances.
The initial LP position is entirely single-sided: 990,000,000 tokens, zero WETH. While the pool's spot price is initialized at the target FDV, a buyer who purchases a significant amount of the token immediately after launch will experience price impact consistent with the constant-product AMM formula. For large buys, the effective cost-per-token is substantially higher than the spot price would suggest. This is expected AMM behavior, not a vulnerability — but it may be counterintuitive to users who compare the UI's estimated receive amount with the spot price.
Acknowledged — By Design: Price impact on large trades is a fundamental property of all AMMs, including Acorn. The launch.acorn frontend now uses a constant-product price-impact formula to estimate received tokens rather than a naive spot-price calculation, giving users an accurate pre-trade estimate. Users are advised to set appropriate slippage tolerance and review the UI estimate carefully before trading, especially on low-volume tokens.
The following security properties were explicitly verified during the audit:
owner, admin, or privileged role. No party — including the Launch by Acorn team — can pause, modify, drain, or destroy deployed contracts. The only privileged role in the entire system is the oracle keeper, which can only update the ETH/USD price.
UUPS, TransparentProxy, Beacon), no delegatecall, and no self-destruct. Contract bytecode is immutable post-deployment. Verified via bytecode analysis.
collectFees() function applies OpenZeppelin's ReentrancyGuard (nonReentrant modifier) before any external calls. State updates (marking fees as claimed) occur before WETH transfers, following the checks-effects-interactions pattern.
CREATOR_BPS + PLATFORM_BPS == 10000) is verified at compile time via a require in the constructor.
receive() or fallback() function. Any attempt to send native ETH directly to the contract will revert. This prevents accidental ETH lockup and reinforces that all value flows through WETH.
safeTransferFrom, transferFrom, approve, or any other NFT transfer path. The LP NFT cannot leave the V3Launch contract by any means.
Beyond vulnerability identification, the audit verified that the protocol's stated mechanics are correctly implemented in the contract code.
| Recipient | Share | Basis Points | Token | Constant in Contract |
|---|---|---|---|---|
| Token Creator | 80% | 8,000 | WETH | CREATOR_BPS = 8000 |
| Platform Treasury | 20% | 2,000 | WETH | PLATFORM_BPS = 2000 |
| Total | 100% | 10,000 | — | Verified: CREATOR_BPS + PLATFORM_BPS == 10_000 |
| Recipient | Tokens | Percentage | Mechanism |
|---|---|---|---|
| Platform Treasury | 10,000,000 | 1% | Minted directly to treasury at token creation |
| Acorn LP (locked) | 990,000,000 | 99% | Transferred to V3Launch, deposited as full-range LP |
| Token Creator | 0 | 0% | No creator allocation |
| Total | 1,000,000,000 | 100% | Fixed supply, no further minting possible |
~$1,700 USD. Verified that TARGET_FDV_USD8 = 1_700e8 is correctly read from the oracle and used in the sqrtPriceX96 computation.
1% (fee = 10,000 in Acorn pool notation). Verified that all pools are created with fee = 10_000. No other fee tier is used.
Each launched token is paired exclusively with WETH. No other quote currency is supported. WETH address is immutable in the factory.
Staleness threshold: 92,200 blocks (~24h). Verified that factory reverts with "Oracle: stale price" when threshold is exceeded.
All contracts are deployed on Robinhood Chain (EVM-compatible, chainId 4663). Addresses can be verified on the Robinhood Chain block explorer.
Previous factory versions (v1–v5) are still deployed but are no longer used for new token launches. Tokens launched on previous factories remain fully functional.
The Launch by Acorn V3Launch protocol demonstrates a strong and thoughtful security architecture. The protocol achieves its stated goals — permissionless token deployment, permanent liquidity locking, and automatic creator fee distribution — through immutable, audited smart contracts with no admin privileges.
The most significant finding (LA-M-01, fee distribution DoS) was correctly identified and remediated in the v5 factory deployment by switching to WETH-based fee distribution. The oracle staleness finding (LA-M-02) was addressed with a 24-hour freshness window. All remaining findings are low-severity or informational, with acknowledged design trade-offs that are reasonable given the protocol's goals.
The no-rug architecture — zero creator token allocation, permanently locked LP, and no admin withdrawal path — is correctly implemented and verifiable on-chain. The immutable fee split (80/20 WETH) is enforced at the contract level and cannot be changed by any party after deployment.
Verdict: Safe for public use. The V3Launch protocol is suitable for production deployment on Robinhood Chain. Users, token creators, and traders can verify the security properties described in this report by reading the on-chain contract bytecode and published source code.