Security
Built to be safe to integrate.
AntiVamp holds a registry entry, not your funds. Here's how the system is designed to fail safely, and how to report a problem.
Design principles
How the system is built
Non-custodial by design
AntiVamp never takes custody of a creator's tokens, treasury, or liquidity. The registry stores a reservation record — a normalized identity, an authorized wallet, and an expiry — nothing more.
Fail closed, not open
When an oracle is stale or an indexer is unreachable, validation calls fail closed: launches are blocked rather than silently allowed on unverifiable data.
Scoped partner keys
Partner API keys are scoped per launchpad and per chain. A compromised key can be rotated without affecting other integrated partners.
On-chain source of truth
Reservation and lock state that matters for enforcement lives on-chain or in a public registry. Off-chain services (indexer, API) are a convenience layer on top, not the sole source of truth.
Smart contracts
Deployment, audits, and ownership
Deployment status
Reservation and graduated-token registry contracts are deployed and documented per chain on the Networks page. Addresses are sourced from environment configuration or explicitly-documented deployments — never hardcoded silently.
Audit status
AntiVamp's contracts have not yet completed a third-party security audit. We treat this as a blocker for scaling reservation volume, not a formality — an audit is planned ahead of broader chain rollout, and status will be reflected here and in the changelog once complete.
Upgrade and ownership controls
Registry contracts use guarded owner/admin functions for operational parameters (e.g. registry wiring on a factory). Ownership keys are held in multisig-controlled wallets where deployed, not single signer accounts.
Published deployments
Contract addresses and roles
| Chain | Contract | Address |
|---|---|---|
| Base | GraduatedTokenRegistry | 0x1BD9FaD154eE084700398323821BfCC1F7e419Eb |
| Robinhood Chain | GraduatedTokenRegistry | 0x4B86930B4a2EFb34170900E94283eC0Bd07424f7 |
| Hyperliquid | TickerReservationRegistry | 0xC10928677f96A860Ee1D9ee3425f344dE37c7D36 |
| Hyperliquid | GraduatedTokenRegistry | 0x47102135Ad7Bd69F89b178b909304804b2101779 |
Owner (Safe multisig)
Registry ownership on HyperEVM sits with a Safe, not a single signer. Owner functions cover pricing tiers, pay assets, oracle wiring, and lock durations — never user funds.
Guardian
Guardians manage the graduated symbol/image blocklist and can clear mistaken blocks. Guardian actions are events on-chain and appear in identity timelines.
Keeper
Market-cap milestone locks are applied only by an authorized keeper after verification — a manipulated FDV spike cannot extend protection on its own.
Oracles and API
Fail-closed pricing and signed responses
Oracle freshness
Reservation pricing reads an on-chain price feed (Chainlink on Base; push oracles on HyperEVM and Robinhood Chain) with a maximum-age check enforced by the contract. A stale answer reverts with StaleOracle — the reservation cannot be mispriced, only paused.
Data freshness policy
Every identity answer carries its data source (index, chain, indexer) and timestamp. When no live source can answer, the API returns recheck_required instead of guessing.
API authentication
Partner keys are stored hashed (SHA-256) and shown exactly once at creation. Per-key rate limits, request logs, revocation, and idempotency are built in. Sandbox keys can never write production records.
Signature model
Validation decisions are HMAC-SHA256 signed with a per-partner secret and expire after 5 minutes; webhooks carry a timestamped X-AntiVamp-Signature header. Signing keys live in server-side secret management only — verification snippets are on the Developers page.
Responsible disclosure
If you find a vulnerability in AntiVamp's contracts, API, or web application, please report it privately before disclosing publicly. We will acknowledge reports and work with you on a fix timeline.