Una policy di tesoreria per piccoli team: chi può muovere il denaro

Quando un'azienda inizia a detenere cripto, di solito si trovano nel wallet di una sola persona. Il fondatore l'ha configurato, il fondatore custodisce la frase di recupero e il fondatore invia i pagamenti. Funziona, finché quella persona non è in viaggio, malata, se ne va, cade vittima di phishing o semplicemente commette un errore senza che nessuno se ne accorga.

Una policy di tesoreria è la soluzione. Non deve essere lunga né formale. Deve rispondere ad alcune domande in modo abbastanza chiaro da far conoscere a tutti le regole prima che il denaro si muova, non dopo.

Domanda 1: chi può spendere?

Inizia separando tre ruoli che spesso si confondono:

• Proponenti: persone che possono preparare un pagamento.
• Approvatori: persone la cui firma è necessaria per inviarlo.
• Osservatori: persone che devono vedere saldi e cronologia ma non dovrebbero mai toccare i fondi, come un commercialista.

Il controllo fondamentale è che nessuno possa muovere fondi da solo. Nelle cripto questo si ottiene con il multisig: un indirizzo di tesoreria che richiede M approvazioni su N firmatari. Per un team da tre a cinque persone, 2-of-3 o 3-of-5 sono punti di partenza comuni. Soglie più alte aggiungono sicurezza e attrito in egual misura.

Domanda 2: che succede alle chiavi quando le persone se ne vanno?

Ogni firmatario è una persona che potrebbe andarsene, perdere un dispositivo o smettere di rispondere. Pianificalo:

• Soglia inferiore al totale. Con 2-of-3, perdere un firmatario non blocca i fondi.
• Nessuna coppia di firmatari con lo stesso singolo punto di guasto: non la stessa cassaforte d'ufficio, non lo stesso portatile, idealmente non la stessa abitazione.
• Una fase di offboarding. Quando qualcuno se ne va, rimuovilo come firmatario e, se necessario, sposta i fondi in un vault senza la sua chiave. Non aspettare che qualcosa vada storto.
• Una procedura di recupero documentata che non dipenda dal fatto che una sola persona ricordi come funzionano le cose.

Domanda 3: quali azioni richiedono un'attenzione particolare?

Alcune decisioni sono più pericolose di un normale pagamento: cambiare i firmatari, trasferire la proprietà, rimuovere persone, eliminare l'organizzazione. Dovrebbero richiedere più di un clic da un account con accesso effettuato. Metti per iscritto quali azioni sono «critiche» e quale conferma richiedono.

Domanda 4: come vengono controllati i pagamenti?

La fase di approvazione ha valore solo se gli approvatori controllano davvero qualcosa. Basta una breve checklist:

• Corrisponde a una richiesta: una fattura, un ciclo di buste paga, un bonifico concordato?
• L'indirizzo è verificato: salvato e confermato in precedenza, non incollato da un'email?
• L'importo è corretto, compresi l'asset e la rete?
• Per le interazioni con contratti, la simulazione corrisponde all'intenzione?

La perdita di tesoreria più comune non è una chiave violata, ma una fattura convincente con un indirizzo modificato. Una regola che imponga di confermare i nuovi indirizzi dei beneficiari tramite un secondo canale, come una telefonata o un contatto già noto, ne blocca gran parte.

Domanda 5: cosa resta registrato?

Ogni pagamento dovrebbe lasciare una traccia: chi l'ha proposto, chi l'ha approvato, quando e perché. È ciò che rende una policy verificabile ed è ciò che permette al team di ricostruire gli eventi se qualcosa va storto.

Un modello per iniziare

Per un piccolo team, qualcosa del genere basta per cominciare:

1. La tesoreria è custodita in un vault multisig con soglia 2-of-3 (o 3-of-5).
2. I firmatari sono persone identificate per nome; niente account condivisi, niente dispositivi condivisi.
3. Chiunque nel team finanziario può proporre; solo i firmatari approvano.
4. I nuovi indirizzi dei beneficiari vengono verificati tramite un canale separato prima del primo utilizzo.
5. Le modifiche ai firmatari e i trasferimenti di proprietà sono azioni critiche con riconferma.
6. Proposta, approvazioni e finalità di ogni pagamento vengono conservate.
7. L'offboarding include la rimozione come firmatario nell'ultimo giorno della persona.
8. La policy viene rivista ogni sei mesi o dopo qualsiasi incidente.

Come SSP Enterprise si collega a tutto questo

SSP Enterprise è stato progettato attorno a queste domande:

• Ruoli. Le organizzazioni hanno proprietari, amministratori, membri e osservatori, quindi proporre, approvare e visualizzare sono attività separate. Ruoli e permessi spiega cosa può fare ciascuno.
• Vault M-of-N. Ogni vault ha la propria soglia e il proprio insieme di firmatari, e un'organizzazione può gestire più vault: ad esempio un conto operativo e una riserva con una soglia più alta. Nella modalità predefinita, ogni firmatario approva sia con SSP Wallet sia con SSP Key, quindi anche l'approvazione di un singolo firmatario è di per sé un 2-of-2. Poiché l'indirizzo di un vault è costruito dalle chiavi dei suoi firmatari, cambiare chi può firmare significa spostare i fondi in un nuovo vault: conviene prevederlo nell'offboarding.
• Azioni critiche. Trasferire la proprietà, rimuovere membri, eliminare l'organizzazione e cambiare l'email aziendale richiedono di firmare di nuovo con le chiavi di identità, non solo una sessione attiva.
• Controlli prima della firma. Le proposte mostrano destinatari e importi, e le interazioni con contratti ricevono simulazione e avvisi di rischio prima che i firmatari approvino.
• Una traccia di ogni pagamento. Le proposte registrano chi ha proposto, chi ha firmato e chi è ancora in attesa, e sono disponibili esportazioni per la contabilità.

Se parti da zero, configurare il tuo primo vault aziendale ti guida passo dopo passo.

Il riepilogo onesto

Una policy di tesoreria risponde a cinque domande: chi può spendere, cosa succede quando le persone se ne vanno, quali azioni sono critiche, come vengono controllati i pagamenti e quale traccia viene conservata. Metti per iscritto le risposte prima di averne bisogno.

Il multisig fa rispettare la regola più importante: nessuno può muovere fondi da solo. Il resto è abitudine: indirizzi verificati, controlli reali prima di approvare e offboarding svolti per tempo.