Les hacks de gouvernance DeFi ne se jouent plus dans les threads publics sur Discourse. Ils ont migré vers les pools de liquidité anonymes et les boucles Telegram privées, là où le sort de milliards de dollars se tranche en l'espace de quelques blocs.
Lancer une attaque à 51 % frontale sur un protocole de gouvernance en rachetant les tokens natifs sur le marché secondaire (du style UNI ou AAVE) est un non-sens économique : le slippage et le design des mécanismes de staking feraient instantanément s'envoler le prix du token jusqu'à la lune. C'est infiniment plus rentable de louer les droits de vote des autres via des Voter Bribes (de la corruption de votants, soyons cash). Quand cette mécanique quitte les plateformes transparentes comme Votium ou Hidden Hand pour s'exécuter via des deals OTC sous le manteau ou des smart contracts privés, on entre dans l'ère du Shadow Governance — une gouvernance fantôme capable de siphonner la trésorerie d'un projet ou de modifier ses paramètres de risque à l'insu complet de la communauté.
Anatomie de la Shadow Governance : Des Curve Wars aux pools opaques
La matrice du marché des bribes, c'est l'architecture veTokenomics (vote-escrowed) pionnalisée par Curve Finance. En lockant du CRV jusqu'à 4 ans, un user récupère du veCRV, qui contrôle l'orientation de l'émission de tokens vers les pools de liquidité. Les projets ont très vite pigé le filon : au lieu de racheter du CRV sur le marché et de bloquer du capital pendant 4 piges, c'est bien moins cher de verser une bribe hebdomadaire aux détenteurs de veCRV pour qu'ils orientent leurs votes vers le bon pool.
C'est ainsi que les marketplaces de bribes publiques ont émergé :
- Votium (pour l'écosystème Convex/Curve)
- Hidden Hand de Redacted Cartel (qui couvre Balancer, Frax, Aura)
Problème : le bribery officiel a un défaut rédhibitoire pour les gros acteurs — il est 100 % public. N'importe quel analyste peut ouvrir un dashboard et tracer exactement qui paie pour quel pool.
La Shadow Governance s'appuie sur des mécaniques bien plus vicieuses :
- Flashloans Governance Interception : Utiliser des flash loans pour prendre d'assaut des protocoles sans verrouillage ve en l'espace d'une seule transaction. L'attaquant emprunte massivement, fait passer sa proposition grâce à son voting power éphémère, et rembourse son prêt dans le même bloc.
- Off-Chain / OTC Bribe Matching : Des deals de gré à gré où de gros holders institutionnels de ve-tokens touchent des stables, des altcoins ou des allocations SAFT futures directement sur des wallets custodial en échange d'une délégation de leur vote.
- Private Dark Pools (Wrapped Voting Power) : Des wrappers de tokens de gouvernance via des smart contracts qui séparent la valeur économique du token de son droit de vote. Les voting rights sont tokenisés et vendus aux enchères aveugles (Dutch Auctions).
Post-Mortems : Quand la gouvernance fantôme déraille
Case Study 1 : L'exploit Beanstalk Farms (Avril 2022) — 182M$ dans la nature
Sur le papier, c'est un hack par flash loan classique. En réalité, c'est un « coup d'État éclair par gouvernance fantôme ». L'attaquant a emprunté 1 milliard de dollars en stETH Lido, BEAN et autres assets via Aave, raflé plus de 70 % du Voting Power sur la proposition BIP-18 (Beanstalk Improvement Proposal) et vidé la trésorerie dans la foulée.
Le vecteur Shadow Governance : Le protocole comptabilisait les voix instantanément sur la base du solde de tokens au bloc courant, sans aucun Timelock ni période de staking préalable.
Case Study 2 : Le takeover de Tornado Cash Governance (Mai 2023)
L'attaquant a soumis une proposition d'apparence inoffensive, copiant le code d'une proposition précédente déjà validée. Sauf qu'un payload malveillant y était dissimulé. Une fois le vote approuvé par la DAO, le hacker a utilisé la fonction selfdestruct pour remplacer le code du contrat de la proposition à la même adresse (via CREATE2). Il s'est minté 1,2 million de faux votes TORN, a pris le contrôle absolu de la DAO et est reparti avec 2,1M$.
Le vecteur Shadow Governance : L'exploitation de contrats métamorphiques (metamorphic contracts) pour contourner l'audit visuel des proposals et modifier la logique d'exécution juste avant le passage à l'acte.
Détecter la Shadow Governance directement On-Chain
Chasser les négociations OTC hors-chaîne est un enfer, mais l'exécution des accords laisse toujours une empreinte indélébile sur le ledger. L'analyse consiste à repérer les anomalies de comportement des whales et des smart contracts de délégation.
Bribes légales vs Shadow Governance : Le benchmark
| Métrique | Bribe Public (Votium / Hidden Hand) | Shadow Governance (OTC / Privé) |
|---|---|---|
| Traçabilité des payouts | Distribution on-chain vérifiable via Merkle Trees | Transit via Tornado, Railgun, CEX ou des wallets vierges |
| Origine des fonds | Smart contracts de market-making publics | Multisigs privés, EOAs opaques, MEV bots |
| Mécanique de délégation | Automatisée via meta-repositories | Shifts de délégués suspects juste avant la clôture du vote |
| Rendement économique | Aligné sur le ROI de marché de l'émission | Payouts disproportionnés ciblés sur un point clé |
| Gestion du Timelock | Respecte le workflow standard de la DAO | Bypassé via des multisigs d'urgence ou des fonctions cachées |
Stack de détection : Tracker les anomalies en Python
Pour flagger les tentatives de gouvernance fantôme, les dev backend et les chercheurs en sécurité mettent en place des bots de monitoring axés sur ces signaux faibles :
- Tracking des re-délégations (Delegate Tracking) : Surveillance de l'événement
DelegateChanged(address indexed delegator, address indexed fromDelegate, address indexed toDelegate). Si un top 20 holder transfère ses droits de vote vers une adresse vierge à 2-3 blocs du cutoff du vote, c'est le red flag typique d'un deal OTC. - Flux d'inflow post-mixers : Quand une adresse récemment déléguée reçoit des stables ou des tokens natifs depuis un mixer quelques heures avant le vote, il y a de très fortes chances qu'on assiste au règlement d'une bribe.
- MEV & Snipping de dernier bloc (MEV-driven Voting) : Passer en force sur une proposition au tout dernier bloc. Les attaquants balancent leur transaction en privé directement au builder (via Flashbots) pour masquer l'accumulation de voix jusqu'au scellement du bloc.
Script d'analyse d'anomalies : Python + web3.py
Voici un script Python léger basé sur web3.py pour catcher les transferts soudains de voting power sur les tokens ERC20Votes (standards Compound / OpenZeppelin).
import time
import logging
from collections import defaultdict
from web3 import Web3
# Config du logger
logging.basicConfig(level=logging.INFO, format="%(asctime)s [%(levelname)s] %(message)s")
RPC_URL = "https://eth-mainnet.g.alchemy.com/v2/YOUR_API_KEY"
RAW_TOKEN_ADDRESS = "0x1f9840a85d5aF5bf1D1762F925BDADdC4201F984" # UNI
# Marge de sécurité anti-reorg (12 blocs ~= 2.5 min)
SAFE_CONFIRMATIONS = 12
BATCH_STEP = 1000
ABI = [
{
"inputs": [],
"name": "decimals",
"outputs": [{"type": "uint8"}],
"stateMutability": "view",
"type": "function"
},
{
"inputs": [],
"name": "totalSupply",
"outputs": [{"type": "uint256"}],
"stateMutability": "view",
"type": "function"
},
{
"anonymous": False,
"inputs": [
{"indexed": True, "name": "delegate", "type": "address"},
{"indexed": False, "name": "previousBalance", "type": "uint256"},
{"indexed": False, "name": "newBalance", "type": "uint256"}
],
"name": "DelegateVotesChanged",
"type": "event"
},
{
"anonymous": False,
"inputs": [
{"indexed": True, "name": "delegator", "type": "address"},
{"indexed": True, "name": "fromDelegate", "type": "address"},
{"indexed": True, "name": "toDelegate", "type": "address"}
],
"name": "DelegateChanged",
"type": "event"
}
]
# 1. Connexion Node
w3 = Web3(Web3.HTTPProvider(RPC_URL))
if not w3.is_connected():
raise ConnectionError("RPC indisponible. Vérifiez la clé API ou l'état du nœud.")
# 2. Checksum et initialisation du contrat
token_address = w3.to_checksum_address(RAW_TOKEN_ADDRESS)
contract = w3.eth.contract(address=token_address, abi=ABI)
# 3. Récupération des paramètres dynamiques
try:
TOKEN_DECIMALS = contract.functions.decimals().call()
TOTAL_SUPPLY = contract.functions.totalSupply().call()
logging.info(f"Token chargé. Decimals: {TOKEN_DECIMALS} | Total Supply: {TOTAL_SUPPLY / (10 ** TOKEN_DECIMALS):,.0f}")
except Exception as e:
logging.warning(f"Impossible de lire les paramètres du token, fallback sur les valeurs par défaut: {e}")
TOKEN_DECIMALS = 18
TOTAL_SUPPLY = 1000000000 * (10 ** 18) # 1B par défaut
# Seuil d'alerte : 100,000 tokens
VOTE_THRESHOLD = 100000 * (10 ** TOKEN_DECIMALS)
def get_logs_batched(event_obj, from_block, to_block):
"""Lecture sécurisée des logs par batchs. Renvoie (logs, is_success)."""
all_events = []
for start in range(from_block, to_block + 1, BATCH_STEP):
end = min(start + BATCH_STEP - 1, to_block)
try:
logs = event_obj.get_logs(fromBlock=start, toBlock=end)
all_events.extend(logs)
except Exception as e:
logging.error(f"Échec de la récupération des logs sur les blocs {start}-{end}: {e}")
return [], False
return all_events, True
def analyze_governance_shifts(from_block, to_block):
"""Analyse du mouvement des voix et calcul du ratio / Total Supply."""
vote_changes, ok1 = get_logs_batched(contract.events.DelegateVotesChanged, from_block, to_block)
delegations, ok2 = get_logs_batched(contract.events.DelegateChanged, from_block, to_block)
if not (ok1 and ok2):
return False # Erreur de lecture, le bloc courant N'EST PAS incrémenté !
# Mappage des événements DelegateChanged par transaction
delegation_map = defaultdict(list)
for d in delegations:
tx_hash = d.transactionHash.hex()
delegation_map[tx_hash].append({
"delegator": d.args.delegator,
"from": d.args.fromDelegate,
"to": d.args.toDelegate
})
for event in vote_changes:
prev_bal = event.args.previousBalance
new_bal = event.args.newBalance
delta = new_bal - prev_bal
if abs(delta) >= VOTE_THRESHOLD:
tx_hash = event.transactionHash.hex()
delegate = event.args.delegate
# Metrics par rapport au Total Supply
fmt_delta = delta / (10 ** TOKEN_DECIMALS)
fmt_new = new_bal / (10 ** TOKEN_DECIMALS)
share_of_supply = (new_bal / TOTAL_SUPPLY) * 100
delta_share_of_supply = (abs(delta) / TOTAL_SUPPLY) * 100
# Niveaux de sévérité
severity = "SPIKE CRITIQUE" if share_of_supply >= 1.0 else "WARNING"
logging.warning(f"[{severity}] Mouvement de Voting Power: {fmt_delta:+,.0f} tokens ({delta_share_of_supply:.3f}% du total)")
logging.info(f" Délégué: {delegate}")
logging.info(f" Poids total du wallet: {fmt_new:,.0f} voix ({share_of_supply:.3f}% du Total Supply)")
logging.info(f" Tx Hash: {tx_hash}")
contexts = delegation_map.get(tx_hash, [])
if contexts:
logging.info(f" Origine: CHANGEMENT DIRECT DE DÉLÉGUÉ ({len(contexts)} évents dans la Tx)")
for ctx in contexts:
logging.info(f" • Delegator: {ctx['delegator']} | {ctx['from']} -> {ctx['to']}")
else:
logging.info(" Origine: Variation de balance du délégué (Transfert / Claim / Mint / Burn)")
print("-" * 75)
return True
def start_realtime_monitoring(poll_interval=12):
"""Worker temps réel gérant la profondeur de confirmation."""
latest_block = w3.eth.block_number
last_processed_block = latest_block - SAFE_CONFIRMATIONS - 1
logging.info(f"Démarrage du worker. Premier bloc sécurisé: #{last_processed_block} (Confirmations = {SAFE_CONFIRMATIONS})")
while True:
try:
current_block = w3.eth.block_number
safe_block = current_block - SAFE_CONFIRMATIONS
if safe_block > last_processed_block:
success = analyze_governance_shifts(last_processed_block + 1, safe_block)
if success:
last_processed_block = safe_block
else:
logging.warning("Range non complètement analysé (échec RPC). Nouvel essai au prochain cycle.")
except Exception as e:
logging.error(f"Crash dans la boucle principale: {e}")
time.sleep(poll_interval)
if __name__ == "__main__":
start_realtime_monitoring(poll_interval=12)Armurer contre la Shadow Governance
L'écosystème s'adapte progressivement à la menace. Un simple audit du smart contract ne suffit plus : c'est l'architecture même de la DAO qu'il faut blinder.
- Timelocks obligatoires + droit de Veto : Aucune exécution automatique à chaud. Un délai minimum de 48 à 72 heures permet à un multisig de sécurité (Security Council) d'intercepter et de geler une proposition malveillante.
- Modèles ve-tokenomics à déblocage progressif : En verrouillant les tokens sans possibilité d'extraction instantanée, le coût marginal d'une attaque fantôme devient tout simplement prohibitif.
- Gouvernance Optimiste (Optimistic Governance) : L'approche poussée par Moonwell ou Lido, où les propositions passent par défaut, à moins que la communauté ne se mobilise activement pour poser son veto.
- Dual-Token Governance : Séparer le droit de vote entre les holders du token applicatif et les apporteurs de liquidité / utilisateurs réels (à l'image de la Dual Governance de Lido, où les détenteurs de stETH peuvent bloquer les décisions unilatérales des holders de LDO).
La gouvernance fantôme est la conséquence directe de la transformation du droit de vote en actif financier négociable. Chez EXMON, la mission de nos ingénieurs blockchain et analystes est de flagger ces anomalies au niveau du mempool et des smart contracts avant qu'elles ne posent risque, garantissant ainsi une sécurité maximale et une transparence totale aux utilisateurs de notre écosystème.
