COOKDEX · OFFICIAL DOCUMENTATION

One protocol. Clear documentation.

CookDEX V2 & V3, Cookchain, swap.cookscan.net, liquidity, analytics, launch markets and integration references.

Contract registry ↓Pool analytics ↗Cookchain swap ↗

Published 3 October 2026 · Registry generated from active configuration · Application V2.834

1. Protocol overview

CookDEX is a decentralized-exchange and analytics portal. It combines wallet-based trading, liquidity-pool discovery, price charts, transaction history, token profiles and creator tools. CookDEX deployments use chain-specific smart contracts; a network, token address and pool address together identify a market.

The portal distinguishes its own CookDEX liquidity pools from third-party DEX pools and from pre-migration bonding curves. A token may have several pools. Selecting a specific pair preserves that market; a token-only link uses the configured default-market selection. Displaying a token on CookDEX does not imply an endorsement, independent audit or guaranteed liquidity.

Users retain control of their wallets. Normal trading and liquidity operations require wallet-authorized on-chain transactions. The website can prepare calldata and display estimates, but a successful HTTP response, submitted transaction hash or saved workflow is not proof that execution succeeded. Check the mined receipt and transaction status.

2. Official applications and Cookchain

cookdex.net is the main analytics and trading portal. swap.cookscan.net is the Cookchain swap interface. On Cookchain, the two applications use the same CookDEX routers and factories: they are frontends to the same underlying protocol, not separate liquidity venues. The same factory pair or V3 pool has the same on-chain reserves regardless of which interface submits a trade. Frontend features, route selection and displayed caches can differ.

Cookscan at cookscan.net is the Cookchain explorer. Cookchain uses COOK as its native gas asset and wCOOK as the wrapped ERC-20 representation used by pool contracts. Native COOK and wCOOK are distinct balances. Wrapping or unwrapping does not move funds between chains. Bridged wCOOK on Base or another network is a chain-specific contract and must not be confused with native Cookchain wCOOK.

The current network IDs, wrapped tokens and configured DEX contracts are listed in the live registry below. Always obtain network details from that registry or the wallet network selector rather than copying old screenshots. Never enter a seed phrase or private key into an explorer, swap page or support message.

CookDEX portal ↗Cookchain swap ↗Cookscan explorer ↗Public Cookchain logo (WebP) ↗

3. Contract roles and the live deployment registry

A V2 factory creates and enumerates pair contracts. A V2 router quotes paths and coordinates swaps and liquidity operations. The pair itself holds the tokens and records reserves. The router address is not the pair address. A V3 factory creates pools for a token pair and fee tier; liquidity positions are managed through a separate NFT position manager.

A V3 quoter is a quote/simulation contract, not a pool factory, liquidity holder or execution router. A platform registering a V3 deployment may require a compatible quoter address in addition to its factory and router. A V2 router cannot be substituted for a V3 quoter. An omitted role in the registry means that this documentation has no configured address for that role; it must not be inferred from another chain.

The registry is generated from the active CookDEX configuration, including retained deployment records. It is not an independent code audit, a bytecode-presence check or a promise that every configured contract is currently usable. Before integration, check the chain ID, deployed bytecode, explorer verification, contract version, permissions and the relationship between factory, router and wrapped native token. Contract upgrades normally involve a new deployment; old pools may continue to exist.

4. CookDEX V2: pairs, swaps and liquidity

V2 uses constant-product automated-market-maker pairs. In the simplified model x × y = k, x and y are the two token reserves. Buying changes the reserve ratio, so the final execution price differs from the pre-trade spot price. Fees, integer rounding, token decimals and transfer restrictions must be included when constructing quotes.

Factory integrations use getPair(tokenA, tokenB), allPairs and allPairsLength. Pairs expose token0, token1, getReserves and ERC-20 LP-token balances. A router commonly exposes factory, WETH, getAmountsOut and getAmountsIn, swapExactTokensForTokens, native-asset swap variants, addLiquidity and removeLiquidity. The WETH-style method name can refer to the chain’s wrapped native asset, including wCOOK, rather than Ethereum WETH.

