Skip to main content
Burst enforces deployment limits through multiple layers at once. Anyone can deploy tokens. But deployment is constrained by both:
  • cost,
  • and throughput limits tied to account identity.
This keeps access open while making spam and bot flooding much harder.

​
Core model

Burst combines:
  • a fixed deployment cost of 0.1 SOL,
  • per-account rate limiting,
  • execution wallet enforcement,
  • and protocol-level validation before launch.
Burst does not rely on one anti-spam switch.It combines economic cost, account binding, and execution controls.

​
Why it exists

Open launch systems fail when token creation becomes too cheap to abuse. Spam deploys do more than clutter a feed. They fragment discovery. They dilute liquidity quality. They make real launches harder to identify. Burst tries to keep token creation open without letting deployment throughput become unbounded.

​
Enforcement model

1

Validate the wallet

The deployment must come from the user’s assigned execution wallet.
2

Check fee payment

The required deployment cost must be paid before launch is accepted.
3

Apply account limits

Burst checks rate limits, cooldowns, and risk signals tied to the account.
4

Check system capacity

Global throttles can delay or reject launches during heavy load.

​
1. Deployment cost

Each token deployment requires 0.1 SOL paid at creation. This is the first economic filter. It helps:
  • prevent zero-cost spam,
  • introduce real capital cost to mass deployments,
  • and align deployers with some minimum level of intent.
Cost alone is not enough. That is why Burst adds execution and throughput controls on top.

​
2. Execution wallet enforcement

All deployments must originate from the user’s Burst-issued execution wallet. That means:
  • users cannot deploy from arbitrary wallets,
  • deployments tie back to a single account identity,
  • and multi-wallet spam becomes harder to scale.
This is enforced before the deployment is accepted.

​
3. Per-account rate limiting

Each Burst account is subject to deployment throughput limits. Burst applies this as a rolling time window rather than fixed intervals. That means:
  • small bursts can still be allowed,
  • but sustained rapid deployment gets blocked.
This helps stop:
  • bot loops,
  • scripted mass launches,
  • and rapid identity flooding.

​
4. Deployment cooldown

After each deployment, Burst can apply a short cooldown period. This prevents back-to-back launches from running indefinitely. It also means even well-funded attackers cannot flood instantly. Cooldowns can be:
  • fixed,
  • or adjusted dynamically based on system conditions.

​
5. Global throughput limits

Burst also enforces a system-wide deployment ceiling. This protects core infrastructure during spikes. That includes:
  • indexing systems,
  • merge layer processing,
  • metadata resolution,
  • and Meteora pool creation flow.
If the system is under heavy load:
  • deployments can be throttled,
  • delayed,
  • or rejected.

​
6. Identity and behavior correlation

Burst does not enforce limits purely by wallet address. It correlates behavior across:
  • execution wallet,
  • account identity,
  • funding source,
  • and device or session signals.
This helps Burst:
  • detect multi-account spam,
  • apply shared limits across linked identities,
  • and restrict abusive deployment patterns that simple wallet limits would miss.

​
Market pressure

Open access remains

Anyone can still launch a token.Burst does not gate creation behind manual approval.

Abuse gets more expensive

Mass deployment requires money, account throughput, and clean behavior.

​
Technical enforcement flow

Before a deployment is accepted, Burst validates the request at the protocol layer.
validateDeployment.ts
async function validateDeployment({ userId, wallet }) {
  if (!isExecutionWallet(userId, wallet)) {
    throw new Error("invalid_wallet")
  }

  if (!hasPaidDeploymentFee(wallet, 0.1 * SOL)) {
    throw new Error("fee_not_paid")
  }

  if (isRateLimited(userId)) {
    throw new Error("rate_limited")
  }

  if (isInCooldown(userId)) {
    throw new Error("cooldown_active")
  }

  if (isGloballyThrottled()) {
    throw new Error("system_busy")
  }

  if (!riskEngine.allows(userId)) {
    throw new Error("deployment_blocked")
  }

  return true
}
This check runs before token creation. That makes the limits enforceable upstream, not just through the UI.

​
Practical effect

Burst keeps creation open. But it prevents low-cost, high-frequency spam from overwhelming discovery. Legitimate creators get a cleaner venue. Traders get better signal density. And the platform avoids turning token deployment into a pure throughput game.