> For the complete documentation index, see [llms.txt](https://docs.antivamp.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.antivamp.io/for-launchpads/overview.md).

# Partner Overview

How a launchpad integrates AntiVamp — validate every launch, verify the signed decision, report lifecycle events, and process webhooks.

As an integrated launchpad you are the enforcement point of the AntiVamp network. Before you deploy a token or mint, you ask AntiVamp whether the creator’s normalized **Name + Ticker** is clear, receive an **Ed25519-signed decision**, and only proceed when that decision says so.

Because the registry is shared, protection earned on one launchpad is honored on all of them — a copycat cannot hop venues to slip a look-alike through.

## Overview

|                               |                                                                                       |
| ----------------------------- | ------------------------------------------------------------------------------------- |
| **Your job**                  | Validate at commit time, verify the signature, enforce server-side, report the launch |
| **Authority**                 | Shared on-chain registry + signed API decisions                                       |
| **Failure mode**              | Fail closed — no fresh verified `allow` means do not launch                           |
| **What you do not vouch for** | Price, contract security, or legitimacy of the token                                  |

{% hint style="danger" %}
Integrating the API is not enforcement. Every launch path must gate on a verified decision. See the [Production Enforcement Guide](/for-launchpads/enforcement-guide.md).
{% endhint %}

## How a protected launch works

|        | Step         | What you do                                                                                                                       |
| ------ | ------------ | --------------------------------------------------------------------------------------------------------------------------------- |
| **01** | **Validate** | Call `POST /v1/launches/validate` (or `enforceLaunch`) after the creator commits, before you deploy. Include the launcher wallet. |
| **02** | **Verify**   | Confirm Ed25519 signature, expiration, nonce, environment, chain, launchpadId, and launcher.                                      |
| **03** | **Enforce**  | Proceed only on a verified `allow`. Reject `block`, `recheck_required`, expiry, and HTTP 503.                                     |
| **04** | **Report**   | After on-chain confirmation, `POST /v1/launches/report`, then bond / milestone events as they occur.                              |
| **05** | **Sync**     | Process webhooks so your UI reflects reservations created elsewhere within seconds.                                               |

```
creator submits launch
  → enforceLaunch()   → allow | allow_authorized_only | block | recheck_required
                        (HTTP 503 / timeout ⇒ fail closed)
  → enforce decision  (SDK verifies Ed25519 by default)
  → deploy only if enforceable
  → reportLaunch()            (records the token — no lock yet)
  → reportBond()              (~$69k market-cap goal → 60d / 48h lock)
  → reportMilestone()         (~$1M market cap → 90d / 7d)
  → webhooks update your UI
```

{% hint style="warning" %}
A bare launch grants no copycat lock. `reportLaunch` records the token; locks fire only at market-cap goals. See [Report Bonding & Milestones](/for-launchpads/report-milestones.md).
{% endhint %}

## What an integration includes

| Step                            | What you build                                                                                                                                    |
| ------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Validate every launch**       | `POST /v1/launches/validate` via `enforceLaunch` at commit time                                                                                   |
| **Verify signed decisions**     | Signature, expiration, and identity fields before trusting any `allow`                                                                            |
| **Report launches**             | `POST /v1/launches/report` after a successful deploy                                                                                              |
| **Report bonding & milestones** | `POST /v1/events/bonded` and `/v1/events/milestone` — production also needs `X-AntiVamp-Keeper`                                                   |
| **Process webhooks**            | Verify `X-AntiVamp-Signature` and persist or invalidate caches                                                                                    |
| **Idempotency**                 | `Idempotency-Key` on `validateLaunch` / reservation prepare so retries replay the stored result (report and event calls are not yet deduplicated) |

## Environments

Sandbox and production are fully isolated: separate key prefixes, signing keys, state, and rate limits.

| Environment    | Key prefix                         | Base URL                          |
| -------------- | ---------------------------------- | --------------------------------- |
| **Sandbox**    | `av_sbx_…` (self-serve)            | `https://sandbox-api.antivamp.io` |
| **Production** | `av_live_…` (operator-provisioned) | `https://api.antivamp.io`         |

A sandbox key can never produce a production decision. Rehearse the full lifecycle in [sandbox](/for-launchpads/sandbox.md), then follow the [production checklist](/for-launchpads/production-checklist.md).

## The three non-negotiables

{% hint style="danger" %}
**Keys stay server-side.** Never ship an AntiVamp key in browser or mobile bundles, and never expose it through `NEXT_PUBLIC_*` or any client build variable.
{% endhint %}

{% hint style="danger" %}
**Never trust the `decision` field alone.** Verify signature, expiration, nonce, environment, launchpadId, chain, and launcher. An unverified string is not a decision. See [Verify Signed Decisions](/for-launchpads/verify-signed-decisions.md).
{% endhint %}

{% hint style="danger" %}
**Fail closed.** If you cannot obtain a fresh, valid, signed `allow`, do not launch. Timeouts, outages, expired decisions, and non-`allow` outcomes all mean refuse.
{% endhint %}

## Partner economics

New launchpad integrations receive a 30-day introductory period, then a **60% launchpad / 40% AntiVamp** share of attributed reservation fees. Details: [Partner Program & Revenue Sharing](/for-launchpads/partner-program.md).

***

## Continue exploring

* [Integration Quickstart](/for-launchpads/quickstart.md) — block a copied identity in about ten minutes
* [Production Enforcement Guide — REQUIRED](/for-launchpads/enforcement-guide.md) — every launch path, bypass tests, checklist
* [Validate Every Launch](/for-launchpads/validate-every-launch.md) — the decision contract
* [Verify Signed Decisions](/for-launchpads/verify-signed-decisions.md) — why an unverified `allow` is worthless
* [Process Webhooks](/for-launchpads/process-webhooks.md) — keep local state in sync
* [Production Checklist](/for-launchpads/production-checklist.md) — go-live gates
* [Developer Overview](/developers/overview.md) — architecture, SDK, and API reference


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.antivamp.io/for-launchpads/overview.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.