Shadow Governance & Manipulasi DeFi: Panduan On-Chain

Exploitation governance di dunia DeFi udah lama bergeser dari thread publik Discourse ke anonymous liquidity pools dan grup Telegram rahasia. Di situlah nasib dana miliaran dolar ditentukan cuma dalam hitungan beberapa blok.

Menerapkan 51% attack secara langsung ke protokol governance lewat pembelian native token di pasar sekunder (seperti UNI atau AAVE) secara ekonomis itu konyol: slippage dan model staking bakal langsung bikin harga token meroket ke langit. Jauh lebih murah buat "menyewa" hak suara orang lain lewat mekanisme Voter Bribes (suap voter). Begitu mekanik ini keluar dari platform transparan kayak Votium atau Hidden Hand dan pindah ke transaksi OTC (Over-the-Counter) atau смарт-контракт tertutup, lahirlah fenomena Shadow Governance — tata kelola bayangan yang bisa nguras treasury proyek atau ngubah parameter risiko tanpa sepengetahuan komunitas retail.

Anatomi Shadow Governance: Dari Curve Wars Sampai Anonymous Pools

Cikal bakal industri "suap-menyuap" ini berawal dari arsitektur veTokenomics (vote-escrowed) buatan Curve Finance. Dengan mengunci CRV sampai 4 tahun, user dapet veCRV yang menentukan alokasi emisi token ke liquidity pool. Proyek-proyek DeFi langsung sadar: daripada boros kapital buat buyback CRV lalu di-lock 4 tahun, mending bayar royalti mingguan ke para holder veCRV biar mereka nge-vote pool tertentu.

Dari sinilah muncul pasar Bribe publik:

• Votium (untuk ekosistem Convex/Curve)
• Hidden Hand dari Redacted Cartel (memayungi Balancer, Frax, Aura)

Tapi, bribe resmi punya celah fatal buat pemain kakap: semuanya kelewat publik. Analytics engineer mana pun tinggal buka dashboard dan langsung tahu siapa bayar berapa buat pool mana.

Di Shadow Governance, mekanik yang dipakai benar-benar beda kelas:

• Flashloans Governance Interception: Pemanfaatan flashloan buat membajak kontrol protokol non-ve secara instan. Attacker pinjam dana raksasa, eksekusi proposal lewat voting power instan, lalu bayar utang di blok yang sama.
• Off-Chain / OTC Bribe Matching: Transaksi "di bawah meja" di mana holder ve-token kelas Paus (institutional) terima pembayaran stablecoin, altcoin, atau alokasi kontrak SAFT ke custodial wallet mereka sebagai imbalan atas delegasi vote.
• Private Dark Pools (Wrapped Voting Power): Membungkus (wrapping) governance token ke dalam smart contract yang memisahkan nilai ekonomi token dari hak suaranya. Hak voting lalu ditokenisasi dan diperjualbelikan lewat lelang tertutup (Dutch Auctions).

Studi Kasus Nyata: Hancurnya Protokol Akibat Suap Gelap

Kasus 1: Exploit Beanstalk Farms (April 2022) - $182 Juta

Secara teknis ini eksekusi Flashloan, tapi lebih tepat disebut sebagai "pengambilalihan governance bayangan secara instan". Attacker meminjam $1 miliar dalam bentuk Lido stETH, Bean, dan aset lain via Aave, menguasai >70% Voting Power di BIP-18 (Beanstalk Improvement Proposal), lalu detik itu juga menguras seluruh isi treasury ke wallet pribadi.

Celah Shadow Governance-nya: Protokol menghitung vote secara instan berdasarkan saldo token di blok berjalan tanpa adanya Timelock maupun syarat staking terlebih dahulu.

Kasus 2: Pembajakan Governance Tornado Cash (Mei 2023)

Attacker mengajukan proposal yang sekilas kelihatan aman dan mirip dengan proposal sebelumnya. Namun, di dalamnya disisipkan malicious code. Setelah di-pass oleh komunitas, attacker mengeksekusi fungsi selfdestruct buat mengganti logika kontrak di address yang sama (via CREATE2), mencetak 1.2 juta vote TORN palsu, merebut kontrol penuh atas DAO, dan membawa lari $2.1 juta dari treasury.

Celah Shadow Governance-nya: Attacker memanfaatkan mekanisme eksekusi kode tersembunyi (metamorphic contracts) untuk mengelabuhi visual audit proposal dan menyuntikkan logic jahat tepat sebelum voting.

Cara Mendeteksi Shadow Governance di Level On-Chain

Lobi-lobi OTC memang susah diendus, tapi eksekusi transaksi gelap di blockchain selalu meninggalkan jejak (on-chain footprint). Kuncinya ada pada analisis anomali perilaku wallet Whale dan smart contract delegasi.

Komparasi: Bribe Legal vs Shadow Governance

Algoritma Praktis Memburu Jejak On-Chain

Buat ngelacak pergerakan shadow governance, backend engineer dan data analyst biasanya nge-set monitoring buat nangkep anomali berikut:

• Delegate Tracking: Pantau event DelegateChanged(address indexed delegator, address indexed fromDelegate, address indexed toDelegate). Kalau wallet Whale (top 20 holders) mendadak ngalihin hak suara ke wallet kosong 2–3 blok sebelum voting window ditutup, ini sinyal kuat adanya deal OTC.
• Aliran Dana dari Flash-Mixer: Jika wallet penerima delegasi menerima pasokan stablecoin atau native token dari mixer cuma beberapa jam sebelum voting, kemungkinan besar itu adalah uang pelicin buat eksekusi perintah pembeli.
• MEV-driven Voting: Pembajakan proposal di blok paling akhir. Attacker ngirim private transaction langsung ke builder (via Flashbots) biar tumpukan vote raksasa mereka nggak ketahuan sampai bloknya selesai di-seal.

