DEVOXPAD
Documentation

Launching a token

One confirmation deploys the token, buys your allocation, and burns or locks it.

What you fill in

  1. 1
    Ticker

    Two to ten characters. This is what people will type.

  2. 2
    Logo

    Pinned to IPFS from the browser. The JWT never reaches the page.

  3. 3
    Name and description

    What it is, and who it is for.

  4. 4
    Socials

    Optional. X, Telegram and a website, shown on the token page.

  5. 5
    Dev buy

    Optional COTI spent buying your own allocation at the first price on the curve.

  6. 6
    Allocation

    Keep it, burn a share of it, or lock it for a fixed number of days.

One confirmation

Deploy, dev buy, and burn or lock all happen in the same transaction. Splitting them would leave a window where a creator who chose to burn could take delivery and simply not burn.

Fixed supply

Every launch is one billion tokens. There is no supply field, and no function that can mint after launch: the curve is the only minter and it can only mint what it sells.

Total supply
1,000,000,000, fixed
Sold on the curve
800,000,000
Seeds the pair
200,000,000, at graduation
Mintable later
nothing

Every address ends in 8888

The token and its curve both deploy with CREATE2, which makes an address a pure function of the deployer, a salt and the init code hash. Before the transaction is sent, your browser searches for a salt whose resulting address ends in 8888.

That is not decoration. It is a mark a lookalike cannot cheaply fake, so someone pasted a contract address can tell at a glance that it came from this launchpad.

The same search the launch page runs
import { mineVanitySalt } from "@/lib/vanity";

const { salt, address, attempts, ms } = await mineVanitySalt(deployer, initCodeHash);
// roughly 65,536 candidates on average, about a second

Four hex characters means one in 65,536. If a launch ever lands on an address that does not end in 8888, it did not come from this factory.

Dev buy, burn and lock

A dev buy spends COTI on the curve on your behalf, in the launch transaction, at the first price anyone can get. It is a public event: everyone can see you did it and how much.

The tokens land in the factory first, so it can act on them before you ever hold them. Then one of three things happens.

Keep
The whole allocation goes to your wallet.
Burn 0 to 100%
That share is destroyed immediately. Nobody can undo it, including you. The rest goes to your wallet.
Lock 1 to 3650 days
The whole allocation goes to a timelock with no owner and no early release. The unlock date is public.

Burning and locking need a dev buy to act on. Choosing them with no dev buy reverts rather than silently doing nothing.

Why the curve deploys first

The factory deploys the curve before the token, so the token can name that curve as its only minter inside its own constructor. There is never a block in which any other address could create supply, and no role handoff to get wrong.

The factory then renounces every role it holds. After the launch transaction returns it is a bystander: it cannot mint, cannot grant, and cannot take the token back.

Source verification

Every launch submits its source to CotiScan automatically once the transaction confirms. CotiScan runs Blockscout, which accepts a Solidity standard JSON input, and that input is exactly what compiled the bytecode, so nothing can drift between what ran and what is published.

Verification is a courtesy, not a gate. A launch that fails to verify is still a working launch, so it never blocks anything. Retry with POST /api/verify.

Private or public balances

Encrypted is the default and deploys a COTI PrivateERC20. Choosing public deploys a plain ERC-20, with no privacy claims made about it. Both use the same curve and the same graduation path.

Tokenizing an agent

Opening /launch?agent={slug} pre-fills the form from an agent you own and writes the resulting token address back to the agent, so its page and the token stay linked.

Launching a token · DEVOXPAD