Standard V2 pairs charge a 0.30% swap fee in the usual constant-product implementation. Check the exact deployed implementation before applying this assumption to external or custom pools. Transfer-tax tokens may require supporting-fee-on-transfer router methods and can make estimated amounts unreliable. An approval authorizes the spender named in that transaction; approving a factory instead of the actual router does not authorize a router swap.

Liquidity deposits mint LP tokens representing a share of the pair. Withdrawals burn the depositor’s LP tokens and return a proportional share of the reserves. Changing reserve ratios can cause impermanent loss relative to holding the assets. Existing V2 pools are not automatically replaced when a new router or auxiliary fee contract is deployed.

5. CookDEX V3: concentrated liquidity

V3 liquidity is allocated to a price range. A position earns swap fees only while it is active at the traded price. A position outside its range can hold effectively one asset and need not earn fees even when the wider pool trades heavily. Multiple pools may exist for the same token pair at different fee tiers.

A V3 factory integration identifies a pool with getPool(tokenA, tokenB, fee). Read token0, token1, fee, tickSpacing, liquidity and slot0 from the deployed pool. Pool liquidity is an implementation-specific liquidity measure, not an ERC-20 reserve balance or USD TVL. Correct valuation needs token decimals, token prices, sqrtPriceX96, tick information and position ranges.

The position manager represents positions as NFTs and handles minting, increasing liquidity, decreasing liquidity and collecting tokens. The swap router executes trades. A compatible quoter simulates swap results. Integrators must use the ABI of the exact router/quoter version: similarly named V3 contracts can accept different parameter structures.

Displayed fee tiers, such as 0.10% or 0.30%, belong to the selected pool, not to the entire chain. Position collectable balances, liquidity withdrawn but not yet collected, LP trading fees and protocol fees are separate accounting concepts. Do not equate a high pool-wide volume with a particular position’s collectable amount.

6. Trading fees, protocol fees, burned LP and locks

For ordinary V2 pairs, LP trading fees remain inside the reserves and are reflected in the value redeemable by LP tokens. They are not generally a separate claimable balance. With an activated protocol-fee mechanism, protocol LP tokens may be minted on a liquidity event. An auxiliary fee vault cannot retroactively convert all accumulated LP trading fees into a separately claimable reward.

If V2 LP tokens are permanently burned, their holder cannot redeem liquidity or the fees embedded in that liquidity. A time-locked LP position is subject to the locker’s actual unlock and withdrawal rules. Burning LP tokens and locking LP tokens are different actions. Configuring a fee controller does not bypass the ownership rules of burned or locked LP.

V3 fees are accounted for by position and may be collected by an authorized position owner or approved operator, subject to the actual manager, locker or burn arrangement. Protocol fees are distinct from liquidity-provider fees. APR shown in the portal is an annualized estimate derived from recent volume, the pool fee and liquidity; it is not a promised return or a wallet-specific yield.

Network gas, token transfer taxes, launch trading fees, listing charges and ordinary pool fees are separate costs. The transaction preview and deployed contract rules take precedence over an old screenshot or marketing description.

7. Trading workflow and best-route selection

Connect a wallet, select the correct chain, select the input and output contracts, enter an amount and obtain a quote. Review the chosen market, output asset, spender, minimum received, price impact, deadline and network fee. Keep sufficient native gas available even if the input asset is USDC or wCOOK.

The portal can compare configured DEX routes. This frontend comparison is not a guarantee that every deployed router is an on-chain best-price aggregator. A selected route determines which contract executes the transaction. A bonding-curve route can require a curve or launch-aware router instead of the ordinary V2/V3 swap router.

