---
title: "Rotazione dei firmatari multisig"
description: "Una procedura incentrata sulla verifica per sostituire i firmatari multisig preservando il quorum, controllando l'insieme dei proprietari e la soglia esatti on-chain e reagendo in sicurezza a una chiave compromessa."
image: "https://wiki.fcontext.com/og.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Rotazione dei firmatari multisig

> Solo a scopo educativo; non costituisce consulenza finanziaria, legale o di sicurezza. Un errore nella rotazione può trasferire il controllo, invalidare approvazioni pendenti o bloccare definitivamente un conto multisig.

<a id="answer"></a>

## Risposta diretta

La rotazione dei firmatari multisig cambia i conti autorizzati ad approvare le transazioni. Normalmente non richiede un nuovo indirizzo di portafoglio né un trasferimento di asset: una transazione privilegiata modifica l'insieme dei proprietari del conto e, talvolta, la sua soglia di approvazione. Le implementazioni sono diverse, quindi occorre verificare il contratto distribuito e lo stato on-chain corrente anziché presumere che le etichette dell'interfaccia descrivano correttamente i poteri.

Una rotazione sicura dimostra innanzitutto il controllo di ogni nuovo firmatario, mantiene per tutta la modifica un quorum eseguibile ma non concentrato, rimuove il vecchio firmatario e verifica lo stato finale on-chain. Perdere il quorum richiesto prima dell'esecuzione può rendere impossibile una normale rotazione dei proprietari; abbassare la soglia per comodità può creare una finestra di acquisizione del controllo.

La persona, il dispositivo di firma, la chiave privata e l'indirizzo del proprietario on-chain sono registri distinti. Documentare l'indirizzo esatto, il custode, il dominio di controllo indipendente, lo stato del backup e il motivo della rotazione. Nessuna rotazione legittima richiede di rivelare una frase seed o una chiave privata.

<a id="mechanism"></a>

## Come funziona

1. **Inventariare i poteri attuali.** Da una chain e da un indirizzo di conto verificati in modo indipendente, leggere l'implementazione distribuita, l'elenco dei proprietari, la soglia, il nonce, i moduli abilitati, i guard, il fallback handler, il percorso di recupero e gli eventuali timelock. Un modulo o meccanismo di recupero può eseguire al di fuori della normale soglia dei proprietari, mentre un guard restrittivo può bloccare una rotazione altrimenti valida.
2. **Definire lo stato obiettivo prima di firmare.** Registrare l'insieme esatto dei proprietari e la soglia dopo la modifica. Confermare che la soglia non superi il numero di proprietari e che almeno altrettanti firmatari indipendenti restino operativi. La separazione geografica non è indipendenza se una sola persona, un vault di password, un conto cloud o un amministratore controlla tutti i dispositivi.
3. **Registrare e autenticare il nuovo firmatario.** Generare o ripristinare la nuova chiave nell'ambiente di custodia previsto, verificare l'indirizzo su un dispositivo affidabile e dimostrare il controllo con una challenge concordata o una firma di prova. Confermare l'indirizzo tramite un secondo canale autenticato; non affidarsi soltanto a testo copiato da una chat o all'interfaccia del portafoglio.
4. **Scegliere un ordine con stati intermedi sicuri.** Alcuni contratti possono sostituire atomicamente un proprietario. Safe, per esempio, espone `swapOwner`; espone anche `addOwnerWithThreshold`, `removeOwner` e `changeThreshold`. Se un'implementazione richiede più transazioni, analizzare l'insieme dei proprietari e la soglia dopo ogni passaggio. Aggiungere e verificare la capacità prima di rimuoverla, a meno che una compromissione attiva renda insicuro tale ordine.
5. **Decodificare e simulare la transazione esatta.** Controllare in modo indipendente chain ID, indirizzo del conto, target, selettore di funzione, vecchio e nuovo indirizzo del proprietario, soglia risultante, nonce, value e tipo di operazione. Trattare `delegatecall`, batching, modifiche ai moduli e modifiche ai guard come effetti ad alto rischio distinti. Ogni firmatario deve approvare lo stesso payload decodificato e lo stesso hash della transazione.
6. **Eseguire con i poteri esistenti.** Il quorum valido corrente autorizza la rotazione, salvo diversa indicazione di un percorso di recupero documentato. In emergenza, coordinarsi solo tramite contatti autenticati e usare firmatari non compromessi. Se non restano disponibili né il quorum normale né un'autorità di recupero preconfigurata, una chiamata standard di gestione dei proprietari non può ripristinare l'accesso.
7. **Verificare e chiudere la modifica.** Dopo la conferma, interrogare direttamente l'insieme dei proprietari e la soglia, esaminare gli eventi emessi o le trace secondo l'implementazione e confermare che il vecchio indirizzo non sia più autorizzato. Far partecipare il nuovo firmatario a una transazione approvata, a basso rischio o a valore zero, che richieda la soglia prevista. Esaminare le transazioni pendenti, revocare accessi off-chain e backup del precedente firmatario e archiviare proposta, firme, hash della transazione, blocco e stato finale.

