Les trésoreries DAO sont assises sur des bilans qui les placeraient dans le quartile haut des fonds mid-cap, et tournent sur des setups de signature qui ne passeraient pas l'onboarding d'un émetteur de cartes bancaires. Refermer cet écart, sans perdre la décentralisation qui définit les DAOs, c'est le travail.
Ce qui suit, c'est le playbook qu'on déroule avec les équipes opérationnelles de DAO. Rien de neuf ; tout est régulièrement sous-fait.
Les quatre risques que toute trésorerie DAO doit affronter
1. Compromission de signataire. Un multi-sig 5-sur-9 où les signataires ne se connaissent pas personnellement est une vraie surface d'attaque sociale. DM Discord usurpés, fausses invitations calendrier, simulation de transaction malicieuse, la couche sociale du multi-sig est ce que ciblent les attaquants, parce que la couche cryptographique est dure.
2. Gouvernance qui approuve la mauvaise calldata. Les DAOs approuvent régulièrement des propositions qui appellent des contrats non audités. La communauté voit le titre de la proposition ; le Safe signe la calldata. Sans process de revue, la gouvernance devient la vulnérabilité, et il n'y a même pas besoin d'exploit, juste un vote Snapshot réussi.
3. Complexité cross-chain. Fonds sur Ethereum, L2s, marchés de prêt, LSTs, RWAs. La surface de trésorerie grandit avec chaque stratégie de yield. Suivre exposition, custody et risque de contrepartie est un travail continu, pas trimestriel.
4. Pas de CEO à appeler quand ça casse. Quand quelque chose dérape, il n'y a pas de chemin d'escalade clair. Chaque incident devient un thread de forum au lieu d'une réponse coordonnée.
L'architecture
L'architecture par défaut qu'on recommande comporte quatre wallets, chacun avec un seuil et un périmètre différents :
Trésorerie froide
L'essentiel des actifs. Multi-sig 5-sur-9 ou 6-sur-9, signataires sur hardware wallets, distribués géographiquement, avec au moins deux signataires dans chaque grand fuseau. Pas d'opérations régulières, juste des rebalances votés par la gouvernance, avec un timelock de 48-72h pour les opérations non urgentes.
Ce wallet est touché de l'ordre d'une fois par mois. Le toucher est un événement délibéré, programmé, avec une checklist de revue.
Trésorerie de travail
Le float opérationnel, typiquement quelques semaines de paiements de grants, de comp contributeurs et de dépenses opérationnelles. Multi-sig 3-sur-5, signataires hardware, seuil plus rapide à assembler. Cap bas sur le solde extant ; rechargé depuis la trésorerie froide selon un calendrier.
Un drain de la trésorerie de travail, c'est une mauvaise journée. Ça ne touche pas la trésorerie froide.
Wallets par stratégie
Chaque stratégie de yield ou intégration externe a son propre multi-sig. Si la stratégie tourne mal, seul ce wallet est exposé. Si la stratégie doit sortir, seuls les signataires concernés doivent se coordonner.
C'est le principe de compartimentage, appliqué à la DeFi. Ça coûte un peu plus en charge opérationnelle et ça vaut des ordres de grandeur en bornage d'incident.
Pause d'urgence
Si votre protocole a des fonctions de pause d'urgence, le détenteur de ces fonctions est son propre multi-sig, typiquement un set plus petit de signataires choisis pour la disponibilité et la couverture des fuseaux plutôt que pour l'équilibre politique. Mandat étroit : mettre en pause si nécessaire, rien d'autre.
Choix des signataires et hygiène opérationnelle
Qui signe est une décision opérationnelle, pas que politique.
Diversité d'identité et d'infrastructure. Les signataires ne doivent pas tous travailler pour la même entité, ne pas tous utiliser le même fournisseur d'email, ne pas tous tourner sur le même browser, ne pas tous garder leur hardware dans le même bâtiment. Si un seul attaquant peut compromettre une organisation et atteindre cinq signataires, le seuil est fictif.
Hardware wallets, pas d'exception. Chaque signataire signe depuis un hardware wallet (Ledger, Trezor, GridPlus, Keystone). Le signataire est responsable de vérifier la calldata sur le device, pas sur l'UI de la dApp, pas sur la simulation. L'écran du device, c'est la source de vérité.
Procédure de signature documentée. Chaque transaction passe par :
- Proposition postée dans le multi-sig avec la calldata.
- Les signataires revoient la calldata. Les seniors ou les techniques doivent lancer Tenderly ou équivalent indépendamment et poster le résultat.
- Les signataires vérifient sur l'écran du hardware avant de signer.
- Seuil atteint, transaction exécutée.
Sauter une étape a coûté de l'argent à de vrais DAOs. La procédure existe parce que les défaillances existent.
Onboarder et offboarder un signataire est une cérémonie. Ajouter un signataire est une procédure multi-étapes avec achat de hardware, drills testnet, vérification d'identité. Retirer un signataire est aussi une cérémonie, et pas optionnel quand un contributeur part.
On livre ça dans une mission Wallet Setup : architecture, liste de signataires, runbooks, et session de formation en direct pour les signataires.
Durcissement de la gouvernance
Un multi-sig qui signe ce que Snapshot lui demande est une vulnérabilité de gouvernance déguisée en décentralisation.
Revue de calldata avant vote. Toute proposition exécutable doit avoir une revue de calldata attachée, quelles adresses elle touche, quelles fonctions elle appelle, quelle valeur elle bouge, quelles permissions elle accorde. Le post de forum sans revue de calldata ne doit pas être voté, point.
Patterns de contrats standardisés. La DAO maintient une bibliothèque de contrats approuvés (modules de gouvernance, gestionnaires de trésorerie, mécanismes de distribution). Les nouveaux patterns demandent une revue par le working group sécurité avant usage. Ça réduit dramatiquement la surface de revue de calldata pour toute proposition.
Timelocks proportionnels à la valeur. Rebalance routinier : 48 heures. Upgrade smart contract : 7 jours. Changement de policy de trésorerie : 14 jours. Le timelock, c'est le temps que la communauté a pour réagir à une mauvaise proposition, y compris pour coordonner socialement une contre-proposition.
Quorum qui coûte cher à battre. Les votes Snapshot qui passent à 2 % de participation, ce n'est pas de la gouvernance, c'est du théâtre. Ajustez les exigences de quorum à la hausse à mesure que le TVL grandit.
Monitoring continu
L'architecture et les procédures sont statiques ; la surface de menace ne l'est pas. De nouvelles stratégies arrivent, de nouveaux bridges se déploient, de nouveaux patterns d'exploit apparaissent.
Wallet Surveillance sur les wallets de trésorerie et les adresses avec lesquelles ils interagissent, c'est la couche continue :
- Transactions en file dans le Safe surfacent dans des alertes avant exécution.
- Approvals à des contrats inconnus déclenchent une revue.
- Sorties qui divergent de la baseline sont flaggées.
- Interactions avec des adresses sanctionnées ou connues comme malicieuses sont bloquées au niveau alerting.
Le coût est petit. Le bénéfice, c'est la différence entre attraper une proposition malicieuse en file et la lire dans un post-mortem.
Quand quelque chose va mal
Une DAO sans procédure de réponse à incident écrite va dérouler son premier incident sur son forum. C'est mauvais pour les fonds et pire pour la communauté.
La procédure qui marche :
- Un working group préauthorisé de contributeurs avec mandat de coordonner la réponse.
- Un chemin d'escalade écrit : qui est pagé, dans quel ordre.
- Une relation établie avec un cabinet de Réponse à incident, sous retainer ou au moins préqualifié, pour que la première heure soit de l'exécution, pas de l'achat.
- Templates de communication rédigés pour « nous sommes au courant », « nous avons contenu », « post-mortem », à remplir et valider rapidement.
Les DAOs qui ont survécu à des incidents, il y en a quelques-unes, ont survécu parce qu'elles avaient la réponse en place avant d'en avoir besoin. Celles qui ne l'avaient pas, n'ont pas survécu.
Là où ça atterrit
Une trésorerie DAO correctement structurée peut tourner pendant des années à travers tout type de marché sans incident sérieux. Le travail est en amont, architecture, runbooks, formation des signataires, mise en place du monitoring, et continu, revue trimestrielle, exercices annuels, rotation régulière des signataires.
L'alternative, c'est la longue queue de DAOs dont les trésoreries ont été drainées, souvent par l'erreur d'un seul signataire, souvent documentée on-chain pour toujours. Ce résultat n'est pas aléatoire ; c'est le résultat prévisible de sauter le travail.
On fait ce travail pour des trésoreries DAO de toutes tailles, de petites DAOs de protocole à des trésoreries d'écosystème à neuf chiffres. Le pattern transfère à travers l'échelle ; seule la valeur en dollars des conséquences scale.