# Multisig Security

## Detecting Durable Nonce Attacks

### Background

Solana transactions normally include a recent blockhash that expires in roughly two minutes. [Durable transaction nonces](https://docs.solanalabs.com/implemented-proposals/durable-tx-nonces) replace that blockhash with a stored nonce value, allowing a signed transaction to remain valid indefinitely. This is a legitimate feature, but it creates a class of attack against multisig wallets.

The attack follows a consistent pattern:

1. **Reconnaissance.** The attacker identifies the signers and approval threshold of a target multisig (e.g., a 2-of-5 Squads v4 multisig).
2. **Nonce staging and social engineering.** The attacker creates durable nonce accounts whose authority is set to one or more of the target's signers — each acting as a "parking slot" for a pre-signed transaction that never expires — while presenting seemingly legitimate transactions to the required number of signers and convincing them to sign. Because the transactions use durable nonces instead of recent blockhashes, the signatures never expire. The signers may not realize the difference. Note that nonce authority can be reassigned after you sign — a transaction that appears harmless at signing time may later be executed by a malicious party once authority has been transferred.
3. **Deferred execution.** The attacker holds the fully-signed transactions and submits them when conditions are most favorable — for example, when token balances are high or vigilance is low.

Step 2 is the only step that leaves an observable on-chain footprint *before* funds are at risk. This is the detection window that matters.

### How WatchTower Detects This

[WatchTower](https://pro.sec3.dev/) processes every Solana block in near real-time and inspects transactions at the instruction level. Three bots cover this attack pattern:

| Bot                             | What it detects                                                      |
| ------------------------------- | -------------------------------------------------------------------- |
| `solana_nonce_creation`         | New durable nonce accounts created with your signer as the authority |
| `solana_nonce_authority_change` | Nonce authority transfers to or from your signer                     |
| `solana_multisig_config_change` | Squads v4 configuration changes (threshold, membership, timelock)    |

> **Not monitoring yet?** [Set up these bots in under five minutes →](https://doc.sec3.dev/sec3-watchtower/multisig-security/quick-start-durable-nonce-monitoring)

The rest of this page explains how each bot works and what to do when an alert fires.

#### Nonce account monitoring (primary detection window)

This is where the attacker must act on-chain, and where WatchTower provides the earliest warning.

**`solana_nonce_creation`** alerts when a new durable nonce account is created with one of your monitored signer keys as the authority. Each alert includes the nonce account address, the authority key, the funding account, and the transaction signature — all extracted directly from the on-chain instruction data at the time of processing. For example:

> **New nonce account detected**
>
> * Nonce account: `3xQp...mN7f`
> * Authority: `8rVk...bT2w` *(monitored signer)*
> * Funded by: `9zLm...cR4k` *(unknown)*
> * Transaction: `5wJd...pK9s`

An unknown or unrecognized funding account is the strongest signal of a potential attack.

**`solana_nonce_authority_change`** alerts when a nonce account's authority is changed to or from one of your monitored signer keys. An inbound change (authority transferred *to* your signer) indicates a variant of nonce staging. An outbound change (authority transferred *away* from your signer) may indicate that an attacker has seized control of an existing nonce account.

#### Multisig configuration changes

**`solana_multisig_config_change`** alerts on any Squads v4 configuration change — threshold modifications, member additions and removals, timelock changes, and other administrative actions. This bot detects the kind of preparatory change an attacker might make to weaken governance controls before executing a drain.

Any removal or reduction of a timelock should be treated as a critical finding requiring immediate review.

### Recommended Actions on Alert

#### Nonce creation alert

1. **Identify the creator.** Check whether the funding account belongs to a known party. If it does not, treat the alert as a potential attack.
2. **Close the nonce account.** A nonce account can be closed by withdrawing its entire balance. This invalidates any pre-signed transactions that reference it.
3. **Review recent signing requests.** Check whether any team member has been contacted with unusual signing requests, unexpected proposals, or unfamiliar transaction links.
4. **Audit governance history.** Review all multisig transactions from the past 60 days and flag any threshold changes, signer rotations, or configuration changes that were not formally authorized. Reject any open proposals that cannot be accounted for.

#### Authority change alert

* **Inbound (authority transferred to your signer):** Treat as nonce staging. Follow the steps above for nonce creation alerts — investigate the account's origin and close it if it was not created by a known party.
* **Outbound (authority transferred away from your signer):** Investigate immediately. This may indicate that an attacker has taken control of a nonce account your signer previously held. Review recent key activity and check for signs of compromise.

### After any alert

**Harden the multisig.** Ensure a minimum 24–48 hour timelock is configured on all administrative actions. Any removal or reduction of a timelock should be treated as a critical finding. Audit the current member list and verify the threshold against your documented governance policy.

## Limitations

WatchTower monitors new on-chain events in near real-time. It does not retroactively scan for nonce accounts that were created before monitoring was enabled. If you are enabling these bots on an existing multisig, consider running a one-time audit to check whether nonce accounts targeting your signers already exist.

Withdrawal and closure of nonce accounts are not currently monitored; detection of those events is on the roadmap.