As tokenized funds and other permissioned onchain products move from pilots to production, one of the key infrastructure challenges has been token-level access control that is enforceable without sacrificing DeFi compatibility.
On Solana, the existing options have forced a tradeoff. Transfer hooks can enforce restrictions, but many DeFi protocols avoid them because they add custom logic to the transfer path. Default Account State allows accounts to start frozen, but usually requires manual thawing by the freeze authority, which creates onboarding and operational friction.
Neither approach cleanly delivers both compliance and standard token behavior.
sRFC37 changes that.
What Token ACL Does Differently
Token ACL is a new standard from the Solana Foundation for permissioned tokens. Rather than intercepting each transfer, it uses a permission de-escalation model built on Token-2022’s Default Account State extension.
Token accounts begin frozen by default. A Gate Program defines who can thaw them using an allowlist, blocklist, or other compliance logic. If a wallet satisfies the Gate Program’s criteria, the user can thaw their own account without issuer intervention. If that wallet is later no longer approved, the account can be frozen again.
The key design difference is that Token ACL does not modify the transfer path. Transfers remain standard Token-2022 transfers. Compliance is enforced at the account level, not the transfer level.
That preserves standard token behavior while enabling permissioned access control.
For a deeper technical comparison between transfer hooks and Token ACL, Exo Technologies published a useful analysis: Are sRFC 37 Permissioned Tokens Replacing Transfer Hooks?
GLAM’s Integration
GLAM is bringing Token ACL to mainnet as part of its institutional vault infrastructure.
When a manager creates a vault with compliance enabled, the vault’s share tokens are issued under the Token ACL standard. That means:
Subscriptions are gated: Unapproved wallets cannot subscribe. The transaction is rejected onchain.
Transfers are restricted to verified holders: Vault shares cannot move to wallets that have not satisfied the vault’s access requirements.
Compliance status is enforceable: If a wallet’s status changes, its token account can be frozen or unfrozen accordingly. The holder retains economic ownership throughout, while transferability depends on the account’s current status.
This is compliance enforced by program logic rather than policy documents or manual follow-up. GLAM’s fine-grained delegate access control enables vault managers to securely offload list management to trusted third parties. For managers, that means less operational overhead and fewer failure points. For allocators, it means access controls that are enforced in the system itself.
What Comes Next: Dynamic Lists
Static allowlists are only a starting point. Institutional compliance does not run on manually maintained wallet lists. KYC and KYB status changes. Sanctions and AML screening results change too.
The Solana Foundation’s ABL (Allow Block List) Gate Program is a reference implementation for standard allowlist and blocklist use cases. But sRFC37 is designed to be extensible: any program that implements the Gate Program interface can serve as the compliance layer.
We are exploring custom Gate Programs that connect Token ACL to external compliance infrastructure.
A Dynamic Allowlist could integrate with KYC, KYB, and ongoing screening providers, so wallets are approved or removed automatically as status changes.
A Dynamic Blocklist could integrate with sanctions and AML screening systems, so flagged wallets are blocked continuously at the protocol level.
The goal is a provider-agnostic architecture where managers choose the compliance stack that fits their requirements, while the Gate Program bridges offchain screening with onchain enforcement.
This is where institutional DeFi needs to go: compliance that is continuous, automated, and enforced by code.
Why This Matters
Institutional capital needs more than tokenization. It needs infrastructure that can enforce who is allowed to hold and move assets without isolating those assets from the rest of the ecosystem.
Token ACL is an important step in that direction, and GLAM is bringing it into production for institutional vault infrastructure.
For managers, that means compliant vault tokens that are easier to operate. For allocators, it means onchain exposure with controls their compliance teams can evaluate. For Solana, it removes one of the biggest blockers to institutional participation: permissioned assets that still work in a composable onchain environment.
Reach out to design your permissioned vault architecture, or get started with GLAM today.
