Reference/Security model

Security model

NASDANK custodies locked liquidity and routes fees, so a bug here loses somebody's money. This page separates what is guaranteed by code from what is guarded by process, because those are very different promises.

Guaranteed by code

These properties hold because there is no function that could violate them. They are checkable by reading the verified source, and you should.

Property	How it is enforced
A launch is all-or-nothing	One transaction. Any revert unwinds token, pool, position and lock together.
Your opening price cannot be front-run	The pool is created and initialised inside the launch. It never exists at an unset price.
Pro and Custom principal never comes back	The locker has no withdraw, no transfer, no decrease-liquidity path, no owner, no proxy.
Fee recipients cannot be re-pointed	Fixed at launch, immutable afterwards.
Fee splits conserve	`creator + treasury == collected` on every leg, with the integer remainder going deterministically to the treasury.
Collection cannot be withheld	Permissionless. Anyone can trigger it; proceeds go to the fixed recipients, never the caller.
Supply cannot be inflated	Minted once in the constructor. No mint function, no upgradeable proxy.
A vesting release always pays the beneficiary	Never `msg.sender`. A third party can pay the gas without any trust.
A referral claim always pays the leaf's account	Same construction, and the chain re-verifies the proof against the live root.

The engineering rules behind them

These are the standing constraints every contract change is reviewed against before it can merge. They are listed because they tell you what we consider a defect, which is more informative than a list of features.

Atomic launchNo orphaned token, pool or position on any revert path.
Single-sided mint correctnessRange entirely at or above the opening price, ticks aligned to spacing, token ordering sorted correctly, the intended fee tier, a deterministic init price. A wrong tier or price silently changes the economics and is exploitable.
One-way custodyEvery escape hatch hunted explicitly: delegatecall, arbitrary call, owner powers, upgradeability, selfdestruct, standing approvals.
Fee correctnessExactly the intended fee; conservation on both legs; immutable recipients.
Snipe and MEV surface documentedThe dev buy is atomic within the launch; the first-block surface is written down rather than assumed away.
ReentrancyChecks-effects-interactions plus a guard on launch, creator buy and collect.
Value handlingSafeERC20, correct wrap/unwrap, refunds for creator-buy change, no stuck ETH or dust, no dangling approvals, no unbounded loops, no admin mint, no upgradeable token.
Address correctnessOnly addresses anchored on-chain. Impostor periphery deployments exist on these networks.
Tests and invariantsUnit tests over every branch, fork tests against the real DEX (launch, buy, sell, collect), plus fuzz and invariant tests for: principal never withdrawable, the position never leaves the locker, fees always conserve.
Audit gateNo mainnet deployment holding real value ships without an external review passing.

Guarded by process, not by code

Be clear-eyed about this section

Everything below depends on people and infrastructure doing their job. None of it can take your principal, but all of it can affect what you receive and when.

Depends on	What it affects	What it cannot do
Keepers	Auto-push reward payouts, standing-order fills, merkle root posting	Take custody of anything. A stalled keeper delays; it does not lose.
The indexer	Displayed volume, charts, discovery, referral proofs	Change any balance. It is derived data.
The frontend	What you are shown before you sign	Move funds. Every write is your own signature.
IPFS gateways	Whether a coin's image loads	Anything financial.
The treasury	Where the protocol's share goes	Reach a creator's leg or a locked position.

Known keeper failure modes

Stated plainly because they have happened:

A keeper below its gas floor skips every send and logs nothing. The symptom is payouts simply stopping, with no error anywhere. Because the underlying claim functions are permissionless, recovery does not need the keeper — anyone can trigger the claim.
Push-mode rewards pool while a keeper is down. They are not lost; they accumulate in the vault and go out when it resumes.
Standing orders do not fill without a running keeper for that chain. Nothing has moved, and the Permit2 approval can be revoked at any time.

Audits and reviews

Review	Scope	Outcome
Security red-team, 2026-07-17	Full contract surface	Core clean. Seven findings outside the core, since addressed, including an upload-endpoint issue and a dead legacy contract.
Money audit, 2026-07-22	Fee routing and custody paths	Zero confirmed leaks.
Fee-routing replay, 2026-08-11	791 payouts across V2, V3 and V4	Zero conservation breaks. Realised protocol share 15.0%, matching the specification.

External audit status

The rule is that no deployment holding real value ships without an external review passing. Newer generations — and the BNB Chain ports in particular — are faithful ports of reviewed contracts, but a port is not an audit. Ask about the review status of the specific launcher you intend to use, rather than assuming coverage transfers across chains.

Verifying rather than trusting

Every claim on this page is checkable. The three that matter most, in order:

Read the locker's verified sourceLook for any call to decreaseLiquidity, transferFrom, safeTransferFrom or burn on the position manager. If there is one, the lock is conditional.
Check for a proxyA locker behind a proxy is only as permanent as its proxy admin.
Confirm the position's ownerownerOf(tokenId) should be the locker the launcher names, not a wallet. Reading token state has the call.

Reporting something

If you find a way to move money that should not be movable, report it before publishing it. Contact through the channels linked from nasdank.fun.