Security model

Status, reviewed 2026-10-16. Latch is not audited. The vault has never run on mainnet and no bug bounty exists. The launch page can create real tokens on mainnet anyway, as an unaudited experiment. Treat anything you put in as money you could lose.

Do not describe this system as trustless. It removes some trust (nobody can pull the liquidity or print more supply) and leaves the rest with named parties, listed in full below.

What the code guarantees today

Guarantee	Why it holds
The supply is fixed at 1,000,000,000	The mint authority is revoked in the same transaction that mints the supply. Anyone can check this on an explorer.
The token cannot freeze anyone	No freeze authority is ever set on the mint.
Nobody can withdraw the pool's liquidity	The position is permanently locked in Meteora's DAMM v2 program, which has no instruction to unlock it. This holds only as long as that program is not changed. See the trust list.
Fees go to the recorded wallets only	When the vault is used, it owns the position, pins the recipient and treasury addresses it pays, and checks them on every claim.
The creator's share can only go down	`lower_creator_bps` rejects any value that is not lower. This protects the protocol's minimum cut. It does not stop the creator pointing their share at another wallet.

What you still have to trust

"Applies today" says whether the thing exists in the product right now.

Who or what	What they can do	Applies today
The creator: metadata	Unless the creator picked "frozen" or the vault-managed wait, their wallet holds the Metaplex update authority and can change the name, symbol and image instantly, with no warning. With the vault-managed wait, a change must be queued publicly first and waits the delay recorded on the launch (this site sets 48 hours; the program accepts anything from 60 seconds, so read the number on the token page). That wait is only as strong as the vault's upgrade key, which could bypass it. Handing the name to the vault cannot be undone, and the name can then never be frozen.	Yes
The creator: first buy	Can buy from another wallet before anyone else. At the default setting (the Community preset: 20 SOL start, 1,000x ceiling), a 10 SOL buy takes about a third of the supply before the fee, and about 29 percent after the 15 percent opening fee. The start fee mostly flows back to the creator, so it does not deter this. The launch page offers an open alternative, a first buy from the creator wallet inside the pool transaction, and the token page flags early buyers the creator funded, but neither can stop a creator who uses a wallet funded some other way.	Yes
The creator: fee recipient	With the vault, can point their share at any wallet at any time (`set_recipient`, effective on the next crank). Without the vault, the creator's wallet simply holds the fee rights.	Yes
Fees paid in the launched token	Fees are collected in both tokens, so the creator and the treasury receive some of the launched token as fees and can sell it into the pool. "The whole supply is in the pool" is true at launch, not afterwards.	Yes
Meteora	Its program holds the pool and the lock. Its admin can disable a pool, which freezes trading, and because the liquidity is locked nobody can withdraw it. Whether DAMM v2 is upgradeable, and who holds that key, decides whether the lock could ever be removed. Check it with `solana program show cpamdpZCGKUy5JxQXB4dcpGPiikHawvSWAd6mEn1sGG`.	Yes
The vault's upgrade authority	Whoever can upgrade the vault program can redirect every launch's fees. The plan is a multisig behind a timelock, then burning the key after an audit. Nothing is deployed yet, so no signers, delay or policy exist to point to.	When deployed
The protocol admin	Can change the treasury instantly, which moves only the protocol's share. Can hand the role over in two steps.	When deployed
The metadata host	The token's image and description live at the link the creator supplied. Freezing the on-chain fields does not freeze that file unless it is on IPFS or Arweave.	Yes
This website	It builds the transactions you sign. A compromised site could build different ones. Read what your wallet shows you.	Yes
The X claim signer	A service that confirms who owns an X account and signs permits. Whoever holds its key, or the admin who can replace it instantly, can release the escrowed share of every X-account launch. The program rejects permits that expire more than 15 minutes ahead, which limits a stolen permit, not a stolen key. A timelock on changing the key, a guardian and a cap are planned, not built. Built, but not switched on: it needs X credentials and the vault.	When switched on

Limits you should know about

