The v4 program is the latest upgrade to Squads Protocol. It expands the capabilities of multisig with several new features, including time locks, spending limits, roles, sub-accounts, multiple-party payments and support for address lookup tables. This program was designed to make it easier for developers to leverage multisig consensus and account abstraction on Solana, facilitating the creation of fintech-like applications and enhancing the secure management of on-chain assets.
This repository contains:
- The Squads Protocol v4 program.
- The
@sqds/multisigTypescript SDK to interact with the v4 program. - The
squads-multisigcrate to interact with the v4 program in Solana programs as well as Rust client applications.
This fork is deployed to the DoubleZero ledger SVM:
- DoubleZero mainnet-beta:
DZSQabvc4J8VTvjphhadVr9PDsBEqLyxQKYhbFiYfVoS
The upstream Squads deployments on Solana and Eclipse run a different program ID and are unaffected by this fork.
The checked-in typedoc output under sdk/multisig/docs is deliberately left as it
was upstream. It documents the Squads deployment, not this one, so its program IDs
and its references to Solana clusters and to solana-verify do not describe this
fork. Nothing in this repository regenerates it.
By interacting with this program, users acknowledge and accept full personal responsibility for any consequences, regardless of their nature. This includes both potential risks inherent to the smart contract, also referred to as program, as well as any losses resulting from user errors or misjudgment.
By using a multisig, it is important to acknowledge certain concepts. Here are some that could be misunderstood by users:
- Loss of Private Keys: If a participant loses their private key, the multisig may not be able to execute transactions if a threshold number of signatures is required.
- Single Point of Failure with Keys: If all keys are stored in the same location or device, a single breach can compromise the multisig.
- Forgetting the Threshold: Misremembering the number of signatures required can result in a deadlock, where funds cannot be accessed.
- No Succession Planning: If keyholders become unavailable (e.g., due to accident, death), without a plan for transition, funds may be locked forever.
- Transfer of funds to wrong address: Funds should always be sent to the multisig vault account, and not the multisig account address. Due to the design of the Squads Protocol program, funds deposited to the multisig account may not be recoverable.
- If the config_authority of a multisig is compromised, an attacker can change multisig settings, potentially reducing the required threshold for transaction execution or instantly being able to remove and add new members.
- If the underlying SVM compatible blockchain undergoes a fork and a user had sent funds to the orphaned chain, the state of the blockchain may not interpret the owner of funds to be original one.
- Users might inadvertently set long or permanent time-locks in their multisig, preventing access to their funds for that period of time.
- Multisig participants might not have enough of the native token of the underlying SVM blockchain to pay for transaction and state fees.
You can interact with the Squads program via our SDKs.
List of SDKs:
- Rust crate: squads-multisig-program
- Typescript SDK: @sqds/multisig
Documentation:
- You can find the SDK documentation including instructions and helper functions here: https://docs.squads.so/main/v/development/development/overview.
The program builds inside Docker, so no Solana toolchain, Anchor CLI, or avm is
needed on the host. Only Docker itself is required.
make build
That writes target/deploy/squads_multisig_program.so. The build runs in
solanafoundation/solana-verifiable-build:2.3.13, which is an amd64-only image, so on
an arm64 host it runs emulated and the first build is slow. The cargo registry, the
cargo git checkouts, and the SBF target/ directory are BuildKit cache mounts, so
later builds reuse them and recompile only what changed.
make clean-docker prunes those caches. BuildKit offers no project-level filter for
cache mounts, so it matches on the program name and could in principle match another
project whose build command contains the same text.
To run the test suite:
make test
That builds the program with --features testing and runs the TypeScript suite
against a solana-test-validator in a container, so no Solana toolchain and no Anchor
CLI are needed on the host. The node modules have to be installed once first:
yarn
The checked-in sdk/multisig/idl/squads_multisig_program.json is the Anchor 0.29 spec,
which is what solita consumes. Anchor 0.30 changed the format, so the file uploaded to
the on-chain IDL account is generated from it:
make idl
That runs anchor idl convert in a container and writes
target/squads_multisig_program.0.30.json. It is derived from the checked-in IDL, so
it is a build artifact rather than a committed file. Its address comes from the source
IDL, so regenerating it after a program ID change needs no extra arguments.
To write the IDL account, so a block explorer pointed at a DoubleZero RPC endpoint can decode instructions and accounts:
make idl-init
That regenerates the IDL first, so it cannot upload a stale one. The program has to be deployed already, and the signing keypair has to be its upgrade authority. It also pays rent for the IDL account.
The keypair defaults to ~/.config/solana/id.json. For one kept elsewhere:
make idl-init WALLET=/path/to/authority.json
make idl-upgrade replaces the contents of an existing IDL account after a redeploy,
and takes the same options. Both default to the DoubleZero mainnet-beta endpoint;
override with RPC=<url>.
Explorers differ in whether they use this. Solana Explorer fetches the IDL account from whatever RPC endpoint it is pointed at, so it decodes instructions and accounts on a custom cluster. Solscan decodes from its own indexed program registry rather than a live lookup, so it shows raw bytes for a program on a custom cluster even when the IDL account is present and correct.
Instructions on how to interact with the Squads V4 program can be found in the Squads developer portal.
Squads Protocol v4 has undergone various independent audits by leading cybersecurity and blockchain smart contract auditing firms.
Below is a list of audit reports pertaining to the v4 program. Each entry enumerates the responsible auditor and is accompanied by a corresponding GitHub link for review:
- OtterSec: View full report
- OtterSec 2024: View full report
- Ottersec 2024 Final: View full report
- Neodyme: View full report
- Neodyme 2024: View full report
- Neodyme 2024 Final: View full report
- Certora + Formal verification: View full report
- Certora Audit + Formal Verification (December 2023): View full report
- Certora Audit + Formal Verification 2024 Final: View full report
- Trail of Bits: View full report
The final and fully audited commit hash of the program is 64af7330413d5c85cbbccfd8c27a05d45b6e666f
The primary license for Squads Protocol v4 is the AGPL-3.0 license, see LICENSE. The following exceptions are licensed separately as follows:
- The file https://github.com/Squads-Protocol/v4/blob/main/programs/squads_multisig_program/src/utils/system.rs is derived from code released under the Apache 2.0 license at https://github.com/coral-xyz/anchor/blob/714d5248636493a3d1db1481f16052836ee59e94/lang/syn/src/codegen/accounts/constraints.rs#L1126-L1179.
- The file https://github.com/Squads-Protocol/v4/blob/main/programs/squads_multisig_program/src/utils/small_vec.rs is derived from code released under both the Apache 2.0 license and the MIT license at https://github.com/near/borsh-rs/blob/master/borsh/src/de/hint.rs and https://github.com/near/borsh-rs/blob/master/borsh/src/ser/mod.rs.
To the extent that each such file incorporates code from another source, such code is licensed under its respective open source license as provided above, and the original open source code is copyrighted by its respective owner as provided above.