Creating a Project - SEND Docs

What a Project Is

A project in SEND is a token launch. Creating one binds a wallet set, a dev wallet, a launch platform, the token metadata and a funding plan into a single record. After the launch executes, that same project page becomes the trading and monitoring surface for the token -- chart, wallets, swap tape, exchange history and volume campaigns.

Every project is created in the Pending Funding status. Nothing touches the chain at create time; the create call only validates and persists.

"New Project" in the top bar opens the wizard in a modal — from any dashboard tab
The Projects tab's empty state opens that same modal
The Tweets page has a separate "Quick Deploy" path that creates and launches in one action, using the same payload but skipping the wizard

The Steps

The step list depends on the platform you pick. Bonding-curve platforms (PumpFun, BonkFun) show eight steps; AMM platforms (Meteora, Raydium) show seven, because there is no bonding curve for a dev buy to move.

Wallet Set -- choose the set whose wallets will participate
Strategy -- launch strategy plus the dev wallet that creates the token
Platform -- launch venue, plus liquidity settings on Meteora/Raydium
Token -- name, symbol, description, image, socials (plus decimals and supply on Meteora/Raydium)
Dev Buy -- bonding-curve platforms only; skipped on Meteora/Raydium
Allocation -- how many wallets participate and what share of supply they buy
Cost -- phase-by-phase cost breakdown and the funding buffer
Confirm -- review, then pick how the project gets funded

Wallet Set, Strategy and Dev Wallet

Step 1 selects an existing wallet set. You can create a new one in a modal without leaving the wizard. Step 2 selects the launch strategy and the dev wallet; both are required to continue.

Sniping is the selectable strategy: the launch transaction goes out, then each participating wallet submits its own buy in parallel with priority fees, up to 250 buying wallets. Bundling is displayed as "Coming soon" and cannot be selected.

Each dev wallet row shows its live SOL balance, so you can see what the future token creator holds without leaving the wizard. The dev wallet creates the token and is not included in the buy transactions.

The step shows no insufficient-balance warning, deliberately: platform, dev buy and allocation -- the inputs that determine cost -- have not been collected yet, so any threshold here would be invented. The authoritative funding verdict arrives on the Cost and Confirm steps.

Platform and Token

Four platforms are launchable: PumpFun (bonding curve), BonkFun (Raydium LaunchLab bonding curve), Meteora (DLMM liquidity pool) and Raydium (CPMM liquidity pool). Selecting Meteora or Raydium reveals Liquidity Settings -- Pool Size in SOL (minimum 0.1) and Initial Liquidity as a whole percentage from 1 to 100, defaulting to 1 SOL and 100%.

Switching platform resets the platform-dependent fields: liquidity settings, dev buy percentage, wallet count and buffer, plus any decimals and supply collected while an AMM platform was selected.

Meteora and Raydium are the platforms whose SPL mint SEND creates, so you choose decimals (integer 0-9, defaulting to 6 when left blank) and total supply (whole tokens, 1 to 1,000,000,000,000, required). The pair must also fit the on-chain limit: supply x 10^decimals is checked, and an overflowing combination is rejected with "Lower the supply or the decimals". PumpFun and BonkFun mint through their own program at a fixed 6 decimals and a fixed 1,000,000,000 supply, so neither input renders.

Token name -- required, up to 32 characters
Token symbol -- required, up to 10 characters
Description -- up to 500 characters
Token image -- required; the wizard blocks Next with "Token image is required"
Social links (X, Telegram, website, Discord) -- optional, validated as you type
Decimals and Total Supply -- shown only on Meteora and Raydium

Dev Buy and Allocation

The Dev Buy slider runs 0-10% of supply in 0.1% steps and defaults to 0. The buy happens in the same atomic transaction as the launch, which moves the bonding curve before snipers enter. Above 1% the wizard warns that higher percentages may reduce sniper profitability. Any non-zero value fetches a live server estimate -- SOL required, tokens received, price impact and the resulting token price -- and a failed estimate shows an error with Retry rather than a fabricated zero.

