Multisignature Accounts

Multisignature accounts are a powerful, natively-supported security and governance feature on Algorand that require multiple parties to approve transactions. Think of a multisignature account as a secure vault with multiple keyholes, where a predetermined number of keys must be used together to open it.

For example, a multisignature account might be configured so that any 2 out of 3 designated signers must approve before funds can be transferred. This creates a balance between security and operational flexibility that’s valuable in many scenarios:

Treasury management for organizations where multiple board members must approve expenditures
Shared accounts between business partners who want mutual consent for transactions
Enhanced security for high-value accounts by distributing signing authority across different devices or locations
Recovery options where backup signers can help regain access if a primary key is lost

Multisigs on Algorand

Technically, a multisignature account on Algorand is a logical representation of an ordered set of addresses with a threshold and version. The threshold determines how many signatures are required to authorize any transaction from this account (such as 2-of-3 or 3-of-5), while the version specifies the multisignature protocol being used.

Multisignature accounts are native to the protocol, not smart contracts. The address is deterministically derived from the ordered list of participant accounts, threshold, and version, and signature validation is enforced at the consensus layer.

This has important implications:

No deployment required: Multisig accounts exist as soon as they are computed
No contract risk surface: No contract logic to audit, upgrade, or trust
Protocol-level enforcement: Signature rules are enforced by consensus
Lower operational overhead: No dependency on third-party contract implementations

Some important characteristics to understand:

The order of addresses matters when creating the multisignature account. Using [A, B, C] creates a different address than [B, A, C].
The order of signatures does not matter when signing a transaction.
Multisignature accounts cannot include other multisignature accounts as participants.
You must send Algos to the multisignature address to initialize its state on the ledger.

Benefits & Implications

Benefits	Implications
Enhanced Security: Requires multiple signatures for transactions, reducing single key risk	Coordination Required: Signers must collaborate for every transaction
Customizable Authorization: Flexible threshold models (e.g., 2-of-3, 3-of-5)	Key Management: Each signer must securely manage their keys
Distributed Key Storage: Keys can be stored across devices, locations, or systems	Larger Transactions: Multisig transactions are larger than single-sig
Governance Enablement: Enables shared control and approval flows	Not Always Necessary: Simpler use cases may not require multisig
Composable with Smart Contracts: Can be combined with application logic (e.g., ARC-55)	Best Practices Required: Signer keys should be isolated and purpose-specific

Weighted Signers in Multisig Accounts

Algorand multisignature accounts support weighted participation by allowing the same address to appear multiple times in the signer list.

Because a multisig address is derived from an ordered list of addresses, each occurrence of an address is treated as an independent signer slot. This means you can effectively assign more “weight” to a specific participant by including their address multiple times.

How It Works

Consider a 2-of-4 multisig [A,A,B,C] (threshold of 2):

In this configuration:

Address A appears twice → effectively has 2 signing slots
Address B appears once → 1 signing slot
Address C appears once → 1 signing slot

This leads to the following behavior:

A alone can satisfy the threshold (by providing signatures for both of its slots)
B or C cannot execute a transaction alone
A + B, A + C and B + C can execute a transaction

Single-Signer Execution in a Multisig

In cases where a single address has enough weight to meet the threshold on its own, the transaction can be, constructed, signed, and submitted all by that single participant, without coordinating with others.

Even though only one party was involved, the transaction will still appear on-chain as a multisignature transaction, since it is authorized under the multisig account configuration.

This is expected behavior and reflects that the threshold was satisfied, not necessarily that multiple unique participants were involved.

How to Generate a Multisignature Account

The examples below demonstrate how to create a multisignature account that requires 2 signatures from 3 possible signers:

// Initialize an Algorand client instance and get funded accounts
const { algorand, dispenser, randomAccountA, randomAccountB, randomAccountC } = await setupLocalnetEnvironment()

// Create a 2-of-3 multisig account that requires
// only 2 signatures from the 3 possible signers to authorize transactions
const multisigAccountA = algorand.account.multisig(
  { version: 1, threshold: 2, addrs: [randomAccountA, randomAccountB, randomAccountC] },
  [randomAccountA.account, randomAccountB.account, randomAccountC.account],
)

