Auto-Freeze and Default-Frozen Launches: The Control Layer Most Tokens Skip
A practical walkthrough of Token-2022 defaultAccountState=Frozen, the operational auto-freeze workflow, five real use cases, and the trap that strands holders.
If you spend any time in Solana operator chats, the phrase "auto-freeze" comes up often, and most of the time the two people in the conversation are pointing at completely different things without realizing it. One is a setting baked into the token at the moment it is created, decided once, kept forever. The other is an operational workflow that runs while the token is alive, taking each new wallet as a separate decision. Conflating the two is how a real-world-asset project ships its launch, revokes the freeze key for the optics, then wakes up to a support ticket six months later from a buyer whose wallet is permanently locked. This post separates the two layers, walks through where each actually fits, and looks at why most launches stay away from this entire pattern.
Start with an analogy. A default-frozen launch works like handing out membership cards sealed in plastic. Every member receives the card, takes it home, can even show it to a friend, but the card cannot get anyone past the door until someone cuts the plastic. The only person allowed to cut the plastic is the doorman. The doorman checks people one by one, opens the card for verified guests, leaves the rest sealed. In token terms, the "card" is the balance sitting in someone's wallet, the "plastic seal" is the frozen state, and the "doorman" is the operator who controls the freeze key.
Two mechanisms, one name
The first mechanism is the "born frozen" setting in Token-2022, Solana's newer token system. Token-2022 layers extra optional features on top of the classic token system, and this is one of them. If you turn the setting on when you create the token, every new wallet opened against it is born in a frozen state. The owner cannot transfer a single unit until the operator who holds the freeze key issues an explicit thaw. This behavior is wired into the token at birth, and it cannot be added or removed later.
The second mechanism is the operational layer. It is a workflow that watches for newly opened wallets and applies freeze or thaw decisions based on a rule set. On j.tools that operational layer lives as the automatic freeze workflow tool, which currently sits on the platform's coming-soon list. This layer works against any token where the operator controls the freeze key, classic or Token-2022, so the two layers can run independently or together as one combined stack.
What the "born frozen" setting actually does
With the setting turned on at token creation, no holder can use a wallet for that token until a thaw signal lands on it, and the only signer with authority to issue that thaw is the operator who holds the freeze key. One detail catches people: once a wallet is thawed, it stays thawed unless the operator explicitly freezes it again. The setting governs the birth state, not the ongoing state. To freeze an already-thawed wallet you fall back on the single account freeze tool, which issues a standard freeze action against any given holder.
Setting this up requires creating the token on Token-2022 from day one. The entry point on j.tools is the Token-2022 mint creation tool, which exposes the switch in its config. A classic token cannot retrofit this setting under any condition, so the choice is permanent at creation.
The operational auto-freeze workflow
The "born frozen" setting alone is not a launch strategy, because every new wallet generates a thaw-or-wait decision that someone has to resolve. At any meaningful scale, doing this by hand burns an operator's day. The operational layer exists to absorb that load.
The pattern is simple in shape: a new wallet triggers a rule check. If the KYC check clears, thaw. If the address sits on a watchlist, escalate to a human reviewer. If it matches a sanctions list, keep it frozen and log the rejection. The automatic freeze workflow tool runs this rule set against incoming wallet events, calling external KYC and screening providers as needed. Classic tokens work here as well; the only hard requirement is that the freeze key still belongs to the operator.
Five legitimate use cases
The default reflex against this pattern reads it as "centralized, therefore bad," and that read misses the point. Five concrete scenarios make the control layer earn its place.
| Use case | Why "born frozen" fits | Cost of the optic |
|---|---|---|
| Real-world-asset token with KYC gating | The thaw step is the verification act; no KYC, no transfer | Audience already expects centralization, optic cost is low |
| Jurisdictionally restricted security token | Sanctions checks and geo restrictions run through the thaw decision | Compliance cost dwarfs the optic concern |
| Anti-sniper memecoin launch | Filters the first 5 to 15 minutes of sniper wallets before mass thaw | High; retail communities react badly to live freeze keys |
| Vesting cliff enforcement | Allocations land in frozen wallets; the cliff date is the thaw date | Low; the investor side already expects controls |
| Pre-launch team distribution | Even leaked private keys cannot sell before the launch event | Very low; purely internal process |
Beyond these five, third-party compliance integrations sit in adjacent territory with the same shape. The core idea stays the same: a thaw signal is the on-chain expression of an off-chain decision. The guides category on the blog covers more practical walkthroughs of these control patterns.
Why most launches skip this
The five cases above are real, and so are the reasons most retail-shaped launches stay away. The first one is exchange aggregator filtering. Major aggregator front-ends like Jupiter and Raydium do not want to surface tokens where holders hit unhelpful transfer errors, so tokens with a live freeze key plus "born frozen" wallets get deprioritized in route discovery. The token works in theory; in practice routing thins out. For a launch chasing liquidity, that is a hard wall.
The second reason is the optic itself. A holder opens Solscan, sees an active freeze key and the "born frozen" setting, and reads it as "the team can lock my bag whenever it wants." Intent does not matter at that point. The third reason is ecosystem coverage; Token-2022 already has narrower wallet, explorer, and exchange support than the classic token system, and layering "born frozen" on top narrows the integration surface further. The fourth reason is ongoing operational load; every new holder is a decision that has to be resolved. The fifth reason is exchange listing alignment, since most exchange listing teams turn down tokens with active freeze keys on principle.
The "I released the token" trap
If you launch with "born frozen," thaw your initial holders, then run the freeze authority revoke tool to decentralize the optics, every new wallet opened for that token will still be born frozen. Nobody can thaw them anymore. Six months later a new buyer ends up with a permanently locked balance, and the project has no path to fix it. This trap has hit real RWA projects.
The same logic catches the make immutable tool. Revoking every key at once does not switch off the "born frozen" setting, it just locks the setting into place with no operator to manage it. If you launched with the setting on and you genuinely want a freely tradeable token afterward, the correct order is this: thaw every current holder, confirm the supply will not grow any further, then revoke the freeze key. Skip a step and the token has a half-life on its own holders.
How this differs from the "permanent delegate" setting
Another Token-2022 setting that gets bundled into the same conversation is the "permanent delegate," and the two solve different problems. "Born frozen" controls who can transfer, applying a hold. The "permanent delegate" grants a designated party the power to move tokens out of any holder wallet at will. From a compliance standpoint the "permanent delegate" is the heavier instrument, because it allows involuntary movement; "born frozen" only says "not yet."
Full j.tools workflow
If you decide "born frozen" actually fits your launch, the end-to-end shape on j.tools is straightforward. Begin at the Token-2022 mint creation tool with the setting enabled and the freeze key pointing at an operator wallet. Connect the rule set through the automatic freeze workflow tool, wired to your KYC provider, watchlists, and sanctions screening service. Keep the single account freeze tool and the single account thaw tool on hand for ad-hoc work the workflow does not cover. Periodically run the holder snapshot tool to audit freeze state across the population. The day you decide to fully release the token, thaw active holders, close the mint authority, and only then revoke the freeze key.
A concrete example helps. Say you are launching a real-estate revenue-sharing token. A buyer fills out a claim form, receives the token in their wallet, and the wallet is born frozen. The operator reviews the KYC report, finds the buyer on the approved list, and sends the thaw signal. From that moment on the buyer can transfer the token freely. A wallet that fails the KYC step still holds the token, but it never gets thawed and therefore never gets to trade. Done correctly, this flow lets the operator carry the regulatory load without inspecting every incoming wallet by hand.
The "born frozen" setting is a strong compliance and launch-control instrument with a real centralization cost attached. Both sides of that trade exist; the decision should be deliberate, since the token creation step locks the option in for the life of the token. For more operator-grade walkthroughs see other solana-tagged articles on the blog.
defaultAccountState: the exact setting behind "born frozen"
The "born frozen" behavior has a precise name in the token program. It is the defaultAccountState extension, one of the optional Token-2022 extensions you opt into at mint creation. The extension stores a single value on the mint that decides the starting state of every token account opened against it. Set it to Frozen and each new holder account is initialized frozen by default. Leave it at Initialized (the normal case) and accounts open ready to transfer.
Two facts about this extension trip people up. First, it is a property of the mint itself, not of any single wallet, so it applies uniformly to every account that gets created afterward. Second, it is fixed at creation. There is no instruction to add, remove, or flip defaultAccountState on a live mint, which is why a classic SPL token can never gain this behavior later. If you want it, you commit at the start through the Token-2022 mint creation tool, where the switch lives in the mint config.
The extension only sets the birth state. Thawing a wallet is a separate freeze-authority action, and a thawed wallet stays thawed until someone freezes it again. The mint setting never re-freezes anything on its own.
How to unfreeze a default-frozen token safely
If holders report locked balances on a token that launched with defaultAccountState=Frozen, the fix depends on whether the freeze authority still exists.
- The freeze key is still held by the operator. Each locked wallet needs an explicit thaw signed by the freeze authority. Run it per account against the holders you intend to unlock. This is recoverable, just manual.
- The freeze key was already revoked. No signer can thaw new accounts anymore, so newly opened wallets are permanently locked with no on-chain path back. The only practical remedies are off-chain: migrate holders to a fresh mint, or distribute a replacement token. There is no instruction that undoes a revoked authority.
Before you mass-thaw, snapshot who actually holds the token so you thaw the right set and skip dust or sniper accounts. The holder snapshot tool gives you that holder list. Then issue thaws to the approved accounts. If your goal afterward is a freely tradeable token, the order matters: thaw every current holder, stop supply growth by closing the mint authority through the mint authority revoke tool, confirm no new accounts will be created, and only then revoke the freeze key.
Default-frozen vs permanent delegate vs freeze authority
Three Token-2022 controls get lumped together because they all give an operator power over holder balances, but they answer different questions.
defaultAccountState (default-frozen)
Controls the starting state of new accounts. Born frozen means a holder cannot transfer until a thaw lands. Set once at creation, cannot be changed, enforced by the freeze authority. Answers: who is allowed to start trading.
Freeze authority
The key that can freeze or thaw any individual account at any time on classic or Token-2022 tokens. It exists independently of the default-frozen setting, and it is the key that actually performs every thaw the setting requires. Revoking it (decentralizing the optic) also removes the only way to thaw future default-frozen accounts. Answers: who can hold or release a specific wallet, live.
Permanent delegate
A Token-2022 extension that lets a designated party transfer or burn tokens out of any holder wallet without that holder signing. It does not block transfers, it moves tokens. This is the heaviest control of the three because it can take a balance, not just pause one. Answers: who can move tokens out of a wallet they do not own.
Default-frozen plus a live freeze authority is a hold. A permanent delegate is a confiscation power. Holders and exchanges read them very differently, so do not describe one as the other when you publish your token's setup.
