> ## Documentation Index
> Fetch the complete documentation index at: https://new-docs.squads.so/llms.txt
> Use this file to discover all available pages before exploring further.

# How Squads works

> Multisig accounts, proposals, and onchain enforcement

Squads is a multisig platform on Solana where multiple keys must approve actions before they execute. This page covers the core concepts: members, thresholds, the proposal lifecycle, and onchain enforcement.

## What is a multisig?

A multisig (multi-signature) is an onchain account that requires more than one person to approve actions. Instead of a single wallet where one key controls everything, a multisig distributes control across multiple keys so no one person can act alone.

On Squads, a multisig account is called a **Squad**. Each Squad has a set of members, a configurable approval threshold, and built-in policies for access control, all enforced onchain by Solana's validator network.

## Members and keys

Each Squad has a set of **members**. A member is a Solana wallet (Phantom, Backpack, Ledger, or any other Solana wallet) added to the Squad. Each wallet added counts as one member.

Most teams add one wallet per person. However, one person can add multiple wallets as separate members — for example, a daily wallet and a hardware wallet. This is useful for small teams that need key redundancy without adding more people.

If one key is compromised, the attacker can't act alone. If one key is lost, the remaining members can still operate, provided enough keys remain to meet the threshold.

## Thresholds

The **threshold** is the number of approvals required to execute any action. A 2-of-3 threshold means two out of three members must approve before a proposal can execute. Only members with the Voter permission count toward the threshold.

| Configuration | Meaning | Typical use |
| - | - | - |
| **2 of 3** | 2 approvals from 3 members | Small teams |
| **3 of 5** | 3 approvals from 5 members | Mid-size teams |
| **4 of 7** | 4 approvals from 7 members | Large teams, high-value treasuries |

<Warning>
  Avoid a threshold of 1 (single point of failure) or equal to total members (one lost key locks the Squad). Recommended: 2-of-3 or 3-of-5.
</Warning>

## The proposal lifecycle

Every action in a Squad (sending tokens, changing settings, upgrading a program) follows the same four steps:

<Steps>
  <Step title="Create">
    A member initiates an action, creating a **proposal**: an onchain record of the intended action, pending approval.
  </Step>

  <Step title="Review">
    The proposal appears in the **Transactions** queue. All members can inspect what will happen, who created it, and when.
  </Step>

  <Step title="Approve or reject">
    Members vote on the proposal. Each vote is recorded onchain. To approve, enough members vote yes to meet the threshold. To reject, enough members vote no to make approval impossible (e.g., a 2-of-5 Squad needs 4 rejections).
  </Step>

  <Step title="Execute">
    Once the threshold is met, any member with execute permission submits the transaction. The action takes effect onchain.
  </Step>
</Steps>

This lifecycle applies to all actions: token transfers, member changes, threshold adjustments, program upgrades, and validator key operations.

## Roles and permissions

Members can have different levels of access:

* **Proposer.** Create proposals but can't approve or execute.
* **Voter.** Approve or reject proposals.
* **Executor.** Submit approved proposals to the network.

These roles let teams separate responsibilities. For example, operational staff can initiate payments while senior members approve them.

For details, see [Roles and permissions](/app-guide/members/permissions).

## Programmable policies

**Spending Limits** let designated members execute transfers below a set amount without full approval, useful for routine expenses.

**Time Locks** add a mandatory delay between approval and execution, giving members time to review approved proposals before they take effect.

Both are enforced onchain and can't be bypassed without meeting the Squad's threshold.

## Onchain enforcement

Squads runs on [Squads Protocol](/developers/overview). All approval logic, thresholds, and policies are enforced onchain by Solana's validator network, not by Squads Labs or any centralized party.

Your Squad is fully self-custodial. No third party can access, freeze, or move your assets. Squads Labs builds the interface and protocol but has no control over your account.

## Next steps

<CardGroup cols={2}>
  <Card href="/getting-started/create-a-squad" title="Create a Squad">
    Set up your multisig account
  </Card>

  <Card href="/resources/multisig-best-practices" title="Best practices">
    Threshold, key management, and security recommendations
  </Card>
</CardGroup>

Choose your quickstart: [Treasury](/getting-started/treasury-management) · [Trading & DeFi](/getting-started/trading-and-defi) · [Programs](/getting-started/program-and-token-management) · [Validators](/getting-started/validator-operations)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.