Locks & the bundler

Every rug has the same anatomy: concentrated supply that could move, and then did. Scanners (Bubblemaps, RugCheck, GMGN) try to detect concentration from the outside and are sometimes wrong in both directions. The locker and the bundler attack the problem from the inside: locked supply provably cannot move, and bundled supply is declared by the buyer at the moment of purchase.

Built · not live - the locker contract is written and extensively tested, and the token-page badge that reads from it is already in the app. It is not yet deployed on the live network; the badge simply never appears until it is.

What it does, once live:

• Time locks - deposit any amount of a token until a fixed date.
• Vesting - release linearly between a start and an end, with an optional cliff before which nothing is claimable.
• Burns - send supply to the dead address, recorded as an event.

And the properties that make a lock mean something:

• Ownerless. The contract has no admin, no fee, no pause and no sweep - no key exists anywhere that can reach locked funds early. That is the entire product.
• Extend-only. A lock can be lengthened, never shortened. “Locked until March” cannot quietly become February.
• Two-step beneficiary transfer. A project can hand a lock to a new owner without the possibility of typo-ing it into the void.

A token with locked or vesting supply shows a badge on its page and in lists - 12% locked until 12 Mar 2027. Read it precisely:

• It counts supply in the Degenland locker, verified on-chain - not claims made in a bio.
• The date shown is when the last lock fully opens; vesting positions release gradually before their end date.
• No badge is a statement too: it means nothing is locked here. Absence of a locks panel is deliberate - an empty one would imply a feature the token failed to use.

Built · not live - contract written, tested and deployed to both EVM testnets (one bundler per chain - each binds its own launchpad and locker). The launch flow plans a bundle in the launch page’s “Opening buy & anti-sniper” drawer, visibly inert (with the reason) on any venue whose bundler isn’t wired to the app yet - enabling a venue is configuration, not new code.

Solana is different, on purpose. There is no bundler program there and our curve config has no per-wallet cap, so there is no rule to bundle around - the launch flow offers a first-buy split instead: one first buy to your wallet, then plain token transfers to the others. Nothing on-chain records it as a bundle, and the UI says so rather than borrowing the guarantees below.

A bundler buys a token into several wallets in one atomic transaction. Creators want this for honest reasons (seeding a community allocation, funding team wallets) - and dishonest ones (disguising insider concentration from scanners). Most launchpads either refuse to build it or quietly help hide it. Degenland's is built backwards from the disclosure:

• Every bundle is recorded on-chain, permanently: the total bought, the share of supply in basis points, the complete recipient list and the block. There is no code path that bundles without recording - no flag, no admin, no “private mode”.
• Anyone can read it. The disclosure is a public contract view, usable by our token page and by any third-party scanner - so “bundled %” on a Degenland token can be a verified fact instead of a heuristic.