Slippage tolerance limits execution relative to the quoted amount; it is not the same as price impact. A deadline limits how long a transaction can execute. A stale quote can fail after market movement. Increasing slippage without understanding the reason exposes users to worse execution and potential MEV.

An ERC-20 trade can require an approval followed by the swap. Native-input routes use msg.value where supported, while ERC-20-input routes transfer approved tokens. A mined failed transaction can still consume gas. If wallet sending is interrupted, check the wallet and explorer before resubmitting; do not assume that the absence of a saved hash means no transaction was sent.

8. Pool pages, charts, transactions and market data

The public pool directory is /pools. The ordinary market profile uses /token/{chain}/{tokenAddress}?pair={pairAddress}. Include the pair parameter when linking a particular pool. Omitting it requests a default market, which can change after migration or as configured pool selection changes. A token address alone is not an immutable identifier for a liquidity pool.

The profile displays available price data, candles, trades, liquidity composition, token metadata and risk indicators. These are assembled from indexed and cached data, RPC reads and external sources where applicable. Indexing and API availability can introduce delay. A missing trade or empty candle is not proof that the on-chain transaction does not exist.

Cookchart updates existing candles from available live price/trade updates without requiring a manual reload. The latest candle remains open until its interval closes. Historical candles depend on recorded or imported history. A newly activated pool with no trades does not have a genuine historical trading series; unavailable history must not be fabricated.

For virtual-reserve markets, displayed virtual liquidity describes pricing depth, not fully deposited, withdrawable backing. Real quote reserves and migration state are separate. External analytics sites decide independently whether to index CookDEX deployments or launch curves; V2-style interfaces or events alone do not guarantee third-party discovery.

Public liquidity pools ↗Cookchain wCOOK / USDC system-curve profile ↗

9. Meme EasyLaunch and migration

Meme EasyLaunch creates a token and a dedicated pre-migration market. A configured and deployed launch factory is required on the selected chain. The creator chooses among supported migration destinations; Cookchain uses CookDEX destinations. Availability on another chain depends on its actual deployment and configuration, not merely on that chain existing in the portal.

New launch defaults are expressed in USD and converted into chain-native amounts at creation. The intended standard starting pricing depth is $30,000: a $15,000 virtual wrapped-native side plus an equivalent token-side value. These virtual reserves are not a funded treasury or a promise of redemption. Existing launches retain the parameters fixed by their deployed contracts even when defaults later change.

Owner activation, the real reserves accumulated from buys and sells, the migration threshold and the allowed caller are enforced by the specific launch version. Progress measures that contract’s migration target, not token supply sold and not the trading-fee percentage. A 1% trading-fee label is not 1% migration progress.

Optional allocations can include team vesting and airdrops. Product limits allow no more than 15% team allocation and no more than 20% combined optional allocation; exact release conditions must be read from the launch configuration and deployed version. Team releases are not available before the required migration milestone. Renouncing token ownership does not remove every permission in a separate launch or vesting contract.

After successful migration, the regular DEX pool becomes the trading destination and is exposed through ordinary public pool/profile views. The migration mechanism is designed to burn the liquidity it creates. Verify the resulting pool address, minted LP destination or V3 position disposition and transaction receipt; a pending migration request is not a completed burn. Launch-aware router integration is version-dependent and must not be assumed for an old generic V2 router.

Meme EasyLaunch directory ↗

10. Existing-token system bonding curves

The wCOOK system curve is a separate product from Meme EasyLaunch. It distributes an existing ERC-20 token inventory rather than creating a new token. The launcher must supply real wCOOK inventory; only the initial quote-side pricing reserve is virtual. Cookchain uses USDC as the quote asset for this deployment. Other deployments can use the corresponding wrapped-native ERC-20 asset.

The configured system-curve design starts with a $60,000-equivalent virtual quote reserve and a $120,000-equivalent real net quote migration target, converted to fixed token units at deployment. A start price of $25.56 with a 60,000 USDC pricing reserve corresponds to approximately 2,347.417840375586854460 wCOOK inventory, subject to decimals and integer rounding. It does not mean that 60,000 USDC was deposited.

