How VeilVault works

Overview

VeilVault is a launchpad on BNB Chain built on the Flap Portal. A VeilVault coin is an ordinary Flap tax coin in every respect that matters to traders: same bonding curve, same graduation to PancakeSwap, same 2% buy / 2% sell tax.

What changes is the tax destination. Instead of one beneficiary wallet per coin, every coin pays into the same public contract, and the person who earns it is only ever represented on chain by a salted hash. Payouts leave the vault as fixed 0.1 BNB transfers to whatever address a code holder names.

The result: an observer can see the aggregate, but cannot answer "which coin earned this", "who owns that coin's income" or "which wallet received it".

Launching

1. Connect any wallet. The wallet pays gas and the optional dev buy; it is recorded by Flap as the creator but has no claim on the tax.
2. Fill in the coin and name a recipient: an X handle. It can be your own or someone else's.
3. The browser mines a CREATE2 salt so the address ends in 7777, then calls VeilLauncher.launch. One signature creates the Flap coin with the vault as sole tax beneficiary and 100% of tax directed to it.
4. The launcher emits Launched(token, creator, recipientHash, meta, devBuyBnb). The site registers the coin from that receipt and the worker verifies the beneficiary on chain before marking it live.

Metadata (name, logo, links) is pinned through Flap's own upload API, so the coin appears on flap.sh exactly like any other.

The vault

VeilVault is a single contract that receives BNB from every coin's tax processor. Flap's processor accumulates WBNB per coin and, once a threshold (~0.08 BNB) is reached, anyone may call dispatch() to forward it. The vault emits FeesReceived(from, amount) on each inflow.

Attribution: from is the coin's tax-processor address, which is deterministic per coin. The worker maps processor → coin off chain and keeps a private ledger of income per coin. The vault itself stores no per-coin balances, so its on-chain state reveals nothing about distribution.

After a coin graduates, the vault also claims the Flap LP reward (claimLp) and books it to the same coin.

Codes and claiming

For every 0.1 BNB a coin accumulates, its recipient is issued one code of the form VV-XXXX-XXXX-XXXX-XXXX (80 bits of entropy). Codes are issued by the worker as income arrives and never expire.

Seeing your codes requires proving you are the handle: sign in with X on the Claim page. This is the only place X is used and it only grants read access to your own list.

Redeeming requires nothing: paste a code and any BNB Chain address. No wallet connection, no login, no cookie. Codes are bearer instruments — hand one to a friend, or redeem each to a fresh wallet. The worker pays 0.1 BNB from the vault within about one tick.

If a payout fails (e.g. the destination is a contract that rejects BNB) the code is marked failed and can be redeemed again to another address.

Privacy model

Limits. Timing correlation is possible if a single coin dominates vault inflows; redeeming many codes to one wallet in one batch weakens unlinkability; the operator can see which code paid which address at redeem time. The salt is held server-side and is never rotated.

Trading

The trade panel calls the Flap Portal directly (swapExactInput) — on the bonding curve before graduation and through the Portal's router on PancakeSwap after. Quotes come from quoteExactInput; slippage is selectable. Tax is applied by the token itself and is the same no matter where you trade.

Trades and Holders tabs are indexed from chain events by the worker and refresh every few seconds. Market cap is derived from the curve price (or pair reserves after graduation) and the Chainlink BNB/USD feed.

Admin and risks

The vault owner can withdraw any amount of BNB or any ERC-20 at any time (rescueBNB, rescueToken) and can replace the operator that executes payouts (setOperator). This is an explicit emergency power. It is also a trust assumption: funds in the vault are custodial until paid out.

• Code issuance and payouts are off-chain processes run by the operator; if the worker is down, codes are delayed, not lost.
• Flap contracts are upgradeable proxies controlled by Flap, not by VeilVault.
• Tokens are speculative. Nothing on this site is financial advice.

Contracts

• VeilVault 0xD5d7B46ce59074f3ed27969AEc3663cdc2ffd0cA
• VeilLauncher 0xbe40cb19199039d9f1EB15daDD08d6640A4ee781
• Flap Portal 0xe2cE6ab80874Fa9Fa2aAE65D277Dd6B8e65C9De0

API

All endpoints are public, JSON, uncached.

• GET /api/coins — listed coins with market snapshot
• GET /api/coins/:token, /trades, /holders
• GET /api/stats — coins, vault income, codes issued / paid
• POST /api/claim/redeem {code, to} · GET /api/claim/redeem?code=
• POST /api/launch/register {txHash, …} — idempotent; re-run with a confirmed tx hash if a launch was not registered
• GET /api/health — launcher, vault, worker heartbeat