<a id="example"></a>

## Esempio pratico

Si supponga che un conto `3-of-5` abbia come proprietari `A`, `B`, `C`, `D` ed `E` e che `B` debba essere sostituito da `F`. Il team verifica prima che `F` controlli l'indirizzo esatto proposto e resti indipendente dagli altri proprietari. Per una distribuzione Safe compatibile prepara `swapOwner(prevOwner, B, F)`. La chiamata è essa stessa una transazione Safe e richiede quindi `3` conferme valide dall'insieme corrente dei proprietari. Il risultato decodificato deve conservare un numero di proprietari pari a `5` e una soglia pari a `3`.

Dopo la conferma della transazione, il team legge `getOwners` e `getThreshold`, verifica che `B` sia assente e `F` presente e fa eseguire a `F` e ad altri due proprietari un test approvato con valore `0`. Esamina anche le transazioni pendenti: una firma o preapprovazione di `B` potrebbe non soddisfare più i controlli sui proprietari dopo la rimozione, perciò le proposte interessate devono essere annullate o ricostruite anziché considerate eseguibili.

Se `B` potrebbe essere compromesso, il team non gli chiede di approvare la rimozione. Altri tre proprietari non compromessi eseguono la sostituzione, quindi ispezionano moduli, permessi di recupero, allowance, session key e transazioni già eseguite, perché rimuovere `B` non annulla le azioni precedenti né revoca i poteri concessi tramite un'altra via. Se sono disponibili meno di `3` proprietari non compromessi, può aiutare soltanto un percorso di recupero o amministrativo configurato in precedenza; condividere frasi seed o fidarsi di un servizio di "recupero" non richiesto non sostituisce il quorum.

<a id="risks"></a>

## Rischi e controlli

- **Conto o indirizzo errato.** Verificare chain ID, indirizzo multisig, implementazione e indirizzo del nuovo proprietario su dispositivi e fonti indipendenti. L'address poisoning e gli errori di copia possono cedere il controllo a un aggressore.
- **Perdita del quorum.** Modellare ogni stato intermedio. Rimuovere troppo presto un proprietario, alzare la soglia oltre i firmatari disponibili o ruotare insieme più dispositivi correlati può rendere inutilizzabile il conto.
- **Concentrazione temporanea.** Una soglia più bassa o un firmatario appena aggiunto può creare un periodo in cui un numero minore di parti controlla il conto. Preferire una sostituzione atomica quando supportata e non abbassare la soglia solo per semplificare la procedura.
- **Custodia correlata.** Indirizzi diversi non sono indipendenti se seed, dispositivi, backup, comunicazioni o amministratori condividono lo stesso dominio di guasto. Verificare il recupero senza centralizzare i segreti.
- **Poteri nascosti.** Moduli, guard, fallback handler, session key, timelock e contratti di recupero possono aggirare o bloccare il percorso dei proprietari. Inventariarli e verificarli prima e dopo la rotazione.
- **Corsa con il firmatario compromesso.** Prima che la rimozione sia confermata, un firmatario sospetto può anticipare, sottrarre asset, cambiare configurazione o approvare un'altra transazione. Usare procedure di risposta agli incidenti, invio privato delle transazioni quando opportuno e monitoraggio continuo dello stato; non presumere che una transazione inviata abbia vinto la corsa.
- **Approvazioni pendenti obsolete.** Le modifiche a proprietari e soglia possono invalidare le firme raccolte o cambiare quali approvazioni siano sufficienti. Rivalutare ogni transazione in coda rispetto allo stato finale e annullare le proposte obsolete.
- **Falso completamento.** Una notifica di successo dell'interfaccia non prova lo stato desiderato. Attendere la politica di conferma richiesta, quindi leggere lo stato del contratto e verificare payload della transazione, eventi e risultato di esecuzione.
- **Offboarding incompleto.** Rimuovere un proprietario on-chain non cancella chiavi copiate, accessi organizzativi, credenziali del relayer, voci del vault di password o poteri in altri contratti e chain. Revocare ciascun elemento separatamente e conservare una traccia di audit.