Parsing Anomali: Script Python untuk Monitoring Delegasi

Di bawah ini ada script Python simpel berbasis web3.py buat memantau pergeseran voting power secara masif pada token ERC20Votes (arsitektur Compound/OpenZeppelin) sebelum proses voting berlangsung.

import time
import logging
from collections import defaultdict
from web3 import Web3
# Setup logging
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
# Protection lag against chain reorgs (12 blocks ~= 2.5 mins)
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. RPC Connection Check
w3 = Web3(Web3.HTTPProvider(RPC_URL))
if not w3.is_connected():
   raise ConnectionError("RPC unreachable. Check API key or node status.")
# 2. Checksum and contract init
token_address = w3.to_checksum_address(RAW_TOKEN_ADDRESS)
contract = w3.eth.contract(address=token_address, abi=ABI)
# 3. Dynamic parameters
try:
   TOKEN_DECIMALS = contract.functions.decimals().call()
   TOTAL_SUPPLY = contract.functions.totalSupply().call()
   logging.info(f"Token loaded. Decimals: {TOKEN_DECIMALS} | Total Supply: {TOTAL_SUPPLY / (10 ** TOKEN_DECIMALS):,.0f}")
except Exception as e:
   logging.warning(f"Failed to fetch token params, falling back to defaults: {e}")
   TOKEN_DECIMALS = 18
   TOTAL_SUPPLY = 1000000000 * (10 ** 18) # 1B default
# Anomaly threshold: 100,000 tokens
VOTE_THRESHOLD = 100000 * (10 ** TOKEN_DECIMALS)
def get_logs_batched(event_obj, from_block, to_block):
   """Safe log fetching in batches. Returns (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"Failed to fetch logs for blocks {start}-{end}: {e}")
           return [], False
   return all_events, True
def analyze_governance_shifts(from_block, to_block):
   """Analyze voting shifts with Total Supply share calculation."""
   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  # Log read failed, hold block pointer!
   # Group DelegateChanged events per 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
           
           # Calculate metrics against 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
           # Criticality level
           severity = "CRITICAL SPIKE" if share_of_supply >= 1.0 else "WARNING"
           logging.warning(f"[{severity}] Voting Power Shift: {fmt_delta:+,.0f} tokens ({delta_share_of_supply:.3f}% of supply)")
           logging.info(f"    Delegate: {delegate}")
           logging.info(f"    Total address influence: {fmt_new:,.0f} votes ({share_of_supply:.3f}% of Total Supply)")
           logging.info(f"    Tx Hash: {tx_hash}")
           contexts = delegation_map.get(tx_hash, [])
           if contexts:
               logging.info(f"    Reason: DIRECT DELEGATE CHANGE ({len(contexts)} events in Tx)")
               for ctx in contexts:
                   logging.info(f"      • Delegator: {ctx['delegator']} | {ctx['from']} -> {ctx['to']}")
           else:
               logging.info("    Reason: Balance change for existing delegate (Transfer / Claim / Mint / Burn)")
           
           print("-" * 75)
   return True
def start_realtime_monitoring(poll_interval=12):
   """Real-time daemon keeping safe confirmation depth."""
   latest_block = w3.eth.block_number
   last_processed_block = latest_block - SAFE_CONFIRMATIONS - 1
   logging.info(f"Daemon started. Initial safe block: #{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("Block range processing incomplete due to RPC error. Retrying next cycle.")
       except Exception as e:
           logging.error(f"Critical error in main loop: {e}")
       time.sleep(poll_interval)
if __name__ == "__main__":
   start_realtime_monitoring(poll_interval=12)

Cara Mitigasi & Proteksi dari Shadow Governance

Industri DeFi pelan-pelan mulai beradaptasi ngelawan serangan model gini. Audit smart contract biasa udah gak cukup; yang butuh diperkuat adalah arsitektur pertahanan dari model DAO itu sendiri.

• Penerapan Timelock + Fitur Veto: Perubahan kode gak boleh langsung jalan begitu vote selesai. Harus ada jeda minimal 48–72 jam biar Security Council punya waktu buat nge-veto proposal mencurigakan.
• Migrasi ke ve-Model dengan Unlocking Delay: Kalau token di-lock dan gak bisa dipindah-tangan secara instan, modal yang dibutuhkan attacker buat bikin serangan bayangan bakal naik berlipat ganda.
• Optimistic Governance: Pendekatan yang dipakai Moonwell dan Lido, di mana proposal dianggap disetujui secara default, dan proses voting cuma digelar kalau komunitas mau mengajukan veto.
• Dual-Token Governance: Memisah hak kontrol antara holder utility token dan liquidity provider / pengguna riil (seperti Dual Governance Lido, di mana holder stETH bisa nge-block keputusan holder LDO).

Shadow governance adalah efek samping alami begitu hak voting berubah jadi komoditas finansial. Tugas kami sebagai analyst dan blockchain engineer di EXMON adalah mendeteksi anomali macam ini secara real-time di mempool dan level smart contract, demi menjamin keamanan dan transparansi penuh bagi seluruh ekosistem.