スマートコントラクトとDeFi：承認・オラクル・ブリッジのリスク

DeFi利用の第一歩はcontract identityと権限の照合

スマートコントラクトはblockchain上のaddressに配置され、transactionを受けるとcodeに従ってstateを変更するprogramです。自動実行でも、codeが正しい、管理者がいない、結果が公正という意味ではありません。protocolのofficial domain、docs、repository、deployment list、explorer verified sourceを照合し、chain ID、proxy address、implementation、version、creation transactionを記録します。

偽frontendや検索広告は正規protocol名を使って悪意あるcontractへ署名させます。bookmarkしたofficial URLから入り、walletのnetworkと表示contractを確認します。upgradeable proxyでは利用者がinteractionするaddressと実際のlogic contractが異なり、administratorがimplementationを変更できます。upgrade delay、timelock、multisig signer、emergency pauseを確認します。

表示名ではなくaddressとchain IDを証拠にします。

approveは送金ではなく将来の支出上限を渡す

ERC-20のapprove/allowanceは、spender contractがholderに代わってtokenを移す上限を設定します。swap時に必要ですが、unlimited approvalを残すと、将来spenderが侵害・upgrade・悪用されたとき残高まで移転される可能性があります。approval transaction自体はtokenを送らないため見落としやすく、walletをdisconnectしてもon-chain allowanceは残ります。

spender address、token contract、amount、expiry/permit deadline、chainを確認し、必要額だけ承認します。利用後はrevoke toolまたはtoken contractでallowanceを減らしますが、revokeもtransactionでgasが必要です。revoke site自体の偽物に注意し、explorerのtoken approval機能や信頼できるofficial linkを使います。NFTのsetApprovalForAllはcollection全体の移転権限になり得ます。

code bugと管理者権限を別の列へ置く

smart contractの典型的riskにはreentrancy、access control、integer/precision、unchecked external call、flash-loanを使ったeconomic exploit、front-running、denial of service、bad upgrade、incorrect accountingがあります。codeがopen sourceでも、利用者が全経路を検証したことにはなりません。compiler、library、oracle、tokenの非標準挙動、governance proposalもattack surfaceです。

audit reportはaudit firm、date、commit hash、scope、severity、unresolved finding、remediation、re-auditを読みます。audit後にcodeやparameterが変わればcoverage外です。bug bountyの上限がTVLに比べ小さい、incident pauseが単一EOA、multisig signerが同一組織に集中する等も確認します。長い無事故履歴は有益なevidenceですが将来保証ではありません。

価格source・更新遅延・liquidationを一つのscenarioで確認する

lendingやderivative protocolはoracle priceでcollateral valueとliquidationを計算します。source venue、median/TWAP、heartbeat、deviation threshold、fallback、stale price handlingを確認します。薄い市場のspot priceを直接使う、更新が遅い、同じvenueへ集中する場合、market manipulationや急変で誤liquidationが起き得ます。

health factorやloan-to-valueは価格が下がるだけでなく、borrowed assetが上がる、interestが累積する、collateral factorがgovernance変更されることで悪化します。liquidation bonus、close factor、auction、network congestion、gas competitionを含め、価格shockとoracle delayを同時にstressします。

bridgeは資産移動ではなく別の検証systemを追加する

bridgeはsource chainでlockしてdestinationでmint、sourceでburnしてdestinationでmint、またはliquidity networkでswapする方式があります。blockchain同士が自然に互いのstateを信頼するわけではないため、light client、validator set、multisig、oracle、relayer、fraud proof等のmessage verificationが必要です。誰が誤messageを止め、どのdelayでfinalizeするかを確認します。

bridge exploitではwrapped assetのbackingが失われてもdestination上のtokenが残り、priceがdepegします。pause後にassetを戻せない、source chain finality前にmintする、upgrade keyが侵害される、liquidity providerが枯渇する経路があります。stablecoinのreserve・償還・depegと同様に、original asset、bridge liability、wrapped supply、exitをbalance sheetとして読みます。

• verification: native/light client、optimistic、external validatorのどれか。
• finality: source confirmation、challenge period、destination creditの順序。
• control: upgrade、pause、rate limit、multisig、guardian。
• exit: canonical redemption、secondary pool、emergency recovery。

専用wallet・simulation・少額・revoke・exitを一巡する

長期保管walletを未知のdAppへ接続せず、interaction用に残高を限定したwalletを分けます。official linkから入り、network・contract・functionを確認し、transaction simulationとminimum receivedを読み、少額でdeposit→claim/repay→withdrawまで試します。approvalは必要額に限定し、終了後に残高とallowanceを確認します。

1. 01依存graphを作る

   contract、proxy、oracle、bridge、admin、frontendを列挙。

2. 02reportを読む

   audit commit、未解決finding、bug bounty、incidentを保存。

3. 03専用walletで少額test

   balanceとapprovalを限定し、simulationを確認。

4. 04exitを完了

   withdraw、repay、bridge back、revokeを実行。

5. 05証拠を記録

   tx hash、contract、amount、fee、status、review dateを保存。

Financial Templates Hubには公開address、contract、approval、audit、dependency、exit testを記録し、seedやprivate keyは入力しません。free TradingView indicatorsはchart contextを補助しますが、smart contractの安全性、oracleの正しさ、protocolのsolvencyを判定しません。