<a id="misconceptions"></a>

## Errori comuni

- **"La rotazione significa spostare tutti gli asset in un nuovo portafoglio."** Molti multisig basati su smart account aggiornano i proprietari allo stesso indirizzo del conto. La migrazione è un'operazione diversa e può essere richiesta solo da una particolare implementazione o piano d'incidente.
- **"Aggiungere prima il nuovo firmatario è sempre sicuro."** Protegge la disponibilità, ma può ampliare temporaneamente l'insieme autorizzato. Durante una compromissione attiva, una sostituzione atomica o un'altra sequenza di emergenza può essere più sicura.
- **"Una soglia `3-of-5` significa che sono disponibili tre persone nominate qualsiasi."** Il contratto conta i conti proprietari validi, non persone, reparti o dispositivi. La custodia condivisa e le chiavi inaccessibili riducono l'indipendenza e la disponibilità effettive.
- **"Rimuovere un proprietario compromesso annulla il danno."** Dopo la conferma, la rimozione impedisce l'uso futuro di quel percorso del proprietario; non annulla le transazioni eseguite né revoca i permessi creati altrove.
- **"L'interfaccia del portafoglio è una prova sufficiente."** Interfacce e servizi di indicizzazione possono essere obsoleti, configurati male o dannosi. Decodificare la transazione e leggere lo stato finale del contratto da un endpoint verificato in modo indipendente.
- **"Senza quorum, l'assistenza può reimpostare il portafoglio."** Un multisig in autocustodia dispone solo dei percorsi di autorità codificati o preconfigurati on-chain. Senza un quorum valido o un percorso di recupero, l'accesso può andare perso definitivamente.

<a id="related"></a>

## Argomenti correlati

- [Portafoglio hardware](/it/crypto/hardware-wallet/)
- [Portafoglio multisig](/it/crypto/multisig-wallet/)
- [Gestione delle chiavi private](/it/crypto/private-key-management/)
- [Rischio di recupero del proprietario di uno smart account](/it/crypto/smart-account-owner-recovery-risk/)
- [Simulazione delle transazioni](/it/crypto/transaction-simulation/)

<a id="sources"></a>

## Fonti

- [Come funzionano gli account intelligenti Safe?](https://docs.safe.global/advanced/smart-account-overview) - Safe Documentation (consultato: 2026-08-21)
- [addOwnerWithThreshold](https://docs.safe.global/reference-smart-account/owners/addOwnerWithThreshold) - Safe Documentation (consultato: 2026-08-21)
- [removeOwner](https://docs.safe.global/reference-smart-account/owners/removeOwner) - Safe Documentation (consultato: 2026-08-21)
- [swapOwner](https://docs.safe.global/reference-smart-account/owners/swapOwner) - Safe Documentation (consultato: 2026-08-21)
- [changeThreshold](https://docs.safe.global/reference-smart-account/owners/changeThreshold) - Safe Documentation (consultato: 2026-08-21)
- [OwnerManager.sol](https://github.com/safe-fndn/safe-smart-account/blob/main/contracts/base/OwnerManager.sol) - Safe Ecosystem Foundation (consultato: 2026-08-21)
- [Raccomandazione per la gestione delle chiavi: Parte 1 - Generale](https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final) - NIST (consultato: 2026-08-21)

Source: https://wiki.fcontext.com/it/crypto/multisig-signer-rotation/index.mdx