Permissioned Tokens on Solana: How Token ACL Works — and How to Tell It From a Honeypot

On-chain, a regulated fund token and a honeypot scam are the same shape.

Both are Token-2022 mints. Both keep an active freeze authority. Both set DefaultAccountState to Frozen, so every new holder's account starts locked. One of them is a European money-market fund following its regulator's rules; the other is a trap built to let you buy and never sell. Every token scanner I tested reads them identically: red flags, high risk, score zero.

The reason this now matters is sRFC-37, the Token ACL standard — the Solana Foundation's official mechanism for permissioned tokens. It has been live on mainnet since March 2026, real institutional money already uses it, and the entire real-world-asset wave forming on Solana is going to ship in this exact shape. This post covers how it works end to end — and the structural check that separates a compliant token from a trap, verified against the chain rather than anyone's metadata.

Why Permissioned Tokens Exist at All

A tokenized treasury fund, a regulated stablecoin, a security token — their issuers are not allowed to let anyone hold them. KYC requirements, sanctions screening, court orders, investor-accreditation rules: the issuer must be able to control who holds the asset and stop specific wallets, or the asset cannot legally exist on a public chain.

Solana had two ways to build that before, and both hurt:

• Transfer hooks run issuer code on every transfer — but every DEX, wallet and protocol touching the token must implement the hook interface, so composability dies at exactly the venues that create liquidity.
• Manual freeze-and-thaw keeps standard transfers — but every new holder starts frozen and waits for the issuer to co-sign a thaw. Onboarding becomes a support ticket, and the issuer signs forever.

Token ACL is the third path: keep the freeze mechanism — the one lever the token program already enforces everywhere — but make thawing self-service against a published rulebook.

The Mechanics: Delegated Freeze, Permissionless Thaw

Three pieces make a Token ACL mint, and each is verifiable on-chain:

• Default-frozen accounts. The mint carries Token-2022's DefaultAccountState extension set to Frozen — every token account anyone creates starts locked.
• Freeze authority delegated to a program. The issuer hands the mint's freeze authority to a MintConfig PDA owned by the Token ACL program (TACLkU6…52TP). From then on, freeze and thaw run through code, not through the issuer's wallet.
• A published gate. The MintConfig points at a Gate Program that answers one question: can_thaw_permissionless(wallet). The mint's metadata declares it under a token_acl key so wallets and SDKs can discover it.

The holder experience collapses to one instruction: create your (frozen) token account, call the permissionless thaw, and the Token ACL program asks the gate whether you qualify. If yes, your account unlocks in the same transaction — no issuer signature, no waiting. If the gate says no, you stay frozen. That is the whole trick: the issuer's compliance rules became a public, self-service API.

The Foundation ships a reference gate — the Allow/Block List program (GATEzz…iULz) — with four modes:

And because sRFC-37 only specifies the interface between Token ACL and gates, an issuer can replace the reference gate with anything — an on-chain KYC registry, an oracle-driven sanctions feed, an identity protocol — without touching the token itself.

What's Actually Live: the Chain, Not the Press Release

The standard was proposed in October 2025, the official guide with mainnet program addresses published January 12, 2026 — and the program's own transaction history says the rest. Its first mainnet transaction landed on March 6, 2026; its most recent, three days before this post. Total transactions ever: 514. This is genuinely early.

Early — but not theoretical. Pull a recent transaction and decode the mint it touches, and you find real institutional money:

A regulated French tokenized fund, running the textbook sRFC-37 setup — plus the rest of the institutional Token-2022 stack: pausable transfers, a permanent delegate, permissioned burn, a mint close authority. Keep that list in mind; it is the second half of this story.

The Honeypot Problem — and the Check That Actually Works

Here is the collision. DefaultAccountState: Frozen plus an active freeze authority is the classic honeypot signature — the pattern scam tokens use so buyers can receive but never sell. Every scanner rightly screams at it. But it is also, byte for byte, the shape of every compliant sRFC-37 token. As RWA issuance grows, scanners face a choice: learn the standard, or misread an entire asset class as scams — and train users to ignore the warning that actually matters.

The tempting shortcut is to trust the metadata: if the mint declares token_acl, call it permissioned. That shortcut is a vulnerability. Metadata is free-form — any scammer can paste a token_acl field into a honeypot and inherit the standard's legitimacy. The claim costs nothing.

What cannot be faked is account ownership. The verification that holds:

• 1 — The mint is default-frozen (the extension is on and set to frozen).
• 2 — The freeze authority is an account OWNED by the Token ACL program. Not "matches a claimed address" — you fetch the freeze authority's account and check its owner. Only the Token ACL program can own its MintConfig PDAs.
• 3 — The metadata declares the gate, so you can tell the holder which rulebook decides their thaw — the official Allow/Block-List gate, or a custom program worth reading before you buy.

I shipped exactly this three-condition check into xroot's free token audit this week. On eurSPKCC it now reads "permissioned token — freeze runs through the Token ACL standard, thaw is self-service through the official gate" where every other tool still prints the honeypot warning. On a mint that merely claims the standard, it prints the harder flag.

Honest Reading: the Standard Doesn't Vouch for Everything

One thing a good audit must not do is let Token ACL launder the rest of the mint. Remember eurSPKCC's other extensions — pausable transfers, permanent delegate, permissioned burn. On an institutional token those exist for regulators: seize on a court order, pause in an incident, burn-and-reissue on a recovery. They are disclosed design. They are also, mechanically, total issuer power over your balance — and Token ACL verifies the freeze mechanism only. A scammer can run a real, verified Token ACL setup and keep a permanent delegate that drains wallets.

So the honest verdict for a permissioned token is two sentences, not one score: this token follows the official standard for who may hold it — and its issuer can freeze, pause, seize, or burn your position, by design. Whether that is fine depends entirely on who the issuer is. For a regulated fund with a prospectus, it is the product working. For an anonymous team, it is the same red flag it always was.

What This Means From Here

• For issuers: permissioned tokens on Solana stopped being a custom-engineering project. Mint with default-frozen state, delegate freeze to Token ACL, pick a gate mode, declare it in metadata — and holders onboard themselves against your rulebook.
• For holders: a frozen-by-default token is no longer automatically a scam — and no longer automatically safe. The question moved from "is there a freeze authority?" to "who holds it, and through what?"
• For tooling: 514 transactions in, this is the cheapest moment there will ever be to learn the standard. The RWA wave will not wait for the scanners.

Sources: the Token ACL documentation, the official sRFC-37 guide, the token-acl and ABL gate repositories, the sRFC-37 forum thread, and the Token ACL program's own mainnet history and the eurSPKCC mint, read directly from the chain on August 30, 2026.