COOK Launchpad — Integration Guide for Routers, Aggregators & Trading Terminals

BONDING                                GRADUATED
────────────────────────────────       ────────────────────────────────
Venue : COOKFactory bonding curve      Venue : PancakeSwap V2 pair
Buy   : factory.buyFor()               Buy   : router, fee-on-transfer variant
Sell  : factory.sellFrom()             Sell  : router, fee-on-transfer variant
Token : TRANSFER-LOCKED                Token : freely transferable, 1% swap tax

Detect with factory.getToken(token).graduated. Graduation happens automatically inside the buy that fills the curve — same transaction, no separate listing step, no window to snipe the listing itself.

Calling buy() / sell() on the factory after graduation reverts AlreadyGraduated (0xe6a0d45f). Calling the PancakeSwap pair before graduation is impossible — the pair does not exist yet.

The API is built so you never need custody. Every path has the factory on one side:

✅ BUY : you send BNB → factory mints/transfers straight to the end user
✅ SELL: user approves the FACTORY → factory pulls straight from the user

After graduation the token is a normal (taxed) ERC-20 and you can route it however you like.

function buyFor(
    address token,
    address recipient,      // end user; tokens go here directly
    uint256 minTokensOut,
    uint256 deadline        // unix seconds, 0 = no deadline
) external payable returns (uint256 tokensOut);

Permissionless — no allowlist needed.

Taking your fee: skim the BNB before forwarding. The factory only ever sees the net amount, so your fee never touches the curve accounting.

function buyWithFee(address token, address user) external payable {
    uint256 fee = msg.value * 25 / 10_000;          // your 0.25%
    payable(feeCollector).transfer(fee);
    factory.buyFor{value: msg.value - fee}(token, user, minOut, deadline);
}

• Tokens never pass through you. recipient receives them directly from the factory.
• Overfill refunds go to recipient, not to the caller. If the order is larger than the remaining curve inventory, the factory spends only what it needs and refunds the rest to recipient. Your contract will not receive stray BNB, so it does not need a receive() for this path.

function sellFrom(
    address token,
    address owner,          // the end user whose tokens are sold
    uint256 tokenAmount,
    uint256 minBnbOut,
    address recipient,      // where the BNB lands — you, or the user
    uint256 deadline
) external returns (uint256 bnbOut);

The user approves the factory, not you. The factory then pulls owner → factory, which the transfer lock permits.

// 1) user (off-chain, their own wallet): token.approve(FACTORY, exactAmount)
// 2) you:
function sellWithFee(address token, address user, uint256 amount) external {
    uint256 before = address(this).balance;
    factory.sellFrom(token, user, amount, minOut, address(this), deadline);
    uint256 gross = address(this).balance - before;

    uint256 fee = gross * 25 / 10_000;              // your 0.25%
    payable(feeCollector).transfer(fee);
    payable(user).transfer(gross - fee);
}

Your contract needs a receive() external payable for this path.

Getting allowlisted

sellFrom is gated by isAllowedRouter[msg.sender], set by the COOK operator/owner via setAllowedRouter. Unlisted callers revert NotOperator (0x7c214f04).

Contact the COOK team with your router address to be added. Expect scrutiny: a cleared router picks recipient, minBnbOut and the timing, so it can in principle redirect the full proceeds of anyone holding an open approval. We ask integrators to:

1. Use exact-amount approvals in your UI — never type(uint256).max on the factory.
2. Set recipient to the end user where your flow allows it.
3. Keep the router contract immutable or behind a timelock.

If you would rather not be allowlisted, you can still route sells by having the user call sell() directly and charging your fee off-chain or on the buy side only.

function getBuyQuote(address token, uint256 bnbIn)
    external view returns (uint256 tokensOut, uint256 fee, uint256 refund);

function getSellQuote(address token, uint256 tokenAmount)
    external view returns (uint256 bnbOut, uint256 fee);

These run the exact same math as buy / sell, so quoted == executed absent other traffic in between. fee is the 1% protocol fee in BNB; getSellQuote's bnbOut is already net of it.

Both revert AlreadyGraduated for graduated tokens — check graduated first, or catch the selector and fall through to your PancakeSwap quoting path.

Remember to subtract your own fee from what you display, since the factory has no knowledge of it.

Curve mechanics, if you want to quote locally

Constant product with virtual reserves:

k  = x0 · y0
x  = x0 + bnbRaised
y  = y0 − tokensSold
y0 = 1,066,666,666.666…      (VIRTUAL_TOKEN_RESERVE, larger than real supply on purpose)
x0 = raiseTarget / 3

Sold on the curve: 800,000,000 (80%). Paired into the burned LP at graduation: 200,000,000 (20%) plus the entire raise. y0 = S²/(S−L) is chosen so the curve's closing price equals the pool's opening price — there is no price step at graduation for you to arbitrage or to explain to users.

Standard pair, with one hard requirement:

You must use the …SupportingFeeOnTransferTokens router variants. The token takes 1% on swaps against the pair, so swapExactETHForTokens / swapExactTokensForETH will revert. Set slippage tolerance to at least 1.5%.

Wallet-to-wallet transfers are not taxed. Only transfers where the pair is the counterparty.

The nominal tax is exactly 1%, both directions. A sell measured with no swap-back pending costs 94 bps — the 1% tax, with rounding.

The variance comes from the swap-back. The token withholds tax in tokens. When the buffer reaches swapThreshold (0.05% of supply = 500,000), the next sell first swaps that buffer to BNB, and only then executes the user's own sell. The buffer's price impact therefore lands inside that one transaction.