# VortexDeployer docs — full text

> Every page of https://vortexdeployer.com/docs in one file, API pages first. Index: https://vortexdeployer.com/llms.txt

---

# API overview & keys

> Trade, launch and run tasks from your own code with an API key — what a key can do, how to call it, and how to keep it safe.

Source: https://vortexdeployer.com/docs/api/overview · Markdown: https://vortexdeployer.com/docs/api/overview.md

The VortexDeployer API does everything the app does: buy, sell, launch, run tasks, read your wallets and PnL, and stream live trades. Every call acts as **your account**, so a trade made from code shows up on your Dashboard, Portfolio and Tasks pages exactly like one made by hand.

Open **API** in the header, the footer or the avatar menu to manage keys, see usage, read these docs and request new API features.

## Base URLs

| What | URL |
|---|---|
| REST | `https://evm.vortexdeployer.com/evm/api/v1` |
| Live streams | `wss://evm.vortexdeployer.com/evm/ws` |
| OpenAPI 3.1 | `https://evm.vortexdeployer.com/evm/api/v1/openapi.json` — the whole REST surface, for Postman, Insomnia or a client generator. No key needed |
| MCP | `https://evm.vortexdeployer.com/evm/api/v1/mcp` — the same operations as tools for Claude, Cursor or any MCP client ([MCP for AI agents](https://vortexdeployer.com/docs/api/mcp)) |
| API index | `GET https://evm.vortexdeployer.com/evm/api/v1` — these addresses as JSON, no key needed |
| For agents | `https://vortexdeployer.com/llms.txt` — the docs index for AI agents; every page is also Markdown at its address plus `.md` ([Build an agent on the API](https://vortexdeployer.com/docs/api/agents)) |

Every REST call sends the key as a bearer token:

```bash
curl https://evm.vortexdeployer.com/evm/api/v1/me \
  -H "Authorization: Bearer vd_1a2b3c4d_…"
```

A key looks like `vd_1a2b3c4d_…`. The short part after `vd_` is the **prefix**, shown in the hub so you can tell keys apart; the rest is the secret.

`GET /me` returns your user, and the key's name, scopes and limits:

```json
{
  "user": { "id": "1", "username": "yourname" },
  "key": {
    "id": "29",
    "name": "my trading bot",
    "prefix": "1a2b3c4d",
    "scopes": ["read", "trade", "stream"],
    "settings": {},
    "restricted": false
  }
}
```

`restricted` is `true` when the key has any limit (a cap, a wallet list or sandbox). A restricted key cannot create, edit or start tasks — see [Per-key limits](#per-key-limits).

## What every answer looks like

- **JSON, camelCase.** Every field is camelCase (`createdAt`, `poolAddress`, `expectedOut`), in answers and in the bodies you send. Wallet ids and mints used as map keys are left exactly as they are.
- **Amounts are strings** when they are in a chain's smallest unit (lamports, wei, token base units), so nothing is rounded. Amounts in whole coin (`amountSol`, `devBuySol`) are numbers.
- **Ids are strings** (`"812"`), including numeric ones.
- **Lists are wrapped**: `{ "wallets": […] }`, `{ "tasks": […] }`, `{ "executions": […] }`. The long ones take `?limit=&offset=` and report `X-Total-Count` — see [Paging long lists](https://vortexdeployer.com/docs/api/wallets-pnl#paging-long-lists).
- **Every error** carries a stable `code` you can switch on, a human `error` and a `traceId` — see [Limits, retries & errors](https://vortexdeployer.com/docs/api/limits-errors#errors).
- Dates are ISO-8601 strings in UTC. `OPTIONS` on any route answers `204` with the allowed methods.

The full contract, route by route, is the OpenAPI document above.

## Create a key

1. **API** → **Keys** → **Create key**.
2. Name it after the bot or script that will use it.
3. Tick the **scopes** it needs, and nothing more.
4. Set limits if you want them (below).
5. Enter your account password if you have one set. Keys that can move funds need it.
6. Copy the secret. **It is shown once.** If you lose it, revoke the key and create a new one.

:::danger The key is your account
Anyone holding a key with `trade` or `launch` can spend from your wallets. Never put a key in a website, a public repo or a shared chat. Revoke it at once if it leaks.
:::

## Scopes

| Scope | Allows |
|---|---|
| `read` | Wallets, balances, portfolio, projects, PnL, task lists and details |
| `trade` | Buy, sell, batches, creating wallets, creating and running tasks |
| `launch` | Launching tokens |
| `stream` | The `txs` and `pnl` live streams |

A call outside the key's scopes returns `403`.

## Per-key limits

All limits are optional. Set them when you want a key to do less than your account can.

| Setting | Effect |
|---|---|
| **Max per buy** | Refuses any single buy above this amount of the chain's coin (SOL on Solana, ETH on EVM) |
| **Daily cap** | Refuses buys once the key has spent this much today (UTC). A buy that was sent counts even if it failed on chain |
| **IP allowlist** | The key only works from these IP addresses or ranges |
| **Default slippage** | Used when a call leaves `slippageBps` out |
| **Allowed wallets** | The key may only trade from these wallet ids, and cannot import private keys |
| **Sandbox** | Only `dryRun: true` calls go through. Nothing is ever sent on chain |

A key with any cap, a wallet list or sandbox is a **restricted key**. Task amounts run later and can't be checked against a cap up front, so a restricted key cannot create, edit or start tasks, and may only simulate launches. Use a key with no limits for those.

:::tip Start in sandbox
Create a sandbox key first and send your whole flow with `dryRun: true`. When it behaves the way you expect, create a real key.
:::

## Revoke, edit, delete

- **Revoke** stops the key on its next call and closes its live streams. It can't be undone.
- **Revoke all** stops every key on the account in one go.
- **Edit** changes name, scopes and limits. The key's open streams close, so reconnect after editing.
- Signing out of the app does **not** revoke keys.

Revoked keys stay listed under **Revoked** so you can still see their past usage.

## Usage

**API** → **Usage** shows calls per day, how many were accepted, refused (4xx) or failed (5xx), and the busiest keys and routes.

## See also

- [Buy, sell & batches](https://vortexdeployer.com/docs/api/trading)
- [Limits, retries & errors](https://vortexdeployer.com/docs/api/limits-errors)
- [Simulate before you send](https://vortexdeployer.com/docs/overview/dry-run)

---

# Buy, sell & batches

> Single buys and sells, many-wallet batches, and what a slow batch turns into.

Source: https://vortexdeployer.com/docs/api/trading · Markdown: https://vortexdeployer.com/docs/api/trading.md

Trades from the API use the same swap engine as the Trade Panel: the same routing, platform fee and ledger. Each needs the `trade` scope.

## Pick the wallet

Every trade names **one** wallet:

- `walletId` — a wallet already in your account (see [Wallets, portfolio & PnL](https://vortexdeployer.com/docs/api/wallets-pnl)).
- `privateKey` — a key you hold. It is imported into your account as a wallet the first time and reused after that, exactly like importing on the Wallets page. The key is never sent back by the API.

## Buy

`POST /buy`

```json
{
  "mint": "7xKX…pump",
  "walletId": "812",
  "amountSol": 0.05,
  "slippageBps": 1500,
  "dryRun": false
}
```

| Field | |
|---|---|
| `mint` | Token address |
| `walletId` or `privateKey` | Exactly one |
| `amountSol` or `amountRaw` | Exactly one. `amountSol` is in the chain's coin (SOL, or ETH on EVM chains); `amountRaw` is its smallest unit as a string |
| `slippageBps` | 1–10000. Falls back to the key's default slippage |
| `chain` | Optional; worked out from the mint when left out |
| `poolAddress`, `dex` | Optional: force a pool or venue |
| `computeUnitLimit`, `computeUnitPriceMicroLamports` | Optional Solana priority settings |
| `dryRun` | `true` simulates the trade and sends nothing. Default `false` |

A sent trade returns:

```json
{
  "confirmed": true,
  "signature": "zeG4fznpHbhHbMHZp9XfMLKm6kqNQWq5XifHhFK2ubTPfG8C32GQ69SxKLbv8jtawmzKEzva42XT2D9Ym2hFxoH",
  "err": null,
  "poolAddress": "6NihTYwWoTQcMVimRA2wFxFoGxZwTFvefCVJ44UYTLoN",
  "dex": "pump_fun",
  "expectedOut": "326807208282",
  "landedOut": null,
  "nativeReceipt": null,
  "minOut": "326807208282"
}
```

| Field | |
|---|---|
| `confirmed` | `true` once the transaction landed on chain |
| `signature` | The on-chain signature (`null` if nothing was sent) |
| `err` | The chain error if it failed, else `null` |
| `poolAddress`, `dex` | The pool and venue the swap used |
| `expectedOut` | Tokens the quote expected, in base units |
| `landedOut` | Tokens actually received once known, else `null` |
| `minOut` | The minimum accepted after slippage |
| `nativeReceipt` | On a sell, coin received once known, else `null` |

A **simulation** (`dryRun: true`) sends nothing and returns the quote plus the simulated transaction result:

```json
{
  "dryRun": true,
  "poolAddress": "6NihTYwWoTQcMVimRA2wFxFoGxZwTFvefCVJ44UYTLoN",
  "dex": "pump_fun",
  "expectedOut": "35254150228",
  "minOut": "35254150228",
  "simulation": { "err": null, "unitsConsumed": 108524, "logsTail": ["…"] }
}
```

## Sell

`POST /sell` takes the same body, but the amount is one of:

- `percentage` — 0–100 of what the wallet holds right now.
- `amountRaw` — token base units.

`amountSol` is refused on a sell. A wallet holding none of the token returns `422` with `code: "unprocessable"`.

The response is the same shape as a buy.

## Batch

`POST /trade/batch` trades one token from many wallets at once.

```json
{
  "mint": "7xKX…pump",
  "side": "buy",
  "walletIds": ["812", "813", "814"],
  "amountMode": { "type": "uniform", "amountRaw": "20000000" },
  "intervalMs": [0, 400],
  "dryRun": false
}
```

| `amountMode.type` | |
|---|---|
| `uniform` | `amountRaw` for every wallet |
| `individual` | `amountsRaw`: one per wallet, in the same order |
| `token_percentage` | `percentage` of each wallet's balance (sells; a restricted key can't use it on buys) |

`intervalMs` is `[min, max]`: a random wait between wallets. Up to 500 wallets, no repeats.

A batch that runs at once returns a per-wallet report:

```json
{
  "source": "api",
  "side": "buy",
  "mint": "7xKX…pump",
  "requested": 2,
  "successful": 2,
  "failed": 0,
  "totalInput": "20000000",
  "totalOutput": "705570950744",
  "results": [
    {
      "walletId": "812",
      "ok": true,
      "signature": "2CykMFSe…budB",
      "confirmed": true,
      "amountIn": "10000000",
      "expectedOut": "352902292117",
      "landedOut": null,
      "minOut": "352902292117",
      "err": null
    }
  ]
}
```

### Slow batches become a Buy task

A call can't stay open for minutes. When `walletIds × max interval` is over **60 seconds**:

- **A buy** starts as a [Buy task](https://vortexdeployer.com/docs/tasks/buy) with the same wallets, amounts and pacing. The response is `202`:

  ```json
  {
    "taskId": "1932",
    "status": "started",
    "task": { "id": "1932", "type": "buy", "status": "running" }
  }
  ```

  Follow it with `GET /tasks/1932`, or on the `tasks` stream.
- **A sell** is refused with `400` and `code: "bad_request"`. Use shorter intervals, or split it into several batches.

With a daily cap, the whole batch counts against today the moment the task starts.

:::warning Real money
Without `dryRun: true`, buys and sells are sent on chain immediately. There is no confirmation step.
:::

## Convert

Convert is the Wallets page's _Convert_ dialog: one wallet's token to SOL or USDC (or back) through the Jupiter rail — a wallet-level swap for tidying balances, not a curve trade. It spends only network fees and the token accounts the route opens.

| Method & path | Scope | Does |
|---|---|---|
| `POST /convert/assets` | `read` | `{ "walletIds": [ … ] }` → every token the wallets hold with a balance per wallet, plus the `destinations` you can convert into |
| `POST /convert/quote` | `read` | The quote for one conversion |
| `POST /convert` | `trade` | Do it |

```json
{ "walletId": "812", "inputMint": "EPjF…Dt1v", "outputMint": "So111…112", "all": true, "slippageBps": 100, "dryRun": true }
```

Send `amountRaw` (base units) or `"all": true`, never both. `dryRun` defaults to **true**. Wrapped SOL is a token here (`"wrapped-sol"`): unwrap it to SOL first, then convert. The assets read scans each wallet on chain and can take a while for many wallets.

## Burn and lock

`POST /tokens/burn` burns part of one wallet's bag, `POST /tokens/lock` locks it until a date. Both need `trade` and **rehearse by default**.

```json
{ "walletId": "812", "mint": "7xKX…pump", "amount": "25", "amountType": "percentage", "dryRun": true }
```

- `amountType` is `tokens` (a token amount) or `percentage` (of the wallet's balance). `amount` is a decimal string.
- Lock also takes `unlockDays` (down to one hour, `1/24`) or a Unix `unlockTimestamp`, and an optional `name`.
- The answer is `{ "ok", "signature", "burnedAmount" | "lockedAmount", "dryRun", "error" }`. A wallet with nothing to burn answers `ok: false` with the reason, not a `500`.

## Creator fees

`GET /tokens/creator-fees?mint=…` (`read`) is what the token's creator can claim on each venue: `{ "mint", "creatorWalletId", "creatorAddress", "venues": [ { "venue", "claimable", "quoteMint", "coolingDown" } ] }`. `POST /tokens/creator-fees/claim` (`trade`) claims them: `{ "mint": "…", "dryRun": false }` → `{ "ok", "signature", "claimed": [ { "venue", "amount" } ] }`. The creator wallet must be one of yours.

## See also

- [Limits, retries & errors](https://vortexdeployer.com/docs/api/limits-errors): retry a trade safely with `Idempotency-Key`, and every error `code`
- [Platform fees & tiers](https://vortexdeployer.com/docs/overview/fees)

---

# Launch a token

> Launch from code — the token, its image, the creator, bundled buys and launch tasks.

Source: https://vortexdeployer.com/docs/api/launch · Markdown: https://vortexdeployer.com/docs/api/launch.md

`POST /launch` is the create-token flow. It needs the `launch` scope. The token becomes a project in your account, with its tasks, exactly like a launch from the app.

:::info Simulated by default
A launch **simulates** unless you send `"dryRun": false`. Simulate first; the response shows what would happen without sending anything.
:::

## Body

```json
{
  "launchpad": "pump",
  "name": "Vortex Cat",
  "symbol": "VCAT",
  "description": "gm",
  "twitter": "https://x.com/…",
  "imageUrl": "https://example.com/cat.png",
  "creatorWalletId": "812",
  "devBuySol": 0.5,
  "buys": [
    { "walletId": "813", "amountSol": 0.3 },
    { "privateKey": "…", "amountSol": 0.2 }
  ],
  "dryRun": false
}
```

| Field | |
|---|---|
| `launchpad` | Defaults to `pump`. The same launchpads as the create modal ([Chains & launchpads](https://vortexdeployer.com/docs/overview/chains-and-launchpads)). Ask `GET /launchpads` for the list |
| `quoteToken` | What the curve is priced in: `sol` (default), `usdc`, `usd1`, `eth` or `stock`. Each launchpad accepts its own set — see [Which quotes can I launch with?](#which-quotes-can-i-launch-with) |
| `pairToken` | The mint or contract of the stock or pair token, when the quote needs one (every StonkFun launch, a pump.fun `stock` quote, an optional pons pair token) |
| `name`, `symbol` | 1–32 and 1–10 characters |
| `description`, `twitter`, `telegram`, `website` | Optional |
| `imageUrl` or `imageBase64` | Exactly one. PNG, JPEG, GIF or WebP, up to 10 MB. With `imageBase64`, also send `imageContentType` |
| `creatorWalletId` or `creatorPrivateKey` | Exactly one: the wallet that creates the token |
| `devBuySol` | The creator's own first buy |
| `buys` | Solana only, up to 24. Each is `walletId` or `privateKey`, plus `amountSol`. They ride the launch as a [Bundle](https://vortexdeployer.com/docs/tasks/bundle) |
| `tasks` | Up to 20 launch tasks written inline, nothing to pre-create. See [Launch tasks](#launch-tasks) |
| `launches` | 1–10: mint the same token several times in a row |
| `launchAt` | Schedule the launch for later. The response is `202` with `scheduled: true` |
| `dryRun` | `true` simulates, `false` sends. Default `true` |

Private keys become wallets in your account, the same as importing them on the Wallets page.

## Launch tasks

`tasks` is step 3 of the create wizard, in JSON: the tasks that should fire the moment the token exists, written on the launch itself. You don't create them first on the [Tasks API](https://vortexdeployer.com/docs/api/tasks); the launch creates them for its mint. Each task is:

| Field | |
|---|---|
| `type` | The engine: `bundle`, `sniper`, `buy`, `volume`, `antisniper`, `holderboost`, `handswitcher`, `fakevolume`, `protrader_boost`, `limit_order`, `ladder`, `mirror`, `dca` or `trailing_stop` |
| `walletIds` | The wallets it trades with, yours (and on the key's list, if it has one). The creator wallet can't be a `bundle` buyer |
| `config` | The engine's settings, the same keys as a `POST /tasks` body ([Tasks API](https://vortexdeployer.com/docs/api/tasks) and each engine's page). No `mint` and no `chain`: both are the launch's |
| `label` | Optional |
| `autostart` | Default `true`: start the instant the mint lands. `false` leaves the task idle on the new project |

```json
{
  "launchpad": "pump",
  "name": "Vortex Cat",
  "symbol": "VCAT",
  "imageUrl": "https://example.com/cat.png",
  "creatorWalletId": "812",
  "devBuySol": 0.5,
  "buys": [{ "walletId": "813", "amountSol": 0.3 }],
  "tasks": [
    { "type": "volume", "walletIds": ["814", "815"], "config": { "minBuySol": 0.02, "maxBuySol": 0.05, "minDelayMs": 2000, "maxDelayMs": 8000 } },
    { "type": "antisniper", "walletIds": ["813", "814", "815"], "config": { "thresholdPercent": 5, "action": "sell_all" } },
    { "type": "dca", "walletIds": ["816"], "autostart": false, "label": "later", "config": { "side": "buy", "everyMs": 60000, "sizeUnit": "native", "sizeValue": 0.01, "maxFires": 10 } }
  ],
  "dryRun": false
}
```

- `buys` is the short form of one `bundle` task; you can send both.
- Settings are checked at the door with the engine's own rules. A wrong value refuses the whole launch as `400 validation_failed`, naming `tasks[i].config`, before anything is pinned or minted.
- The tasks follow the launch: a sent launch creates them on the new project and starts the `autostart` ones; the response lists them in `tasks` with their `taskId`, `started`, or an `error`. Engines with no simulation of their own (`bundle`, `volume`, `antisniper`, the order tasks) can't ride a simulated launch, so simulate with the other tasks and send with all of them.
- A task's `dryRun` setting is ignored: the launch's `dryRun` decides for every task on it.

`POST /launch/affordability` takes the same `tasks` shape, so you can price the plan before you send.

## Which quotes can I launch with?

Two `read` calls answer it, from the same rules and lists the create modal uses:

| Call | Returns |
|---|---|
| `GET /launchpads` | Every launchpad with its chain, the `quoteToken` values it accepts and, per quote, whether a `pairToken` is needed and which dev-buy field applies |
| `GET /launchpads/:launchpad/quotes` | What a launch on that launchpad can be quoted in **right now**, each entry with the exact `quoteToken` and `pairToken` to send |

`GET /launchpads`:

```json
{
  "launchpads": [
    {
      "launchpad": "pump",
      "name": "Pump.fun",
      "chain": "solana",
      "quoteTokens": ["sol", "usdc", "stock"],
      "quotes": [
        { "quoteToken": "sol", "symbol": "SOL", "decimals": 9, "address": null, "pairToken": "none", "devBuyField": "devBuySol" },
        { "quoteToken": "usdc", "symbol": "USDC", "decimals": 6, "address": "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v", "pairToken": "none", "devBuyField": "devBuyQuote" },
        { "quoteToken": "stock", "symbol": "STOCK", "decimals": null, "address": null, "pairToken": "required", "devBuyField": "devBuySol" }
      ],
      "liveQuoteList": true
    }
  ]
}
```

`GET /launchpads/stonkfun/quotes` — the tokenized stocks StonkFun launches in today. Copy `quoteToken` and `pairToken` straight into the launch body:

```json
{
  "launchpad": "stonkfun",
  "chain": "solana",
  "quotes": [
    {
      "quoteToken": "stock",
      "pairToken": "Xsc9qvGR1efVDFGLrVsmkzv3qi45LTBjeUKSPmx9qEh",
      "symbol": "TSLAx",
      "name": "Tesla xStock",
      "decimals": 8,
      "address": "Xsc9qvGR1efVDFGLrVsmkzv3qi45LTBjeUKSPmx9qEh",
      "kind": "stock",
      "devBuyField": "devBuySol",
      "approved": true,
      "category": "Technology",
      "logoUrl": "https://…"
    }
  ]
}
```

- `pump` lists SOL, USDC and the stocks pump.fun's on-chain whitelist allows. `stonkfun` lists only stocks. `raydium_launchlab`, `bonk` and `bonkers` list SOL and USD1. `meteora_dbc` lists SOL. `pons` lists ETH plus the approved pair tokens (USDG, tokenized stocks) launches on Robinhood Chain have used; any other approved contract can still be sent as `pairToken`.
- `devBuyField` tells you where the creator's first buy goes: `devBuySol` is spent in SOL and swapped into the quote when needed, `devBuyQuote` is spent in the quote the creator holds, `devBuyEth` on pons.
- A stock quote is a live list: an entry can disappear when the venue stops listing it. The launch checks the pair again when it runs. When the venue's list is unreachable the answer is `503` with `code: "service_unavailable"`; retry.
- An unknown launchpad is `404` with `code: "not_found"`.

## Response

A sent launch returns the mint, the on-chain signature, the hosted metadata `uri` and `imageUri`, the new `projectId`, and the `tasks` it created:

```json
{
  "mint": "J11LopwNEF3wkMQGskM3jVmEMmncqdkadQ1b6PuXpump",
  "creator": "6729VKWPgq1qTaxkv2n1SVPzDc1A2tajiNTvS3uUCE88",
  "launchpad": "pump",
  "quoteToken": "sol",
  "pool": null,
  "dryRun": false,
  "signature": "3BNESKPXnqoAfSpgSrjCsz9CnWNCTRiXzHQYuR3jLgqx8KQSJgvVLrdu7WRvjZDpFYjGDtZKnhQviRj7MngM5L98",
  "confirmed": true,
  "err": null,
  "devBuyTokens": null,
  "projectId": "1021",
  "uri": "https://api.vortexdeployer.com/metadata/….json",
  "imageUri": "https://api.vortexdeployer.com/image/….png",
  "tasks": []
}
```

A **simulation** (`dryRun: true`) returns the same shape with `confirmed: false`, `signature: null`, and a `simulation` object instead of `projectId`/`imageUri`:

```json
{
  "mint": "J11LopwN…pump",
  "creator": "6729…CE88",
  "launchpad": "pump",
  "quoteToken": "sol",
  "pool": null,
  "dryRun": true,
  "signature": null,
  "confirmed": false,
  "err": null,
  "devBuyTokens": null,
  "simulation": { "err": null, "unitsConsumed": 100811, "logsTail": ["…"] },
  "uri": "https://api.vortexdeployer.com/metadata/….json"
}
```

With `launches` over 1, a `batch` report lists every mint and where the run stopped.

## Before you launch: the helpers

The create modal's checks are routes too. All are `read` except the upload, which is `launch`.

| Method & path | Does |
|---|---|
| `GET /launch/readiness` | `{ "killSwitch", "lut": { "configured", "address", "live" }, "selfRugThresholdPercent" }` — `killSwitch: true` means real sends are off platform-wide |
| `GET /launch/mint-address?launchpad=pump` | The mint `address` the next launch on that launchpad will use (from the keypair pool), so you can pre-announce it |
| `POST /launch/clone` | `{ "chain", "address" }` of a token that exists: its name, symbol, description, socials, `imageUrl`, the image as base64 and `warnings` — the app's _Vamp_ button, ready to paste into a launch body |
| `POST /launch/affordability` | How many of the `launches` the creator and buyers can pay for from live balances: `{ "creatorWalletId", "launchpad", "quoteToken", "devBuySol", "launches", "tasks" }` → `{ "requested", "affordable", "stop", "creatorPerLaunch", "buyers" }` |
| `POST /launch/supply-preview` | What each bundled buy lands on a fresh curve: `{ "launchpad", "quoteToken", "wallets": [ { "walletId", "mode", "sol" } ] }` → per wallet the coin it spends and its % of supply |
| `POST /launch/metadata` | Host a token's metadata JSON and image ahead of time: the launch body's `name`, `symbol`, `description`, socials and image → `{ "uri", "imageUri" }` |
| `GET /launch/pons/launch-terms?chain=…` · `GET /launch/otcdesks/rewards` | The venue's current launch terms (pons fees, pair tokens and configs; OTC Desks holder-reward terms) |

## Supply plans

A supply plan is a saved bundle layout in % of supply per wallet slot. `GET /supply-plans` lists yours (paged), `POST /supply-plans` saves one (`trade`), `DELETE /supply-plans/:id` removes it.

```json
{
  "name": "12 wallets, 18%",
  "slots": [ { "targetPercent": 1.5, "walletId": "812" }, { "targetPercent": 1.5, "role": "trading" } ],
  "maxTotalPercent": 18,
  "maxWalletPercent": 2
}
```

A slot pins a `walletId` or names the `role` a wallet must carry; an open slot takes the next wallet you select when the plan is mounted. `POST /supply-plans/:id/mount` resolves the plan against wallets and a curve: `{ "walletIds": [ … ], "launchpad": "pump", "quoteToken": "sol" }` for a fresh curve, or `mint` for a token already trading, and answers per row the wallet, its slot, the coin it must spend and any shortfall.

## Refusals

| Status | Code | When |
|---|---|---|
| `400` | `validation_failed` | Missing or double image or creator, a field out of range, or a launch task's `config` the engine refuses. `details` names it |
| `400` | `bad_request` | Unknown launchpad, `buys` on an EVM launchpad, a `bundle` (or `buys`) on a simulated launch, or an image that isn't a real picture |
| `403` | `key_restricted` | A restricted key sending `dryRun: false` |
| `403` | `private_key_not_allowed` | A wallet-list key using a private key |
| `403` | `wallet_not_allowed` | A wallet (the creator's, a buyer's or a task's) that isn't yours, or isn't on the key's list |

A restricted key (caps, wallet list or sandbox) can only simulate launches. See [API overview & keys](https://vortexdeployer.com/docs/api/overview).

## See also

- [Create a project in the app](https://vortexdeployer.com/docs/launch/create-project)
- [Create, edit and delete a project](https://vortexdeployer.com/docs/api/wallets-pnl#create-edit-and-delete-a-project): a draft project before the launch, wallets in it, close-out after
- [Tasks API](https://vortexdeployer.com/docs/api/tasks)

---

# Tasks API

> Create, start, pause, edit and stop the same tasks the Tasks page runs.

Source: https://vortexdeployer.com/docs/api/tasks · Markdown: https://vortexdeployer.com/docs/api/tasks.md

Every engine on the [Tasks](https://vortexdeployer.com/docs/tasks/overview) page is available from code: Buy, Bundle, Volume, DCA, Ladder, Trailing stop and the rest. Reading needs `read`; anything that changes a task needs `trade`, on a key **without limits** (see [API overview & keys](https://vortexdeployer.com/docs/api/overview)).

## Routes

| Method & path | Does |
|---|---|
| `GET /tasks` | Your tasks |
| `GET /tasks/:id` | One task |
| `GET /tasks/:id/executions` | Its trades |
| `GET /tasks/:id/postmortem` | Why a run stopped or failed |
| `POST /tasks` | Create a task |
| `PATCH /tasks/:id` | Edit it, even while running |
| `POST /tasks/:id/preview` | What the next run would do |
| `POST /tasks/:id/start` · `/resume` | Run it |
| `POST /tasks/:id/pause` · `/stop` | Pause or stop it |
| `POST /tasks/stop-all` | Stop every running task |
| `DELETE /tasks/:id` | Remove it. Its history stays |
| `GET /tasks/presets` · `POST /tasks/presets` · `DELETE /tasks/presets/:id` | Saved setups |
| `GET /events` | Your task and trade events, newest first |
| `GET /warmup/candidates` | Tokens the [Warmup](https://vortexdeployer.com/docs/tasks/wallet-warmup) engine would trade right now |

## Create

`POST /tasks`

```json
{
  "type": "buy",
  "mint": "7xKX…pump",
  "walletIds": ["812", "813"],
  "label": "morning buys",
  "config": {
    "buyMode": "exact",
    "walletAmounts": { "812": 0.1, "813": 0.05 },
    "minDelayMs": 2000,
    "maxDelayMs": 9000,
    "dryRun": true
  },
  "autostart": true
}
```

| Field | |
|---|---|
| `type` | The engine, e.g. `buy`, `bundle`, `volume`, `dca`, `ladder`, `trailing_stop` |
| `mint`, `walletIds` | Token and wallets |
| `config` | That engine's settings, the same fields as its form in the app. See the engine's own docs page |
| `chain`, `label`, `projectId` | Optional |
| `autostart` | `true` starts it right away. Default `false` |

The response is `201` with the full task:

```json
{
  "id": "6186",
  "projectId": null,
  "chain": "solana",
  "type": "buy",
  "mint": "7xKX…pump",
  "status": "running",
  "config": { "buyMode": "exact", "walletAmounts": { "812": 0.1, "813": 0.05 }, "dryRun": true, "…": "…" },
  "walletIds": ["812", "813"],
  "label": "morning buys",
  "lastError": null,
  "startedAt": "2026-09-16T01:09:24.531Z",
  "stoppedAt": null,
  "createdAt": "2026-09-16T01:09:24.500Z"
}
```

Wallets must be yours; someone else's wallet id is refused with `403` and `code: "wallet_not_allowed"`. A key with limits gets `403` and `code: "key_restricted"`.

## Read

`GET /tasks` returns `{ "tasks": [ … ] }`, each in the same shape as the object above. `GET /tasks/:id` returns one. Task `status` is `idle`, `running`, `completed`, `stopped` or `failed`.

`GET /tasks/:id/executions` returns `{ "executions": [ … ] }`: one row per trade the task sent, newest first, with its `signature`, `walletId`, amounts in base units and whether it was simulated.

:::tip Simulate first
Most engines take `"dryRun": true` in `config`, and walk through every step without sending. Executions are marked as simulated, and nothing leaves the wallet.
:::

## Events

`GET /events` is the app's activity feed: every task status change and every trade, as one row each.

```json
{
  "events": [
    { "id": "918273", "ts": "2026-09-16T20:11:02.000Z", "category": "execution", "type": "task_execution", "severity": "success",
      "taskId": "6605", "mint": "7xKX…pump", "walletId": "812", "title": "Buy landed", "data": { "…": "…" } }
  ],
  "nextBefore": "918200"
}
```

Filter with `category` (`task` or `execution`), `taskId`, `mint` or `severity` (`info`, `success`, `warn`, `error`); `limit` up to 200. Pass `nextBefore` back as `?before=` for the older page. You only ever see your own events.

`GET /warmup/candidates?chain=solana&limit=20` lists the tokens the Warmup engine's live rule accepts at this moment, with the rule and cache stats — handy before you create a Warmup task.

## Follow a task

Subscribe to the `tasks` topic on the [live stream](https://vortexdeployer.com/docs/api/streams) with a `read` key. You get a snapshot of your running tasks, then every status change.

## See also

- [Buy, sell & batches](https://vortexdeployer.com/docs/api/trading): slow batches start a Buy task for you
- [How tasks run](https://vortexdeployer.com/docs/tasks/overview)

---

# Wallets, portfolio & PnL

> List and create wallets, read balances, holdings, projects and profit and loss.

Source: https://vortexdeployer.com/docs/api/wallets-pnl · Markdown: https://vortexdeployer.com/docs/api/wallets-pnl.md

## Wallets

| Method & path | Scope | Does |
|---|---|---|
| `GET /wallets` | `read` | Every wallet in your account (paged) |
| `GET /wallets/balances` | `read` | Coin balances (paged) |
| `GET /wallets/token-balances?mint=…` | `read` | One token's balance in each wallet |
| `POST /wallets` | `trade` | Create or import wallets |
| `PATCH /wallets/:id` | `trade` | Rename a wallet, change its role or move it into a group |
| `DELETE /wallets/:id` | `trade` | Delete a wallet |
| `GET /wallets/:id/profile` | `read` | One wallet's trading history in numbers |
| `GET /wallets/groups` · `POST /wallets/groups` | `read` / `trade` | Your wallet groups (folders) |
| `PATCH /wallets/groups/:id` · `DELETE /wallets/groups/:id` | `trade` | Rename or delete a group |
| `GET /wallets/cashback` · `POST /wallets/cashback/claim` | `read` / `trade` | pump.fun cashback per wallet, and claim it |

`GET /wallets` lists your **global** wallets by default. `?scope=all` adds the wallets that live inside a project, `?groupId=` narrows to one group and `?chain=` to one chain.

`GET /wallets`:

```json
{
  "wallets": [
    {
      "id": "812",
      "chain": "solana",
      "evmChainId": null,
      "address": "7tXi4mbvppPBgYgTVj2NpYq9K1KYYQvHv6tfCpJv9kMT",
      "role": "dev",
      "label": "funded-test-wallet",
      "groupId": null,
      "projectId": null,
      "createdAt": "2026-08-29T10:03:44.318Z"
    }
  ]
}
```

`GET /wallets/balances` — coin balance per wallet, in the coin's smallest unit (`lamports` on Solana):

```json
{
  "balances": [
    {
      "id": "812",
      "address": "7tXi4mbv…9kMT",
      "chain": "solana",
      "role": "dev",
      "label": "funded-test-wallet",
      "lamports": "419434195",
      "block": 447482145,
      "seeded": true
    }
  ]
}
```

`GET /wallets/token-balances?mint=…` — one token's balance in every wallet, as a map of wallet id to base units (`mint` is required):

```json
{
  "mint": "7xKX…pump",
  "balances": { "812": "3512000000", "813": "0" }
}
```

### Create or import wallets

`POST /wallets`

```json
{ "chain": "solana", "count": 5, "label": "bot fleet" }
```

- `count` is 1–100 new wallets.
- Send `privateKey` instead to import a wallet you hold, or `privateKeys` (a list, up to 100) to import many in one call:

```json
{ "chain": "solana", "privateKeys": ["5Kd3…", "3xQe…", "4hTm…"], "label": "imported fleet" }
```

- Importing is all-or-nothing: one bad or repeated key is a `400` naming its position (`privateKeys[2]`) and nothing is written.
- A key you already hold comes back as the wallet it is, unchanged (same id, role and label), so a list can be sent again after a timeout.
- Wallets are **global**: every wallet lives in your account's pool and any project can use it. Add `projectId` to create or import straight into a project — the wallets show under that project and stay reusable elsewhere. A project takes up to 100 wallets; an id that is not one of your projects is a `404`.

The response is `201` with the new wallets:

```json
{ "wallets": [ { "id": "9001", "chain": "solana", "address": "…", "role": "trading", "label": "bot fleet" } ] }
```

New wallets appear on the [Wallets](https://vortexdeployer.com/docs/wallets/overview) page straight away.

:::info No key export
The API never returns private keys. Export them from the app, with your password ([Key export](https://vortexdeployer.com/docs/wallets/key-export)).
:::

A key limited to **allowed wallets** can still list every wallet, but can only trade from, rename or delete the wallets on its list.

### Rename a wallet or change its role

`PATCH /wallets/:id`

```json
{ "label": "sniper 1" }
```

- `label` is up to 120 characters; send `null` to clear it.
- `role` is `dev`, `trading` or `funding` (the roles the app's wallet page offers).
- `groupId` moves the wallet into one of your [groups](#wallet-groups); `null` takes it out of its group.
- Send any of the three; an empty body or an unknown field is a `400`.
- The answer is `{ "wallet": { … } }`, the wallet after the change, in the same shape as `GET /wallets`.

### Delete a wallet

`DELETE /wallets/:id`

Deleting moves no funds and cannot lose a key you still hold: the wallet leaves your lists and stops being usable in the app and the API, and importing the same private key again brings it back as it was. The answer is `{ "deleted": "812" }`.

Two refusals, both `409` with `code: "conflict"`:

- A running or paused task uses the wallet. Stop the task first (the error names it).
- One of your projects still uses the wallet. The error lists them in `projects`. Deleting anyway empties the wallet's seat in each project; do that with `DELETE /wallets/:id?force=true`.

A wallet that is not yours, or does not exist, is a `404`.

### Wallet groups

Groups are the folders of the Wallets page. A group only organises: it moves no funds and a wallet can be in one group at a time.

```bash
curl -X POST https://evm.vortexdeployer.com/evm/api/v1/wallets/groups \
  -H "Authorization: Bearer vd_…" -H "Content-Type: application/json" \
  -d '{ "name": "snipers" }'
```

```json
{ "group": { "id": "728", "name": "snipers", "walletCount": "0", "createdAt": "2026-09-16T23:12:35.947Z" } }
```

- `GET /wallets/groups` returns `{ "groups": [ … ] }` with a `walletCount` per group.
- `PATCH /wallets/groups/:id` takes `{ "name": "…" }` (1–64 characters). A name you already use is `409` with `code: "conflict"`, on create and on rename.
- `DELETE /wallets/groups/:id` answers `{ "deleted": "728" }`. Its wallets stay in your account, ungrouped.
- Put a wallet in a group with `PATCH /wallets/:id { "groupId": "728" }`; list a group's wallets with `GET /wallets?groupId=728`.

### Wallet profile

`GET /wallets/:id/profile` is the wallet's history in numbers, from your ledger:

```json
{
  "profile": {
    "walletId": "812", "chain": "solana", "address": "7tXi4mbv…9kMT", "role": "dev", "label": "funded-test-wallet",
    "createdAt": "2026-08-29T10:03:44.318Z", "ageDays": 18, "lastActivityAt": "2026-09-15T20:11:02.000Z",
    "tradeCount": 141, "buyCount": 80, "sellCount": 61, "distinctMints": 9, "holderPositions": 3,
    "solSpentLamports": "1048881293", "solReceivedLamports": "552401905"
  }
}
```

### Cashback

pump.fun pays cashback on volume to each trading wallet. `GET /wallets/cashback` (paged like `GET /wallets`) lists what each wallet has `earned`, `claimed` and can claim now, in lamports, with `needsWsolAccount` when the claim must first open the wallet's wrapped-SOL account.

`POST /wallets/cashback/claim` claims for up to 200 wallets:

```json
{ "walletIds": ["812", "813"], "dryRun": true }
```

`dryRun` defaults to **true**; send `false` to claim. The answer is `{ "dryRun": …, "outcomes": [ { "walletId", "claimable", "ok", "signature", "err" } ] }`. A sandbox key can only rehearse; a wallet-list key can only claim for wallets on its list.

### Paging long lists

`GET /wallets`, `GET /wallets/balances` and `GET /portfolio` can run to hundreds of rows. They take `limit` (1–500, default 200) and `offset` (default 0), and every answer carries the full size in `X-Total-Count`:

```bash
curl "https://evm.vortexdeployer.com/evm/api/v1/wallets?limit=100&offset=200" \
  -H "Authorization: Bearer vd_…" -i
```

Keep adding `limit` to `offset` until `offset` reaches `X-Total-Count`. A `limit` outside 1–500 is `400` with `code: "validation_failed"`.

## Portfolio & projects

| Method & path | Does |
|---|---|
| `GET /portfolio` | Coin totals across your wallets (`balances` paged) |
| `GET /portfolio/holdings` | Tokens you hold, grouped by token |
| `GET /portfolio/pnl` | PnL per token |
| `GET /portfolio/daily` | Day-by-day results |
| `GET /projects` | Tokens you launched, newest first, with their live stage and market cap |
| `GET /projects/:mint` · `GET /projects/by-id/:id` | One project |
| `POST /projects` · `POST /projects/cto` | Create a draft project, or take over a token that already exists on chain |
| `PATCH /projects/:id` · `DELETE /projects/:id` | Edit or delete a project |
| `GET /projects/:id/wallets` · `POST /projects/:id/wallets/assign` · `DELETE /projects/:id/wallets/:walletId` | The wallets in a project |
| `POST /projects/:id/closeout` | Sell every project wallet's bag and sweep the coin to one wallet |
| `POST /pnl/wallet-totals` | One token's cash-flow totals across a list of wallet addresses |

Reads need `read`; every write needs `trade`.

`GET /portfolio`:

```json
{
  "chain": "solana",
  "sol": {
    "totalLamports": "31497186480",
    "walletCount": 716,
    "balances": [ { "id": "812", "address": "…", "lamports": "419434195", "…": "…" } ]
  }
}
```

`GET /projects` returns `{ "projects": [ … ], "launchedTotal": 12, "nextCursor": null }`. Each project has its `id`, `chain`, `mint`, `name`, `symbol`, `launchpad`, `devWalletId`, `dryRun`, `launchedAt`, `createdAt`, the `metadataUri` the launch pinned, and on the list `market` (stage and market cap). Pass `nextCursor` back as `?cursor=` for the next page. `GET /projects/:mint` returns `{ "project": { … } }`.

### Create, edit and delete a project

`POST /projects` creates a **draft**: a project without a token yet, the same as _New project_ in the app. Set it up, put wallets in it, then launch it with [`POST /launch`](https://vortexdeployer.com/docs/api/launch) or from the app.

```json
{ "chain": "solana", "name": "Vortex Cat", "symbol": "VCAT", "launchpad": "pump", "devWalletId": "812" }
```

Every field is optional (`chain` defaults to `solana`). The answer is `201 { "project": { … } }` in the same shape as `GET /projects/by-id/:id`.

`POST /projects/cto` takes over a token that is already on chain (a _community takeover_): `{ "chain": "solana", "mint": "…" }` makes it a project of yours so tasks and the terminal can work on it. A mint nobody has indexed is a `404`.

`PATCH /projects/:id` changes `name`, `symbol`, `launchpad` or `devWalletId`. Once a project is launched its name, symbol and launchpad are frozen: changing them is `409` with `code: "conflict"`. `DELETE /projects/:id` answers `{ "deleted": "1021" }`; the project leaves your lists and its history stays.

### A project's wallets

`GET /projects/:id/wallets` lists them (paged), each with an `origin`: `project` for a wallet created inside the project, `assigned` for one of your global wallets linked to it.

`POST /projects/:id/wallets/assign` links global wallets: `{ "walletIds": ["813", "814"] }` (up to 500) answers `{ "assigned": [ … ], "skipped": [ … ] }`, `skipped` being the ones already in the project. Or create wallets straight into a project with `POST /wallets` and `projectId`.

`DELETE /projects/:id/wallets/:walletId` takes a wallet out: `{ "walletId": "813", "outcome": "unassigned" }` for a linked global wallet (it still exists) or `"deleted"` for a project-only wallet.

### Close out a project

`POST /projects/:id/closeout` is the app's _Close out_: it sells the token in every project wallet and starts a Collector task that sweeps the coin to one wallet.

```json
{ "destinationWalletId": "812", "dryRun": true }
```

`dryRun` defaults to **true** and rehearses the sells without sending; the sweep is recorded as a dry-run Collector task, so you can inspect it under `GET /tasks`. Send `"dryRun": false` to close out for real. The answer:

```json
{
  "projectId": "1021", "mint": "J11L…pump", "chain": "solana", "symbol": "APIQA", "dryRun": true,
  "sells": [ { "walletId": "813", "address": "…", "ok": true, "signature": null, "err": null } ],
  "closed": [], "sweep": { "taskId": "6868", "sources": ["813"] }, "skipped": []
}
```

A key with limits (caps, a wallet list or sandbox) can only rehearse: `dryRun: false` is `403` with `code: "key_restricted"`. A wallet-list key must have the destination on its list.

`POST /pnl/wallet-totals` sums one token's flows across wallet **addresses** (up to 1000): `{ "mint": "…", "wallets": ["7tXi…"], "quoteMint": "So111…112" }` answers the spent, received and held totals the token page shows for that selection.

`GET /portfolio/holdings`:

```json
{
  "chain": "solana",
  "holdings": [
    {
      "mint": "7xKX…pump",
      "symbol": "VCAT",
      "name": "Vortex Cat",
      "decimals": 6,
      "rawAmount": "51920524244101",
      "uiAmount": 51920524.244101,
      "walletCount": 23,
      "wallets": [ { "id": "812", "address": "…", "label": "bot 1" } ]
    }
  ]
}
```

`GET /portfolio/daily`:

```json
{
  "chain": "solana",
  "days": [
    {
      "day": "2026-09-08",
      "buyCount": 81,
      "sellCount": 59,
      "solSpentLamports": "1048881293",
      "solReceivedLamports": "552401905",
      "netLamports": "-496479388",
      "feesLamports": "254446",
      "exactCount": 2
    }
  ]
}
```

## PnL

| Call | Returns |
|---|---|
| `GET /pnl` | Every token's position PnL, as on the Dashboard (same as `GET /portfolio/pnl`) |
| `GET /pnl?mint=…` | One token's realized and unrealized PnL in USD, the figure on its share card |

`GET /pnl`:

```json
{
  "chain": "solana",
  "tokens": [
    {
      "mint": "7xKX…pump",
      "symbol": "VCAT",
      "name": "Vortex Cat",
      "buyCount": 23,
      "sellCount": 0,
      "solSpentLamports": "2294703578",
      "solReceivedLamports": "0",
      "realizedSolPnlLamports": "-2294703578",
      "feesLamports": "225000",
      "exactCount": 23,
      "held": true,
      "currentValueLamports": "2276357388",
      "totalPnlLamports": "-18346190"
    }
  ]
}
```

`GET /pnl?mint=…`:

```json
{
  "mint": "7xKX…pump",
  "pnl": {
    "profitUsd": 42.17,
    "profitQuote": 0.271,
    "quoteUsd": 155.6,
    "wallets": 3,
    "trades": 12,
    "held": 3512000000,
    "spotQuote": 0.0000004
  }
}
```

When a token can't be priced, `pnl` is `null` and `reason` says why:

```json
{ "mint": "7xKX…pump", "pnl": null, "reason": "Live holdings are not available yet" }
```

Want it live? Subscribe to `pnl` or `pnl:<mint>` on the [live stream](https://vortexdeployer.com/docs/api/streams).

## See also

- [Dashboard](https://vortexdeployer.com/docs/account/dashboard)
- [Portfolio](https://vortexdeployer.com/docs/account/portfolio)

---

# Account settings & KOLs

> Read and change your trading settings and the wallets you track (KOLs) from code, and what stays in the app.

Source: https://vortexdeployer.com/docs/api/account · Markdown: https://vortexdeployer.com/docs/api/account.md

Two account-level settings pages are on the API: the temporary-wallet sell settings and the KOL tracker. Reads need `read`, writes `trade`.

## Trading settings

`GET /settings/trading` is the [Settings → Trading](https://vortexdeployer.com/docs/account/settings) page:

```json
{
  "sellThroughTemporaryWallet": true,
  "temporarySellMode": "all",
  "temporarySellManual": { "simple": true, "uniqueWallet": true, "percentage": true, "sellAll": true, "sellAllExceptDev": true, "sellDev": true, "tradePanel": true },
  "temporarySellTasks": true,
  "temporarySellTaskTypes": { "…": true }
}
```

`PATCH /settings/trading` takes either the one switch — `{ "sellThroughTemporaryWallet": false }` — or the full custom shape (`temporarySellMode` of `off`, `all` or `custom` with `temporarySellManual`, `temporarySellTasks` and optionally `temporarySellTaskTypes`). The answer is the settings after the change. The setting applies to every sell you make afterwards, from the app, the API and tasks alike.

## Tracked wallets (KOLs)

The addresses the terminal marks as KOLs are yours to edit:

| Method & path | Does |
|---|---|
| `GET /kols` | Your tracked addresses (paged) |
| `POST /kols` | Track one: `{ "address": "…", "name": "…", "emoji": "🐳" }` → `201 { "kol": { "id", "address", "name", "emoji", "createdAt" } }` |
| `PATCH /kols/:address` | Change `name` or `emoji` (`null` clears) |
| `DELETE /kols/:address` | Stop tracking it → `{ "removed": "…" }` |

An address that is not on your list is a `404`; tracking one twice is a `409` with `code: "conflict"`.

## What stays in the app

- **API keys.** Creating, editing and revoking keys is only possible signed in, in the API hub. A key that could mint keys would be a way around every limit you put on it.
- **Wallet private keys** never leave the platform through the API: there is no export route.
- Sign-in, password and profile, the marketplace, referrals, subscription and support tickets are app-only.

## See also

- [API overview & keys](https://vortexdeployer.com/docs/api/overview)
- [Wallets, portfolio & PnL](https://vortexdeployer.com/docs/api/wallets-pnl)

---

# Live streams

> Subscribe to live trades, live PnL and live wallet balances over a WebSocket with your API key.

Source: https://vortexdeployer.com/docs/api/streams · Markdown: https://vortexdeployer.com/docs/api/streams.md

Connect to `wss://evm.vortexdeployer.com/evm/ws` and send JSON messages. Put your key in `token` on each subscribe.

```js
const ws = new WebSocket('wss://evm.vortexdeployer.com/evm/ws');
ws.onopen = () => {
  ws.send(JSON.stringify({ type: 'subscribe', topic: 'txs', token: 'vd_…' }));
  setInterval(() => ws.send(JSON.stringify({ type: 'ping' })), 25_000);
};
ws.onmessage = (m) => console.log(JSON.parse(m.data));
```

:::danger Server-side only
Never open a keyed stream from a web page. Anyone can read the key from the browser.
:::

## Topics

| Topic | Scope | Sends |
|---|---|---|
| `txs` | `stream` | Every trade the platform sees, as it happens — across every venue. No per-token subscribe needed |
| `txs:<mint>` | `stream` | Trades on one token, starting with a snapshot of its recent trades |
| `pnl` | `stream` | Your per-token PnL on Solana, refreshed as it changes |
| `pnl:<mint>` | `stream` | One token's PnL for your account |
| `wallet:<address>` | `stream` | Live balance of one of **your** wallets: a snapshot, then a frame on every change |
| `tasks` | `read` | Your running tasks, then every change |

After a `subscribe` you get `{ "type": "subscribed", "topic": … }`, or `{ "type": "error", "topic": …, "message": … }` saying why not. Send `{ "type": "unsubscribe", "topic": … }` to stop a topic.

The bare `txs` topic is a firehose: subscribe once and every trade streams in, no mint list to keep. It answers with `{ "type": "txs_snapshot", "topic": "txs", "note": "firehose: deltas only" }`, then live frames. `txs:<mint>` instead opens with a `trade_snapshot` of that token's recent trades.

## Trade frames

Every trade frame carries both sides of the pair, the pool, and the pool's reserves before and after the swap.

:::info Frames keep their on-chain names
Stream frames are the platform's raw chain feed and keep snake_case names (`pool_address`, `base_amount`, `block_index`). Only REST answers are camelCase.
:::

```json
{
  "type": "trade",
  "chain": "solana",
  "mint": "NnLz6wXfB3c41KwPWPvk9Rz75zR5enTGtYmsELrpump",
  "quote_mint": "So11111111111111111111111111111111111111112",
  "pool_address": "B8GeyGLChfj3Mn9HCyVJYS4nMRSMVDCCutRTwGasoH7V",
  "dex": "pump_swap",
  "side": "buy",
  "trader": "A2uqWi4Zm3yVYqvuRb4GF6BSb56pocvw1J2V2nQeU3QE",
  "base_amount": "44917",
  "quote_amount": "179054",
  "signature": "42RU7t2Drzyr…faT22",
  "block": 447482805,
  "block_index": 805,
  "timestamp": 1789549114,
  "pre_base_reserves": "2105102154648",
  "pre_quote_reserves": "8391614579937",
  "post_base_reserves": "2105102109731",
  "post_quote_reserves": "8391614758991"
}
```

| Field | |
|---|---|
| `mint` | The token traded (the base token) |
| `quote_mint` | The token it traded against (the quote token — e.g. wrapped SOL) |
| `pool_address` | The pool the trade went through |
| `dex` | The venue (`pump_fun`, `pump_swap`, `raydium_cpmm`, `meteora_bonding`, `pons`, …) |
| `side` | `buy` or `sell` |
| `trader` | The wallet that traded |
| `base_amount`, `quote_amount` | Amounts traded, in each token's base units |
| `signature`, `block`, `block_index`, `timestamp` | Where the trade landed on chain |
| `pre_base_reserves`, `pre_quote_reserves` | The pool's two reserves just before the swap |
| `post_base_reserves`, `post_quote_reserves` | The pool's two reserves just after |

Reserves are `null` for a venue that does not report them. From the reserves you can read the pool's price without another call.

## PnL frames

```json
{ "type": "pnl_update", "mint": "7xKX…pump", "at": 1757923203112, "pnl": { } }
```

- `at` only ever goes up. Ignore a frame whose `at` is not newer than the last one.
- On `pnl` (no mint), the frame carries `chain` and `tokens` instead of `pnl`.
- `pnl: null` comes with a `reason`.
- `{ "type": "resync" }` means the server may have missed updates: re-read what you need over REST.

## Balance frames

`wallet:<address>` streams the live coin and token balance of one wallet. The address must be one of **your** wallets — any other address is refused. Subscribing answers with a `wallet_balance_snapshot`, then a `wallet_balance_update` on every change:

```json
{
  "type": "wallet_balance_snapshot",
  "topic": "wallet:7tXi4mbvppPBgYgTVj2NpYq9K1KYYQvHv6tfCpJv9kMT",
  "chain": "solana",
  "address": "7tXi4mbvppPBgYgTVj2NpYq9K1KYYQvHv6tfCpJv9kMT",
  "sol": "419434195",
  "tokens": [ { "mint": "7xKX…pump", "amount": "3512000000" } ],
  "block": 447482145,
  "block_index": null
}
```

```json
{
  "type": "wallet_balance_update",
  "chain": "solana",
  "address": "7tXi4mbvppPBgYgTVj2NpYq9K1KYYQvHv6tfCpJv9kMT",
  "sol": "420100000",
  "tokens": [ { "mint": "7xKX…pump", "amount": "3500000000" } ],
  "block": 447482806,
  "block_index": 806
}
```

| Field | |
|---|---|
| `chain`, `address` | The wallet |
| `sol` | Coin balance in the smallest unit as a string — lamports on Solana, wei on EVM |
| `tokens` | Token balances being tracked for this wallet: `mint` and `amount` in base units |
| `block`, `block_index` | Where the balance was last observed on chain (`block_index` can be `null`) |

To seed a token into the snapshot, send `mint` on the subscribe: `{ "type": "subscribe", "topic": "wallet:<address>", "mint": "7xKX…pump", "token": "vd_…" }`. The stream then keeps that token's `amount` live alongside the coin balance.

A key limited to an **allowed wallet list** can only open wallets on that list.

## Rules

- **One identity per socket.** Once a socket subscribes with a key, a different key or account on the same socket is refused.
- Up to **5 sockets per key**, and **50** `txs`/`pnl` subscriptions (and **50** `wallet` subscriptions) per socket.
- Too many bad keys closes the socket (code `4008`).
- Revoking or editing the key closes its sockets (code `4001`). Reconnect with a valid key.
- Keys can't use the socket's read requests. Use REST for reads.
- The key's IP allowlist applies to sockets too.

Reconnect with a backoff after a drop, then subscribe again. Subscriptions don't survive a reconnect.

## See also

- [Limits, retries & errors](https://vortexdeployer.com/docs/api/limits-errors)

---

# Limits, retries & errors

> Rate limits, safe retries with Idempotency-Key, and what every error looks like.

Source: https://vortexdeployer.com/docs/api/limits-errors · Markdown: https://vortexdeployer.com/docs/api/limits-errors.md

## Rate limits

Only **reads** are rate-limited. Buys, sells, batches, launches and every other write are **not** throttled — the spending guardrails are the key's own scopes and caps (`maxSolPerTrade`, `dailySolCap`, the wallet list), not a per-minute bucket.

Reads are counted per minute, per key **and** per account. Many keys on one account share the account's limit.

| Kind of call | Per key | Per account |
|---|---|---|
| Reads (`GET`) | 300 | 600 |
| Writes and launches | no limit | no limit |

A read answer carries the key's bucket in three headers (writes carry none — there is no bucket):

| Header | |
|---|---|
| `X-RateLimit-Limit` | Reads per minute the key allows |
| `X-RateLimit-Remaining` | Reads left in the current minute |
| `X-RateLimit-Reset` | When the bucket is full again, as a Unix time in seconds |

Over the limit you get `429` with a `Retry-After` header (seconds), and the same number in the body:

```json
{ "code": "rate_limited", "error": "rate limit reached — slow down", "retryAfterSeconds": 12, "traceId": "…" }
```

Wait that long before trying again. Too many calls with a wrong or revoked key from one address are refused with `429` and `code: "auth_rate_limited"` for a minute.

## Retry safely

Networks drop answers. To retry a buy, sell, batch or launch without doing it twice, send an `Idempotency-Key` header: a unique string you pick per operation, 8–128 characters of letters, digits, `-`, `_` or `:`.

```bash
curl -X POST https://evm.vortexdeployer.com/evm/api/v1/buy \
  -H "Authorization: Bearer vd_…" \
  -H "Idempotency-Key: buy-2026-09-15-0001" \
  -H "Content-Type: application/json" \
  -d '{"mint":"7xKX…pump","walletId":"812","amountSol":0.05}'
```

| You send again | You get |
|---|---|
| Same key, same body | The first call's answer. Nothing is sent twice |
| Same key, same body, first call still running | `409` with `code: "operation_pending"`. Ask again shortly |
| Same key, **different** body | `409` with `code: "idempotency_conflict"`. Use a new key for a new operation |
| A key outside 8–128 characters or with other characters | `400` with `code: "invalid_idempotency_key"` |

:::warning Always use it for money
Without `Idempotency-Key`, a retry is a new trade.
:::

## Errors

Every error is JSON with three fixed fields:

```json
{ "code": "insufficient_scope", "error": "this API key does not have the 'trade' scope", "traceId": "9f1c…" }
```

| Field | |
|---|---|
| `code` | A stable, machine-readable name for the refusal (table below). Switch on this |
| `error` | What went wrong, for people. The wording may change; the code won't |
| `traceId` | Quote it in a [support ticket](https://vortexdeployer.com/docs/account/support) |

Some codes add a field naming the limit that refused you: `over_trade_cap` sends `maxSolPerTrade`, `over_daily_cap` sends `dailySolCap`, `wallet_not_allowed` sends `walletId`, `rate_limited` sends `retryAfterSeconds`.

A malformed body is `validation_failed` and lists each problem with its `path`:

```json
{
  "code": "validation_failed",
  "error": "validation failed",
  "details": [{ "path": "amountSol", "message": "Too small: expected number to be >0" }],
  "traceId": "…"
}
```

### Codes

| Code | Status | Means |
|---|---|---|
| `validation_failed` | `400` | The body or query is malformed. `details` lists every problem. Fix it; retrying won't help |
| `bad_request` | `400` | Understood but refused, e.g. a delayed sell batch, or `buys` on an EVM launchpad |
| `invalid_idempotency_key` | `400` | The `Idempotency-Key` header is malformed |
| `invalid_api_key` | `401` | Missing, wrong or revoked key |
| `insufficient_scope` | `403` | The key doesn't have the scope this route needs |
| `ip_not_allowed` | `403` | The call came from outside the key's IP allowlist |
| `key_restricted` | `403` | A key with limits tried something only an unlimited key may do (tasks, a real launch) |
| `sandbox_key` | `403` | A sandbox key sent a real (`dryRun: false`) call |
| `wallet_not_allowed` | `403` | The wallet isn't yours, or isn't on the key's wallet list |
| `private_key_not_allowed` | `403` | A wallet-list key sent a `privateKey` |
| `over_trade_cap` | `403` | A buy above the key's **Max per buy** |
| `over_daily_cap` | `403` | The buy would pass the key's **Daily cap** |
| `not_found` | `404` | No such route, or the task, project or wallet isn't yours |
| `idempotency_conflict` | `409` | Same `Idempotency-Key`, different body |
| `operation_pending` | `409` | Same `Idempotency-Key`, first call still running. Ask again shortly |
| `conflict` | `409` | The change clashes with the current state |
| `payload_too_large` | `413` | The body is over the size limit |
| `unprocessable` | `422` | Understood but impossible, e.g. selling a token the wallet doesn't hold |
| `rate_limited` | `429` | Over the rate limit. Honour `Retry-After` |
| `auth_rate_limited` | `429` | Too many bad keys from this address. Wait a minute |
| `internal_error` | `500` | Our side. Retry with the same `Idempotency-Key`, and quote the `traceId` |
| `service_unavailable` | `503` | Briefly unavailable, or an idempotent operation is being reconciled. Retry with the same `Idempotency-Key` |

Every status and code, per route, is in the [OpenAPI document](https://evm.vortexdeployer.com/evm/api/v1/openapi.json).

## Request an API feature

**API** → **Requests** files a feature request. Replies arrive on the ticket and in the bell.

---

# MCP for AI agents

> Let Claude, Cursor or any MCP client trade, launch, run tasks and read your PnL through your API key — one tool per API operation, nothing to install.

Source: https://vortexdeployer.com/docs/api/mcp · Markdown: https://vortexdeployer.com/docs/api/mcp.md

VortexDeployer is an **MCP server** (Model Context Protocol, the open standard AI assistants use to call tools). Point an MCP client at the endpoint with your API key and it gets one tool per API operation — the same buy, sell, launch, tasks, wallets and PnL calls as the REST API, with the same scopes and limits.

| What | Value |
|---|---|
| Endpoint | `https://evm.vortexdeployer.com/evm/api/v1/mcp` |
| Transport | Streamable HTTP, stateless — plain JSON answers, no session to keep |
| Auth | `Authorization: Bearer vd_…` on every request, exactly like REST — or a `vdo_…` OAuth access token bound to one ([OAuth for connectors](https://vortexdeployer.com/docs/api/oauth)) |
| Tools | 84, generated from the [OpenAPI document](https://vortexdeployer.com/docs/api/overview#base-urls) — never out of date |

:::danger The agent acts as you
Every tool runs as your account with real funds. Give an agent a key with only the scopes it needs, put `maxSolPerTrade` and `dailySolCap` on it, and keep `launch` off unless it launches. Start with a `read`-only key.
:::

## Connect

**Claude Code**

```bash
claude mcp add --transport http vortex https://evm.vortexdeployer.com/evm/api/v1/mcp \
  --header "Authorization: Bearer vd_…"
```

**Claude Desktop, Cursor, Windsurf and most others** take a JSON entry:

```json
{
  "mcpServers": {
    "vortex": {
      "url": "https://evm.vortexdeployer.com/evm/api/v1/mcp",
      "headers": { "Authorization": "Bearer vd_…" }
    }
  }
}
```

Then ask: *"Which of my wallets hold SOL?"*, *"Dry-run a 0.1 SOL buy of `<mint>` from wallet 12"*, *"Pause every running task"*. The assistant picks the tool, fills the arguments and shows you the answer.

**From your own code** — any MCP SDK works; with the official TypeScript one:

```ts
import { Client } from '@modelcontextprotocol/sdk/client/index.js';
import { StreamableHTTPClientTransport } from '@modelcontextprotocol/sdk/client/streamableHttp.js';

const client = new Client({ name: 'my-agent', version: '1.0.0' });
await client.connect(new StreamableHTTPClientTransport(new URL('https://evm.vortexdeployer.com/evm/api/v1/mcp'), {
  requestInit: { headers: { Authorization: 'Bearer vd_…' } },
}));
const { tools } = await client.listTools();
const me = await client.callTool({ name: 'me', arguments: {} });
```

**Claude.ai (custom connector)** — claude.ai can't send a static bearer key, so it connects with **OAuth** instead: add a custom connector with the URL `https://evm.vortexdeployer.com/evm/api/v1/mcp`, and Claude runs the standard OAuth 2.1 dance against this server — register, consent, token. At consent you sign in here and **pick which of your API keys the connector acts as**; the access token it receives (`vdo_…`) then works everywhere a `vd_` key does, governed by that key's scopes and caps. Full details: [OAuth for connectors](https://vortexdeployer.com/docs/api/oauth).

## Tools

Tool names are the `operationId`s of the OpenAPI document. A tool's arguments are the operation's path and query parameters plus its JSON body, flattened into one object; a route that takes an `Idempotency-Key` header takes it as the `idempotencyKey` argument.

| Tool | REST call | Scope |
|---|---|---|
| `me` | `GET /me` | any |
| `buy`, `sell`, `trade_batch` | `POST /buy`, `/sell`, `/trade/batch` | `trade` |
| `launch` | `POST /launch` (`dryRun` defaults to **true**) | `launch` |
| `list_launchpads`, `launch_quotes` | `GET /launchpads`, `/launchpads/:launchpad/quotes` — which quote tokens and stocks a launch can use | `read` |
| `list_wallets`, `wallet_balances`, `token_balances`, `wallet_profile` | `GET /wallets`, `/wallets/balances`, `/wallets/token-balances`, `/wallets/:id/profile` | `read` |
| `create_wallets`, `update_wallet`, `delete_wallet` | `POST /wallets`, `PATCH`/`DELETE /wallets/:id` | `trade` |
| `list_wallet_groups`, `create_wallet_group`, `rename_wallet_group`, `delete_wallet_group` | `/wallets/groups…` | `read` / `trade` |
| `list_cashback`, `claim_cashback` | `GET /wallets/cashback`, `POST /wallets/cashback/claim` (`dryRun` defaults to **true**) | `read` / `trade` |
| `portfolio`, `holdings`, `portfolio_pnl`, `daily_pnl`, `pnl`, `wallet_totals` | `GET /portfolio…`, `/pnl`, `POST /pnl/wallet-totals` | `read` |
| `list_projects`, `project_by_id`, `project_by_mint`, `project_wallets` | `GET /projects…` | `read` |
| `create_project`, `create_cto_project`, `update_project`, `delete_project`, `assign_project_wallets`, `unlink_project_wallet` | `POST`/`PATCH`/`DELETE /projects…` | `trade` |
| `closeout_project` | `POST /projects/:id/closeout` (`dryRun` defaults to **true**) | `trade` |
| `launch_readiness`, `next_mint_address`, `clone_token_look`, `launch_affordability`, `supply_preview`, `pons_launch_terms`, `otcdesks_rewards` | `GET`/`POST /launch/…` helpers | `read` |
| `upload_metadata` | `POST /launch/metadata` | `launch` |
| `list_supply_plans`, `save_supply_plan`, `delete_supply_plan`, `mount_supply_plan` | `/supply-plans…` | `read` / `trade` |
| `conversion_assets`, `conversion_quote`, `convert` | `POST /convert/assets`, `/convert/quote`, `/convert` | `read` / `trade` |
| `burn_tokens`, `lock_tokens` | `POST /tokens/burn`, `/tokens/lock` (`dryRun` defaults to **true**) | `trade` |
| `creator_fees`, `claim_creator_fees` | `GET /tokens/creator-fees`, `POST /tokens/creator-fees/claim` | `read` / `trade` |
| `list_events`, `warmup_candidates` | `GET /events`, `/warmup/candidates` | `read` |
| `trading_settings`, `update_trading_settings` | `GET`/`PATCH /settings/trading` | `read` / `trade` |
| `list_kols`, `track_kol`, `update_kol`, `untrack_kol` | `/kols…` | `read` / `trade` |
| `list_tasks`, `get_task`, `task_executions`, `task_playbook`, `task_postmortem`, `task_mixer_orders`, `task_disperse`, `preview_task` | `GET /tasks…`, `POST /tasks/:id/preview` | `read` |
| `create_task`, `update_task`, `delete_task`, `start_task`, `resume_task`, `pause_task`, `stop_task`, `stop_all_tasks` | `POST`/`PATCH`/`DELETE /tasks…` | `trade` |
| `list_presets`, `save_preset`, `delete_preset` | `/tasks/presets…` | `read` / `trade` |
| `execute_mixer_recipient` | `POST /tasks/:id/mixer-orders/:orderId/recipients/:recipientId/execute` | `trade` |

Every tool carries MCP annotations: `readOnlyHint` is true on the `GET` tools, so a client that asks before any non-read call asks before every trade.

## What a call returns

A tool result is the REST answer, as text and as `structuredContent`, with the HTTP status and your rate window in `_meta`:

```json
{
  "content": [{ "type": "text", "text": "{ \"user\": { \"id\": \"1\", … }, \"key\": { … } }" }],
  "structuredContent": { "user": { "id": "1", "username": "yourname" }, "key": { "name": "agent", "scopes": ["read"], "restricted": false } },
  "_meta": { "status": 200, "rateLimit": { "limit": 300, "remaining": 299, "reset": 1758050400 } }
}
```

A refusal is `isError: true` with the same body a REST caller gets — a stable `code`, the human `error` and a `traceId` — so the assistant can read `insufficient_scope`, `validation_failed` (with `details`) or `rate_limited` and act on it:

```json
{ "isError": true, "content": [{ "type": "text", "text": "{ \"code\": \"insufficient_scope\", \"error\": \"this key lacks the trade scope\", \"traceId\": \"…\" }" }] }
```

Scopes, per-key limits, rate limits, idempotency and the [error codes](https://vortexdeployer.com/docs/api/limits-errors#codes) are exactly the REST ones — each tool call is the REST call, made for you.

## Good to know

- **No session.** Every request authenticates on its own; there is nothing to resume and a dropped connection loses nothing.
- **Long calls.** A launch or a synchronous batch can take a while; a tool call waits up to three minutes for its answer.
- **Streams** are not tools. For live trades, PnL and balances use the [WebSocket](https://vortexdeployer.com/docs/api/streams).
- **Usage** from an agent shows in the API hub under the same key, per route.

---

# OAuth for connectors

> Connect Claude.ai and other OAuth-only MCP clients to VortexDeployer — discovery, dynamic client registration, authorization code + PKCE, and grants bound to your API key.

Source: https://vortexdeployer.com/docs/api/oauth · Markdown: https://vortexdeployer.com/docs/api/oauth.md

Some MCP clients — **Claude.ai custom connectors** among them — can only authenticate with OAuth, never with a static bearer key. For them, VortexDeployer is also an **OAuth 2.1 authorization server**: the standard authorization-code flow with PKCE, dynamic client registration and refresh tokens, ending in an access token that works exactly like a `vd_` API key on [the MCP endpoint](https://vortexdeployer.com/docs/api/mcp), the REST API and the streams.

| What | Value |
|---|---|
| Issuer | `https://evm.vortexdeployer.com/evm/api/v1` |
| Discovery | `https://evm.vortexdeployer.com/.well-known/oauth-authorization-server` (RFC 8414) and `https://evm.vortexdeployer.com/.well-known/oauth-protected-resource` (RFC 9728) — fetched at the API host's root, not under `/api/v1` |
| Register | `POST https://evm.vortexdeployer.com/evm/api/v1/oauth/register` (RFC 7591) |
| Authorize | `GET https://evm.vortexdeployer.com/evm/api/v1/oauth/authorize` |
| Token | `POST https://evm.vortexdeployer.com/evm/api/v1/oauth/token` |
| Revoke | `POST https://evm.vortexdeployer.com/evm/api/v1/oauth/revoke` (RFC 7009) |

## The one idea: a grant is a key

At consent time **you pick one of your API keys**, and the OAuth grant is bound to it. The access token the client receives (`vdo_…`) then *is* that key for every purpose: the key's scopes, per-trade and daily caps, IP allowlist and rate limits govern everything the agent does, its calls appear in the API hub under that key, and **revoking the key ends the agent's access** — every token minted from it dies on the next call. Refresh tokens (`vdr_…`) rotate on every use; a replayed refresh token revokes the whole chain.

:::warning Pick a small key
The agent acts as you with real funds. Bind a `read`-only key for research, or a `trade` key with `maxSolPerTrade` and `dailySolCap`. Create a dedicated key in the app under **API** before connecting.
:::

## For a person connecting Claude.ai

1. In the app, open **API** and create a key for the agent (read-only or capped — see above).
2. In Claude.ai → **Settings → Connectors → Add custom connector**, paste `https://evm.vortexdeployer.com/evm/api/v1/mcp`.
3. Claude registers itself, then sends your browser to VortexDeployer. Sign in, pick the key, **Approve**.
4. Done — Claude's tools now act as that key. Disconnecting the connector (or revoking the key) ends access.

## For a client developer

The flow is textbook OAuth 2.1 — the SDK you already use (`@modelcontextprotocol/sdk` auth helpers, any OIDC-less OAuth client) works as-is.

**Discovery.** Fetch `/.well-known/oauth-protected-resource` at the MCP host's root (or follow the `WWW-Authenticate` header on a bare `401` from `POST /mcp`) to find the authorization server, then its `/.well-known/oauth-authorization-server` for the endpoints.

**Register** (once, public client — no secret is issued):

```http
POST https://evm.vortexdeployer.com/evm/api/v1/oauth/register
Content-Type: application/json

{ "client_name": "My agent", "redirect_uris": ["https://myapp.example/oauth/callback"] }
```

→ `201` with `client_id`, `grant_types`, `token_endpoint_auth_method: "none"`. Redirect URIs must be `https` (or `http` on loopback for local development), no fragments, and the authorize request's `redirect_uri` must match one **exactly**.

**Authorize.** Send the browser to:

```
GET https://evm.vortexdeployer.com/evm/api/v1/oauth/authorize?response_type=code
  &client_id=…&redirect_uri=…&state=…
  &code_challenge=<base64url(sha256(verifier))>&code_challenge_method=S256
```

S256 only. The owner signs in on the consent page, picks the API key the grant binds to, and approves; the browser comes back to your `redirect_uri` with `code` and `state` (or `error=access_denied`). A malformed request never redirects — it answers `400` in place.

**Exchange** (form-encoded, like every OAuth server):

```http
POST https://evm.vortexdeployer.com/evm/api/v1/oauth/token
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code&code=…&redirect_uri=…&client_id=…&code_verifier=…
```

→ `{ "access_token": "vdo_…", "token_type": "Bearer", "expires_in": 3600, "refresh_token": "vdr_…" }`. Codes are single-use and expire in two minutes; client, redirect URI and PKCE verifier must all match.

**Refresh.** `grant_type=refresh_token&refresh_token=…&client_id=…` — the old refresh token is rotated out; reuse revokes the chain.

**Use.** `Authorization: Bearer vdo_…` on `POST https://evm.vortexdeployer.com/evm/api/v1/mcp`, any REST route, and as the `token` field of a stream subscribe — anywhere a `vd_` key works, with the bound key's scopes and limits.

**Revoke.** `POST /oauth/revoke` with `token=…` — always `200`. Revoking the bound key in the app revokes every token minted from it.

## Errors

Protocol endpoints answer RFC 6749-style JSON, not the API's public error shape: `{ "error": "invalid_grant", "error_description": "…" }`. The usual suspects: `invalid_client_metadata` (bad registration), `invalid_request` (unknown client, redirect mismatch, missing PKCE), `invalid_grant` (code or refresh token invalid, expired, used or replayed), `temporarily_unavailable` (rate limited — the same per-IP budgets as failed API-key auth).

## Good to know

- **Lifetimes** (server-configured): auth code 2 min, access token 1 h, refresh token 30 days, parked consent 10 min.
- **No OAuth scopes.** The `scope` parameter is accepted and ignored — the bound key's scopes are the grant's scope.
- **No client secrets.** Every client is public; PKCE is what binds a code to its client.
- Streams accept `vdo_` tokens wherever a `vd_` key works, with the key's `stream` scope.

---

# Build an agent on the API

> How an AI agent finds the API, authenticates, and trades safely — llms.txt, the OpenAPI document, MCP, and the dry-run-then-commit loop.

Source: https://vortexdeployer.com/docs/api/agents · Markdown: https://vortexdeployer.com/docs/api/agents.md

Everything an agent needs is public and machine-readable. This page is the map; the other API pages hold the details, and each of them is also plain Markdown at its address plus `.md`.

## Find the API

| What | Where |
|---|---|
| `agents.txt` | `https://vortexdeployer.com/agents.txt` — the one-page manifest: every address below, how a key works, the safety rails, what an agent may fetch here and the rules, as `Field: value` lines |
| `llms.txt` | `https://vortexdeployer.com/llms.txt` — a short index of every docs page with a one-line summary, API pages first |
| `llms-full.txt` | `https://vortexdeployer.com/llms-full.txt` — every docs page in one Markdown file |
| Any page as Markdown | add `.md` to its address, e.g. `https://vortexdeployer.com/docs/api/trading.md` |
| API index | `GET https://evm.vortexdeployer.com/evm/api/v1` — a JSON object with every address in this table, no key needed |
| OpenAPI 3.1 | `https://evm.vortexdeployer.com/evm/api/v1/openapi.json` — every REST operation with its `operationId`, parameters, body schema and the scope it needs (`x-scope`) |
| MCP server | `https://evm.vortexdeployer.com/evm/api/v1/mcp` — the same operations as tools ([MCP for AI agents](https://vortexdeployer.com/docs/api/mcp)) |
| Live streams | `wss://evm.vortexdeployer.com/evm/ws` — trades, PnL and balances as they happen ([Live streams](https://vortexdeployer.com/docs/api/streams)) |

An agent handed nothing but the REST base can read the index, fetch the OpenAPI document and start calling.

## Authenticate

A person creates the key in the app — open **API** in the header — and hands it to the agent. There is no sign-up or token exchange for agents, and a key works until its owner revokes it. (The one exception: an OAuth-only MCP client like a Claude.ai custom connector goes through the [OAuth flow](https://vortexdeployer.com/docs/api/oauth) itself, which ends in an access token bound to a key the owner picked — same rules from then on.)

- REST and MCP: `Authorization: Bearer vd_…` on every request (or a `vdo_…` OAuth access token bound to a key).
- Streams: the key in the `token` field of the subscribe message.
- `GET /me` tells the agent what its key may do: scopes, per-trade and daily caps, the wallet list, and whether it is sandboxed. Read it first and plan within it instead of discovering refusals one by one.

## Stay safe

The agent acts as the key's owner with real funds. The API is built so that a careful agent cannot do harm by accident:

- **Ask for the smallest key.** `read` for research and reporting; `trade` with `maxSolPerTrade` and `dailySolCap` for trading; `launch` only for an agent that launches. See [API overview & keys](https://vortexdeployer.com/docs/api/overview).
- **Dry-run first.** `POST /launch` is a dry run unless `dryRun` is `false`; `buy`, `sell` and `trade/batch` take `dryRun: true`. A dry run runs the whole route and reports what would happen without sending anything.
- **Send an `Idempotency-Key`** on every buy, sell, batch and launch. When a connection drops or a call times out, retry with the same key and the same body: you get the original answer, never a second trade. `409 operation_pending` means the first attempt is still settling; wait and retry the same key. Details in [Limits, retries & errors](https://vortexdeployer.com/docs/api/limits-errors).
- **Expect long calls to be cut.** A launch or a synchronous batch can run longer than the edge keeps a connection open (about 100 seconds). The trade continues on the server; retry with the same `Idempotency-Key` to collect the result. For anything slow, prefer the delayed batch, which returns a task id at once.
- **Read the headers.** `X-RateLimit-Remaining` and `X-RateLimit-Reset` say when to slow down; a `429` carries `retryAfterSeconds`.
- **Switch on `code`, not on `error`.** Every refusal has a stable machine-readable `code`; the human text changes.

:::warning Amounts
SOL amounts are decimal strings in the API (`"0.25"`); token amounts are base units (`amountRaw`) or a percentage of the bag on sells. Never guess decimals — read them from the wallet or token-balance answers.
:::

## A loop that works

1. `GET /me` — what may this key do?
2. `GET /wallets` and `GET /wallets/balances` — which wallet, with what?
3. For a launch, `GET /launchpads` and `GET /launchpads/:launchpad/quotes` — which launchpad, quoted in what? Copy the `quoteToken` and `pairToken` an entry gives you.
4. Dry-run the trade (`dryRun: true`) and show the person the expected result.
5. Commit with a fresh `Idempotency-Key`; on any error other than a refusal, retry the same key.
6. Subscribe to `txs:<mint>` and `pnl:<mint>` on the socket to follow the outcome instead of polling.

## MCP or REST?

- **MCP** for assistants (Claude, Cursor, Windsurf and others): tools arrive with descriptions, schemas and a `readOnlyHint`, so a client that asks before non-read calls asks before every trade. Nothing to install.
- **REST** for your own code: the OpenAPI document generates a typed client in any language.
- **Streams** are a WebSocket in both cases — MCP tools do not stream.

---

# API changelog

> Every change to the public API, newest first, with what to update in your code.

Source: https://vortexdeployer.com/docs/api/changelog · Markdown: https://vortexdeployer.com/docs/api/changelog.md

The API is versioned in the path (`/api/v1`). Within v1, fields are only ever added, never removed or renamed, except where this page says so. Machine-readable error `code`s are stable; the human `error` text is not.

## 2026-09-19 — New address, no write limits

**Changed**

- **The API moved to `https://api.vortexdeployer.com`**: REST base `https://api.vortexdeployer.com/api/v1`, streams `wss://api.vortexdeployer.com/ws`. The old `dev.vortexdeployer.com` address was retired the same day — calls there now answer `404` naming this address; update your config.
- **Writes are no longer rate-limited.** Buys, sells, batches and launches have no per-minute cap anymore, per key or per account. Only reads (`GET`) keep their bucket (300/min per key, 600/min per account), and `X-RateLimit-*` headers now ride read answers only. If you paced trades against the old 60/min, you can stop.
- MCP `_meta.rateLimit` now appears on read tool calls only.

## 2026-09-19 — OAuth 2.1 for the MCP endpoint

**Added**

- The MCP endpoint is now also an **OAuth 2.1 authorization server**, so OAuth-only MCP clients — Claude.ai custom connectors among them — can connect: discovery (`/.well-known/oauth-authorization-server` and `…/oauth-protected-resource` at the API host root), dynamic client registration (`POST /v1/oauth/register`), authorization code + PKCE (S256 only) with consent in the webapp, rotating refresh tokens and revocation. See [OAuth for connectors](https://vortexdeployer.com/docs/api/oauth).
- A grant is **bound to one of your API keys**, picked at consent. The `vdo_…` access token it issues works everywhere a `vd_` key does — MCP, REST, streams — with that key's scopes and caps; revoking the key ends the grant.
- A `401` on `POST /mcp` now carries a `WWW-Authenticate` header pointing at the protected-resource metadata (RFC 9728).

**Changed**

- Nothing about `vd_` keys: they work exactly as before, and every existing client needs no update.

## 2026-09-17 — Faster two-sided Volume, trading-bot markers

**Added**

- `volume` tasks in the Mixed style (a config with no `mode`, or `mode: "mixed"`): `maxInFlight` (1–50, trades out at once, one per wallet), `maxSameSideStreak` and `maxNetBuySol` (0 = off). See [Volume](https://vortexdeployer.com/docs/tasks/volume).
- `markerPlatforms` on `volume` (Mixed) and `warmup` configs: any of `PHOTON`, `TROJAN`, `BULLX`, `AXIOM1`, `AXIOM2`, no repeats, default `[]`. Each trade also sends 10 lamports to that bot's fee wallet. Solana only.

**Changed**

- `minDelayMs` / `maxDelayMs` on a Mixed `volume` config now start at 20 (was 250) and are the gap between sends, not between confirmations.
- `maxNetBuySol` measures what the run still _holds_ — the SOL it paid for the tokens it hasn't sold back — not buys minus sells. Round-trip fees and slippage made the old reading grow on their own and pin a long run at the cap while it held nothing.
- `maxConsecutiveErrors` counts bad _moments_, not failed trades: with `maxInFlight` above 1 the extra trades that a single bad moment takes down with it are forgiven once (the effective threshold is `maxConsecutiveErrors + min(maxInFlight, wallets) − 1`).
- Sells routed through a temporary wallet carry no `markerPlatforms` tag — the throwaway wallet signs them, so the tag would label the wrong wallet. `POST /tasks/:id/preview` names how many of the task's wallets sell that way.

## 2026-09-16 — Launch tasks inline on the launch

**Added**

- `tasks[]` on `POST /launch` is now a typed list of launch tasks: `type` (one of the 14 launch engines), `walletIds`, `config`, `label`, `autostart`. No `chain` (the launch's) and no pre-created task. Settings are validated at the door with the engine's own rules (`400 validation_failed` naming `tasks[i].config`); wallets must be yours and on the key's list. `POST /launch/affordability` takes the same shape. The `launch` MCP tool shows the full task schema. See [Launch tasks](https://vortexdeployer.com/docs/api/launch#launch-tasks).

**Changed**

- `tasks[]` used to be forwarded unchecked, with `chain` required on every task. A task with a `chain` field is now refused; drop it.

## 2026-09-16 — Everything the app does, on the API

Every account action the app offers that makes sense from code is now a route, each with an MCP tool of the same name. Key management stays in the app on purpose (a key that could create keys would be a way around its own limits), and no route returns a private key.

**Added**

- Wallets: `GET`/`POST /wallets/groups`, `PATCH`/`DELETE /wallets/groups/:id`; `groupId` on `PATCH /wallets/:id`; `?scope=all` and `?groupId=` on `GET /wallets`; `GET /wallets/:id/profile`; `GET /wallets/cashback` and `POST /wallets/cashback/claim`. See [Wallet groups](https://vortexdeployer.com/docs/api/wallets-pnl#wallet-groups).
- Projects: `POST /projects` (a draft), `POST /projects/cto`, `PATCH`/`DELETE /projects/:id`, `GET /projects/:id/wallets`, `POST /projects/:id/wallets/assign`, `DELETE /projects/:id/wallets/:walletId`, `POST /projects/:id/closeout` (rehearses by default), `POST /pnl/wallet-totals`. See [Create, edit and delete a project](https://vortexdeployer.com/docs/api/wallets-pnl#create-edit-and-delete-a-project).
- Launch helpers: `GET /launch/readiness`, `GET /launch/mint-address`, `POST /launch/clone`, `POST /launch/affordability`, `POST /launch/supply-preview`, `POST /launch/metadata`, `GET /launch/pons/launch-terms`, `GET /launch/otcdesks/rewards`; supply plans at `/supply-plans` with `POST /supply-plans/:id/mount`. See [Before you launch](https://vortexdeployer.com/docs/api/launch#before-you-launch-the-helpers).
- Trading: `POST /convert/assets`, `/convert/quote`, `/convert`; `POST /tokens/burn` and `/tokens/lock` (rehearse by default); `GET /tokens/creator-fees` and `POST /tokens/creator-fees/claim`. See [Convert](https://vortexdeployer.com/docs/api/trading#convert).
- Tasks: `GET /events` (your activity feed, paged with `before`) and `GET /warmup/candidates`. See [Events](https://vortexdeployer.com/docs/api/tasks#events).
- Account: `GET`/`PATCH /settings/trading`, `GET`/`POST /kols`, `PATCH`/`DELETE /kols/:address`. New page: [Account settings from the API](https://vortexdeployer.com/docs/api/account).
- 43 new MCP tools (84 in all).

**Rules for keys**

- A key with limits (caps, a wallet list or sandbox) can only rehearse a close-out; a sandbox key can only rehearse burns, locks, conversions and cashback claims.
- A wallet-list key may only name wallets on its list, in every new route that takes wallet ids.

## 2026-09-16 — Rename and delete wallets

**Added**

- `PATCH /wallets/:id`: change a wallet's `label` (null clears it) or `role`. See [Rename a wallet or change its role](https://vortexdeployer.com/docs/api/wallets-pnl#rename-a-wallet-or-change-its-role).
- `DELETE /wallets/:id`: delete a wallet; `409 conflict` while a task or a project uses it, `?force=true` to delete past the project check. See [Delete a wallet](https://vortexdeployer.com/docs/api/wallets-pnl#delete-a-wallet).
- MCP tools `update_wallet` and `delete_wallet`.

## 2026-09-16 — Ask which quotes a launchpad takes

**Added**

- `GET /launchpads`: every launchpad with its chain, the `quoteToken` values it accepts and, per quote, whether a `pairToken` is needed and which dev-buy field applies.
- `GET /launchpads/:launchpad/quotes`: what a launch on that launchpad can be quoted in right now, including the live list of tokenized stocks on pump.fun and StonkFun and the pair tokens on pons, each with the exact `quoteToken` and `pairToken` to send. See [Which quotes can I launch with?](https://vortexdeployer.com/docs/api/launch#which-quotes-can-i-launch-with).
- MCP tools `list_launchpads` and `launch_quotes`.

## 2026-09-16 — Import many wallets, into a project

**Added**

- `POST /wallets` takes `privateKeys` (a list, up to 100) next to `privateKey`, and `projectId` to create or import wallets straight into one of your projects. Imports are all-or-nothing and a wallet you already hold comes back unchanged. See [Create or import wallets](https://vortexdeployer.com/docs/api/wallets-pnl#create-or-import-wallets).

**Changed**

- Re-importing a wallet you already hold through `POST /wallets` no longer resets its role to `trading`; it is returned as it is.

## 2026-09-16 — Agent discovery

**Added**

- `https://vortexdeployer.com/llms.txt` and `https://vortexdeployer.com/llms-full.txt`: the docs as an index and as one Markdown file for AI agents, and every docs page as Markdown at its address plus `.md`.
- `GET https://evm.vortexdeployer.com/evm/api/v1` (no key): a JSON index of the REST base, OpenAPI document, MCP endpoint, WebSocket and docs.
- [Build an agent on the API](https://vortexdeployer.com/docs/api/agents): discovery, authentication and the dry-run-then-commit loop.
- These docs no longer need sign-in: every `/docs` page, the API index and the OpenAPI document are readable without an account. Keys are still made in the app.
- `https://vortexdeployer.com/agents.txt`: the agent manifest — every address, how a key works, the safety rails and the rules, as `Field: value` lines. `GET https://evm.vortexdeployer.com/evm/api/v1` names it as `agentsTxt`.

## 2026-09-16 — MCP server

**Added**

- `POST https://evm.vortexdeployer.com/evm/api/v1/mcp`: the API as a Model Context Protocol server for Claude, Cursor or any MCP client — one tool per operation, your key as the bearer token, stateless Streamable HTTP. See [MCP for AI agents](https://vortexdeployer.com/docs/api/mcp).
- Every OpenAPI operation now has an `operationId` (`buy`, `list_wallets`, `start_task`, …). Client generators name methods by it; it is also the MCP tool name.

**Removed**

- The unpublished `https://evm.vortexdeployer.com/evm/api/v1` and `wss://evm.vortexdeployer.com/evm/ws` addresses no longer accept API keys: REST answers `404 not_found` naming the real address, the socket refuses the key. Use `https://evm.vortexdeployer.com/evm/api/v1` and `wss://evm.vortexdeployer.com/evm/ws`.

## 2026-09-16 — camelCase answers, error codes, paging, OpenAPI

**Breaking for early keys.** If you started before this date, update your code:

- **Every answer is camelCase.** `pool_address` → `poolAddress`, `expected_out` → `expectedOut`, `created_at` → `createdAt`, `wallet_ids` → `walletIds`, and so on for every field. Wallet ids and mints used as map keys are unchanged. [Live stream](https://vortexdeployer.com/docs/api/streams) frames keep their on-chain snake_case names.
- **Errors carry a `code`**, and `trace_id` is now `traceId`: `{ "code": "insufficient_scope", "error": "…", "traceId": "…" }`. Switch on `code` — see the [full table](https://vortexdeployer.com/docs/api/limits-errors#codes).
- **`GET /tasks` is wrapped**: `{ "tasks": [ … ] }` instead of a bare array. `GET /tasks/:id/executions` is `{ "executions": [ … ] }`.
- **Internal columns are gone** from task rows: `user_id`, `run_seq`, `execution_epoch`.
- **Projects** no longer return the stored `meta` object. Use `metadataUri` for the token's metadata JSON.
- **Validation messages** changed wording, e.g. `Too small: expected number to be >0`. Match on `code: "validation_failed"` and `details[].path`, never on the message.

**Added**

- `?limit=&offset=` and `X-Total-Count` on `GET /wallets`, `GET /wallets/balances` and `GET /portfolio` ([Paging long lists](https://vortexdeployer.com/docs/api/wallets-pnl#paging-long-lists)).
- `X-RateLimit-Reset` next to `X-RateLimit-Limit` and `X-RateLimit-Remaining`, and `retryAfterSeconds` in every `429` body.
- `GET /openapi.json`: the OpenAPI 3.1 document for the whole REST surface, no key needed.
- `OPTIONS` on any route answers `204` with `Allow`.

## 2026-09-16 — v1 opened

First release: keys and scopes, buy / sell / batch, launch, wallets, portfolio and PnL, the tasks router, live streams. See [API overview & keys](https://vortexdeployer.com/docs/api/overview).

---

# Welcome to VortexDeployer

> What the app does and where to start.

Source: https://vortexdeployer.com/docs/overview/welcome · Markdown: https://vortexdeployer.com/docs/overview/welcome.md

VortexDeployer launches and trades meme tokens on Solana and Robinhood Chain. You bring the wallets — the app mints the token, runs your launch (bundles, snipes), keeps it alive (volume, holders), and gives you a live terminal to trade from. Every automation is a **task** that keeps running even after you close the tab.

For the current navigation, workspace search and display options, start with [Find your way around](https://vortexdeployer.com/docs/overview/workspace).

## What you can do

- **Launch** a token in a 4-step wizard or with [Quick deploy](https://vortexdeployer.com/docs/launch/quick-deploy). Launchpads: pump.fun, Raydium LaunchLab, Bonk, Bonkers, Bags on Solana; pons on Robinhood Chain.
- **Trade** in the [terminal](https://vortexdeployer.com/docs/terminal/overview): quick buys/sells from every wallet, Sell all, limit orders and ladders.
- **Automate** with [tasks](https://vortexdeployer.com/docs/tasks/overview): Buy, Snipe, Volume, Holder Boost, Anti-Sniper, Bundle, Mixer, Limit order, Ladder, Mirror, DCA, Trailing stop and more.
- **Manage [wallets](https://vortexdeployer.com/docs/wallets/overview)**: folders, funding, collecting back, warming up — or buy ready-made ones in the [Marketplace](https://vortexdeployer.com/docs/wallets/marketplace).
- **Take over a token** you didn't launch with [CTO](https://vortexdeployer.com/docs/launch/cto).
- **Watch X** in the [XID feed](https://vortexdeployer.com/docs/xid/feed) and deploy from a post in two clicks.

- **Follow work** in [Operations](https://vortexdeployer.com/docs/account/operations) and get updates in [Notifications](https://vortexdeployer.com/docs/account/notifications).
- **Review results** with the [Dashboard](https://vortexdeployer.com/docs/account/dashboard) and [Portfolio explanations and CSV exports](https://vortexdeployer.com/docs/account/portfolio).

## The layout

- **Top bar** — Dashboard, Projects, Wallets, XID and Marketplace, plus workspace search, **CTO** and **Create Project**. Your account menu opens Portfolio, Swap, Tasks, Operations, Notifications, Support and Settings. On mobile, use the menu.
- **Left rail** — one tile per project. Click a launched one for its terminal; a draft reopens the wizard.
- **Footer** — connection dot, XID toggle, Tracker, Quick deploy, Help/Bug/Suggest, notifications, live SOL and ETH prices, and this Docs link.

## Where to start

1. [Sign in](https://vortexdeployer.com/docs/overview/sign-in) with Telegram or username and password.
2. [Create a wallet](https://vortexdeployer.com/docs/wallets/create-and-import) and [fund it](https://vortexdeployer.com/docs/wallets/fund).
3. Read [Simulate & dry run](https://vortexdeployer.com/docs/overview/dry-run) — what can rehearse first, and which tasks trade for real from the start.
4. [Create a project](https://vortexdeployer.com/docs/launch/create-project) and launch it.

:::tip Search these docs
Press `/` or choose **Search docs** to search every guide. Workspace search in the header finds your projects, wallets, tasks and pages.
:::

## See also

- [Chains & launchpads](https://vortexdeployer.com/docs/overview/chains-and-launchpads)
- [Platform fees & tiers](https://vortexdeployer.com/docs/overview/fees)
- [Glossary](https://vortexdeployer.com/docs/other/glossary)

---

# Find your way around

> Navigation, workspace search, pinned items and display density.

Source: https://vortexdeployer.com/docs/overview/workspace · Markdown: https://vortexdeployer.com/docs/overview/workspace.md

Use the top bar for **Dashboard**, **Projects**, **Wallets**, **XID** and **Marketplace**. **Create Project** opens the launch wizard. The account menu contains Portfolio, Swap, Tasks, Operations, Notifications, Support and account settings. On a phone, open the menu to reach these pages and tools.

## Search your workspace

Press the **Search** button in the header, or **Ctrl K / ⌘ K** outside the docs. Search by project name, wallet label or address, task, or page name. Paste a token address to open its terminal.

![Workspace search with page and account shortcuts. Example account.](https://vortexdeployer.com/docs/overview/workspace.png)

- Use **↑ / ↓** to select, **Enter** to open and **Escape** to close.
- Press the star beside a result to pin it. Pinned and recent items appear first.
- Task search covers the latest 100 tasks. Use the [Tasks page](https://vortexdeployer.com/docs/tasks/overview) for older runs.
- On documentation pages, use **Search docs** or `/` to search the guides.

## Choose your workspace

**Settings → Your workspace → Display density** offers **Compact** and **Comfortable**. Workspace preferences, trading presets and deployment defaults save to your account. See [Settings](https://vortexdeployer.com/docs/account/settings) for save status, named configurations and changes from another device.

New accounts see starting steps on the Dashboard. You can launch a token, trade an existing token, or manage wallets; each path links to the relevant tools.

## Follow work after leaving a page

- [Operations](https://vortexdeployer.com/docs/account/operations) keeps conversions and project closeouts, including progress and receipts.
- [Notifications](https://vortexdeployer.com/docs/account/notifications) links updates to their operation, task or order.
- The footer shows the connection state. During a disconnect, visible figures may be the last received values.

## See also

- [Dashboard](https://vortexdeployer.com/docs/account/dashboard)
- [The terminal](https://vortexdeployer.com/docs/terminal/overview)

---

# Sign in & accounts

> Two ways to sign in, and what your account owns.

Source: https://vortexdeployer.com/docs/overview/sign-in · Markdown: https://vortexdeployer.com/docs/overview/sign-in.md

Everything — wallets, projects, tasks — belongs to one account, and you only ever see your own. There is no wallet-connect: the app holds the keys of wallets you create or import (encrypted) and signs for you.

![The sign-in page.](https://vortexdeployer.com/docs/overview/sign-in.png)

## Two ways in

- **Continue with Telegram** — the default. Register through the Vortex Telegram bot first; the same identity signs you in here.
- **Sign in with Vortex** — username and password. Web login must be enabled for your account (ask via [Support](https://vortexdeployer.com/docs/account/support)); then set your credentials under [Settings → Profile](https://vortexdeployer.com/docs/account/settings).

Coming from the legacy vortexdeployer.com app? A link from there signs you straight in.

## Sessions

- A session lives in this browser until you **Sign out** from the account menu — signing out ends it everywhere.
- Changing your password ends every other session.
- Changing your username or password asks for the current password first.

## What an account owns

- **Wallets** — created or imported by you.
- **Projects** — launched tokens and pending drafts.
- **Tasks** — every automation, with its history.
- **Tickets**, **KOL tracker** list, XID preferences, trading presets and supply plans.

:::warning Keys
The app never shows a private key unless you ask on the Wallets page and re-enter your password. See [Export a private key](https://vortexdeployer.com/docs/wallets/key-export).
:::

## See also

- [Settings](https://vortexdeployer.com/docs/account/settings)
- [My profile](https://vortexdeployer.com/docs/account/profile)

---

# Chains & launchpads

> Solana and Robinhood Chain, their launchpads, and what's chain-specific.

Source: https://vortexdeployer.com/docs/overview/chains-and-launchpads · Markdown: https://vortexdeployer.com/docs/overview/chains-and-launchpads.md

Two chains, picked per wallet at creation and per project via the launchpad. A task inherits its token's chain. Balances and P&L show in the chain's coin: **SOL** on Solana, **ETH** on Robinhood Chain.

## Launchpads

| Launchpad | Chain | Quote | Notes |
|---|---|---|---|
| Pump.fun | Solana | SOL, USDC, Mayhem, stocks | Graduates to PumpSwap; stock quotes still trade in SOL (swapped inside the transaction) |
| LaunchLab | Solana | SOL, USD1 | Raydium |
| Bonk | Solana | SOL, USD1 | letsbonk.fun |
| Bonkers | Solana | SOL, USD1 | |
| Bags | Solana | SOL | Meteora DBC, graduates to DAMM v2 |
| pons | Robinhood Chain | ETH, USDG, stocks | Creator fees, buyback, custom pair token |

The footer shows the live graduation market cap for pump.fun (**P**) and pons (**R**).

## Quotes on pons

A pons curve can be quoted in ETH, the USDG stable, a tokenized stock (NVDA, TSLA, SPY, GLD and ~30 more), or any contract under **Custom CA**. When the quote isn't ETH, the dev buy and launch tasks first swap ETH into the quote through the router; gas stays in ETH.

## Chain-specific features

Most tasks run on both chains. **Solana only:**

- **Bundle** (Jito bundle of up to 24 wallets in the create block)
- **Fake volume**, **Hand Switcher**, **Migrate & buy**
- **Dev warmup** (Meteora DBC throwaway launches)
- **Convert** (stocks, stablecoins and tokens) and **Claim cashback** on the Wallets page
- Token **Lock** in the terminal
- Holder Boost **Reclaim** (rent returns on Solana only)

**Robinhood only:**

- **Creator fees** — tax up to 10 %, optional **Buyback**, swept by the pons contracts
- Pair-token quotes and the **Creator fees** panel in the terminal

:::info When a venue is paused
A paused launchpad disappears from the wizard and Quick deploy tiles. Tokens already launched there keep trading and their tasks keep running.
:::

## See also

- [Create a project](https://vortexdeployer.com/docs/launch/create-project)
- [Launch settings](https://vortexdeployer.com/docs/launch/launch-settings)

---

# Simulate & dry run

> Which tasks can rehearse first, what a simulation shows, and which ones always trade for real.

Source: https://vortexdeployer.com/docs/overview/dry-run · Markdown: https://vortexdeployer.com/docs/overview/dry-run.md

Some tasks and tools can **simulate**: they check the supported parts of a planned run, but send nothing — no funds move, no token is minted. Others trade for real from the moment they start. Know which is which before you press Start.

![A Buy task's Simulate section.](https://vortexdeployer.com/docs/overview/dry-run.png)

## Where you can simulate

- **Task forms** — Buy, Snipe, Token Sender, Migrate & buy and Scheduled launch have a **Simulate** switch, on by default: *Check the task without sending transactions or spending funds.*
- **Launches** — the wizard's **Simulate** checks creation; **Create** sends it. Read the launch result for any creator buy, bundle buyers or task execution that was not tested.
- **Wallets page** — Collect, Transfer, Claim cashback, Warm up and Dev warmup have a **Dry run** box (Transfer's button reads **Rehearse send** while it's ticked). Convert has **Simulate** after **Review**. [Close out](https://vortexdeployer.com/docs/launch/close-out) has one too.
- **Quick deploy** — its own **Simulate** button.

## Tasks that always trade for real

**Volume**, **Bundle**, **Holder Boost**, **Hand Switcher**, **Fake Volume**, **Anti-Sniper**, **Pro Trader Boost** and the order tasks (**Limit order**, **Ladder**, **Mirror**, **DCA**, **Trailing stop**) have no Simulate switch. They send transactions and spend funds as soon as they start — size them small the first time.

A saved setup from before this change shows *This saved setup uses simulation, which is no longer available for this task.* Press **Use real trading** to keep it, knowing it now spends funds.

:::info Read the launch result
The wizard reports which parts of creation were checked. Attached tasks are not guaranteed to have been simulated; an untested task or bundle buy is called out in the result.
:::

## What a simulation shows

On the task card:

- **Simulate** (no funds move) — what the task would do right now: how many wallets will buy or skip, the total, the simulated transaction's result, and per wallet the amount or the reason it's skipped. The ↻ button recomputes it from live balances.
- **Executions** — rows marked **simulated**: checked, nothing left the wallet.
- **Results** — per wallet, what happened or why it was skipped.

Numbers are real: a simulation reads live balances and live prices.

## Going live

Switch **Simulate** off on the form before **Create task** — or duplicate a rehearsed task and switch it off on the copy.

:::danger Live means live
With Simulate off, a task spends from your wallets the moment it starts. Rehearse, read the Simulate section, then go live.
:::

## What a simulation can't tell you

- Whether a Jito bundle would **land** (depends on the tip and the network at that moment).
- Whether outside traders would front-run you.
- The exact fill of a live swap (slippage still applies live).

## See also

- [How tasks run](https://vortexdeployer.com/docs/tasks/overview)
- [Best practices](https://vortexdeployer.com/docs/other/best-practices)

---

# Platform fees & tiers

> One fee on buys and sells — it drops as you trade.

Source: https://vortexdeployer.com/docs/overview/fees · Markdown: https://vortexdeployer.com/docs/overview/fees.md

The platform charges one fee: a percentage of each buy and sell your wallets make through the app. No subscription. The more fees you've paid, the lower your rate.

## The rate

Starts at **1 %** for a new account, falls to as low as **0.4 %** as your total fees paid grow. Your current tier and progress to the next one show on [My profile](https://vortexdeployer.com/docs/account/profile).

## When it's charged

- **Buys** — taken from the spend before the swap. "Full balance", "% of balance" and "max" all leave room for the fee and gas, so a wallet is never left unable to sell.
- **Sells** — taken from the proceeds after the swap.
- **Launch tasks** — dev buy, bundles and snipes are buys and carry the fee.
- **Sell all** — fee on the quoted proceeds.

**Not charged:** Holder Boost funding, Disperse hops, Collect sweeps, Send SOL, Mixer orders (the exchange takes its own fee), Pro Trader Boost farm buys (that task charges its tier price instead), and dry runs.

## Where you see it

- Terminal P&L and Portfolio quote bags **net** of the fee you'd pay to exit.
- **Fees paid** in the terminal header is the running total on that token.

:::info Creator fees are separate
On pons, the **creator tax** you set at launch is paid by traders to _your_ creator wallet — it's your income, swept automatically. See [Launch settings](https://vortexdeployer.com/docs/launch/launch-settings).
:::

## See also

- [My profile](https://vortexdeployer.com/docs/account/profile)
- [Portfolio](https://vortexdeployer.com/docs/account/portfolio)

---

# Create a project

> The 4-step wizard that mints your token.

Source: https://vortexdeployer.com/docs/launch/create-project · Markdown: https://vortexdeployer.com/docs/launch/create-project.md

A **project** is one token: its metadata, the wallets that launch it, and the tasks that fire at the mint. **Create Project** (top bar, or the plus on the left rail) opens the wizard. Close it anytime — the draft is saved and reopens where you left off via **Resume** on the Projects page.

![Step 1 of 4, Metadata.](https://vortexdeployer.com/docs/launch/wizard-step1.png)

## The four steps

1. **Metadata** — name, symbol, image, launchpad, quote, creator fee (pons). See [Token details](https://vortexdeployer.com/docs/launch/token-details). The **Vamp** tab fills all of this from an existing token — see [Clone a token](https://vortexdeployer.com/docs/launch/clone-token).
2. **Wallets** — the dev wallet that mints, its dev buy, and the project wallets tasks trade from. See [Wallets step](https://vortexdeployer.com/docs/launch/wallets-step).
3. **Tasks** — launch tasks (Snipe, Buy, Volume…) with autostart. See [Tasks step](https://vortexdeployer.com/docs/launch/tasks-step).
4. **Review & Deploy** — summary plus **Launch at** and **Launches**. See [Launch settings](https://vortexdeployer.com/docs/launch/launch-settings).

Nothing is minted before the last screen.

## Review & Deploy

The last step lists everything: token, creator wallet, quote, dev buy, wallets and tasks. **Before you can launch, add:** names what's missing — until that list is empty, **Simulate** and **Create** stay disabled.

- **Simulate** — checks launch creation without broadcasting. Read the result for any untested creator buy or task execution; a creation simulation is not proof that every launch task was tested.
- **Create** — the real launch. The terminal opens on your new mint. See [After launch](https://vortexdeployer.com/docs/launch/after-launch).

:::info Simulate first
Simulate reads live balances and the live curve, so it catches an under-funded wallet or an oversized plan before you pay for the mint.
:::

## Reserved contract address

On Pump.fun, LaunchLab, Bonk and Bonkers, **Contract address (CA)** shows the mint reserved for your launch. Click to copy it; **Refresh contract address** requests another reservation. Wait for a reservation before launching. For a batch, the displayed address belongs to its first launch.

Reservation does not mean the token has been minted. Read [After launch](https://vortexdeployer.com/docs/launch/after-launch) to check the actual result.

## Drafts

A closed wizard becomes a **Pending** card on the Projects page (also a tile on the left rail). Delete a draft from its card; its project-only wallets are soft-deleted and come back if you re-import them.

## See also

- [Quick deploy](https://vortexdeployer.com/docs/launch/quick-deploy) — the one-modal version
- [Chains & launchpads](https://vortexdeployer.com/docs/overview/chains-and-launchpads)

---

# Quick deploy

> Launch a token from one modal, from anywhere in the app.

Source: https://vortexdeployer.com/docs/launch/quick-deploy · Markdown: https://vortexdeployer.com/docs/launch/quick-deploy.md

**Quick** in the footer opens the Quick deploy modal — the whole launch on one screen. Everything you don't see here comes from your saved defaults under [Settings → Quick deploy](https://vortexdeployer.com/docs/account/settings), including the launch tasks that autostart at the mint.

![The Quick deploy modal.](https://vortexdeployer.com/docs/launch/quick-deploy.png)

## The form

- **Launchpad · quote** — same tiles as the wizard. On pons pick ETH, USDG, a stock under **More stocks…**, or paste a **Custom CA**.
- **Creator fees** (pons) — recipient (**Creator wallet**, **Holders** or **Custom address**), **Tax** up to 10 %, **Buyback** on/off.
- **Name**, **Symbol**, **Token image** — PNG, JPEG, GIF or WebP up to 5 MB, or generate an **ASCII** image.
- **Creator wallet** — any wallet in your global pool on that chain.
- **Dev-buy** — how much the creator buys in the mint transaction (in SOL on SOL pairs and stock-quoted pump.fun curves). The line under it shows the creator's live balance, slippage and priority fee.
- **Custom token address** (Solana) — paste a mint keypair secret for a vanity address, or leave it empty to use a reserved address on supported launchpads. **Contract address (CA)** shows the reservation; click to copy or refresh it. See [Token details](https://vortexdeployer.com/docs/launch/token-details).
- **Launches** — 1 mints once; up to 10 identical mints in a row. Above 1, the line says how many your wallets can fund — see [Launch settings](https://vortexdeployer.com/docs/launch/launch-settings).

Handy extras:

- **Reuse a launch** chips fill the form from a previous launch, tasks and wallets included.
- **Vamp** tab clones an existing token's look — see [Clone a token](https://vortexdeployer.com/docs/launch/clone-token).
- **Full wizard →** carries what you typed into the 4-step wizard, for changing wallets or tasks just this once.

## Simulate and Deploy

- **Simulate** — checks launch creation without broadcasting. Read the result for any creator buy or task execution that was not tested. See [After launch](https://vortexdeployer.com/docs/launch/after-launch).
- **Deploy** — the real launch; the terminal opens on the new mint.

:::info Which wallets trade at launch
Quick deploy uses the launch tasks, wallets and amounts saved in your deploy defaults. Check Settings → Quick deploy to see exactly what will fire.
:::

## See also

- [Create a project](https://vortexdeployer.com/docs/launch/create-project)
- [Settings](https://vortexdeployer.com/docs/account/settings)

---

# Token details

> Step 1 of the wizard: name, symbol, image, launchpad, quote and creator fees.

Source: https://vortexdeployer.com/docs/launch/token-details · Markdown: https://vortexdeployer.com/docs/launch/token-details.md

Step 1 is what the world sees. Only **name**, **symbol** and an **image** are required; everything else is optional.

![Metadata step with the quote picker open.](https://vortexdeployer.com/docs/launch/token-details.png)

## Reuse a launch

The **Reuse a launch** chips above the form (plus **All launches** for older ones) fill the whole wizard from a past launch: metadata, launchpad, quote, creator fees, dev buy, wallets and tasks. Edit anything afterwards — the old project is untouched.

## Identity

- **Name** (max 32 chars) and **Symbol** (max 16) — written on-chain, cannot be changed after the mint.
- **Description**, **Website**, **X URL**, **Telegram** — optional metadata.
- **Token image** — PNG, JPG, GIF or WebP up to 5 MB. **ASCII** generates an image from text if you have none.

## Custom token address (Solana)

Want a vanity mint? Generate a keypair (e.g. `solana-keygen grind`) and paste its secret (base58, JSON array or base64) into **Custom token address**. The field checks it live: green = free, red = taken or invalid. A custom address fixes one mint, so **Launches** must be 1. Not available on Robinhood.

Leave it empty on Pump.fun, LaunchLab, Bonk or Bonkers and **Contract address (CA)** shows the address reserved for your launch. Click to copy; **Refresh contract address** requests another reservation. Wait for the address to be ready before launching. In a batch, the preview is for the first launch only. StonkFun, Bags and Robinhood tokens get their address from the venue.

## Platform · quote · mode

The launchpad tiles decide the chain. On **pons** pick the **quote** the curve trades in:

- **ETH** — the chain's coin; every wallet already holds it.
- **USDG** — the stable; ETH is swapped into USDG right before the launch.
- **A tokenized stock** — NVDA, SPCX, SPY, DJT, GLD, GME and ~30 more under **More stocks…**. Same swap rule.
- **Custom CA** — any ERC-20 contract address.

The note under the picker tells you where the buys' money comes from for your pick.

## Creator fees (pons)

- **Creator wallet / Holders / Custom address** — who receives the creator share of every trade.
- **Tax** — 0 to 10 % per trade.
- **Buyback** — the fee escrow buys the token back off the curve with the platform share.

The pons contracts sweep the share automatically; the terminal's **Creator fees** button shows the totals.

## See also

- [Wallets step](https://vortexdeployer.com/docs/launch/wallets-step)
- [Chains & launchpads](https://vortexdeployer.com/docs/overview/chains-and-launchpads)

---

# Wallets step

> Step 2 of the wizard: the dev wallet, the dev buy, and the project wallets.

Source: https://vortexdeployer.com/docs/launch/wallets-step · Markdown: https://vortexdeployer.com/docs/launch/wallets-step.md

Step 2 gathers this launch's wallets. The **DEV** wallet mints the token and pays the launch fee; the other project wallets are what step 3's tasks trade from. Every wallet added here is a **project wallet**, listed on the Wallets page under this project.

![Wallets step with a dev wallet and three project wallets.](https://vortexdeployer.com/docs/launch/wallets-step.png)

## The tiles

- **Dev** — add the creator wallet: pick a project wallet, import a key directly, or switch the dev later (the old dev becomes a regular project wallet).
- **Create** — fresh project-only keypairs; they never appear in your global pool. Set a count and a naming pattern like `Volume #{n}`.
- **Import** — one private key per line, encrypted immediately, scoped to this project.
- **Global** — link wallets from your global pool; they stay in the pool and can serve other projects too.
- **Fund** — the [Fund wallets](https://vortexdeployer.com/docs/wallets/fund) modal, scoped to the project's wallets.

The header shows the **Total** balance across the project wallets. A project holds up to **1000 wallets**.

## The dev row

The DEV row carries the **dev buy**: the amount the creator buys in the same transaction as the mint. On a USDG/stock pons quote it must hold that quote (or its ETH is swapped right before the mint); on a stock-quoted pump.fun curve the dev buy stays in SOL and is swapped inside the mint transaction.

:::info The dev is not a trader
Tasks pick from the project wallets. The DEV wallet is the creator — a Snipe or Buy never fires from it.
:::

## Empty state

You can move to step 3 without trading wallets, but the Tasks step will tell you there's nothing to trade with.

## See also

- [Wallets overview](https://vortexdeployer.com/docs/wallets/overview)
- [Tasks step](https://vortexdeployer.com/docs/launch/tasks-step)

---

# Tasks step

> Step 3 of the wizard: the launch tasks that fire at the mint, and supply plans.

Source: https://vortexdeployer.com/docs/launch/tasks-step · Markdown: https://vortexdeployer.com/docs/launch/tasks-step.md

Step 3 gives the launch its first buyers. Each task is a normal [task](https://vortexdeployer.com/docs/tasks/overview) tied to the project; with **Start immediately** it starts the instant the mint lands. No tasks = the launch just mints (and dev-buys, if set).

![Tasks step with a Snipe and a Volume task added.](https://vortexdeployer.com/docs/launch/tasks-step.png)

## Add task

**Add task** opens the engine picker. Launch buys lead the list: on Solana **Bundle** (with Auto-start on a SOL curve it rides the launch's Jito bundle — see [Bundle](https://vortexdeployer.com/docs/tasks/bundle)) and **Snipe**; on Robinhood **Snipe** and **Buy**. Then Volume, Holder Boost, Anti-Sniper, Pro Trader Boost, Limit order, Ladder, Mirror, DCA, Trailing stop. (Migrate & buy and Wallet warm-up aren't launch tasks.)

Each task uses the same form as the Tasks page, with the project wallets preselected. **Create** fires autostart tasks for real, including Volume, Bundle and order tasks. **Simulate** checks launch creation; read the result for any task execution or bundle buyers that were not tested. A passed creation check is not proof that every attached task was simulated.

## Buy order

Wallets stack in the order they buy, first at the top. Drag a row's ⠿ handle or use the hover arrows. The order is saved with the task.

## Supply calculator and plans

On Bundle and Snipe cards:

- **Supply calculator** (last setting) estimates each wallet's share of the fresh curve and the cumulative total for the amounts you typed. It's a tool, not a required step — wallets + amounts is a complete task.
- **Max supply per wallet** skips a wallet that already holds that share.
- The launch refuses a plan whose cumulative share exceeds the cap.
- The estimate is best case: it assumes nobody else buys first.

A **supply plan** is a saved preset of slots, each a percentage of supply, kept under [Settings → Supply plans](https://vortexdeployer.com/docs/account/settings). Pick one and press **Mount**: it picks the wallets (a **Dev** slot takes the dev wallet, a **Trading (no role)** slot a role-less wallet), prices each amount on this token's curve, and sets the ceiling. A slot landing on the **creator wallet** fills the Dev buy instead. Mount again after changing wallets. Plans are never required — hand-picked wallets and amounts work just as well.

:::warning At most 31 launch buyers on Robinhood
A Robinhood launch shields Snipe and instant-Buy wallets from the launch-window snipe tax, and that list holds 31 wallets. More than 31 distinct wallets on those tasks refuses the launch — remove extras, or give them a Buy task with a delay.
:::

:::info Wallets first
Tasks take their wallets from the project wallets; the DEV wallet is never one of them.
:::

## See also

- [Snipe](https://vortexdeployer.com/docs/tasks/snipe)
- [Bundle](https://vortexdeployer.com/docs/tasks/bundle)
- [Launch settings](https://vortexdeployer.com/docs/launch/launch-settings)

---

# Launch settings

> Dev buy, Launch at, Launches, pair-token quotes, OTC Desks and creator fees — and what Simulate checks.

Source: https://vortexdeployer.com/docs/launch/launch-settings · Markdown: https://vortexdeployer.com/docs/launch/launch-settings.md

The settings that shape the mint itself, collected in one place.

![Review & Deploy with Launch at and Launches.](https://vortexdeployer.com/docs/launch/launch-settings.png)

## Dev buy

Set on the DEV row of the Wallets step: how much the creator buys inside the mint transaction, making it the first holder. Limit: 85 SOL on Solana; quote-dependent on pons. Leave at 0 for no creator buy.

On a stock-quoted pump.fun curve the dev buy is typed in **SOL** and swapped into the stock inside the mint transaction. USDC curves and StonkFun stocks spend the quote the creator already holds.

## Launch at

On Review & Deploy. **Empty = mint now.** Set a time 30 seconds to 30 days out to schedule; the whole launch (dev buy and tasks included) becomes one [Scheduled launch](https://vortexdeployer.com/docs/tasks/scheduled-launch) task you can stop from the Tasks page.

## Launches

**1 = mint once.** Up to **10** identical launches run one after another — same wallets, dev buy and tasks on every mint.

Above 1, the line under the field adds up every launch's cost against live wallet balances: "Your wallets fund all 5 launches" means go; "fund 3 of 5" means the batch mints the three it can pay for. If a launch can't be funded when its turn comes, the batch stops there; earlier mints stay live.

## Quote and pair token

On pons with a USDG or stock quote, buyers need that token, not ETH:

- The dev buy and launch-task buyers swap ETH into the quote through the router right before launch (1 % router fee on that leg); a wallet already holding the quote spends that first.
- Gas and the launch fee stay in ETH — keep a little ETH in every buyer.

A stock-quoted pump.fun curve is the reverse: everything is typed in SOL, and each buy/sell swaps in the same transaction.

## OTC Desks pairing (pump.fun)

A pump.fun SOL launch can route creator fees to holders as rewards via otcdesks.cash. Picked on step 1 under the quote row — see [OTC Desks pairing](https://vortexdeployer.com/docs/launch/otc-desks).

## Creator fees (pons)

Picked on step 1: recipient (**Creator wallet**, **Holders**, **Custom address**), **Tax** up to 10 %, **Buyback**. The pons contracts sweep the share automatically; the terminal's **Creator fees** button shows totals.

## What Simulate checks

- Metadata wouldn't revert on-chain (name/symbol length, image present).
- The creator can pay the mint, dev buy and gas.
- Every autostart task builds and simulates cleanly.
- A mounted supply plan fits under the supply cap.

:::warning Irreversible
Name, symbol, quote, creator-fee recipient and tax are written at the mint and cannot be edited afterwards. Simulate, read the review, then Create.
:::

## Pump Holder Rewards

Choose **Creator Fees** or **Holder Rewards** at launch. Holder Rewards is permanent: Pump distributes the creator-fee share to eligible holders in the pair's quote token. Hold more than $20 worth to be eligible; payouts are proportional, several times an hour; no claim button.

- SOL and USDC pairs keep Pump's standard tiered fees. Custom pairs expose a flat fee of **0.01%–3%**, final at launch.
- Holder Rewards can't combine with OTC Desks. Existing Cashback/Creator Fee tokens can [apply to convert through Pump](https://forms.gle/CbnEm8gvZubpJkQh9) — conversion is permanent.
- New Cashback launches are no longer supported; existing ones keep trading and their cashback stays claimable.

## See also

- [Scheduled launch](https://vortexdeployer.com/docs/tasks/scheduled-launch)
- [Platform fees & tiers](https://vortexdeployer.com/docs/overview/fees)

---

# Clone a token

> Vamp fills the launch form from an existing token's name, symbol, image and socials.

Source: https://vortexdeployer.com/docs/launch/clone-token · Markdown: https://vortexdeployer.com/docs/launch/clone-token.md

**Vamp** copies the look of an existing token. Paste its address and the wizard (or Quick deploy) fills with its name, symbol, description, image and socials — you launch it on your own launchpad with your own wallets. Find the Vamp tab next to Metadata on step 1, next to Settings in Quick deploy; the XID feed opens it for a contract address it spots in a post.

![The Vamp tab with a loaded token.](https://vortexdeployer.com/docs/launch/vamp.png)

## Using it

1. Paste a Solana mint (base58) or a 0x contract address.
2. The source token's card appears: image, name, symbol, description and which socials it has.
3. Use the look — the Metadata step is filled; edit anything before going on. The image is stored by the app, so the clone doesn't depend on the original's hosting.

## Options

- **Auto-detect clipboard** — reads an address from your clipboard when you open the tab.
- **Auto-load** — loads the token as soon as a valid address is pasted.

:::info What Vamp doesn't copy
Only metadata. Launchpad, quote, wallets, dev buy, creator fee and tasks are yours to set; nothing about the source's curve or holders carries over.
:::

## See also

- [Token details](https://vortexdeployer.com/docs/launch/token-details)
- [Deploy from XID](https://vortexdeployer.com/docs/xid/deploy)

---

# OTC Desks pairing

> Pair a pump.fun launch with otcdesks.cash so creator fees pay holders a reward.

Source: https://vortexdeployer.com/docs/launch/otc-desks · Markdown: https://vortexdeployer.com/docs/launch/otc-desks.md

A **pump.fun × SOL** launch can be paired with [OTC Desks](https://otcdesks.cash). The coin's creator fees go to the OTC Desks reward pool instead of your creator wallet, and OTC Desks pays them out to holders as the reward you picked: a tokenized stock (e.g. AAPLx), a basket, or a community mint.

**The pairing is permanent** — once live, creator fees can't be pointed back at your wallet.

## Where to pick it

The **OTC Desks** row sits under the quote row on wizard step 1, in Quick deploy, and in Settings → Deploy defaults. It only shows for pump.fun with a SOL quote.

- **Off / Paired** switches it on.
- **Single** pays one reward; **Basket (2–5)** pays several. Community mints and not-yet-listed rewards are single-only.
- The chips are the catalog; **More rewards…** lists the rest. **Mint** accepts any SPL mint — it's imported into the community list first, so an unaccepted mint is refused up front.

The line under the picker reads back what holders earn and the fee split.

## Limits

OTC Desks is stricter than pump.fun. A paired launch is refused before anything is sent when:

| Field | Limit |
| --- | --- |
| Name | 32 characters |
| Ticker | 13 characters |
| Description | 500 characters |
| X link | 120 characters |

## What happens at launch

1. If the token's **website** is empty, its OTC Desks page (`otcdesks.cash/coin/<mint>`) is written in as the website before the mint. A website you typed is kept.
2. The coin mints like any pump.fun launch — dev buy and tasks included. Pairing never delays the mint.
3. Right after the mint, the creator wallet signs one transaction routing creator fees to the reward pool — keep a little SOL in it.
4. The coin registers with OTC Desks; its page appears within a minute.

The project card shows the result: **Paired** links the coin page; **Pairing failed** shows why (the coin still trades normally, but fees go to the creator wallet and it's not listed).

## Not available on

LaunchLab, Bonk, Bags, StonkFun, pons and every non-SOL quote. Scheduled and batch launches keep the pairing on every mint.

---

# After launch

> What happens the second you press Create.

Source: https://vortexdeployer.com/docs/launch/after-launch · Markdown: https://vortexdeployer.com/docs/launch/after-launch.md

Pressing **Create** (or **Deploy**) sends the mint. The terminal opens on the new mint immediately and fills in as the mint and first buys land.

![The terminal seconds after a launch.](https://vortexdeployer.com/docs/launch/after-launch.png)

## What you see

- **The terminal** on your token, Trade Panel ready. Header: market cap, price, liquidity, supply, **Fees Paid**.
- **Tasks rail** — every autostart task with its status. Click a row to expand the full card.
- **Trades feed** — your fills tagged **YOU**; outside trades show the trader's address.
- **Projects page** — the new card shows launchpad and date, stage (**BONDING** until graduation), live market cap, P&L and **Open terminal**.

## Read the launch result

The result distinguishes **Minted on-chain**, **Mint failed** and simulation outcomes. **Creation simulation passed** covers the creation check; **Simulation incomplete** or **Simulation result unavailable** does not mean success. Read any **Task execution was not tested** or creator-buy message.

For a bundle, inspect whether it landed and which buyers were packed into each transaction. In a simulation, bundled wallet buys may be untested because the mint does not exist yet. Creator-fee or OTC Desks errors can be reported after the token itself launched; read those separately before retrying anything.

## If something didn't land

- Clean Simulate but reverted launch → the curve or balances moved in between. The task's **Results** names the failed leg.
- A task that never started says why on its card — in **Results**, or in **Simulate** on tasks that have it.
- With **Launches** above 1, the batch stops at the failed launch; earlier mints stay up.

## Next

- Add tasks with **New task** in the terminal's Tasks rail: Volume, Holder Boost, a sell Ladder, Anti-Sniper. These trade for real from the start.
- **Share PnL** in the header makes a card of the run — see [P&L share cards](https://vortexdeployer.com/docs/terminal/pnl-cards).
- Done? [Collect funds](https://vortexdeployer.com/docs/wallets/collect) back to one wallet, or **Close out** on the Projects page to sell, close accounts and sweep in one go — see [Close out](https://vortexdeployer.com/docs/launch/close-out).

## See also

- [The terminal](https://vortexdeployer.com/docs/terminal/overview)
- [How tasks run](https://vortexdeployer.com/docs/tasks/overview)

---

# Close out

> Sell what's left of a finished launch, close its token accounts and sweep the coin home — for several projects at once.

Source: https://vortexdeployer.com/docs/launch/close-out · Markdown: https://vortexdeployer.com/docs/launch/close-out.md

A finished launch leaves bags across wallets, empty token accounts holding rent (Solana), and coin spread over project wallets. **Close out** on the Projects page does all three in one go, for as many projects as you tick.

![The Close out modal.](https://vortexdeployer.com/docs/launch/close-out.png)

## What it does, per project

1. **Sells every remaining bag** — every wallet of yours holding the token market-sells its whole balance. A token with no working sell route keeps its bags and says so.
2. **Closes the empty token accounts** (Solana) — rent goes to the destination wallet. Accounts still holding tokens are left alone.
3. **Sweeps the coin** — the project's wallets send their SOL/ETH to the destination as a [Collect funds](https://vortexdeployer.com/docs/wallets/collect) task.

Each project reports its own line: what sold, what closed, the sweep task, and anything skipped.

## Using it

- Tick the projects you're done with (or **Select all**); the modal lists them by chain and stage.
- **Destination** — the wallet receiving rent and sweep; must be on the same chain.
- **Dry run** is on by default: everything is simulated, nothing is sent.
- Switch it off, press **Close out N projects**, then confirm with **Sell, close and sweep**. For a simulation, press **Rehearse N projects**. Select up to 100 projects per operation.

:::warning Everything goes
A real close out sells the whole bag of every wallet at market with no slippage limit. Only use it on launches you're finished with.
:::

## Saved progress

The queue and its per-project results are saved to your account. Close the dialog or tab and reopen it from [Operations](https://vortexdeployer.com/docs/account/operations) on any device. Each result can show per-wallet receipts and a link to the sweep task.

**Stop remaining items** stops projects that have not started. **Continue remaining items** skips items needing attention and runs only those still queued. Check affected receipts before creating another closeout.

## See also

- [Collect funds](https://vortexdeployer.com/docs/wallets/collect)
- [After launch](https://vortexdeployer.com/docs/launch/after-launch)

---

# CTO an existing token

> Take over a token you didn't launch here and trade it with your own project wallets.

Source: https://vortexdeployer.com/docs/launch/cto · Markdown: https://vortexdeployer.com/docs/launch/cto.md

**CTO** runs a token that already exists — launched elsewhere, or by someone else — with your own wallets. It creates a project on that mint, so you get the terminal, tasks and P&L as for your own launch.

![CTO, step 1: the token mint.](https://vortexdeployer.com/docs/launch/cto.png)

The **CTO** button sits in the top bar, next to **Create Project**, and on the Projects page.

## 1. Token mint

Paste the **Mint address** and press **Next: Wallet setup**. The app finds the token and creates the project.

## 2. Wallet setup

Create, import or assign the trading wallets, then **Fund** them from the same screen. There's no Dev wallet to pick — you didn't mint this token. Add at least one wallet, then press **Open Swap Manager**: the terminal opens on the token with those wallets attached.

From there it's a normal project: add tasks from the Tasks rail, trade from the wallet table or the [Trade panel](https://vortexdeployer.com/docs/terminal/trade-panel).

## See also

- [The terminal](https://vortexdeployer.com/docs/terminal/overview)
- [How tasks run](https://vortexdeployer.com/docs/tasks/overview)

---

# Wallets overview

> The Wallets page: global pool and project wallets, folders, roles, live balances, and every wallet action.

Source: https://vortexdeployer.com/docs/wallets/overview · Markdown: https://vortexdeployer.com/docs/wallets/overview.md

The **Wallets** page holds every keypair the app manages for you. Wallets live in one **global pool**, can be filed into **folders**, carry a **role**, and can be assigned to projects. Balances are live — no refresh needed.

![The current Wallets page, with folders, filters and actions. Example account.](https://vortexdeployer.com/docs/wallets/overview.png)

## Global vs Project wallets

- **Global wallets** — the pool: everything you generate, import or buy, on either chain.
- **Project wallets** — pick a project to see its wallets: project-only ones (created in the wizard, never in the pool) plus pool wallets **assigned** to it. An assigned wallet stays in the pool and can serve other projects.

The header totals the view: wallet count, SOL and ETH.

## Folders

The left column lists **All wallets**, **Unassigned** and your folders, each with its count; the folder icon adds one. See [Groups](https://vortexdeployer.com/docs/wallets/groups).

## The table

Above it: **Search address or label…**, chain and role filters, sort order, **Hide empty**, and **Copy visible addresses**.

- **Label** — with the address under it (click to copy). Task-created wallets carry the task's name (e.g. `holder-t716`).
- **Role** — `Dev`, `Trading`, `Holder`, `Sniper`, `Bundle`, `Fee`, `Temp`. A label for you and a filter for forms; a project's DEV wallet is the one that mints.
- **Folder** — where it's filed, or **Unassigned**.
- **Balance (live)** — updates on every on-chain change.
- **⋯** — **Activity** (the wallet's profile: age, trades, positions, realized P&L — its real on-chain footprint, simulations excluded), **Copy address**, **Export key**, and delete (**Remove from project** in a project view).

## Actions

The panel on the right. Tick wallets first; the line under **Funds** shows which wallets an action starts from.

- **Selection** — **Assign folder…**, **Remove from folder**, **Export keys**, **Delete selected**.
- **Funds** — [Fund](https://vortexdeployer.com/docs/wallets/fund), [Collect](https://vortexdeployer.com/docs/wallets/collect), **Transfer**, **Convert**, [Claim cashback](https://vortexdeployer.com/docs/wallets/cashback).
- **Acquire** — [New wallet](https://vortexdeployer.com/docs/wallets/create-and-import), [Warm up](https://vortexdeployer.com/docs/wallets/warm-up), **Dev warmup**.

Need ready-made wallets? Buy them in the [Wallet Marketplace](https://vortexdeployer.com/docs/wallets/marketplace).

## Open a wallet directly

[Workspace search](https://vortexdeployer.com/docs/overview/workspace) opens a wallet's own detail page. It shows the address, chain and role, with **Send funds** and, on Solana, **Convert tokens**. **All wallets** returns to the wallet list.

## Transfer

Send coin from one wallet to any address.

![Transfer: send from one wallet to an address.](https://vortexdeployer.com/docs/wallets/transfer.png)

- **Source wallet (pays + sends)** — its balance shows under it.
- **Destination address** — any address on that chain. A send is irreversible — double-check it.
- **Amount to send** — the source keeps a small fee and rent floor on top of it. To empty wallets, use [Collect](https://vortexdeployer.com/docs/wallets/collect).
- **Dry run** is ticked at first and the button reads **Rehearse send**; untick it to send for real.

## Convert

Solana only. Swaps stocks, stablecoins and tokens inside each selected wallet — every wallet keeps its own funds.

![Convert across Solana wallets.](https://vortexdeployer.com/docs/wallets/convert.png)

- **From** / **To** — pick a token, or find one by name or pasted mint (**Use mint**). The arrows between them reverse the conversion.
- The amount per wallet (e.g. **SOL per wallet**), or **All available in each wallet**.
- **Max impact %** and **Slippage %** — routes with too little liquidity, unverifiable pricing or a bigger price impact are blocked, and every conversion is checked again before sending.
- SOL for fees and token accounts stays in each wallet.

Press **Review conversion**, then **Simulate** to check it or **Convert** to run it. Progress is saved to your account in [Operations](https://vortexdeployer.com/docs/account/operations), so you can close the dialog and return later. **Stop remaining items** stops queued wallets; an already-started conversion may still finish. Review receipts on any item that needs attention before starting another conversion.

:::info Deleting a wallet
Delete is soft: the row disappears, the key stays encrypted, and re-importing revives it with its history. Move funds out first — a deleted wallet is not swept for you.
:::

## See also

- [Create & import](https://vortexdeployer.com/docs/wallets/create-and-import)
- [Groups](https://vortexdeployer.com/docs/wallets/groups)
- [Wallet Marketplace](https://vortexdeployer.com/docs/wallets/marketplace)

---

# Create & import

> Generate fresh keypairs or import private keys, into the pool or a project.

Source: https://vortexdeployer.com/docs/wallets/create-and-import · Markdown: https://vortexdeployer.com/docs/wallets/create-and-import.md

**New wallet** in the actions column opens the modal. On the Global tab the wallet joins your pool; on a project tab it's created straight into that project.

![The New wallet modal.](https://vortexdeployer.com/docs/wallets/new-wallet.png)

## Generate

- **Chain** — `SOLANA · SOL` or `ROBINHOOD · ETH`; a wallet lives on one chain.
- **How many** — 1 to 50 keypairs at once. Secrets are encrypted at rest, never shown until you export.
- **Role** — Bundle, Sniper, Dev, Trading, Fee, Holder (changeable later).
- **Label** — optional; numbered when creating several.

## Import

- **Paste a private key** — one per line for many. Solana keys in base58, Robinhood keys as 0x hex.
- Keys are encrypted immediately. Re-importing a deleted wallet revives it with its old label and history.

## Inside the wizard

The wizard's Wallets step has the same flows behind **Create** and **Import** — but those wallets are **project-only** and never appear in the pool. Use **Global** there to assign pool wallets. See [Wallets step](https://vortexdeployer.com/docs/launch/wallets-step).

:::warning Keys you paste
An imported key is only as private as where it came from. Prefer generating here and funding via [Fund wallets](https://vortexdeployer.com/docs/wallets/fund).
:::

## See also

- [Export a private key](https://vortexdeployer.com/docs/wallets/key-export)
- [Fund wallets](https://vortexdeployer.com/docs/wallets/fund)

---

# Wallet Marketplace

> Filter wallets, select up to 100 at once, compare costs and follow checkout.

Source: https://vortexdeployer.com/docs/wallets/marketplace · Markdown: https://vortexdeployer.com/docs/wallets/marketplace.md

**Marketplace** sells ready-made funded and aged wallets. Delivered wallets join your [global wallet pool](https://vortexdeployer.com/docs/wallets/overview). Pick a category first: Funded Solana, Aged Solana, Aged Robinhood, Solana dev or Robinhood dev.

![Marketplace filters, Quick select and the cost breakdown. Example account.](https://vortexdeployer.com/docs/wallets/marketplace.png)

## Find wallets

Filter by funding exchange, **Wallet age** and **Funding order**, or search by exchange or funding date. Aged wallets also offer **Trader type** and **Region**. **Reset filters** clears the filters.

Each row shows funding history, the balance included and the **Wallet cost**. Addresses stay private until purchase.

## Quick select

Choose **How many wallets?** and **Time between funding**, then press **Select wallets**. Quick select uses your filters across catalog pages and supports up to **100 wallets**.

Funding gaps range from **30 minutes to 6 hours**. The selected wallets must meet that gap; the result tells you if fewer matching wallets are available. You can also select individual rows or **Select page**. Rows too close to an existing selection are unavailable. If a changed gap makes the selection invalid, select again or adjust the gap before checkout.

## Understand the total

The selection summary separates the balance you keep from the wallet cost. **Total to pay** includes both. Where included USDC is valued in native coin, the cost estimate uses the current exchange rate.

On desktop the selection summary sits beside the catalog. On mobile the checkout summary stays at the bottom when wallets are selected.

## Pay and receive

Press **Continue to payment** to reserve the selection and open checkout. Send the **Exact amount to send** to the displayed **Payment address**, on the chain shown. Checkout checks payment automatically.

You can close checkout and use **Your orders** or **Resume payment** to return. When delivery completes, choose **Open Wallets**. [Notifications](https://vortexdeployer.com/docs/account/notifications) also links marketplace updates to their order.

:::warning Pay before the order expires
The countdown is your reservation window. If you paid but the order expired, use **Check late payment** or **Open Support** before paying again.
:::

## See also

- [Wallets overview](https://vortexdeployer.com/docs/wallets/overview)
- [Wallet warm-up](https://vortexdeployer.com/docs/wallets/warm-up)

---

# Groups

> Folders on the Wallets page — file wallets, filter, act on a folder at once.

Source: https://vortexdeployer.com/docs/wallets/groups · Markdown: https://vortexdeployer.com/docs/wallets/groups.md

Folders (the left column of the Wallets page) keep a big pool readable. A wallet is in at most one folder; the rest are **Unassigned**. Folders are per account and span both chains.

![The Folders column.](https://vortexdeployer.com/docs/wallets/folders.png)

## Working with folders

- **New folder** — the plus next to the Folders heading.
- **Rename** / **Delete** — hover a folder row. Deleting keeps the wallets; they go back to Unassigned.
- **All wallets** and **Unassigned** are fixed rows with live counts.

## Filing wallets

- Select rows and file them via the folder picker, or **Remove from folder** to send them back to Unassigned.
- A folder filter narrows the table, stat tiles and every action modal (Fund, Collect, Warm up) to that folder.

## Folders vs projects

A **folder** is a label for you; a **project** is a launch whose wallets its tasks trade from. A wallet can be in a folder and in several projects at once. Folders = "the June sniper set"; projects = "the token I launched today".

:::tip Copy a folder
With a folder selected, **Copy** above the table copies every address in it, one per line.
:::

## See also

- [Wallets overview](https://vortexdeployer.com/docs/wallets/overview)

---

# Fund wallets

> Fund many wallets from one deposit, through privacy hops or the Mixer exchange hop.

Source: https://vortexdeployer.com/docs/wallets/fund · Markdown: https://vortexdeployer.com/docs/wallets/fund.md

**Fund** in the actions column funds the wallets in view — either from a **deposit address** you pay from anywhere (exchange, hardware wallet, another app — the on-chain trail never starts at a managed wallet), or **from one of your wallets** that already holds the total. On a project tab the same modal is scoped to the project's wallets.

![Fund wallets, step 1.](https://vortexdeployer.com/docs/wallets/fund.png)

## Method

- **Vortex Disperse** — on-chain privacy hops: the deposit goes through a throw-away wallet and a temporary layer that closes fully into each destination. Nothing links back.
- **Mixer** — one Husher exchange order: the exchange pays each wallet, so there's no on-chain link at all. Minimum per destination: 0.15 SOL or 0.01 ETH.

## Step 1: wallets and amounts

- **Wallets** — tick destinations. Per-wallet **Delay** (Disperse) or **Hold** (Mixer) in minutes.
- **Total to deposit** — fees and reserves come out before the split; the line shows what each wallet actually receives.
- **Distribution** — equal split, **custom** per wallet, or **Variation ± %** around the even share.
- **Fund from** — the deposit address, or one of your wallets on the same chain (insufficient ones are greyed out).
- **Supply plan** — on a project view, **Mount** funds each wallet exactly what it lacks for its planned buy.

## Step 2 (Mixer): exchanges and holds

Each wallet gets its own exchange (Binance, KuCoin, Bitget) and hold time. **Randomize exchanges** spreads them; **Auto-distribute holds** spreads payouts over a window. Then **Create order — get deposit address**.

## The last step

- **Deposit address:** send exactly the shown amount (small shortfall tolerated), then **Close** — the task waits for the deposit (30 min default; re-run keeps the same address) and pays the wallets.
- **From your wallet:** nothing to pay — the last step shows the task's live status.

Follow progress on the Tasks page.

:::info Fees
No platform fee on funding. Husher takes its own fee out of the total.
:::

## See also

- [Collect funds](https://vortexdeployer.com/docs/wallets/collect)
- [Mixer](https://vortexdeployer.com/docs/tasks/mixer)

---

# Collect funds

> Sweep SOL or ETH from many wallets into one destination, on-chain or through the Mixer.

Source: https://vortexdeployer.com/docs/wallets/collect · Markdown: https://vortexdeployer.com/docs/wallets/collect.md

**Collect** consolidates coin from many wallets into one destination. Runs as a task; closing the modal never stops it.

![Collect funds with wallets selected.](https://vortexdeployer.com/docs/wallets/collect.png)

## Method

- **Sweep (on-chain)** — direct transfer from each source to the destination, one after another.
- **Mixer (one order per wallet)** — every source opens its own Husher order, so no shared order links the wallets.

## Wallets and amounts

- **Select Wallets** — tick sources or **Select All**.
- **Amount** per wallet — blank = all of it; more than it holds = all of it.
- **Leave behind** — keep at least this much in every source (rent floor and fee headroom stay regardless). A per-wallet value wins over the global one.
- **Delayed collection** — **Min** / **Max** minutes of random wait before each wallet after the first.

## Destination

**My wallets…** or paste any address you control.

:::danger Do not withdraw directly to a CEX
Never sweep many wallets straight into an exchange deposit address. Withdraw to a wallet you control first, then send on to the exchange.
:::

## Results

After **Collect**, the modal shows **Collection details**: per-wallet lines and **Total Collected**, live as transfers land. In dry run everything is simulated.

## See also

- [Fund wallets](https://vortexdeployer.com/docs/wallets/fund)
- [Mixer](https://vortexdeployer.com/docs/tasks/mixer)

---

# Claim cashback

> Collect the PumpSwap cashback your Solana wallets earned — it lands as wrapped SOL.

Source: https://vortexdeployer.com/docs/wallets/cashback · Markdown: https://vortexdeployer.com/docs/wallets/cashback.md

Some pump.fun tokens graduate as **cashback coins**: every PumpSwap trade pays a slice of the fee back to the trader. Cashback doesn't land in your wallet directly — it accrues as wrapped SOL in a vault, and only a claim moves it out. **Claim cashback** on the Wallets page does that for the wallets you pick.

Cashback was removed as a new launch option on September 12, 2026 — this page applies to existing Cashback tokens. Pump Holder Rewards pay automatically and don't use this flow.

## What you see

**Wallets → Claim cashback** lists every Solana wallet in view with cashback waiting, selected by default — untick any to skip.

## What a claim does

- One transaction per wallet; the wallet pays its own fee.
- Cashback arrives as **wrapped SOL** in the wallet's wSOL account. Nothing is unwrapped or closed; wSOL is spendable on wSOL-quoted pools, and you can unwrap it yourself anytime.
- A wallet without a wSOL account gets one opened (≈ 0.002 SOL rent, which stays as the account's floor) — the row says so first.
- The vault keeps collecting on your next trades.

## Dry run first

The modal starts in **Dry run**: every claim is simulated, nothing moves, and each row shows whether it would go through. Untick Dry run and confirm to claim for real.

## See also

- [Wallets overview](https://vortexdeployer.com/docs/wallets/overview)

---

# Wallet warm-up

> Age wallets with real buy, hold and sell cycles on live coins.

Source: https://vortexdeployer.com/docs/wallets/warm-up · Markdown: https://vortexdeployer.com/docs/wallets/warm-up.md

A fresh wallet with one transaction looks like a bot. **Warm up** gives wallets an organic history of buys, holds and sells on live coins. **Dev warmup** gives a creator wallet a launch history via throwaway tokens. Both open from the actions column and run as tasks.

![Warm up wallets modal.](https://vortexdeployer.com/docs/wallets/warm-up.png)

## Warm up wallets

- **Wallets** — tick the wallets to age; one chain at a time.
- **Tokens to warm on** — **Auto (warmup cache)** picks a different fresh launch per buy (never one the wallet already warmed, never above 1.5× launch price). **One token** warms on a mint you paste.
- **Buy** range, **Hold time (seconds)**, **Trades per cycle**, **Cycles** (0 = until stopped), interval between cycles.
- **Stop-loss (%)** — sell early if a held buy drops this far below cost. 0 = off.
- **Dry run** — on by default; rehearse only.

Every trade is a real swap with the platform fee — keep balance for fees and gas.

## Dev warmup (Solana only)

Gives one **Dev wallet** a real launch history: each throwaway token is created on Meteora DBC, filled in one buy, migrated to DAMM v2.

- **Tokens to launch** — 1 to 20 (≈ 0.05 SOL each; estimate updates live).
- **Custom metadata** — your own name/symbol/image for a single token; otherwise each clones a recent pump.fun graduate's look.
- **Dry run** — simulate, launch nothing.

:::info Warm-up task
The same engine as a Tasks page task, with every option exposed: [Wallet warm-up task](https://vortexdeployer.com/docs/tasks/wallet-warmup).
:::

## See also

- [Best practices](https://vortexdeployer.com/docs/other/best-practices)

---

# Export a private key

> Reveal a wallet's private key after re-entering your password.

Source: https://vortexdeployer.com/docs/wallets/key-export · Markdown: https://vortexdeployer.com/docs/wallets/key-export.md

The app never shows a private key on its own. Export reveals it once, masked, in a modal, after a password check.

![The Export private key modal.](https://vortexdeployer.com/docs/wallets/export-key.png)

## One wallet

Row menu → **Export private key**. The modal names the wallet and warns you:

> Anyone with this private key has full control of this wallet and everything in it. Never share it, never paste it into a website, store it somewhere only you can reach.

- **Account password** — required only if you've set a web-login password here. Telegram-only accounts leave it blank. (A password from the old site doesn't count until you've signed in with it here.)
- Wrong passwords are refused in the modal — your session is never ended. Repeated wrong attempts pause exports for a while; the modal says how long.
- **Reveal private key** — copy it, then close the modal.

## Several wallets

Select rows → **Export keys** in the actions column. Same password check; each key is listed with label and address.

## What is recorded

Every export is logged against your account (wallet + time). Deleted or foreign wallets can't be exported.

:::danger Treat an exported key as burned
Once a key leaves the app, assume it can leak. Move funds back to an app-generated wallet when you're done with the outside tool.
:::

## See also

- [Create & import](https://vortexdeployer.com/docs/wallets/create-and-import)

---

# The terminal

> One screen per token: chart, trades, your wallets' positions and the tasks on it — in two layouts.

Source: https://vortexdeployer.com/docs/terminal/overview · Markdown: https://vortexdeployer.com/docs/terminal/overview.md

Every token gets a **terminal**: live chart, trades feed, your wallets with inline buy and sell buttons, and the tasks on that token, on one screen. It opens automatically at launch, from a project card's **Open terminal**, the left rail, or `/swap?mint=…`.

![The terminal, Side by side layout.](https://vortexdeployer.com/docs/terminal/overview.png)

## Layouts

The switch in the header picks how the screen is split. The terminal remembers your choice.

- **Side by side** — chart, market stats and the Trades feed in a resizable column; your wallets beside it, the Tasks rail under them.
- **Classic** — a compact chart with the Trades feed beside it, your wallets below, and the stats and Tasks rail in a column on the right.

![The terminal, Classic layout.](https://vortexdeployer.com/docs/terminal/classic.png)

## Header

Symbol, name, chain and quote badges, contract address (click to copy), explorer link. Live figures: **Market cap**, **Price**, **Liquidity**, **Supply**, **Fees Paid**. On the right: the layout switch and **Share PnL** (see [P&L share cards](https://vortexdeployer.com/docs/terminal/pnl-cards)).

## Chart and stats

The app's own candles from the on-chain feed — shows a token from its first trade, before any explorer indexes it. Your fills and [KOL tracker](https://vortexdeployer.com/docs/terminal/kol-tracker) wallets' trades are marked on it.

- Market: **24h Vol**, **Buys**, **Sells**, **Net Vol**.
- Yours: **Bought**, **Sold**, **Holding**, **PnL** — open bags valued at what selling them now would return, with the coin estimate under it.

## Tabs

- **Wallets (n)** — your wallets on this token, with inline trading (below). Opens by default.
- **Trades** — every swap as it lands, with its transaction link. Your wallets carry a **YOU** tag; tracked KOLs their emoji.
- **Holders** — current holders, largest first, with % supply. **YOU** and **dev** tags included; a donut splits supply into Dev / Yours / Top 10 / Other / Pool.
- **Bubblemaps** — the holder-cluster map, embedded; spot one person behind many wallets.
- **Pools (n)** — DEX, pool address and reserves behind the price.
- **History** — your fills only, with transaction links.

## The tab bar

- **Add wallets** — attach pool wallets to this token (your own launches).
- **Tasks** — shows the Tasks rail again.
- **Trade Panel** — one buy or sell across many wallets, see [Trade panel](https://vortexdeployer.com/docs/terminal/trade-panel).
- **Sell all**, **Sell all (excl dev)**, **Sell dev** — see [Sell all](https://vortexdeployer.com/docs/terminal/sell-all).
- **Claim fees** — claim the creator fees your launch has earned. On a coin with pump.fun **Holder Rewards** the button reads **Holder Rewards**: they're paid automatically in the quote token. On Robinhood it reads **Creator fees** and shows the totals — pons sweeps them to the creator wallet by itself.
- **Focus wallets** (⤢) — the wallet table takes the full width; press again to bring back the chart and stats.

## Trading from the wallet table

Columns: **#**, **Wallet**, **Balance**, **Bought / Sold**, **P&L (SOL)**, **Remaining** (tokens left and % of supply), the trade buttons, and **Ops**.

- **Buy / Sell** above the buttons picks which set every row shows.
- **SOL / %** — buy buttons in coin, or in % of each wallet's spendable balance.
- The wrench edits the button amounts.
- **Buy** rows: preset amounts plus **MAX** — everything spendable, with the gas reserve and platform fee kept back so the wallet can still sell.
- **Sell** rows: **25 % · 50 % · 75 % · 100 %** of that wallet's bag.

One press is one real swap from that wallet. Double-click a wallet's label to rename it; the role chip changes its role.

**Ops:** **Burn** destroys the wallet's tokens (both chains); **Lock** locks them with Streamflow (Solana). Both need tokens in the wallet.

## Tasks rail

Every task on this token. **Active** / **All** switches the list; the flame is **Warm up wallets**; **New task** opens the task form pointed at this mint. Click a row to expand it into the full card. With nothing running it says **No active tasks.**, with **View finished** and **+ Create a task**.

:::info Live
Everything updates by itself. If the footer doesn't say **Connected**, you're seeing the last received state.
:::

## See also

- [Trade panel](https://vortexdeployer.com/docs/terminal/trade-panel)
- [How tasks run](https://vortexdeployer.com/docs/tasks/overview)
- [After launch](https://vortexdeployer.com/docs/launch/after-launch)

---

# Trade panel

> Group buys and sells from many wallets at once.

Source: https://vortexdeployer.com/docs/terminal/trade-panel · Markdown: https://vortexdeployer.com/docs/terminal/trade-panel.md

**Trade Panel** in the terminal's tab bar opens a floating ticket for group trading: pick wallets, and every buy or sell fires from all of them at once — one swap per wallet, in parallel. The fast hand of the app; tasks are the slow one.

![The Trade panel open over the terminal.](https://vortexdeployer.com/docs/terminal/trade-panel.png)

## The top row

- **Select wallets** / **N wallets** — choose which wallets trade. The line under it reads **N selected wallets · amounts apply to each wallet**.
- **SOL / %** — size in coin per wallet, or in percent (below).
- Drag the dots to move the panel; the pencil edits the presets; ✕ closes it.

## Buy

- **Chips** — the active preset's sizes, per wallet. In % mode they're a share of each wallet's spendable balance.
- **Amount** — type any size instead.
- **MAX** — each selected wallet buys with its whole spendable coin; the gas reserve and platform fee are kept back so it can still sell. SOL-quoted markets only.
- **Stock-quoted pump.fun coins** (SPYx, AAPLx…) still trade in SOL: the swap into the stock and back happens inside the same transaction. Costs a little more in fees and impact than a SOL-quoted coin.
- **Buy** fires; fills appear in the Trades feed tagged **YOU** within seconds.

## Sell

- **Chips** — a percentage of each wallet's bag.
- In % mode, **% of bag** / **% of supply** — with % of supply each wallet sells that share of the total supply, never more than it holds.
- **Worth** — sell the amount of tokens worth that much coin instead.
- A wallet with no tokens is skipped, not failed.
- **Sell all wallets** / **Sell all (excl dev)** at the bottom — see [Sell all](https://vortexdeployer.com/docs/terminal/sell-all).

## The footer line

`slippage 3.00 % · PRESET 1 · Settings → Trading` — which preset is live. Presets 1–3 each carry their own chips and slippage; **Randomize** adds a small random band to sizes so fills don't look identical.

## Confirmations

Both off by default, under Settings → Trading:

- **Confirm dev trades** — ask before any trade including a Dev-role wallet.
- **Confirm Sell all** — ask before Sell all or Sell all (excl dev) fires.

:::warning A group trade is many real swaps
Each selected wallet sends its own transaction with its own gas and fee. No simulation here — rehearse with a [Buy task](https://vortexdeployer.com/docs/tasks/buy) instead.
:::

## See also

- [Fees](https://vortexdeployer.com/docs/overview/fees)
- [Settings](https://vortexdeployer.com/docs/account/settings)

---

# Sell all

> One press sells every wallet's bag at market — all of them, all but the dev, or the dev only.

Source: https://vortexdeployer.com/docs/terminal/sell-all · Markdown: https://vortexdeployer.com/docs/terminal/sell-all.md

Three buttons in the terminal's tab bar, each one press:

- **Sell all** — 100 % from every wallet on this token that holds it.
- **Sell all (excl dev)** — the same, leaving this token's creator wallet untouched.
- **Sell dev** — 100 % from this token's creator wallet only.

The Trade panel repeats the first two at its bottom as **Sell all wallets** and **Sell all (excl dev)**.

![Sell all, Sell all (excl dev) and Sell dev in the tab bar.](https://vortexdeployer.com/docs/terminal/sell-all.png)

## What happens

1. Every wallet in scope that holds the token gets a 100 % market sell, sized from its **live** balance at press time.
2. Sells go out in parallel at the preset's slippage. Temporary-wallet mode uses extra transactions.
3. Each landed sell pays the platform fee on actual proceeds.
4. Feed and P&L update as fills land.

An empty wallet is skipped; a failed wallet (slippage, no liquidity) is reported and doesn't stop the others. Buttons stay available while trades run. If nothing can be sold, the app explains why. A missing browser route does not stop the request; the backend can find the route when you sell.

## Excluding the dev

Use **Sell all (excl dev)** when the creator should keep holding. This uses the token's creator wallet from its project, rather than every wallet with a Dev role.

## Guarding the button

By default it's one fast press, no dialog. Turn on **Confirm Sell all** under Settings → Trading for a prompt before Sell all or Sell all (excl dev) fires.

:::tip Selling through another wallet
With **Sell through another wallet** on under [Settings → Trading](https://vortexdeployer.com/docs/account/settings), each sale runs from a fresh wallet that returns the proceeds — pick **All sells**, or choose Sell all, Sell all except dev and Sell dev one by one under **Custom**.

If the temporary setup cannot be funded or prepared before submission, the app tries a normal source-wallet sale automatically. The setting remains on for future sales.
:::

:::danger Market floor
Sell all fires every holder against the same pool at once — on a thin curve, later sells land much lower. For a gentler exit use a [Ladder](https://vortexdeployer.com/docs/tasks/ladder) or [DCA](https://vortexdeployer.com/docs/tasks/dca) sell.
:::

## See also

- [Trade panel](https://vortexdeployer.com/docs/terminal/trade-panel)
- [Anti-Sniper](https://vortexdeployer.com/docs/tasks/anti-sniper) — automatic emergency sell

---

# P&L share cards

> Share a token's P&L or a period's P&L as an image.

Source: https://vortexdeployer.com/docs/terminal/pnl-cards · Markdown: https://vortexdeployer.com/docs/terminal/pnl-cards.md

Two share cards, both drawn from the same numbers the app shows — a card never disagrees with the screen.

![The Share PnL card for a token.](https://vortexdeployer.com/docs/terminal/share-pnl.png)

## Share PnL (per token)

**Share PnL** in the terminal header opens the card for the token you're on: bought, sold, fees, holding and P&L across every attached wallet, from on-chain fills.

- **Default** / **Custom image** — the app's plate or your own background.
- **Show @handle** — put your username on it, or stay anonymous.
- The **summary** line is the plain-text version, including how the bag is valued (full-bag sell quote with impact and fee inside).
- **Copy summary**, **Copy image**, **Download PNG**.

## PNL Card (per period)

**PNL Card** on the dashboard: **1D**, **7D**, **30D** or a custom range, per chain. Counts **realized flow only** — landed sells minus landed buys, fees included, no open bags.

## What the numbers mean

- **Realized** P&L is exact per fill (delta + fee recorded).
- **Unrealized** P&L is what selling the whole bag now would return, net of impact and fee — never spot price × bag size.
- Dry-run and simulated trades are excluded everywhere.

:::info The coin icon
Values are in SOL on Solana, ETH or the quote token on Robinhood. USD uses the live price when you open the card.
:::

## See also

- [Portfolio](https://vortexdeployer.com/docs/account/portfolio)
- [Dashboard](https://vortexdeployer.com/docs/account/dashboard)

---

# KOL tracker

> Follow known wallets — their trades are marked on the chart and tagged in the feed.

Source: https://vortexdeployer.com/docs/terminal/kol-tracker · Markdown: https://vortexdeployer.com/docs/terminal/kol-tracker.md

**Tracker** in the footer opens your list of tracked wallets. When one of them trades a token you have open, the trade is tagged with its emoji and name in the Trades feed and marked on the chart.

![The Tracker with the default list.](https://vortexdeployer.com/docs/terminal/tracker.png)

## The list

- New accounts are seeded with well-known trader wallets — edit or remove them freely.
- **Track wallet** — paste an address, name it, pick an emoji (the emoji is what shows on the chart).
- Click a row to edit or remove; removal is immediate.

## Where it shows

- **Trades feed** — emoji and name instead of a bare address.
- **Chart** — a buy/sell-colored marker at the candle.
- **Wallet profile** — click a tracked address for its on-chain activity on that token.

One list per account, applied across every terminal on both chains.

:::tip Track your competitors' devs
Add the creator wallets of tokens you watch — their sells are the earliest signal a launch is winding down.
:::

## See also

- [The terminal](https://vortexdeployer.com/docs/terminal/overview)

---

# How tasks run

> Creating, starting, pausing and editing tasks — the form, the card and its sections.

Source: https://vortexdeployer.com/docs/tasks/overview · Markdown: https://vortexdeployer.com/docs/tasks/overview.md

Every automation is a **task**: a snipe, a volume loop, a sell ladder. They all share the same lifecycle and the same card on the **Tasks** page. Learn the card once and every task reads the same.

![The Tasks page with a card's Results open.](https://vortexdeployer.com/docs/tasks/overview.png)

## Creating a task

- **New task** on the Tasks page — **Choose target token**: one of your tokens, or paste a mint and press **Continue**.
- **New task** in the terminal's Tasks rail — same form, pointed at that token.
- The wizard's [Tasks step](https://vortexdeployer.com/docs/launch/tasks-step) creates launch tasks that start with the launch.

The form, top to bottom:

- **Presets** — **Load preset…** or **Save as preset**.
- **Task type** — use **Find a task** or the category buttons, then choose a task tile. Only types supported on the token's chain appear. [Token Sender](https://vortexdeployer.com/docs/tasks/token-sender) distributes existing tokens.
- **Supply plan** (where supported) — pick a plan and **Mount** it.
- **Task name (optional)** and **Start immediately**.
- **Wallets** — click selects, shift-click selects a range; picked wallets stack in buy order, drag ⠿ to reorder.
- **Task settings** — options are grouped by setup, wallets and funding, amounts and limits, and timing. Additional controls such as slippage, timeouts and tips appear under **Advanced** where supported.

**Create task** saves it (and starts it with **Start immediately**).

:::warning Some tasks trade for real
Volume, Bundle, Holder Boost, Hand Switcher, Fake Volume, Anti-Sniper, Pro Trader Boost and the order tasks have no **Simulate** switch — they spend funds as soon as they start. See [Simulate & dry run](https://vortexdeployer.com/docs/overview/dry-run).
:::

## The card

Header: task type, status (**IDLE**, **RUNNING**, **COMPLETED**, **STOPPED**, **FAILED**), then token, wallet count and task number.

Buttons (hover for the name):

- **Start** — begins a run; on a finished task it means **Run again**.
- **Pause** / **Resume** — resume skips wallets that already landed, so nothing fires twice.
- **Stop** — ends the run; landed stays landed.
- **Edit** — applies to a running loop without stopping it.
- **Duplicate** — a new idle task with the same options.
- **Delete** — asks once; history stays in your executions.

## Sections

Each opens on click:

- **Deposit** — on funding tasks that wait for a deposit: where to pay and who receives.
- **Executions** — one row per action: wallet, side, amount, status, transaction. Simulated rows say **simulated**.
- **Orders** — on Limit order, Ladder, Mirror, DCA and Trailing stop: every order with its state, and the live market cap.
- **Results** — the last run: counts (Landed, Failed, Simulated, Skipped, No action), start and end, and per wallet what it did or why it did nothing. **Replay timeline** steps through it; ↻ rebuilds it from landed fills.
- **Simulate** (no funds move) — what the task would do now from its options and live balances, and why it would be skipped. ↻ recomputes. Not on tasks that always trade for real.

## Open a task directly

Task results from [Operations](https://vortexdeployer.com/docs/account/operations), [Notifications](https://vortexdeployer.com/docs/account/notifications) and workspace search open the task's own page. Use it to follow the execution history without finding the task again in a long list.

## Filters and history

**All / Active / Completed / Stopped** with counts, a type filter and **Search mint, label, or type…**. The page loads the newest 100 tasks; **Load 100 older** fetches more — until then the counts cover only what's loaded.

:::info Nothing fires twice
A task remembers every landed action: an interrupted run picks up where it stopped. That's also why Pause and Resume are safe.
:::

:::warning One fee rule
Task buys pay the platform fee on the spend, sells on what lands — same as a manual trade. See [Fees](https://vortexdeployer.com/docs/overview/fees).
:::

## See also

- [Simulate & dry run](https://vortexdeployer.com/docs/overview/dry-run)
- [Buy](https://vortexdeployer.com/docs/tasks/buy) — the simplest task to learn the card

---

# Buy

> One round of buys from many wallets, with your choice of sizing, delays and guards.

Source: https://vortexdeployer.com/docs/tasks/buy · Markdown: https://vortexdeployer.com/docs/tasks/buy.md

**Buy** is one round: every picked wallet buys once, then the task completes. It's the building block of [Snipe](https://vortexdeployer.com/docs/tasks/snipe); for a continuing loop use [Volume](https://vortexdeployer.com/docs/tasks/volume).

![A Buy task form.](https://vortexdeployer.com/docs/tasks/buy.png)

## Sizing

**Buy mode** decides each wallet's amount:

- **Full balance** — everything minus gas reserve and platform fee (so it can still sell).
- **Exact per-wallet** — you type an amount per wallet; empty = skipped.
- **Random % of balance** — between **Min %** and **Max %**.
- **Random in range** — between **Min buy** and **Max buy**.
- **One total across wallets** — **Total to spend** split **Equal**, **Random** or **Weighted by balance**.

**Wallets** picks who takes part: all funded, random, richest/poorest first, most/least holdings; **How many** keeps the top N.

## Timing

**Min delay** / **Max delay** space wallets out (0/0 = all at once). **Initial delay** waits before the first. **Min wallet balance** skips poorer wallets.

## Guards (Advanced)

- **Supply guard** + **Max supply change** — aborts mid-round if outside buyers grab too much of the curve while you fire (pump.fun only).
- **Max supply per wallet** — skips wallets already at that share; a mounted plan sets it.
- **Max consecutive errors** — stops the task after that many failures in a row.

:::info Simulate before Start
Keep **Simulate** on for the first run: the card's **Simulate (no funds move)** section prices every wallet's buy from live balances and the current curve, before anything fires.
:::

@engine(buy)

---

# Snipe

> The launch buyer — a Buy round that fires the instant your token is live.

Source: https://vortexdeployer.com/docs/tasks/snipe · Markdown: https://vortexdeployer.com/docs/tasks/snipe.md

**Snipe** is a Buy that fires at launch. Add it on the wizard's Tasks step (or Quick deploy); it waits for the mint, then every sniper wallet buys the moment the token exists. On pons it lands in the launch block, so nobody is ahead. Outside a launch it behaves exactly like [Buy](https://vortexdeployer.com/docs/tasks/buy).

![The Snipe card with the supply calculator.](https://vortexdeployer.com/docs/tasks/snipe.png)

## Supply calculator

On the Tasks step, the card shows your sizes as **% of supply**, priced against the launch curve with the dev buy ahead. The total is capped to your plan or ceiling. Best case: it assumes nobody else is in the same block.

## Sizing and wallets

Same as Buy: **Buy mode** (Full balance, Exact per-wallet, Random %, Random range, One total), **Wallets** pick and **How many**, **Min wallet balance**, **Slippage**. No delays — a snipe fires everything at once.

## Guards

- **Supply guard** + **Max supply change** (pump.fun curves).
- **Max supply per wallet** from a mounted plan.

## Pair-token launches

On a pair-token pons launch, sniper wallets must hold the pair token — the wizard's **Fund** tile can swap ETH into it before launch. The Snipe buys the curve directly, so it pays no launch-window tax.

:::info Simulate
With **Simulate** on, a Snipe checks its buys against the simulated curve; nothing is sent. In a launch it follows the launch's Simulate / Create.
:::

@engine(sniper)

---

# Volume

> A continuing loop of organic-looking buys and sells across your wallets.

Source: https://vortexdeployer.com/docs/tasks/volume · Markdown: https://vortexdeployer.com/docs/tasks/volume.md

**Volume** prints trades across your wallets to keep a chart alive. **Volume style** picks how, and can't be changed after the task is created:

- **Scheduled** — a plan of buys _or_ sells in one direction, from a second apart.
- **Mixed** — buys and sells together, as fast as 10+ trades a second, until you stop it or a limit ends it. The rest of this page is the Mixed style.

Volume always trades live — it has no rehearsal mode.

![A Volume task running.](https://vortexdeployer.com/docs/tasks/volume.png)

## Buys and sells

**Buy power** / **Sell power** are relative weights: 100/0 only buys, 50/50 is even, 70/30 leans long. At least one must be above zero. A sell takes between **Min sell** and **Max sell** percent of the wallet's bag.

Two guards keep the feed from reading as one-way:

- **Max same side in a row** — after that many buys (or sells) in a row the next trade goes the other way. 0 turns it off.
- **Net-buy cap** — while the run has this much SOL tied up in tokens it hasn't sold back yet, it only sells. 0 turns it off. Buys still on their way count, so a fast run can't overshoot it. It reads what the run still _holds_, not buys minus sells: fees and slippage make every round trip cost a little, and that alone would pin a long run at the cap while it held nothing.

## Sizing

- **Random size in a band** — each buy between **Min buy** and **Max buy**.
- **Reach a volume target** — **Target volume** within **Within** minutes: sizes are recomputed each tick from what's landed, so it catches up when behind and stops on target. **Size jitter** (Advanced) varies sizes so ticks don't look alike.

## Pacing and limits

- **Min delay** / **Max delay** — the gap between _sending_ trades (from 20 ms), not between confirmations.
- **Trades at once** — how many trades may be on their way together. A wallet only ever has one trade out, so the real ceiling is your wallet count. At 1 the run is one-at-a-time, about 2–4 trades a second at best.
- **Maximum trades** — 0 runs until stopped.
- **Min SOL reserve** — buys that would breach it are clamped or skipped.
- **Max supply per wallet** — skips wallets at the ceiling.
- **Max consecutive errors**.

## Going fast

For 10+ trades a second: **Min delay** and **Max delay** around 50–100 ms, **Trades at once** 10 or more, and at least as many wallets as that.

:::warning Speed costs money
Every trade pays the network fee, the send tip and the platform fee. Ten trades a second is 600 paid trades a minute — set **Maximum trades** or a volume target before you start a fast run.
:::

## Look like trading bots

Pick any of **Photon**, **Trojan**, **BullX**, **Axiom**: every trade then also sends 10 lamports (0.00000001 SOL) to that bot's fee wallet, the same transfer those bots make, so explorers and wallet trackers label the trade as made through the bot. Each wallet sticks to one of the bots you picked. Pick none to turn it off. Solana only.

:::info Sells through a throwaway wallet aren't tagged
If **Sell through a temporary wallet** is on for this task, those sells are signed by a throwaway wallet that trades once — tagging it would label that wallet, not your trader — so they go out untagged. The task's preview tells you how many of its wallets sell that way.
:::

:::tip More wallets, more traders
Volume rotates through every task wallet — a handful of wallets makes the feed show many traders. Pair with [Hand Switcher](https://vortexdeployer.com/docs/tasks/hand-switcher) to actually move supply between hands.
:::

@engine(volume)

---

# Fake volume

> Print volume on pump.fun with two wallets at almost no net cost. Solana only.

Source: https://vortexdeployer.com/docs/tasks/fake-volume · Markdown: https://vortexdeployer.com/docs/tasks/fake-volume.md

**Fake volume** prints a target amount of USD volume on a pump.fun curve at close to zero net cost. Each cycle, one wallet buys and the other sells in the same atomic bundle — the SOL comes back, only fees leave. Solana only; needs **exactly two** wallets.

![A Fake volume task card.](https://vortexdeployer.com/docs/tasks/fake-volume.png)

## Options

- **Target volume** (USD) — stops when reached, or cap by **Max cycles**.
- **Max SOL / cycle** — size of each buy; the matching sell returns it.
- **Min/Max delay** between cycles.
- **Jito tip** and **Priority fee** — what each bundle pays to land; most of the cost.
- Slippage, confirm timeout, max consecutive errors.

## What it costs

Per cycle: Jito tip + pump.fun fee on both legs + platform fee on the buy. Temporary token accounts are closed in the same transaction, so no rent is left behind; anything not guaranteed back is swept after landing.

:::warning Volume, not holders
This moves one bag between two of your wallets — no new holders, no supply change. Use [Holder boost](https://vortexdeployer.com/docs/tasks/holder-boost) for that.
:::

@engine(fakevolume)

---

# Holder boost

> Create fresh holder wallets and give each a few tokens, then reclaim the rent when done.

Source: https://vortexdeployer.com/docs/tasks/holder-boost · Markdown: https://vortexdeployer.com/docs/tasks/holder-boost.md

**Holder boost** creates fresh wallets and sends each a small amount of your token, so the holder count on explorers rises. On Solana each holder costs token-account rent — **Reclaim** mode gets it back. On Robinhood, holders are funded through the Disperse contract in one transaction for a few cents each.

![A Holder boost task.](https://vortexdeployer.com/docs/tasks/holder-boost.png)

## Boost

- **Holder count** — fresh wallets to create (they appear on the Wallets page with the task's label).
- **Tokens / holder (raw)** — amount each receives.
- **Advanced:** delays between batches, jitter, max consecutive errors.

Transactions automatically use the largest supported batch: up to 8 holders on Solana or 200 on Robinhood.

The task's wallet is the source: it must hold enough tokens for every holder plus coin for rent and gas.

## Reclaim (Solana only)

**Mode: Reclaim** burns the holders' tokens and closes their accounts, returning rent to the **Rent recipient** (a source wallet by default), automatically recovering up to 5 holders per transaction. Nothing to reclaim on Robinhood.

:::info No platform fee
Funding holders isn't a trade — you pay rent and gas only.
:::

@engine(holderboost)

---

# Pro trader boost

> The platform's aged trader wallets buy your token in tiers of 10 to 500, paid by your wallets.

Source: https://vortexdeployer.com/docs/tasks/pro-trader-boost · Markdown: https://vortexdeployer.com/docs/tasks/pro-trader-boost.md

**Pro trader boost** buys your token from the platform's own farm of warmed, aged trader wallets — so the buyers on your chart are accounts with real history, not fresh wallets. You pick a tier; your task wallets pay the tier's fee up front; the farm buys.

![A Pro trader boost task.](https://vortexdeployer.com/docs/tasks/pro-trader-boost.png)

## Tiers

**Pro traders** lists tiers with the price per buyer: 10 traders for $5, up to 500 for $125. The fee is paid in coin by the task's wallets before any buy. A tier the wallets can't cover is downgraded to one they can.

## The buys

Each trader targets **1 whole token**. The amount is fixed; there is no token-amount input or minimum spend floor. The final fill can vary with fees, rounding and price movement.

- **Advanced:** delay between buys, slippage, retries, abort limits.

Farm buys carry no platform fee — the tier fee is the price. Farm wallets never appear on your Wallets page; their bags aren't yours.

:::info Not a sell
The farm holds what it buys. This adds buyers and volume; it doesn't move your own supply.
:::

@engine(protrader_boost)

---

# Migrate & buy

> Launch a pump.fun token, fill its curve, migrate to PumpSwap and buy from the pool — one task. Solana only.

Source: https://vortexdeployer.com/docs/tasks/migrate-and-buy · Markdown: https://vortexdeployer.com/docs/tasks/migrate-and-buy.md

**Migrate & buy** creates a pump.fun token, buys the whole curve with the creator so it migrates immediately, then buys from the new PumpSwap pool with your buyer wallets — one bundled sequence. The chart starts on the DEX with a full pool and your buyers already in. Solana only.

![A Migrate & buy task.](https://vortexdeployer.com/docs/tasks/migrate-and-buy.png)

## Token

- **Token name**, **Symbol**, **Metadata URI** — the token to create (the URI is what the wizard's Metadata step produces).
- **Mayhem mode** and **Cashback** — pump.fun launch options.

## Buys

- **PumpSwap buy** — total SOL bought after migration, split across buyer wallets, or set **Per-buyer SOL** explicitly.
- **Advanced:** **Buyers / tx** (1–3), dev-buy and PumpSwap slippage.
- **Jito tip** and **Confirm timeout** — the bundle's landing cost.

The dev wallet is the task's first wallet: it pays the create, the curve fill and the migration — it needs the full curve's worth of SOL plus fees.

:::warning Everything or nothing
Each bundle lands whole or not at all — no half-done states — but a landed migration can't be undone. Keep **Simulate** on for the first run and read the Simulate section for the amounts.
:::

@engine(migrate_and_buy)

---

# Anti-Sniper

> Watch outside buyers after launch — if they grab too much, auto-sell everything or stop your buys.

Source: https://vortexdeployer.com/docs/tasks/anti-sniper · Markdown: https://vortexdeployer.com/docs/tasks/anti-sniper.md

**Anti-Sniper** watches the token from the moment it starts. If outside wallets cross a threshold, it acts at once: emergency-sell every task wallet, or stop your buying tasks. Add it on the Tasks step so it's armed at launch.

![An Anti-Sniper task.](https://vortexdeployer.com/docs/tasks/anti-sniper.png)

## Thresholds

- **Supply threshold** — outside holders' share of supply that triggers.
- **Spend threshold** — total outside buyers have spent.

Set one or both; whichever trips first fires.

## Action

- **Emergency sell all** — every task wallet market-sells its whole bag at the task's slippage (default 50 %, so it lands). **Keep dev wallet** spares Dev-role wallets. Built for speed: skips pre-send simulation and pays the **Priority fee** (default 5×) to land early in the next block, ahead of the sniper's exit.
- **Stop our buys** — stops your other buying tasks on this token; sells nothing.

## Window and exceptions

- **Monitor window** — auto-stop (no sell) after this many seconds.
- **Ignore buyers** — addresses that never count as snipers (partners, market makers). Your own wallets never count.

:::danger Slippage is deliberately high
An emergency sell that fails on slippage is worse than one that lands low. Lower the default only if you know the pool is deep.
:::

@engine(antisniper)

---

# Bundle

> Up to 24 wallets buy in one atomic Jito bundle — all land in the same slot or none do. Solana only.

Source: https://vortexdeployer.com/docs/tasks/bundle · Markdown: https://vortexdeployer.com/docs/tasks/bundle.md

**Bundle** buys from up to 24 wallets in one atomic Jito bundle: every buy lands in the same slot, or none do. It's the Solana launch buyer for the first block. (On Robinhood the [Snipe](https://vortexdeployer.com/docs/tasks/snipe) lands in the launch block on its own, so Bundle is Solana only.)

![A Bundle task.](https://vortexdeployer.com/docs/tasks/bundle.png)

## The simple part

The default form is just **Per-wallet SOL** (the exact buy of each wallet). Everything else sits under the **Advanced** fold with automatic defaults. A Bundle on the Tasks page buys for real — there's no Simulate. A launch simulation shows bundle packing, but cannot simulate wallet buys before the mint exists.

## Lookup tables (automatic)

There is **no lookup-table setting** — a status box under the wallet list handles it:

- **Up to 10 wallets** — fits on the platform table, nothing to set up.
- **More** — the box attaches your best existing table, or offers **Create lookup table** (rent ≈ 0.04 SOL, returned when you close it).
- Add wallets later and it offers **Extend lookup table**. Tip: create/extend **once, when you've finished picking wallets** — cheapest.
- The table is paid by the first selected wallet that can afford the rent.

How many wallets fit per bundle:

| Setup | Live token | At launch |
|---|---|---|
| No table | 5 | 4 |
| Platform table | 10 | 8 |
| Your own table | 15 (20 live, 24 with pre-made token accounts) | 8 |

First-time buys (the wallet's token account is created inside the buy) are heavy: at most **2 share a transaction**, so an all-first-time bundle fits 10 even with your own table. The status box words every cap as "up to X — fewer if the wallets have never bought this token".

## Modes

- **Buy (creates ATAs)** — token accounts are created inside the buy (default).
- **Pre-create ATAs only** — makes them ahead in batches of **ATA batch size**.
- **Buy (ATAs pre-made)** — assumes they exist; packs tightest.

**Wallets / tx** (1–8) caps how many buys share one transaction; a bundle is at most 5 transactions.

## At launch

Add a Bundle with **Auto-start** in the wizard and, on a SOL-quoted curve, it **rides the launch**: the create + dev buy is the first transaction of the Jito bundle and your wallets fill the other four — same slot or nothing. No buyer can land between the dev buy and your wallets; if the bundle doesn't land, the token isn't minted.

- The wizard card is the same form: pick wallets, type each one's SOL, or mount a [supply plan](https://vortexdeployer.com/docs/launch/tasks-step).
- Simulate shows the packing; the buys themselves can't be simulated before the mint exists.
- **Create** sends the bundle for real. Check the launch result for whether it landed.

**Curves quoted in a stock or USDC:** right before launch, each wallet swaps the SOL it needs into the quote through Jupiter (what it already holds counts first). If the launch doesn't land, every wallet is swapped back to SOL. A wallet short on SOL is **dropped with the reason** — it never stops the bundle; the launch is refused only when no wallet is left.

**USD1 LaunchLab curves** start at the mint instead (reserves can't be priced before the token exists) — create your table before launch so the bundle fires the instant the token lands.

## Advanced

- **Jito tip** — what the bundle pays to land, in lamports.
- **Fire if already live** — buy anyway if the token is already trading when the task starts.
- **Max wait** — how long to wait for the launch; 0 = no limit.
- **Confirm timeout**, **Slippage**, **Pre-swap slippage** (stock/USDC curves only).

:::info Simulation is not a landing guarantee
A launch's Simulate builds and checks every transaction, catching sizing and account errors. Whether a live bundle lands still depends on the tip and the slot.
:::

@engine(bundle)

---

# Hand Switcher

> Move supply from seller wallets to buyer wallets in bundled sell-and-buy pairs. Solana only.

Source: https://vortexdeployer.com/docs/tasks/hand-switcher · Markdown: https://vortexdeployer.com/docs/tasks/hand-switcher.md

**Hand Switcher** rotates supply between two sets of your wallets: **sellers** sell, the task's **buyers** buy, and each pair lands in one bundle. Buyers spend their own SOL. Solana only.

![A Hand Switcher task.](https://vortexdeployer.com/docs/tasks/hand-switcher.png)

## Wallets

Each side is picked one of three ways: **Custom wallets** (pick by hand), **Role wallets** (every wallet with a [role](https://vortexdeployer.com/docs/wallets/overview)), or **Role + custom**.

- **Sellers** — source of supply. With a role, the set is re-read every cycle, so wallets given the role later join in.
- **Buyers** — the task's own wallets; they need coin. **Min buyer SOL** (Advanced) skips poor buyers.
- A wallet on both sides only sells. An empty side stops the task before its first cycle.

## Sizing and pacing

- **Spend limit per buy** — largest single buy, per cycle. The matching sell is capped by the seller's holdings.
- **Min/Max SOL reserve** (Advanced) — random reserve each buyer keeps.
- **Min/Max delay** between cycles; **Max cycles** (0 = until sellers are empty).
- **Max supply per wallet** — skips buyers at the ceiling; a mounted plan sets it.
- **Advanced:** Jito tip, slippage, confirm timeout, max consecutive errors.

:::tip After a bundle
Add a Bundle and a Hand Switcher in the wizard, click **Use bundle wallets as sellers**, pick separate funded buyers, enable autostart, and set a finite cycle limit for a test.
:::

@engine(handswitcher)

Hand Switcher trades for real — there's no Simulate on the Tasks page. Added to a launch, it rehearses with the launch's Simulate.

Non-SOL quotes may need conversion transactions, kept in the same atomic bundle. A rehearsal checks each transaction on its own and can't carry a prior transaction's new quote balance forward, so a split route may report an unfunded leg even when the live atomic bundle would execute.

---

# Token Sender

> Distribute a token from source wallets to fresh or existing wallets.

Source: https://vortexdeployer.com/docs/tasks/token-sender · Markdown: https://vortexdeployer.com/docs/tasks/token-sender.md

**Token Sender** moves tokens you already hold. Create it from **New task**, or add it in a launch's Tasks step. Choose the token and the source wallets that hold it. It supports Solana and Robinhood Chain.

## Destinations

| Mode | What to choose |
|---|---|
| Auto-create | The task chooses how many fresh wallets to create from the available tokens and per-wallet range |
| Set count | Create up to the chosen wallet count, limited by available tokens |
| Existing wallets | Pick the recipients under **Receive tokens in** |

**Min per wallet** and **Max per wallet** are percentages of the token's total supply. They are not percentages of the source wallet's balance. **Set count** accepts 1–500 wallets.

## Funding and fees

For new wallets, set **Fund each new wallet** in the chain's native coin. **Funding wallet** chooses who pays that funding; Automatic uses the first eligible token source.

On Solana the funding wallet also pays token-account rent and transaction fees. On Robinhood, each token source pays its own transfer gas, so it needs ETH even when another wallet funds the recipients.

## Rehearse and inspect

Leave **Simulate** on to check the task first. Turn it off for real transfers. Inspect the task's **Results** and **Executions** for each transfer and any reason an item was skipped.

**Advanced** holds the batch size, delay between batches, delay jitter and error limit.

@engine(tokendisperser)

## See also

- [How tasks run](https://vortexdeployer.com/docs/tasks/overview)
- [Fund wallets](https://vortexdeployer.com/docs/wallets/fund)

---

# Mixer

> Move SOL or ETH through an exchange hop with Husher — fund many wallets from one order, or collect many without a shared order.

Source: https://vortexdeployer.com/docs/tasks/mixer · Markdown: https://vortexdeployer.com/docs/tasks/mixer.md

**Mixer** routes coin through a Husher exchange order (Binance, KuCoin or Bitget), so there's no on-chain link between source and destination. It isn't a task type under **New task** — it's a method you pick on the Wallets page, in **Fund** or **Collect**.

![Fund wallets with the Mixer method picked.](https://vortexdeployer.com/docs/tasks/mixer.png)

## Funding through the Mixer

In [Fund wallets](https://vortexdeployer.com/docs/wallets/fund), pick **Mixer** under **Method**. The modal runs in three steps:

1. **Wallets and amounts** — tick the wallets to fund, set **Total SOL to deposit** (or ETH) and the **Distribution**: **Equal**, **Custom** or **Variation**. **Per-wallet delays** sets how long the exchange holds each wallet's share before paying it out. Under **Fund from**, pick the **Deposit address** or one of your wallets — a wallet you're funding can't also be the source. The line at the bottom shows what each wallet gets before Husher's fee.
2. **Exchanges and holds** — each wallet gets its own exchange and hold time. **Randomize exchanges** and **Auto-distribute holds** spread them for you.
3. **Deposit** — pay the exact amount shown to the deposit address (or watch it go out from your wallet). The exchange then pays each wallet.

Each destination must receive at least 0.15 SOL or 0.01 ETH.

## Collecting through the Mixer

In [Collect funds](https://vortexdeployer.com/docs/wallets/collect), pick **Mixer (one order per wallet)**. Every source wallet opens its own Husher order paying the destination, so no shared order links the wallets. Husher's fee comes out of each deposit.

:::info Fees
No platform fee on Mixer orders. Husher takes its own fee out of the total.
:::

## See also

- [Fund wallets](https://vortexdeployer.com/docs/wallets/fund)
- [Collect funds](https://vortexdeployer.com/docs/wallets/collect)

---

# Wallet warm-up task

> Age wallets with buy → hold → sell cycles on live coins — the full engine form.

Source: https://vortexdeployer.com/docs/tasks/wallet-warmup · Markdown: https://vortexdeployer.com/docs/tasks/wallet-warmup.md

The **Wallet warm-up** engine ages wallets with buy → hold → sell cycles on live coins. The Warm up modal on the Wallets page is the short form; this task form exposes everything, including the repeat schedule and jitter. Every task wallet runs its own cycles.

![A Wallet warm-up task.](https://vortexdeployer.com/docs/tasks/wallet-warmup.png)

## Token source

- **Auto** — a different fresh coin per buy from recent launches: never one the wallet already warmed, never one already 1.5× its launch price. On Robinhood, from pons launches.
- **This task's mint only** — warm on the task's token.

## A cycle

- Each trade buys between **Min buy** and **Max buy**, holds between **Min hold** and **Max hold**, then sells.
- **Trades / cycle** trades spread over **Cycle duration** minutes.
- **Stop-loss** sells a held buy early if it drops that far below cost.

## Look like trading bots

Pick any of **Photon**, **Trojan**, **BullX**, **Axiom**: every warm-up buy and sell then also sends 10 lamports (0.00000001 SOL) to that bot's fee wallet, the same transfer those bots make, so the wallet's history reads as a trader using that bot. Each wallet sticks to one of the bots you picked, across every task. Pick none to turn it off. Solana only.

:::info Sells through a throwaway wallet aren't tagged
If **Sell through a temporary wallet** is on for this task, those sells are signed by a throwaway wallet that trades once — tagging it would label that wallet, not the wallet you're warming — so they go out untagged. The task's preview tells you how many of its wallets sell that way.
:::

## The schedule

- **Max cycles** — 0 runs until stopped.
- **Repeat interval** — hours between cycles; 0 is back-to-back.
- **Cadence jitter** and **Trade-count jitter** (Advanced) — randomize spacing and count by ± that percent.

:::warning Real trades, real fees
Every warm-up leg is a real swap paying the platform fee and gas. Size buys to what the wallet can afford across the whole schedule.
:::

@engine(warmup)

---

# Limit order

> Fire one buy or sell when the market cap crosses a level.

Source: https://vortexdeployer.com/docs/tasks/limit-order · Markdown: https://vortexdeployer.com/docs/tasks/limit-order.md

A **Limit order** waits for the market cap to cross a level, fires once from the task's wallets, and ends. Sell above = take-profit, sell below = stop-loss, buy below = accumulate, buy above = breakout chase. Stack several into a [Ladder](https://vortexdeployer.com/docs/tasks/ladder).

![A Limit order task's settings.](https://vortexdeployer.com/docs/tasks/limit-order.png)

New orders default to **All wallets**. The order uses the current wallets in this token's project, or your global pool for a task outside a project, on the token's chain when it triggers. Wallets added later are included automatically. Select **By role** to use all wallets carrying one of the chosen roles, including later additions and role changes. Neither option needs individual wallet selections. **Choose wallets** keeps a fixed selection.

Sells skip wallets with no tokens.

## The rule

- **Side** — Buy or Sell.
- **Market cap level** (USD) and whether it fires above or below.
- **Size** + **Size unit** — per wallet, per fire: coin, % of wallet balance, % of tokens held or % of supply.
- **Wallets to use** — with a custom selection, use Every wallet (default), Take turns, Random, Biggest/Smallest holder, or Richest.

## Timing

- **Start delay** (Advanced) — wait before the order may fire.
- **Lifetime** (Advanced) — ends this long after the start delay; empty = until it fires.
- **Max supply per wallet**, **Slippage**.

A Limit order trades for real — there's no Simulate. Size it small the first time.

## Reading the card

The **Orders** section shows the order's state: **Waiting** → **Fired** → **Ended**, with the live market cap in the header.

:::tip Market cap, not price
Levels are in USD market cap — what the chart and every launchpad show. The app converts with the live coin price at each check.
:::

@engine(limit_order)

---

# Ladder

> A stack of limit orders between two market caps — sell into a rise or buy into a dip.

Source: https://vortexdeployer.com/docs/tasks/ladder · Markdown: https://vortexdeployer.com/docs/tasks/ladder.md

A **Ladder** is 2 to 40 limit orders spread between a **From** and a **To** market cap. A sell ladder fires above each line as the market cap climbs; a buy ladder below each line as it falls. Each line fires once. The gentler alternative to [Sell all](https://vortexdeployer.com/docs/terminal/sell-all).

![A Ladder task's settings.](https://vortexdeployer.com/docs/tasks/ladder.png)

## The lines

- **Side** — Buy or Sell.
- **From** / **To** (market cap) — first and last line; To must be above From.
- **Lines** — how many, both ends included.
- **Spacing** — **Even dollars** or **Same % step**.

## Size and wallets

- **Size per line** + **Size unit** — same sizing for every line, per wallet.
- **Wallets per fire** — which wallets fire each line.

With **% of tokens held**, later lines sell a share of what's left — a 4-line ladder at 25 % never empties the bag. Use **% of supply** or 100 % on the last line to finish.

## Timing and guards

Same as a Limit order: **Start delay**, **Lifetime**, **Max supply per wallet**, **Slippage**. A Ladder trades for real — there's no Simulate.

## Reading the card

The **Orders** section lists every line with its level, state and fire count. Lines already passed when the task starts fire immediately on a sell ladder — so start a sell ladder below the market and a buy ladder above it.

@engine(ladder)

---

# Mirror

> Answer other people's trades — buy their sells, sell into their buys.

Source: https://vortexdeployer.com/docs/tasks/mirror · Markdown: https://vortexdeployer.com/docs/tasks/mirror.md

**Mirror** reacts to strangers' trades on the token: a sell-side mirror sells into their buys, a buy-side mirror buys their sells. Each answer comes from one of the task's wallets, sized as a share of the trade it answers or a fixed size.

![A Mirror task.](https://vortexdeployer.com/docs/tasks/mirror.png)

## What it answers

- **Side** — Buy or Sell (what your wallet does).
- **Answer odds** — share of external trades answered; the rest are skipped at random so the response isn't mechanical.
- **Batch below** — smaller trades are accumulated and answered together, so tiny trades never spawn dust legs.
- **Ignore traders** — addresses never mirrored; your own wallets are always ignored.

## Size

- **Size unit** — **% of the trade** (default), coin per wallet, % of wallet balance, % of tokens held or % of supply.
- **Size** — 100 with % of the trade answers a 0.5 SOL buy with a 0.5 SOL sell.
- **Wallets per fire**.

## Limits

- **Zone from** / **Zone to** — armed only while the market cap is in range.
- **Budget** — the most the task may spend (buys) or receive (sells).
- **Max fires**, **Start delay**, **Lifetime**, **Max supply per wallet**, **Slippage**.

:::warning A mirror can empty a wallet
With no budget and 100 % of the trade, a run of large buys makes your mirror sell everything. Set a Budget or Max fires.
:::

@engine(mirror)

---

# DCA

> Buy or sell on a timer, optionally jittered, inside a market-cap zone and under a budget.

Source: https://vortexdeployer.com/docs/tasks/dca · Markdown: https://vortexdeployer.com/docs/tasks/dca.md

**DCA** fires on a clock: every interval, one of the task's wallets buys or sells a fixed size. Add jitter so fires don't land on the minute, a zone so it only runs inside a market-cap range, and a budget or fire count so it ends on its own.

![A DCA task.](https://vortexdeployer.com/docs/tasks/dca.png)

## The timer

- **Side** — Buy or Sell.
- **Every** — interval between fires.
- **Jitter** — ± this much on every interval.

## Size and wallets

- **Size** + **Size unit** — per wallet, per fire.
- **Wallets per fire** — **Take turns** rotates; **Every wallet** fires all of them each tick.

## Limits

- **Zone from** / **Zone to** — armed only in range; outside it the timer counts but nothing fires.
- **Budget** — the most to spend (buys) or receive (sells).
- **Max fires**, **Start delay**, **Lifetime**, **Max supply per wallet**, **Slippage**.

:::tip A slow exit
A sell DCA at 5 % of tokens held every few minutes with Every wallet leaves a position quietly. Combine with a sell [Ladder](https://vortexdeployer.com/docs/tasks/ladder) above for the upside.
:::

@engine(dca)

---

# Trailing stop

> Sell when the market cap pulls back a set percentage from its peak.

Source: https://vortexdeployer.com/docs/tasks/trailing-stop · Markdown: https://vortexdeployer.com/docs/tasks/trailing-stop.md

A **Trailing stop** follows the market cap up and sells when it falls a set percentage from the highest point since the task armed. It locks in a rise without picking a top.

![A Trailing stop task.](https://vortexdeployer.com/docs/tasks/trailing-stop.png)

## The trail

- **Drop from peak** — sell when the market cap falls this much from the peak.
- **Arm above** — the peak must reach this level before the trail counts; empty trails from the start.

## Size and wallets

- **Size** + **Size unit** — % of tokens held or % of supply, per wallet.
- **Wallets per fire**.

## Limits

**Zone from** / **Zone to**, **Budget**, **Max fires**, **Start delay**, **Lifetime**, **Max supply per wallet**, **Slippage**.

## Reading the card

The **Orders** section shows the peak and the current drop. A trailing stop sells for real when it fires — there's no Simulate, so tune the drop percentage on a small size first.

:::info Peak resets per run
Run again starts a fresh peak from that moment's market cap. Stop and Start re-arms after a fire.
:::

@engine(trailing_stop)

---

# Scheduled launch

> The task that holds a launch until its time and fires it on its own.

Source: https://vortexdeployer.com/docs/tasks/scheduled-launch · Markdown: https://vortexdeployer.com/docs/tasks/scheduled-launch.md

A **Scheduled launch** is what the wizard creates when you set **Launch at**. The whole launch — mint, dev buy, every launch task — fires at that instant without you being there. It appears on the Tasks page like any other task.

![A Scheduled launch task waiting.](https://vortexdeployer.com/docs/tasks/scheduled-launch.png)

## Options

- **Launch at** — the instant to mint (30 seconds to 30 days ahead), set from the wizard.
- **Simulate** — follows the launch: on for a rehearsal, off for a real launch.

Nothing else to configure — the launch it holds was configured in the wizard.

## Before it fires

- **Stop** or **Delete** cancels the launch; the project goes back to a resumable draft.
- **Edit** the project (Resume on its card) to change the launch; the task picks the changes up.
- Fund the wallets before it fires — the card's **Simulate** section shows what the launch would do from live balances.

## When it fires

Exactly like a manual **Create**: terminal opens (if you're on the app), launch tasks start, the project card moves to **Deployed**. If it fails (drained wallet, launchpad error), the task is **FAILED** with the reason and nothing else fires.

:::info Fires without your browser
Times are your local time zone. The launch fires whether or not the tab is open.
:::

@engine(scheduled_launch)

---

# XID feed

> Live X/Twitter monitoring of a shared account catalog, with a Deploy button on every post.

Source: https://vortexdeployer.com/docs/xid/feed · Markdown: https://vortexdeployer.com/docs/xid/feed.md

**XID** is the app's X/Twitter monitor. A shared catalog of ~900 accounts is watched around the clock; every post, follow or profile change lands in your **feed** within seconds, and each post carries a **Deploy** button that opens the create wizard with the post as the token. Three tabs: **Feed**, **Accounts**, **Settings**. The footer's **XID** button opens the feed as a side column on any page.

![The XID feed.](https://vortexdeployer.com/docs/xid/feed.png)

## Feed

- Header: **Live** status, posts shown, and your **accounts enabled** count.
- Each post card: avatar, name, handle, event type, text, media, and **Deploy**.
- **Vamp** in the header opens [Clone a token](https://vortexdeployer.com/docs/launch/clone-token) without leaving the feed.
- **Pause on hover** (Settings → Feed) stops the feed moving under your mouse.

Posts aren't stored — the feed shows what arrived while it was open, newest first.

## Accounts

The catalog is shared; you control what reaches **your** feed.

- Sort by **Newest**, **Enabled first** or **A–Z**.
- **Enable all** / **Disable all**, or toggle per account — with per-account **event type** choices.

## Settings

- **Auto-enable new accounts** — off means only accounts you explicitly enabled reach you.
- **Global event filter** — Posts, Following, Profile updates, OCR, Translation. Per-account choices override it.
- **Notifications** — sound, volume, **CA detection** (alerts on posts containing an address or ticker), and per-account custom notifications. Notifications follow your account; feed settings are per device.

:::info Shared catalog, personal view
Toggling an account changes only your feed. To add an account to the catalog, ask via [Support](https://vortexdeployer.com/docs/account/support).
:::

## See also

- [Deploy from XID](https://vortexdeployer.com/docs/xid/deploy)

---

# Deploy from XID

> Turn a post into a token in two clicks.

Source: https://vortexdeployer.com/docs/xid/deploy · Markdown: https://vortexdeployer.com/docs/xid/deploy.md

Every post in the feed can become a launch. Nothing launches on its own — each shortcut opens the [create wizard](https://vortexdeployer.com/docs/launch/create-project) pre-filled, and the launch still needs your **Create**.

![A post with the Deploy chip.](https://vortexdeployer.com/docs/xid/deploy.png)

## Three ways in

- **Deploy** on the card — wizard opens with the post's first words as name/symbol and its image as the token image.
- **Double-click deploy** — double-click one word: that word becomes name and symbol.
- **Selection deploy** — select text and a **Deploy** chip appears for it.

The last two are toggles under Settings → Deploy.

## What the wizard starts with

Settings → Deploy controls the pre-fill:

- **Platform** — the launchpad pre-selected (falls back to the first tile if paused).
- **Launch mode** — seeded tasks: **Dev buy only**, **Bundle**, **Snipe** or **Bundle + Snipe**. You still pick wallets and amounts.
- **After deploy** — open the terminal or stay on the feed.
- Plus your Quick deploy defaults (creator wallet, dev buy, creator fees) from [Settings](https://vortexdeployer.com/docs/account/settings).

## Speed

Deploy → check name/image → wallets pre-filled → Review → Simulate → Create. With warmed, funded wallets and a saved profile: well under a minute. [Quick deploy](https://vortexdeployer.com/docs/launch/quick-deploy) is faster still.

:::tip Simulate first
The wizard opened from XID works like any other: **Simulate** rehearses the launch and its tasks, **Create** sends it.
:::

## See also

- [XID feed](https://vortexdeployer.com/docs/xid/feed)
- [Create a project](https://vortexdeployer.com/docs/launch/create-project)

---

# Dashboard

> Balances, launch outcomes, portfolio performance and the live Mooners feed.

Source: https://vortexdeployer.com/docs/account/dashboard · Markdown: https://vortexdeployer.com/docs/account/dashboard.md

The **Dashboard** puts account totals above a performance chart and the live **Mooners** feed. Choose a chain or the combined view to set their scope.

![Dashboard balances, performance and Mooners. Example account.](https://vortexdeployer.com/docs/account/dashboard.png)

## Cards

- **Native Balance** — SOL/ETH held in your wallets. Token holdings are separate; use **View token holdings** to open your portfolio. The eye button hides the balance and performance amounts.
- **Total P&L** — current all-time result across recorded traded positions: trade cash received minus spent, plus estimated proceeds from selling remaining tokens. If some held tokens cannot be priced, the card becomes **Estimated P&L**: all trade costs and proceeds remain included, but unpriced holdings add no value. Missing trade records or an unavailable holdings inventory still show **—**.
- **Tokens Launched** — distinct real launches in your projects, excluding drafts, simulations and imported/CTO projects. Drafts and scheduled launches appear underneath.
- **Tokens Migrated** — confirmed migrations among your eligible curve launches. A confirmed migration stays counted after liquidity is removed. Older migrations without recorded confirmation are shown as **unverified**, rather than assumed successful from an AMM pool alone.

## Performance

The selected view changes the headline number and its scope:

- **Balance** shows your current native balance, sampled history and change since the first sample in the selected window. Deposits, withdrawals and trades all change this balance.
- **Net Flow** shows trade cash received minus spent over the selected 7, 30 or 90 UTC days. It is not profit. The calendar and share buttons belong to this view.
- **P&L** keeps the original dated line with 7/30/90-day controls. The line shows cumulative trade cash over the selected period; the headline separately shows current all-time position P&L, including priced holdings.

All-chains figures convert each chain using its current exchange rate. They are not historical USD valuations. Missing prices or incomplete accounting leave combined totals unavailable.

## Mooners

The feed shows observed launches from the last 24 hours that reached **8× or more within their first 10 minutes**, with at least **$500 in verified real quote-side liquidity**. A peak multiple is a past spot-price move in the launch quote, not a current return or sell quote.

Choose **Newest** or **Highest peak**. Click a token to trade it, copy its address, or expand its details for description, creator and launch links. Social and explorer links appear where available. **Live**, **Connecting** or **Unavailable** shows the feed's connection state.

## Continue from the Dashboard

Use **Projects** to compare and open your launches, **Tasks** for automation, and [Operations](https://vortexdeployer.com/docs/account/operations) for saved conversions and closeouts. New accounts also see guided starting steps for launching, trading or managing wallets.

## See also

- [Portfolio](https://vortexdeployer.com/docs/account/portfolio)
- [Find your way around](https://vortexdeployer.com/docs/overview/workspace)

---

# Portfolio

> Trading cash, holdings at exit quote, accounting explanations and CSV exports.

Source: https://vortexdeployer.com/docs/account/portfolio · Markdown: https://vortexdeployer.com/docs/account/portfolio.md

**Portfolio** is the accounting view: what every wallet holds, what your recorded trades received minus spent, and what open bags are worth if sold now. One chain at a time.

![Portfolio totals and Explain & export. Example account.](https://vortexdeployer.com/docs/account/portfolio.png)

## Tiles

- **Total held** — coin across every wallet.
- **Realized P&L** — native coin received from recorded landed sells minus native coin spent on buys. This trade-cash figure includes the cost of tokens you still hold.
- **Trades landed** — on-chain buys and sells.
- **Active wallets** — wallets that traded.

## Total position P&L

`realized + bags = total`:

- **Realized** — trade cash from recorded landed fills, with fees already included. **Explain & export** shows how many fills have exact accounting evidence.
- **Bags** — valued at their **full-bag sell quote**: what selling everything now returns after price impact and fee. Never spot price × bag size.

## Realized trading

Spent on buys, received on sells, tokens traded, holders funded, **Net realized**. Dry-run and simulated trades excluded everywhere.

## By wallet

Every wallet with role and live balance, sorted by balance. Click a row to open it on the Wallets page.

## Explain and export

Press **Explain & export**, or the realized P&L number, for a frozen snapshot of the view you opened. It shows the chain and wallet scope, spending, sale proceeds, remaining holdings, fees, evidence count and valuation status.

- **Export this summary** downloads the snapshot as CSV. Native amounts are in base units; the export includes the chain's decimals.
- **Recorded trade receipts** links fills to their on-chain transactions. Use **Load older receipts** for more, then **Export loaded receipts** to download the loaded rows.
- Receipt rows help trace the result. Recovered accounting adjustments are also part of the totals, so raw receipts are not a second P&L calculation.

Fees shown are already included; do not subtract them again. Deposits and withdrawals are not trading profit. If holdings inventory is incomplete or a held token cannot be valued, the portfolio total stays unavailable.

:::info Compare the same scope
The terminal can show project wallets while Portfolio covers account trading, including historical managed wallets and excluding the platform trader pool. The Dashboard can combine chains and show an estimated total when some holdings lack prices. Compare chain, wallets, time window and valuation status before comparing figures.
:::

## See also

- [Wallets overview](https://vortexdeployer.com/docs/wallets/overview)

---

# Operations

> Follow saved conversions and closeouts, inspect receipts and stop queued work.

Source: https://vortexdeployer.com/docs/account/operations · Markdown: https://vortexdeployer.com/docs/account/operations.md

Open **Operations** from the account menu or workspace search. Conversions and project closeouts are saved to your account: you can close the dialog or tab and return from another device.

![Operations with a saved project closeout. Example account.](https://vortexdeployer.com/docs/account/operations.png)

## Find a queue

Choose **All queues**, **Needs attention** or **Completed**. **Older queues** loads earlier work; **Newest** returns to the latest page. Simulations carry a **Simulation** label.

Open a row for its progress, per-item results and transaction links. Closeouts also link the sweep task when one was created. Keep the **Operation reference** if you need support.

## Read the status

| Status | Meaning |
|---|---|
| Queued | Waiting to start |
| In progress | Work has started |
| Awaiting confirmation | A submitted result is still being checked |
| Completed | The item or queue finished |
| Needs attention | Review the detail and any receipt before taking another action |
| Stopped | Remaining work was stopped |

**Check status** reloads the saved result. A lost connection does not mean a transaction failed.

## Stop or continue

**Stop remaining items** prevents queued items from starting. Work already started may still finish.

**Continue remaining items** is offered when a queue needs attention and still has queued items. It skips items needing attention and starts only the remaining queued items. It does not retry the affected transaction. Review its receipts before creating another operation.

A queue accepts up to **100 items**. An account can have up to **five active queues**.

## Launches, trades and automation

The lower section links the latest 100 tasks, including launch, trade and wallet activity. Open a task for per-wallet execution history, or **All tasks** to find older work.

## See also

- [Convert tokens](https://vortexdeployer.com/docs/wallets/overview#convert)
- [Close out](https://vortexdeployer.com/docs/launch/close-out)
- [Notifications](https://vortexdeployer.com/docs/account/notifications)

---

# Notifications

> An account inbox for operation, task and marketplace updates, with optional delivery.

Source: https://vortexdeployer.com/docs/account/notifications · Markdown: https://vortexdeployer.com/docs/account/notifications.md

Open **Notifications** from the account menu or workspace search. Each update links to the operation, task or marketplace order it concerns. The inbox and read state are saved to your account.

![Notifications and delivery preferences. Example account.](https://vortexdeployer.com/docs/account/notifications.png)

## Read updates

- Open an update to follow its link and mark it read.
- **Unread only** filters the inbox; **Show all** brings read updates back.
- **Mark these and older read** marks updates through the newest one in the current view.
- **Older** loads earlier updates; **Newest** returns to the latest page.

Support conversations have their own inbox. Use **Open support conversations** to read or reply to support.

## Delivery preferences

Delivery is optional. Updates remain in the inbox even if delivery is off or fails.

| Channel | Requirements |
|---|---|
| Browser notifications | Enable delivery, allow permission on this device, and keep an app tab open |
| Telegram notifications | A Telegram-linked account, an available server bot and delivery enabled |

Telegram can deliver while the app is closed. If the button is disabled, the page explains which requirement is missing. A delivery that has not been confirmed is not proof that the underlying operation failed; open the update for its saved result.

## See also

- [Operations](https://vortexdeployer.com/docs/account/operations)
- [Support](https://vortexdeployer.com/docs/account/support)

---

# Settings

> Account-synced preferences, display density, named configurations and trading defaults.

Source: https://vortexdeployer.com/docs/account/settings · Markdown: https://vortexdeployer.com/docs/account/settings.md

Settings holds your profile, trading presets, Quick deploy defaults and supply plans. Trading and deployment preferences now save to your account and follow you across devices.

![Your workspace settings and account save status. Example account.](https://vortexdeployer.com/docs/account/settings.png)

## Your workspace

- **Display density** — choose **Compact** or **Comfortable**.
- **Save status** — wait for **Saved to your account**. If synchronization needs attention, changes remain on this device; use **Sync now** to retry.
- **Changes from another device** — choose **Use account version** or **Keep this version** for each conflict.
- **Named configurations** — save your currently saved trading and deployment settings together. Give the configuration a name, then **Save configuration**. **Load** sets it as your active defaults; it does not launch or trade. You can keep up to 20 configurations.
- **Reload forms from saved settings** — refresh the forms after loading or resolving settings.

If this browser contains older local presets, **Import this browser’s old settings** lets you bring them into the current account. Import only settings that belong to you.

## Profile

- **Display name**, **Username**, **Provider**, **Account ID**.
- **Change web credentials** — username (3–24 chars) and password (8+) for [Sign in with Vortex](https://vortexdeployer.com/docs/overview/sign-in), once web login is enabled (ask via [Support](https://vortexdeployer.com/docs/account/support)). Changing the password signs out every other session.

## Trading

- **Trading presets** — Preset 1 · 2 · 3, three independent sets. The active preset is what the Trade panel trades with, and it shows in the panel's footer. Each carries **Buy amounts** (per chain) and **Sell sizes (%)**; **Reset this slot to defaults** restores one.
- **Default slippage (bps)**.
- **Randomize** — small random band on chip sizes so fills differ.
- **Confirmations** — **Confirm dev trades** and **Confirm Sell all** (off by default).

## Sell through another wallet

*Fresh wallet → sell → return proceeds.*

- **Off** — sells go out from the wallet that holds the tokens.
- **All sells** — try a temporary wallet for every sale.
- **Custom** — pick case by case. **Manual sells**: Simple sell, Unique wallet sell (quick sells on a wallet row), Percentage sell (from the Trade panel), Sell all, Sell all except dev, Sell dev, Trade panel (fixed-amount sells). **Task types**: Volume, Anti-Sniper, Limit order, Ladder, Mirror, DCA, Trailing stop.

Press **Save sell setting**.

How it works:

- **Solana** — the first transaction sends 0.01 SOL and the tokens to a temporary wallet; the second sells and returns everything. A failed sale retries from the same temporary wallet. The extra transactions pay network fees.
- **Robinhood** — each temporary sale uses a new selling contract and may need a token approval first.

If the optional setup needs more funds than the source has, or its fee check, configuration or route is unavailable, the app tries a normal sale from the source wallet. Your saved setting stays on. The normal sale still needs enough funds for its own network fees and must meet your slippage limit.

Once a transaction has been submitted, its result is tracked before any retry. Tokens already moved to a temporary wallet stay on that wallet's recovery path.

## Quick deploy

What [Quick deploy](https://vortexdeployer.com/docs/launch/quick-deploy) fires with and the wizard starts from:

- **Launchpad · quote · mode** — venue, quote coin, creator fees (recipient, **Tax** up to 10 %, **Buyback**).
- **Default dev wallet**, **Dev buy**, and the **launch tasks** that auto-start at the mint.

## Supply plans

Named **% of supply** presets for the supply calculator: slots with a percent each, **Even split**, and per slot which wallet **role** may take it (or a pinned wallet). A plan is percentages only — it mounts on any launch. See [Tasks step](https://vortexdeployer.com/docs/launch/tasks-step).

:::tip Keep the dev wallet out of the Snipe
Give slot 1 the **Dev** role and the rest **Trading (no role)**. Mounted on a Snipe, the dev slot becomes the launch's **Dev buy** and the Snipe gets only no-role wallets — so the dev never takes one of the 31 launch-buyer places on Robinhood.
:::

## See also

- [My profile](https://vortexdeployer.com/docs/account/profile)
- [Sell all](https://vortexdeployer.com/docs/terminal/sell-all)

---

# My profile

> Your account at a glance: identity, P&L, launches, wallets, web login.

Source: https://vortexdeployer.com/docs/account/profile · Markdown: https://vortexdeployer.com/docs/account/profile.md

**My profile** (avatar menu) is the one-page summary of your account, all live numbers.

![My profile.](https://vortexdeployer.com/docs/account/profile.png)

## Identity

Display name, username, sign-in provider, account ID. Edit these in [Settings](https://vortexdeployer.com/docs/account/settings).

## Tiles

- **Net P&L** — realized, both chains.
- **Launches** — tokens that reached a chain.
- **Wallets** — your pool size.

Each tile links to its page.

## Fees

Your current platform fee and progress to the next reduction (starts at 1 %, falls to 0.4 %) — see [Fees](https://vortexdeployer.com/docs/overview/fees).

## Web login

- **Unlocked** + **Set credentials** button once web login is enabled for your account (ask via [Support](https://vortexdeployer.com/docs/account/support)).
- Otherwise: sign in with Telegram.

## Support

Link to the [Support](https://vortexdeployer.com/docs/account/support) inbox — every ticket and its replies.

## See also

- [Sign in](https://vortexdeployer.com/docs/overview/sign-in)

---

# Support

> Tickets, bug reports and feature requests — and how replies reach you.

Source: https://vortexdeployer.com/docs/account/support · Markdown: https://vortexdeployer.com/docs/account/support.md

Every message to the team is a **ticket** in the **Support** inbox (opened from the profile page or avatar menu). The footer's **Bug** and **Suggest** buttons file the two special kinds from anywhere.

![The Support inbox.](https://vortexdeployer.com/docs/account/support.png)

## The inbox

- **New** — **Support**, **Request** or **Bug**, with subject and details.
- Filters by kind and status: **Open**, **In progress**, **Resolved**, **Closed**.
- Pick a ticket to read the thread and reply. Team replies show on the ticket and in the top bar's bell.

## Bug reports

**Bug** in the footer → **Report a bug**. Say what you did, what you expected, what happened — with the task number or token if there is one. The report carries the page you were on.

## Feature requests

**Suggest** in the footer → **Request a feature**. Requests are read; the changelog on the Docs home lists what shipped.

:::tip Include the task number
Every task card shows `#id` — a ticket with the number lets support look at that exact run.
:::

## See also

- [My profile](https://vortexdeployer.com/docs/account/profile)

---

# Best practices

> What experienced launchers do — warm wallets, fund privately, rehearse, size against the curve, exit in steps.

Source: https://vortexdeployer.com/docs/other/best-practices · Markdown: https://vortexdeployer.com/docs/other/best-practices.md

None of this is required. All of it separates a launch that reads as organic from one that reads as a bot.

## Before the launch

- **Warm every wallet that will buy.** A wallet whose first transaction is your snipe is a red flag. Run [Warm up](https://vortexdeployer.com/docs/wallets/warm-up) a day or two ahead; give the dev a **Dev warmup**.
- **Fund through hops, not from one wallet.** Use [Fund wallets](https://vortexdeployer.com/docs/wallets/fund) with Disperse or the Mixer — wallets funded from one source look like one wallet to an explorer.
- **Use a supply plan.** Decide % of supply per role once, mount it on the Tasks step, let the calculator size the snipe.
- **Rehearse.** Run the launch once with **Simulate** and read each task's **Results**. Then go live. Tasks that always trade for real (Volume, the order tasks) — start them small.

## At launch

- **Simulate before Create.** A clean simulation is cheap; a reverted launch is not.
- **Arm an Anti-Sniper** so outside snipers don't make you the exit liquidity.
- **Keep the dev bag visible** — that's what Sell all (excl dev) is for.

## After launch

- **Exit in steps.** A sell [Ladder](https://vortexdeployer.com/docs/tasks/ladder) or [DCA](https://vortexdeployer.com/docs/tasks/dca) leaves a chart buyers stay on; Sell all leaves a cliff.
- **Rotate hands.** [Hand Switcher](https://vortexdeployer.com/docs/tasks/hand-switcher) moves the launch bag into warmed wallets.
- **Collect through the Mixer** — never straight to an exchange deposit address.

## Every day

- **Export nothing you don't need to.** A key that left the app can leak.
- **Read the [fees page](https://vortexdeployer.com/docs/overview/fees) once** — the fee falls as you trade, and sizing always leaves a wallet able to sell.

## See also

- [Glossary](https://vortexdeployer.com/docs/other/glossary)

---

# Glossary

> The words the app uses, in one place.

Source: https://vortexdeployer.com/docs/other/glossary · Markdown: https://vortexdeployer.com/docs/other/glossary.md

| Term | Meaning |
|---|---|
| **Bonding curve** | The launchpad's pricing contract before a token migrates to a DEX pool. Price rises with every buy. |
| **Bundle** | Several transactions submitted to land together in one slot, all or nothing. Solana, via Jito. |
| **Creator fees** | On pons: the share of every trade paid to the creator wallet or holders, with optional tax and buyback. |
| **CTO** | Taking over an existing token: a project on its mint, run with your own wallets. |
| **Dev wallet** | The wallet that mints the token. Its buy in the create transaction is the **dev buy**. |
| **Dry run / Simulate** | Building and checking every action without sending anything. Launches and some tasks and wallet tools have it; the order tasks, Volume and the other market-making tasks always trade for real. |
| **Exit quote** | What selling a whole bag now would return after price impact and fee. The app's only valuation of open bags. |
| **Fill** | One landed buy or sell, recorded with its exact delta and fee. |
| **Folder** | A label grouping wallets on the Wallets page. A wallet is in at most one. |
| **Global pool** | Every wallet you own that wasn't created inside a project. |
| **Husher** | The exchange-hop service behind the Mixer. |
| **Jito tip** | What a Solana bundle pays a validator to land. |
| **KOL** | A known trader wallet you track; its trades are marked on the chart. |
| **Launchpad** | The venue a token is created on: pump.fun, LaunchLab, Bonk, Bonkers, Bags (Solana); pons (Robinhood). |
| **Limit order** | A buy or sell that fires once when the market cap crosses a level. |
| **Market cap** | Price × total supply, in USD. Every level in the app is a market cap. |
| **Migration** | The moment a curve token moves to a DEX pool (PumpSwap, Raydium, DAMM v2). |
| **Mixer** | Routes coin through a Husher exchange order so deposits and destinations are unlinked on chain. |
| **Nonce hop** | Vortex Disperse's private funding route: deposit → throw-away wallet → hop → temporary layer → destination. |
| **Pair token** | A non-ETH quote on pons: USDG or a stock token. Buyers must hold it. |
| **Play** | One rule inside a Limit order, Ladder, Mirror, DCA or Trailing stop task. |
| **Preset** | One of three saved sets of buy chips, sell chips and slippage for the Trade panel. |
| **Project** | One launch: its token, wallets, tasks, and its draft before launch. |
| **Quote** | The coin a token is priced in: SOL or USDC on Solana; ETH, USDG or a stock token on pons. |
| **Results** | The story of a task's last run on its card: timeline plus what every wallet did or why it did nothing. |
| **Role** | A wallet's label: Dev, Trading, Holder, Sniper, Bundle, Fee, Temp. |
| **Run** | One Start-to-end of a task. Run again starts a new one. |
| **Slippage** | The price move a swap tolerates before it reverts, in basis points (100 bps = 1 %). |
| **Snipe** | A Buy that fires the instant the token is live; on pons in the launch block. |
| **Supply plan** | A named preset of % of supply per slot that mounts on a launch to size the buys. |
| **Sweep** | A direct on-chain transfer of a wallet's coin to a destination. |
| **Vamp** | Cloning another token's name, symbol, image and socials into your launch. |
| **Warm-up** | Giving a wallet a history of buys, holds and sells on live coins before it's used. |
| **XID** | The X/Twitter monitor and its Deploy shortcuts. |

## See also

- [Welcome](https://vortexdeployer.com/docs/overview/welcome)