A creator can point their share at a wallet whose token accounts are unusable. Cranks for that launch then fail until they set a working recipient, and the protocol's share waits with theirs.
Tokens sent to a launch account by mistake cannot be recovered, and a launch cannot be closed.
The 60 second minimum rename wait is the program's floor, not a recommendation. The site defaults to 48 hours, which only holds for launches made through it.
For an X-account launch the creator's choice of account is their own claim, and a wrong or lookalike account strands the share.

What registering with the vault proves, and what it does not

Registration (register_launch) checks that the position and pool belong to Meteora's program, that every unit of the position's liquidity is permanently locked, that both mints are plain SPL Token mints, that the pool is the launched token against wrapped SOL, that the token's mint authority and freeze authority are both revoked, and that the launch address holds the position NFT. It also records the pool's total and locked liquidity in the registration event. It does not require them to be equal, because anyone can add liquidity to a pool and that would let them block registration. Compare the two numbers: if total is above locked, someone holds liquidity in the pool that is not locked.

It does not prove that the mint authority is revoked, that the whole supply sits in the pool, that the token was made by the Latch site, or that the creator will keep the fee split they chose. Anyone can call the vault with their own client. A token being "registered" is evidence about the lock and the fee routing, not a safety rating.

Nothing forces step three either: a creator can skip the vault and keep the position in their own wallet. "A Latch token" is not a class you can verify, which is why you should check each token yourself.

Check a token yourself

The token page does these checks for you, reading the chain directly, and links to where you can check each one yourself. An explorer is enough for all of them. See Verify a token.

Mint: the mint authority and the freeze authority are both empty, and the supply is 1,000,000,000.
Pool: the pool is a Meteora DAMM v2 pool of this token against wrapped SOL, and the vault holding the token has close to the full supply at launch.
Lock: the pool's permanently locked liquidity is close to its total liquidity. A gap means some liquidity is unlocked, and whoever holds it can withdraw it.
Position: the position NFT is held by the vault's launch account, not by a wallet.
Launch account: read the creator share and the recipient. Check whether the recipient is the creator and whether it changed.
Metadata: read the update authority and whether the metadata is mutable. If a wallet holds it, the name can change at any time.
Creator wallet: look at what it holds and who funded it. A creator who already owns a large share is the main risk for a new buyer.
Programs: run solana program show on the vault and on Meteora's program and note who can upgrade them.

Attacks to design against

Mitigations marked planned do not exist yet.

Creator front-running their own launch. The creator can buy first from a second wallet at the lowest price. Mitigations, both built but not yet run on a validator or mainnet (the first buy has integration checks waiting in vault/tests-int/src/app-launch.ts, the flag has offline unit tests): an optional creator first buy inside the launch, made from the creator wallet in the same transaction that opens the pool and capped at 10 percent of the supply, so nobody trades before it and anyone can see it; and a token page flag for early buyers whose wallets the creator funded directly. The flag is a heuristic: funding through an exchange or a chain of wallets is not detected, and a hit is not proof of bad intent. Neither stops a determined creator, so the token page still shows the creator checks first.

Rename scams. Change a token's name to impersonate another one after it gains attention. Only the vault-managed mode slows this down, with a public wait that the token page shows. In the other modes nothing does, so the token page flags a creator-changeable name.

Honeypot variants. A token that cannot be sold. Standard SPL tokens with no freeze authority and no transfer hooks cannot do this, and the vault refuses mints that are not plain SPL Token mints.

Fee-claim hijack. Someone names a famous X id as the recipient. The share then waits in escrow, and only a login as that account can release it, so an impostor cannot collect it. The creator's choice of account is their own claim and is not checked, so a wrong id strands that share. See X claims.

Rounding and dust. Concentrated-liquidity maths uses fixed-point square roots. The integration tests cover tiny trades and an exact split, but extreme ranges are not exhaustively tested.

What Latch will not do

Claim the system is audited before it has been.
Offer pair switching on locked pools, because that would imply the lock is not real.

Status before opening this up to the public

Item	Status
Independent audit of the vault	Not done
Adversarial soak test on a public test network	Not done. Devnet was skipped by choice; the vault has local integration tests only.
Bug bounty and an incident contact	None
Legal review	Not done
The launch page on mainnet	Can create real tokens on mainnet, but has never been used there or with a real browser wallet. Unaudited: start with an amount you can lose.