The Allocation step has two sliders: how many wallets participate, and what percentage of supply they buy. The percentage runs from 1% up to 100% minus the dev buy, and starts at 50%.

At the default 50% allocation the 0.8%-per-wallet rule requires 63 wallets. Raising the allocation raises the wallet requirement with it, and a split allocation ceils each phase separately, so it can need one more wallet than the flat calculation suggests.

One wallet may hold at most 0.8% of supply, so the minimum wallet count is the allocation divided by 0.8, rounded up
Sniping is capped at 250 buying wallets
If the set has too few wallets the slider is replaced by a "More Wallets Needed" card with a one-click create button (200 wallets per batch, with live progress)
If the wallet roster fails to load you get a "Couldn't read this wallet set" card with Retry -- it never claims you have zero wallets
Above the platform's curve cap (PumpFun 79.31%, BonkFun 73.2521%, each reduced by the dev buy) the allocation splits into two phases: Phase 1 buys on the bonding curve, Phase 2 buys on the DEX and executes automatically when the token graduates

Cost and Confirm

The Cost step breaks the launch into phases -- Phase 0: Launch, then Phase 1: Pre-Graduation and Phase 2: Post-Graduation on a split bonding-curve allocation, or a single Phase 1 buy on an AMM platform. Below the phase anatomy, a "What you'll deposit" block lists each funded wallet, the Project Launch Fee and an exchange and routing reserve; those rows sum exactly to the deposit total.

The buffer slider runs 0-100% and defaults to 0. It is discretionary headroom only: exchange fees and spread, rent, forwarding fees, proxy hops and per-wallet transaction fees are already covered and rounded up before the buffer applies, so 0% still funds every wallet to its full launch target.

The Confirm step reviews the whole plan -- name and symbol, strategy, platform, allocation and wallet count, dev buy, dev wallet, and pool size and initial liquidity on AMM launches -- then asks how the project gets funded.

Every cost figure in the wizard is an estimate and is prefixed with "~": the exchange provider that executes a funding leg is not assigned until the deposit is created, and providers differ substantially in their flat fee. The one figure that is never approximate is the deposit card's "Send exactly" amount, which the funding check enforces literally.

Fund Fully -- deposit the full planned amount; always offered and selected by default
Top Up -- appears only when your wallets already hold part of the plan; deposit only the difference
Use Funds -- appears only when your wallets already cover the plan; confirm and skip the deposit

What Happens When You Press Create

Create Project re-runs every step's validation -- including steps you jumped over using the stepper -- then submits. The wizard never opens a deposit modal itself: it hands your funding choice to the project page and routes you there, where the full deposit breakdown, the server-sized top-up, or the use-funds consent dialog opens. Closing that page loses nothing; the project exists and its funding controls live on it.

Server-side, the project is persisted in Pending Funding, and the funding breakdown is recomputed from your raw allocation, dev buy and buffer percentages -- the cost snapshot the wizard showed is superseded by that recompute. Note that the project takes its name and description from the token: there is no separate project-name field anywhere in the flow.

On Meteora and Raydium the allocation must stay at or under 0.9x the initial-liquidity percentage, because snipers buy from the pool you seed. The wizard does not pre-check this -- the server rejects the create with a message naming both values and telling you to lower the allocation or raise the initial liquidity. All of these rejections happen before any funds move.

Decimals outside 0-9, or set at all on a fixed-decimals platform
Total supply outside 1 to 1,000,000,000,000, missing on Meteora/Raydium, or supplied on a fixed-supply platform
Liquidity settings sent for a bonding-curve platform -- rejected, not ignored
A pool size that disagrees with the submitted breakdown
A stale cost snapshot, answered with "re-run the cost preview and submit the breakdown it returns"