Securing assets on Solana with enterprise-grade controls
In Part 1, we examined how institutions can integrate compliance frameworks and on-chain regulatory controls into their Solana operations. In this second chapter, we turn to the practical core of institutional security—who controls keys, how they’re managed, and how policies are enforced.
On Solana, this means more than safe storage. It’s about designing layered systems where custody, key management, and policy logic reinforce each other. When done right, these layers enable institutions to move quickly, operate transparently, and meet compliance requirements without compromising decentralization.
Why this layer matters
Traditional finance relies on clear operational boundaries: treasuries, signers, auditors, and policies. Translating that discipline into a high-throughput chain like Solana introduces new challenges.
Solana’s speed amplifies the need for control. Transactions finalize in milliseconds—so safeguards must live inside the infrastructure, not in someone’s inbox waiting for approval. Institutional-grade Solana deployments care about three principles:
Auditability with speed — policy engines and governance flows must operate as quickly as Solana, without bottlenecks.
Defence in depth — no single entity should hold all the keys or control every layer. Custody, wallet, and governance roles must remain distinct.
Compliance by design — instead of enforcing rules manually, policies should be written into token logic, wallets, and on-chain programs.
The result is infrastructure that can scale both in transaction volume and in trust.
Mapping the infrastructure
Institutions on Solana now assemble their operational stack across three layers: custody, key management, and on-chain governance. Each serves a unique role, but they work best when connected.
Custody
This is the vault—the secure reserve layer. Custodians like Fireblocks, Anchorage Digital, BitGo, and Copper provide regulated environments for institutional holdings. They offer:
Chartered trust structures and insurance coverage
Support for staking and liquid staking (SOL, JitoSOL, Marinade)
SOC 1/2 reporting, policy segregation, and off-exchange settlement
Custody remains the anchor of institutional control, but it is no longer where operations stop. Increasingly, it’s paired with policy-driven key management for day-to-day movement of assets.
Key Management & Policy Engines
This layer governs how assets move. Multiparty computation (MPC) wallets like Fireblocks, Fordefi, and Utila allow institutions to define transaction policies that mirror internal governance.
A single Solana transaction might pass through:
a proposer initiating it,
multiple approvers reviewing,
spending limits or destination whitelists,
and a timelock before execution.
These wallets provide granular control without ever exposing private keys. They integrate with Solana’s native instruction model, so program calls and batched transactions can be pre-approved and logged.
For lighter-weight consumer-facing apps, embedded wallets like Privy or Web3Auth enable non-custodial access with passkeys or email login—while institutions still enforce their own policies server-side.
On-chain Governance & Policy Enforcement
Even with custody and wallet layers in place, on-chain enforcement closes the loop. Platforms like Squads v4 bring enterprise-grade multisig functionality directly onto Solana, supporting:
Timelocks and spending limits
Role-based access and sub-accounts
Address Lookup Table (ALT) support for complex transactions
Meanwhile, Realms—Solana’s governance framework—enables proposals, votes, and execution rules for DAO or corporate treasuries.
At the token level, Solana Token Extensions introduce features such as transfer hooks, required memos, non-transferable flags, and permanent delegates. Combined with the Solana Attestation Service, institutions can enforce KYC or accreditation checks at the protocol layer itself.
Check out Part 1 for more on both:
Together, these tools turn policy into programmable infrastructure.
How institutions are putting it together
Across Solana, we’re seeing three dominant architectural patterns.
1 · Strategic Treasury + Daily Ops
Large institutions hold reserves with a qualified custodian while operating through an MPC wallet for working capital. Significant actions—such as treasury rebalancing, protocol upgrades, or changes to mint authority—are routed through a Squads v4 multisig with timelocks and approvals. Tokens issued under this model utilize Solana Token Extensions to ensure that only verified, authorized addresses can transfer funds. The result: cold-storage safety meets on-chain agility.
2 · Governed DAO Treasuries
For protocols that prioritize transparency, governance tools like Realms anchor every major decision. Sub-accounts under a Squads multisig handle day-to-day spending, while larger transfers require community votes. Each proposal and transaction leaves an immutable, auditable trail. This model transforms treasury management into a public process—something only Solana’s throughput makes viable at scale.
3 · Permissioned Tokenization
Projects issuing RWAs, stablecoins, or other regulated instruments on Solana have several viable patterns. Token Extensions are gaining traction, but they aren’t the default. Many teams still launch with the standard SPL Token and enforce policy around the asset—via MPC wallet whitelists and spend limits, Squads/Realms-based approvals, or custom programs that gate mint/burn/transfer flows.
When Token Extensions are used, transfer-hook logic can call external policy services (e.g., allow/deny lists or SAS-backed credentials) before settlement. Embedded wallets may simplify end-user onboarding, but issuance and redemption typically remain behind institutional controls and on-chain governance. The takeaway: compliance can live in wallet policy, in program logic, or at the token layer—mature deployments often combine these layers rather than rely on just one.
Avoiding common pitfalls
Even mature institutions misstep when they treat off-chain policy as sufficient.
MPC ≠ governance — Multiparty wallets protect keys but don’t replace on-chain oversight. Major authorities should still be controlled by a multisig or governance module.
Policy drift — Rules that live in documents rather than code inevitably fall behind. Embedding them in wallet logic, transfer hooks, or multisig timelocks ensures consistent execution.
Centralization of control — When one provider handles custody, wallet, and governance, segregation of duties disappears. Distribute responsibilities intentionally.
Lagging with protocol changes — Solana evolves fast. Providers should demonstrate active support for new primitives like ALTs, fee-payer abstraction, or token extensions.
Choosing partners wisely
When evaluating your stack, the questions to ask are simple but revealing:
Does your custodian support Solana’s ecosystem, including staking, liquid staking, and program integrations?
Can your wallet or MPC engine define granular policies, simulate transactions, and log approvals?
Does your on-chain governance layer include formal audits and timelocks?
Are your tokens using transfer hooks or attestation checks to enforce compliance automatically?
And finally—does each layer remain independent enough to preserve true defense-in-depth?
The takeaway
Institutions building on Solana are no longer asking if the ecosystem can meet their security and compliance needs, they’re architecting the how. The combination of regulated custodians, MPC wallets, on-chain governance, and programmable token controls creates a framework that rivals traditional finance in control while exceeding it in transparency.
The key is integration: ensuring that every approval, policy, and limit is closely tied to the transaction it governs.
In the next part of this series, we’ll explore Payments & Fiat Connectivity: The power of Solana Pay and native USDC.
Stay tuned.
Dirt
— Exo Research