Skip to main content
Mainnet activation is gated on the external audit. Contracts are live on Base Sepolia for testnet UX validation. Until the audit clears, bag-lock is testnet-only.
Bag-lock is filter.fun’s structural answer to “trust me, I won’t dump my own bag.” A creator opts in to time-locking the tokens held by their own wallet. The lock is enforced by the token contract itself — it cannot be circumvented by the protocol, by the creator, or by anyone else.A creator with a 60-day lock has burned the option to rug for 60 days. That’s a different category of trust signal than “trust me bro.”

​
Why this is the killer feature

Every other launchpad — Clanker, Bankr, Pump.fun — lets creators dump their own holdings whenever they want. The trust gradient is asymmetric: creators promise restraint, holders cannot verify it. Bag-lock collapses that gradient. A locked creator’s commitment is a public, on-chain fact, readable by any block explorer, with no escape hatch and no unlock function.The product implication is simple: bag-locked tokens get a badge on the Arena leaderboard. Holders trade tokens with badges; creators who refuse to lock signal exactly that. The badge becomes table stakes for serious launches over time.

​
How to use it

The contracts are live on Base Sepolia. The creator console UI wrap is coming. Until then, lock from the contract directly on Sepolia:
# unlockUntil is a unix timestamp; the block must be strictly later
# than block.timestamp AND strictly later than any existing lock.
cast send $CREATOR_COMMITMENTS \
  'commit(address,uint256)' $TOKEN $UNLOCK_UNTIL \
  --rpc-url $BASE_SEPOLIA_RPC_URL \
  --private-key $CREATOR_KEY
You must call commit from the creator-of-record wallet — the address that originally launched the token. Auth is checked against CreatorRegistry.creatorOf(token), not adminOf. If you’ve handed admin to a multisig, the multisig cannot call commit; the lock is a personal commitment by the original launcher.To extend an existing lock, call commit again with a later timestamp. The contract refuses any value <= the existing unlock.To lock forever, pass type(uint256).max. The contract explicitly allows this; the gate will revert on every transfer from your address indefinitely.

​
How holders verify a lock

CreatorCommitments exposes two view functions any holder can read without permission:
function isLocked(address creator, address token) view returns (bool);
function unlockOf(address creator, address token) view returns (uint256);
isLocked returns true if and only if block.timestamp < unlockTimestamps[creator][token]. unlockOf returns the raw unix timestamp (zero if no lock has ever been recorded).The contract address lives in the deployment manifest under addresses.creatorCommitments.

​
Five things bag-lock does NOT do

These are the false-trust risks. The web UI must surface every one of them loudly — a holder who misunderstands the lock as broader than it is will feel betrayed when they encounter the gap.

​
1. Pre-commit transfers escape

If the creator transferred half their bag to a second wallet before calling commit, that second wallet is not subject to the lock. The gate is keyed off (creator-address, token). Anything that left the creator’s wallet before the commit lives outside the gate.The implication: a “creator locked X% of supply” badge must compute against the creator’s current balance at commit time, not the launch-time balance. Otherwise a creator who pre-distributed gets credit for a lock they didn’t actually take.

​
2. Buying more is fine; selling is not

Incoming transfers to the locked address still work. Fee revenue, tips, swaps from a different wallet into the locked address — all permitted. Only outgoing transfers from the locked address revert.This is intentional: a lock that prevented incoming credits would block creator-fee claims and trap the creator’s revenue. The lock is about not selling, not no activity.

​
3. The lock does not cover other wallets the creator controls

Only the address that called commit is gated. If the creator quietly transferred to a sibling wallet they also control before committing, they can dump from the sibling without restriction. Detecting “common controller” addresses is an off-chain heuristic problem (Arkham-style), not something the contract can do.The implication: surface the creator’s other on-chain activity (clusters, large transfers near commit time) so holders can form their own judgment. Don’t claim the lock covers more than the literal mapping says.

​
4. Lost keys = permanent lock

If the creator loses access to the wallet that called commit, the bag is permanently locked. The protocol cannot rescue it. This is by design — an escape hatch would be the exact same hatch a creator could use to renege on the commitment.The implication: creators must be told this before they commit. The “Lock my bag” flow surfaces an acknowledgement: “If you lose this wallet, your tokens stay locked forever. You cannot recover them.”

​
5. Legacy Sepolia tokens

Tokens deployed before the bag-lock-aware FilterFactory was wired up don’t consult the commitments contract. A creator of one of those tokens who calls commit will see it succeed, but the lock won’t enforce — transfers will still go through. Bag-lock is not advertised for those tokens; the in-app badge logic excludes them.

​
Locks extend, never shorten

The contract enforces strict-> monotonicity:
  • Calling commit with a timestamp <= block.timestamp reverts with LockMustBeFuture.
  • Calling commit with a timestamp <= the existing unlock reverts with LockCannotShorten.
  • There is no unlock function. There is no cancel. There is no admin override. There is no pause.
This is the property that makes the lock credible. A function that could shorten the lock would be the same function a creator could use to renege. So the function does not exist.If a security issue is found post-deploy, the only remediation is to deploy a new contract instance. Locks recorded on the existing instance remain enforced for as long as the FilterToken contracts that reference it exist.

​
Audit constraints

Mainnet activation is gated on the external audit, which specifically validates:
  • No way to shorten or cancel a lock. commit enforces strict-> monotonicity; no other state-mutating function exists on CreatorCommitments.
  • No admin override. The contract has no owner, no pause, no upgradeability, no escape hatch.
  • The transfer gate is consulted on every balance change (not just direct transfer). OZ v5’s _update hook is the single funnel — the override calls it on transferFrom, swap-routing, and burn paths too.
  • Auth uses creatorOf, not adminOf. Admin transfers do not carry the bag-lock right.
  • Reentrancy guard on commit. Defensive — no current external calls inside, but the guard is load-bearing if a future change adds one.
A loud failure mode caught in audit (lock-shortening, admin override, gate bypass) would be worse than not shipping the feature. That is why mainnet activation is gated.

​
Next

Creator console

Where the bag-lock UI will live once shipped.

Launch a token

The launch flow that establishes the creator-of-record bag-lock keys off.

Risks

What can happen, what isn’t promised — including the limitations above.

The filter

The competitive cut bag-lock is designed to live alongside.