Introduction
In June 2026, Spiko launched its tokenized funds on Solana. As described in our previous articles, we aim to be blockchain agnostic: our infrastructure is designed to scale across networks with minimal friction. But each chain forces us to rethink something we take for granted, and Solana was a challenge of a different kind.
On every network we had integrated so far (EVM, Starknet and Stellar) we wrote our own token contract. All the rules that make a regulated fund share behave correctly (who can hold it, who can transfer it, how it is issued and redeemed) lived in code we authored, deployed, and audited. On Solana, the way of thinking is inverted: you don’t write a token contract at all. You compose the token out of Token-2022’s native extensions and a handful of standard ecosystem programs, and you only write custom code for the logic that doesn’t exist yet.
This article covers what that shift looks like in practice: assembling a compliant token from Token-2022 extensions, the single program we did write, and the operational specificities of Solana.
Role Management
On EVM, access control is itself a contract: our permission manager is a single registry that every other contract queries to know who is allowed to mint, burn, or freeze. One place grants and revokes every role.
Solana pushes us the other way. There is no contract that every other contract calls into, and “granting a role” to an address isn’t really a native concept. Instead, each capability carries its own authority, set directly where that capability lives. The result is not one role manager but a set of dedicated authorities:
- a mint authority and a mint initiator for issuance,
- a burn authority that controls burning,
- a freeze authority (delegated to Token ACL) and a gate authority for whitelisting,
- a pause authority, a mint-close authority, a metadata-update authority, and a permanent delegate on the mint itself.
Each is an independent key (in practice a separate Squads multisig), so compromising one never escalates into the others.
Token-2022
On EVM, an ERC-20 is your code: you deploy a contract and the token is that contract. On Solana, tokens don’t have their own code at all. Every token is just an account owned by one program that defines how all tokens behave: Token-2022 program (the successor to the original SPL Token program). Token-2022 is the standard token program and is highly customizable. It has a bunch of extensions that can be set up on the mint at creation time. Instead of inheriting from a base contract and overriding behavior, you pick the extensions you need and configure them.
For our funds, that means the token is defined by the set of extensions we turn on. We enable six:
| Extension | Configuration | Why we need it |
|---|---|---|
DefaultAccountState | Initialized to Frozen | New token accounts start frozen: nobody holds shares until allowlisted |
PermanentDelegate | Set to our delegate authority | A delegate authority for regulatory action, set immutably at creation |
MetadataPointer | Pointing at the mint itself | On-chain name, symbol, and URI, with the mint itself holding the metadata |
PausableConfig | Pause authority, initially unpaused | The ability to pause all transfers of a given token |
MintCloseAuthority | Set to our close authority | The ability to close the mint account if a fund is wound down |
PermissionedBurn | Set to our burn authority | Every burn requires a co-signature from a dedicated burn authority |
Alongside these we attach the TokenMetadata extension, storing the name, symbol, and URI directly on the mint.
Permissioned Tokens
The most distinctive part of the integration is how we enforce regulation. On EVM, every transfer calls into a permission contract that checks, at execution time, whether sender and recipient are allowed. Compliance is control flow: code runs on every transfer.
On Solana, compliance is state. Thanks to DefaultAccountState = Frozen, a freshly created token account cannot send or receive anything. A wallet becomes usable only once its account is thawed, and it can be frozen again at any time. The question “can this wallet transact?” is answered by a single bit on the account.
This is a deliberate choice. Token-2022 offers a TransferHook extension, another way to enforce permissions, by running custom validation logic on every transfer. We chose not to use it: a transfer hook makes the token non-standard, requiring every counterparty to pass extra accounts and understand our logic, which breaks composability with the broader DeFi ecosystem. A frozen-by-default token, by contrast, is an ordinary Token-2022 token that any DEX, custodian, or wallet can integrate without special handling. The permissioning lives entirely in whether each account is thawed.
To do so, we rely on two standard ecosystem programs:
- ABL Gate maintains the allow and block lists in composite mode: the allow list encodes KYC, the block list encodes sanctions, and the block list always wins.
- Token ACL holds the delegated freeze authority and exposes a permissionless thaw: anyone can thaw a wallet, but only if that wallet is on the allow list and not on the block list.
Whitelisting an investor therefore becomes “add to the allow list, then thaw”. De-whitelisting is the mirror image: freeze the account and remove the wallet from the allow list.
Minter Custom Smart Contract
The minter implements the same controlled minting flow we described in our rate-limited minting article: a mint-initiator proposes a mint, and amounts beyond a per-token daily limit require a separate admin approval before they execute. As on EVM, the person who initiates a mint is not the person who can approve a blocked one, and a compromised initiator key can only ever mint up to the daily cap.
Because Solana programs are stateless, this policy lives entirely in Program Derived Addresses (PDAs): a MinterConfig for the roles, a MintDailyLimit per token that resets every 24 hours, and a MintOperation per request tracking its status.
Redemption Workflow
Issuance needed a custom program; redemption did not. On EVM and Stellar, redemptions flow through a dedicated redemption contract that records each request on-chain. On Solana we deploy nothing for this: the workflow is a standard token transfer followed by a permissioned burn, orchestrated off-chain.
It runs in two steps:
- Initiation. The investor transfers their shares to a Spiko-controlled redemption vault with a plain
TransferChecked, attaching a memo that carries a unique salt. The salt ties the on-chain transfer back to the off-chain redemption request. - Execution. Once the redemption has been processed off-chain, Spiko burns the shares from the vault. Thanks to the
PermissionedBurnextension, this burn requires two signers: the vault authority and a separate burn authority, so no single key can destroy shares on its own.
Operations
Relaying and Squads
Many of these authorities are immutable: an extension like PermanentDelegate or MintCloseAuthority is fixed at mint creation and can never be reassigned. Pointing such an authority at a raw operational key would be a trap. The day that key has to be rotated, we would be stuck. So we never set an authority to a plain wallet. We set it to a Squads v4 multisig (Solana’s equivalent of EVM’s Safe). The on-chain authority is the Squad, which is immutable and fixed forever, while the operational wallet that actually drives it is merely a member of that Squad. Rotating an operator then comes down to registering a new member and removing the old one: the authority itself never changes.
For the operational squads the relayer drives day to day, the gate authority over the allow and block lists, and the Token ACL authority over freeze and thaw, the approval threshold is 1: a single registered operator is enough to act. Every action is wrapped in a Squads vault transaction, where the relayer serializes the inner instructions and emits the four-step create → propose → approve → execute sequence so the multisig executes them under its own authority.
Signing itself is delegated to DFNS. A single transaction can require several signers (sponsor, burn authority, and sender) and the relayer assembles their signatures cumulatively before broadcasting.
Indexing
Indexing on Solana breaks the pattern we use elsewhere. There are no event logs like EVM’s. Instead, our indexer reconstructs events by decoding the instruction discriminators in each transaction and reading their arguments and accounts. Transfers, mints, burns, freezes, and thaws are all recovered this way, and the preceding memo instruction is matched back to its operation to recover the salt. It is more work than parsing logs, but it fits the same indexer architecture we standardized across every chain.
Final Thoughts
Solana asked us to think differently more than to build more. A regulated fund token, which on every other network is a contract we author, here is assembled from standard parts: Token-2022 extensions for the token itself, ABL Gate and Token ACL for compliance, Squads for governance, and a single small custom minter program.
That model has real trade-offs. Immutable extensions mean the design discipline moves entirely up front.
As with Stellar, the biggest win is that the integration took weeks, not a rearchitecture, validating our blockchain-agnostic approach.