# 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](https://dev.algorand.co/concepts/accounts/funding) 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:

- [Utils (TypeScript)](https://dev.algorand.co/concepts/accounts/multisig/#tab-panel-718)
- [Utils (Python)](https://dev.algorand.co/concepts/accounts/multisig/#tab-panel-719)
- [goal](https://dev.algorand.co/concepts/accounts/multisig/#tab-panel-720)

```javascript
// 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),

})
```

```python
env: LocalnetEnvironment = setup_localnet_environment()

algorand_client = env.algorand_client

disperse = 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),

),

)
```

```
$ 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:

1. A transaction (or group) is constructed
2. It is shared with other signers
3. Each signer provides their signature
4. Signatures are assembled to meet the threshold
5. 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](https://dev.algorand.co/arc-standards/arc-0055/#_top)

### 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.

* * *