Deployment alone does not activate trading. The launcher approves the exact inventory and calls fund(). The contract verifies the received amount. quoteBuy(maximum) returns the actual quote spent and token output; a purchase near the target can spend less than the maximum. quoteSell(amount) checks that output is covered by real quote reserves. Buy and sell use minimum-output and deadline protections, and transfer-tax assets are not supported by this system-curve implementation.

The curve functions are buy(uint256 maximum, uint256 minimum, uint256 deadline) and sell(uint256 amount, uint256 minimum, uint256 deadline). They use ERC-20 transfers, not native msg.value. Approve the curve itself for the relevant input token. Read token(), quote(), active(), migrated(), ready(), realReserve(), virtualReserve(), virtualTokens() and pool() from the exact deployed contract. Trade and Funded events provide on-chain activity and activation evidence.

Once ready, the launcher can call migrate(uint16 maximumDeviationBps). The implementation limits permitted deviation to 1,000 basis points and deposits the actual collected quote into a V2 pool. It checks compatibility when an already funded pool exists; LP newly minted by this migration is permanently burned. This does not burn previously existing LP held by unrelated providers. After migration, use the regular DEX pool; curve trading is disabled. A system curve is not itself an ordinary funded V2 pair.

11. Integrating factories, routers and indexers

Start with the network registry and verify each deployment using eth_chainId, eth_getCode and the contract’s own relationship getters. Use the deployed ABI, compiler build and constructor arguments. For V2 indexing, enumerate factory pairs or process PairCreated events, then pair Mint, Burn, Swap and Sync events. For V3, process PoolCreated and the appropriate pool swap/liquidity events and position-manager events.

Normalize ERC-20 amounts by each token’s decimals. Never assume all tokens have 18 decimals or that token0 is the asset named first in the UI. Keep block numbers, log indexes, transaction hashes and pool addresses to deduplicate events. Handle chain reorganizations and distinguish confirmed history from pending transactions. Backfill in bounded ranges rather than requesting an entire chain’s logs at once.

External factory registration must use the real regular DEX factory. A launch registry, discovery adapter, launch-aware router and V2/V3 pool factory have distinct roles. Do not register a bonding curve as an ordinary fully funded pair unless the receiving integration explicitly supports and understands its reserve semantics.

Third-party indexing of launch markets requires support for the specific launch implementation. The fact that regular CookDEX pools are discovered does not establish that a pre-migration curve is supported. Verification publishes source-code information; it does not automatically enroll a contract into GeckoTerminal, DEX Screener or DEXTools.

12. Public portal API and deep links

Public discovery endpoints include GET /api/public/search?q={query}&chain={chain}, GET /api/pools/catalog and GET /api/public/token/{chain}/{tokenAddress}/market?pair={pairAddress}. These are portal-level interfaces, not RPC replacements or immutable protocol standards. Consumers should tolerate optional fields, unavailable markets, timeouts and version changes.

Use HTTPS, cache sensible public responses, limit request concurrency and apply retry backoff. Validate the response content type before JSON parsing: a reverse proxy can return an HTML 502/504 error instead of JSON. Keep a previous valid value marked stale instead of displaying an unavailable price as a verified zero.

Stable documentation URL: https://cookdex.net/docs. Pool analytics directory: https://cookdex.net/pools. Chain-specific token profile: https://cookdex.net/token/{chain}/{tokenAddress}. Selected pool profile: append ?pair={pairAddress}. Social preview image: /social/token/{chain}/{tokenAddress}.jpg?mode=update. A shared preview is a cached snapshot, not a live streaming price feed.

Cookchain explorer address links use https://cookscan.net/explorer/address/{address}; transaction links use https://cookscan.net/explorer/tx/{transactionHash}. The /explorer segment is required. Internal server RPC addresses and credentials are intentionally not published in this documentation.