// Fund the multisig account
await algorand.account.ensureFunded(multisigAccountA, dispenser, (10).algo())

// Send a payment transaction from the multisig account
// which will automatically collect the required number of signatures
// from the signing accounts provided when creating the multisig account
await algorand.send.payment({
  sender: multisigAccountA,
  receiver: randomAccountA,
  amount: algo(1),
})

Source

env: LocalnetEnvironment = setup_localnet_environment()
algorand_client = env.algorand_client
dispenser = env.dispenser
account_a = env.account_a
account_b = env.account_b
account_c = env.account_c

"""
Create a 2-of-3 multisig account that requires
only 2 signature from the 3 possible signers to authorize transactions
"""
multisig_account = algorand_client.account.multisig(
    metadata=MultisigMetadata(
        version=1,
        threshold=2,
        addresses=[
            account_a.address,
            account_b.address,
            account_c.address,
        ],
    ),
    signing_accounts=[account_a, account_b, account_c],
)

algorand_client.account.ensure_funded(
    multisig_account.address, dispenser, AlgoAmount(algo=10)
)

"""
Send a payment transaction from the multisig account
which will automatically collect the required number of signatures
from the signing accounts provided when creating the multisig account
"""
algorand_client.send.payment(
    PaymentParams(
        sender=multisig_account.address,
        receiver=account_a.address,
        amount=AlgoAmount(algo=1),
    ),
)

Source

$ ADDRESS1=$(goal account new | awk '{ print $6 }')
$ ADDRESS2=$(goal account new | awk '{ print $6 }')
$ ADDRESS3=$(goal account new | awk '{ print $6 }')

$ goal account multisig new $ADDRESS1 $ADDRESS2 $ADDRESS3 -T 2
Created new account with address [MULTISIG_ADDRESS]

Coordination & Signing

The protocol defines who must sign, but not how signatures are coordinated.

To execute a multisig transaction:

A transaction (or group) is constructed
It is shared with other signers
Each signer provides their signature
Signatures are assembled to meet the threshold
The final transaction is broadcast

This coordination is traditionally handled off-chain, requiring signers to exchange partially signed transactions via messaging, email, wallet tooling, or backend services.

This is the real friction point of multisig systems—not the cryptography, but the coordination.

There are three common approaches:

Manual coordination: Passing unsigned and partially signed transactions between participants
Backend-assisted coordination: A centralized service aggregates and distributes signatures
On-chain coordination (ARC-55): A standardized contract-based coordination layer

ARC-55: On-Chain Coordination Layer

ARC-55 is an Algorand Request for Comments that defines a standard for using on-chain smart contracts to coordinate multisig transaction signing, eliminating the friction of off-chain coordination between signers.

With ARC-55, pending transactions and their collected signatures are stored directly on-chain in a smart contract, giving every authorized signer a shared, trustless source of truth.

You can find full ARC-55 details here:

ARC-55

How ARC-55 Works

An ARC-55-compliant smart contract is deployed once per multisig group. The admin sets up the contract with the threshold and signer addresses. From there, the workflow is fully on-chain:

A signer generates a new transaction group nonce using arc55_newTransactionGroup()
Any authorized signer adds the transaction(s) to sign using arc55_addTransaction()
Each signer submits their signature using arc55_setSignatures()
Once the threshold of signatures is met, anyone can assemble and broadcast the final multisig transaction
Signers clean up by calling arc55_clearSignatures() and arc55_removeTransaction(), reclaiming their minimum balance requirements

Typical Lifecycle

Creator deploys an ARC-55 compliant smart contract
Admin sets threshold and signer addresses
A signer creates a transaction group nonce
Transactions are added to the group (MBR paid)
Signers submit signatures
Anyone submits the finalized transaction
State is cleared and MBR is reclaimed

Positioning

It’s important to understand that ARC-55 does not replace native multisignature accounts.

Instead, it sits alongside them as a coordination layer:

Native multisig (protocol layer): Defines who must sign and enforces signature validity
ARC-55 (application layer): Defines how signers coordinate and exchange signatures

You still end up submitting a standard multisignature transaction to the network. ARC-55 simply facilitates the process of getting there.