Introduction to Wallets 5
GREED Academy12 min read·Just now--
How serious money stays safe
Introduction
One key is a single point of failure. Serious protection is never built on a single point of anything.
In Lesson 4, you learned how attackers actually take wallets down, and the habits that keep you safe day to day. That covers most of what an individual user needs. This lesson covers what happens above that line.
There is a level of crypto activity where single-signature wallets stop being enough, no matter how careful the user is. Treasuries holding millions. Protocols controlled by a small team. DAOs making onchain decisions for thousands of token holders. Long-term holders with enough value that losing it would rewrite their life. At that level, the tools change. What takes their place is an architecture: multiple signers, programmable rules, time delays, governance layers, and stacks that back each other up when one of them fails.
By the end of this lesson, you will understand how multi-signature wallets work on Solana, what tools like Realms and Squads actually do, how vaults extend the model further, how DAO governance wallets tie voting to execution, and how all of these layers combine into something far stronger than any single piece on its own.
Revisiting Multi-Sig Fundamentals
At its base, a multi-signature wallet, usually shortened to multi-sig, replaces a single private key with a group of designated signers and a rule about how many of them must approve any transaction. The rule is called M-of-N. N is the total number of signers. M is the minimum number required to authorize an action. A 3-of-5 multi-sig has five signers in total, and any three of them must co-sign before the transaction executes. No single person can move funds alone. No single compromised key leads to a loss.
The shift this creates is more philosophical than technical. A single-key wallet trusts one person not to be compromised, not to make mistakes, not to turn malicious. A multi-sig trusts that at least M of N signers are still honest and uncompromised at the moment a transaction is signed. The math of trust spreads across multiple people, devices, and locations instead of concentrating in one.
Multi-sig is not new. Bitcoin has supported it at the protocol level for over a decade through the OP_CHECKMULTISIG opcode. On Ethereum, Safe (formerly Gnosis Safe) made contract-based multi-sig the default for serious treasuries and now secures tens of billions of dollars across the network. On Solana, multi-sig is implemented through onchain programs that handle signer management, proposal tracking, and transaction execution with the same low-latency profile Solana users expect.
What makes the modern version of multi-sig different from the Bitcoin original is flexibility. Today’s multi-sig tools can add role assignment, spending limits, time delays, and governance integration. The core idea is the same as it was in 2013, but the surrounding infrastructure has caught up to what treasuries actually need.
Solana’s Approach
Solana’s architecture prioritizes low latency and high throughput. Instead of the EVM, Solana runs programs compiled to eBPF, which keeps transaction costs low and execution fast. That difference matters for multi-sig because coordination overhead is already part of the friction. If every approval took thirty seconds and cost ten dollars in gas, multi-sig would be painful enough that most teams would avoid it. On Solana, a proposal, three approvals, and an execution can happen in under a minute for fractions of a cent.
Two tools dominate the space: Realms for DAO governance, and Squads for multi-sig wallet control. They solve different problems, they work well together, and most serious Solana projects use both.
- Realms for DAO Governance
Realms is often described as the home base for DAOs on Solana. It is built on the SPL Governance program, the onchain infrastructure that handles proposals, votes, and token-weighted or NFT-weighted governance. A treasury placed under Realms governance operates under explicit rules: voting thresholds, quorum requirements, timelocks, and configurable approval paths for different kinds of actions. The way it works in practice is straightforward. Token holders (or NFT holders, depending on the configuration) have voting weight proportional to what they own. When someone wants to move treasury funds, upgrade a program, or change a parameter, they create a proposal inside Realms. Other holders vote. If the proposal passes the configured threshold, it moves to an “executed” state, which triggers the actual onchain action. Realms is what projects like Mango, Marinade, and others use to run their DAOs. Visiting the platform and clicking through real proposals is one of the fastest ways to understand how onchain governance actually feels from the inside, which is exactly what Lesson 6 will walk you through in detail. - Squads for Collaborative Wallet Control
Squads is the multi-sig layer most Solana users interact with directly. It is an onchain program that lets you create a shared wallet with multiple designated signers and a threshold rule. Every transaction becomes a proposal that eligible signers can approve or reject. Once the threshold is met, the transaction executes. Until then, it sits pending. The strength of Squads is in what it abstracts away. Under the hood it is a robust, audited Solana program handling signature management, account derivation, and transaction construction. What you see is a clean interface that looks like any wallet, except transactions pause for co-signer approval before moving. Squads and Realms are designed to work together. A DAO typically uses Realms for the deliberation layer, where token holders vote on what should happen, and a Squads multi-sig for the execution layer, where a smaller group of trusted operators actually signs the transactions that carry out the approved proposal. Realms owns the politics. Squads owns the keys. The two layers reinforce each other. Even if one is compromised, the other can catch the attack before funds move.
Vaults
A vault takes the multi-sig idea further by adding programmable rules to how assets are stored and released. In the simplest case, a vault is just a multi-sig address. In more advanced implementations, it becomes storage that enforces its own constraints, not storage that depends on the signers to do the right thing every time.
The most common vault feature is a timelock. When a transaction is approved, it does not execute immediately. It enters a waiting period, often 24 to 72 hours, during which the pending action is visible onchain. If something looks wrong, the community, the co-signers, or independent watchers have time to react, cancel, or raise alarms. For treasuries of meaningful size, that delay is often what turns a would-be catastrophe into a contained scare.
Other vault designs enforce daily withdrawal limits, cap single-transaction sizes, or restrict destinations. Some vaults are deposit-only under normal conditions and require a separate governance action to unlock withdrawals. Each rule narrows what an attacker can accomplish even if they manage to pass a malicious transaction through the signing layer.
On Solana, vaults appear in several forms. The Metaplex Vault Program is designed for NFT custody and fractionalization. It lets a single NFT or a set of NFTs remain locked until specific onchain conditions are met, often used in auctions or fractional ownership arrangements. For fungible tokens, teams frequently build custom vault programs tailored to their treasury rules, sometimes gating withdrawals behind a Realms vote or a Squads approval. Across all implementations, the core principle is the same: storage that thinks for itself.
DAO Governance Wallets
A DAO governance wallet is where deliberation meets execution. It is the onchain account that actually holds the funds or controls the program, but it only moves when a formal governance process says it should. The wallet does not belong to any one person. It belongs to the governance rules attached to it.
Realms implements this through the SPL Governance program’s three core concepts: governances, proposals, and votes. A governance is a specialized account that controls certain assets or programs. A proposal defines an action, for example sending 10,000 USDC to a developer wallet, or upgrading a smart contract. A vote reflects what the community decides. If a proposal meets the configured threshold (a simple majority, a supermajority, whatever the rules demand), it moves to the “executed” state, which triggers the actual onchain instruction. Because the governance account is the thing with authority over the underlying funds or program, no signature can bypass the proposal and voting process. The rules are enforced by the program itself, not by the people following it.
A typical execution flow in a fully layered setup looks like this. Token holders in Realms vote on a proposal, say a transfer of 10,000 USDC to a development wallet. The proposal passes. Realms instructs a Squads multi-sig that the action is authorized. The Squads multi-sig collects the required M-of-N signatures from its recognized signers, which might be core contributors or community-elected operators. If a vault with a timelock is involved, the transaction then enters the delay period before funds actually move. Each step is a fail-safe. Each step gives the community or key signers a chance to intervene if something looks wrong.
This is the core architecture of how large treasuries on Solana operate today. Lesson 6 will take a closer look at the governance side specifically: what it actually feels like to participate in a DAO, how voting works in practice, and where participation tends to break down.
What Multi-Sig Looks Like Under the Hood
You do not need to read code to understand what a multi-sig program actually does, because the logic itself is simple. A multi-sig program stores three things and enforces one rule.
The signer list is the set of public keys authorized to participate. When the multi-sig is created, these keys are recorded on the program account. A key that is not on the list has no authority, no matter what it tries to sign.
The threshold is the number M in the M-of-N. It is also recorded when the multi-sig is created and can only be changed through the multi-sig’s own rules. A 3-of-5 multi-sig has a threshold of 3.
The vote state is a running record of which signers have approved the current pending transaction. Every time a recognized signer approves, the program checks their key against the signer list, records their vote, and counts how many approvals have accumulated.
The rule it enforces is the threshold check. When a signer approves, the program counts the total approvals. If the count is below the threshold, nothing happens yet. If the count meets or exceeds the threshold, the program executes the actual transaction, which could be a token transfer, a program upgrade, or any other onchain action the multi-sig is authorized to take. Once the transaction executes, the vote state resets and the multi-sig is ready for the next proposal.
That is the entire concept. Real implementations like Squads add considerable complexity on top of this base, role assignment, re-entrancy protection, recovery paths, UI integration, advanced permissioning, but the core logic is always: store the signers, track the votes, execute when the threshold is met. Everything else is engineering around that idea.
Layering Security Through DAO Governance
Serious security is rarely built on a single mechanism. It is built by layering multiple mechanisms that each protect against a different failure mode. The goal is that no single compromise can reach the assets, because every attack has to defeat multiple independent systems.
A fully layered setup typically combines three protections.
A governance layer, usually Realms on Solana, records formal votes from a broader group of token holders or NFT holders. This is where the political legitimacy of an action is established. A malicious proposal that cannot get majority support dies here, before it ever reaches the signers.
An execution layer, usually a Squads multi-sig, handles the actual signing of transactions that carry out approved governance actions. Even if a governance vote is somehow manipulated, the multi-sig signers are a second line of review. A 3-of-5 Squad forces at least three independent signers to agree the action is legitimate before any transaction executes.
A constraint layer, usually vaults with timelocks or withdrawal limits, adds a final delay or cap on what the execution layer can actually do. If the governance layer is tricked and the execution layer is compromised, the constraint layer still forces the malicious transaction into a waiting period where community watchers have a chance to see what is happening and organize a response.
The logic of the stack is that every layer catches the failures of the layers above it. If token holders are manipulated into passing a bad proposal, the multi-sig signers can refuse to execute. If the multi-sig signers are compromised, the timelock delays execution long enough for the rest of the community to intervene. If all three layers fail at once, the problem is bigger than any onchain security design can solve. But in practice, most attacks only break through one layer before getting caught by the next.
This is how protocols on Solana survive incidents that would have wiped out simpler setups. Communities regularly share post-mortems from attempted exploits on places like the Solana Tech forums and DAO-focused channels, and the pattern that shows up most often is layered defense catching what single-layer protection would have missed. No system is perfectly trustless. But the distance between “compromised signer” and “drained treasury” can be enormous when the architecture is built right.
Why This Matters
Most readers of this lesson will not run a DAO treasury. You do not need to. The reason this architecture matters even for individuals is that the same principles scale down.
If you hold a meaningful amount of crypto, a 2-of-3 Squads multi-sig with one key on a hardware wallet, one on your phone, and one in a secure backup location is dramatically safer than any single-key setup, including a hardware wallet on its own. Lose one key and you can still operate. Have one compromised and an attacker still cannot touch your funds. The operational friction is real, and the setup is not for money you move every day, but for long-term holdings it is one of the highest-leverage security upgrades available.
Even if you never use a multi-sig yourself, understanding how these layers fit together changes how you evaluate the projects you interact with. When a protocol announces its treasury is controlled by a 5-of-9 multi-sig under a Realms governance with a 48-hour timelock, you now know exactly what that means and how much protection it actually provides. When a project’s treasury is controlled by a single key held by an anonymous founder, you know what that means too.
In the next lesson, we will go deeper into the governance side. What a governance wallet is from the user’s perspective, how Realms works when you are the one voting, the participation problem that quietly undermines most DAOs, and where onchain governance is heading.
Resources
If you want to learn more about wallets review some of these:
- Watch: Solandy: Multisig Wallets, Solana Tutorial | The Next Billion #10: Squads, Building Solana’s Multisig Wallet Standard
- Read: Ledger Academy: What Is a Multisig Wallet? | Fystack: Squads, From Zero to the Multisig Protocol Securing $10B on Solana
- Try It: Set up a practice multi-sig on Squads using two wallets you control. Create a 2-of-2 Squad, send a small amount of SOL to it, then try sending it back out. Experience what it feels like to require multiple approvals before a transaction executes.