13. GeckoTerminal and other listing submissions

For DEX Official Documentation, submit https://cookdex.net/docs. For DEX Pool Page/Analytics, submit https://cookdex.net/pools or, preferably, the exact ordinary pair-profile URL for the pool being registered. Supply the CookDEX factory and router for the relevant chain and protocol version from the registry. Do not mix Base addresses with Cookchain addresses.

For the Cookchain chain logo, the direct public image URL is https://cookdex.net/media/chains/cookchain.webp. It is a WebP image and does not require a login. A chain logo is not necessarily the correct token logo for every asset on that chain. Check the receiving platform’s file-format, dimensions, deployment verification and indexing requirements.

Include a mined pool-creation transaction, the regular pool address, base and quote token addresses and the exact fee tier if requested. A virtual-reserve launch should be disclosed as such and submitted only under an integration that supports it. Listing approval and indexing coverage remain decisions of the external platform, not promises made by CookDEX.

14. Verification, ownership and risk indicators

Explorer source verification means that the published compiler input and settings match the deployed bytecode under the explorer’s rules. It is not an independent security audit. Compiler version, optimizer, via-IR settings, dependency sources, linked libraries, immutables and constructor arguments may all affect matching. Preserve the original deployment build instead of redeploying solely to obtain verification.

A token marked renounced has relinquished the relevant ownership mechanism; this must be checked on-chain. Other roles, proxy upgrade powers, transfer restrictions, taxes, external controllers or separate launch permissions can still exist. Unknown, not verified and failed reads must not be treated as safe, burned or renounced.

Audit scores and lock/burn indicators are informational and depend on the available RPC/indexing evidence. Inspect the actual LP holder, locker contract, unlock time and contract roles. A dashboard badge does not guarantee that tokens can always be sold or that a pool cannot lose value.

Smart contracts, frontends, RPC providers, token issuers, bridges and external indexers can fail. Tokens can have malicious behavior and price manipulation. Protect against phishing, verify approval spenders, limit allowances when appropriate and never sign a transaction whose recipient or calldata you do not understand.

15. Troubleshooting and operational checks

Wrong pool displayed: check the chain, token address and explicit pair query parameter. Multiple pools for one token are normal. A link to the token without a pair is not a promise to preserve the previous market. After migration, distinguish the old curve contract from the newly selected regular DEX pool.

Transaction reverted: inspect the receipt and reproduce the call with the correct sender, amount, allowance, route, minimum output and deadline. Check activation, reserves, migration state and token transfer restrictions. Failed gas estimation, a rejected wallet request and an on-chain revert are different failure stages.

No claimable V2 fees: LP trading fees can remain in reserves rather than existing as a claimable token amount. Protocol-fee minting can require a subsequent liquidity event. No V3 fees: check position ownership, fee tier, range activity and collectable amounts, not just pool-wide volume.

Price, logo or shared card looks old: social platforms cache previews and already published post text does not automatically change. New token updates use the applicable market source. Logo resolution uses the stored token profile, not a chain emblem as a universal token identity.

HTTP 502/504: the reverse proxy could not obtain a timely valid application response. This is not proof of an on-chain transaction failure. Check your wallet receipt before repeating any write operation. An inaccessible RPC can also delay charts or audits independently of whether the chain executed a transaction.

For support, include the network, token and pool addresses, exact public URL, UTC or local timestamp with timezone, transaction hash when available, browser/wallet version and the displayed error. Remove secrets and never send a private key. Official account information is linked below.

Official verified accounts ↗CookDEX whitepaper ↗

Live network & contract registry

Only active configured EVM DEX networks are listed. Empty, malformed and zero addresses are omitted. Addresses are configuration references, not a live bytecode or verification attestation. The regular factory address is the one used for a regular DEX listing; do not substitute an EasyLaunch factory.

CookchainChain ID 20261001 · Gas COOK