DeFiで落ちてるお金を拾いたいブログ

DeFiについてのメモ書きやポエムを投下する予定です

トップ > ステーブルコイン > Liquityにおける鯨の影響の考察

Liquityにおける鯨の影響の考察

ステーブルコイン

f:id:vividot:20210414225042p:plain

注意書き

このブログは事実をもとに所感や考察を述べるレポートではなく、ポエムとなっております。

意見の偏りや認識の違いについてご了承ください。

Liquityの概要

LiquityはDAIなどと同様に暗号資産担保型のステーブルコインLUSDを発行するプロジェクトです。 特徴として、プロトコルレベルで精算や担保率の維持をサポートすることで許容する担保率を最低110%までに下げています。

また、フロントエンドの運営をコミュニティにまかせることで、フロントエンドの分散化にも成功しています。
ちなみに、公式HPに載せるフロントエンドの一覧が運営の恣意的な判断であることや、キックバック率の仕組みが崩壊していることからフロントエンドの分散化については個人的に懐疑的です（UniswapみたいにIPFSに載せとけばよくね感）。

余談

ちなみに、執筆時点でLUSDのStakeがAPR191%あるので、Ethereum上のそこそこまともなDeFiにしては美味しい案件です。 ※This is not financial advice

スクリーンショットのフロントエンドはLiquity.fiを利用しています。

f:id:vividot:20210414155221p:plain

2021/04/16 追記

Liquityについて記事が出ていたのでリンク張っておきます。こちらで概要をさらに把握していただけると、本ブログの内容も分かりやすいかと思います。 defipocket.jp

検討したいこと

先日、次のツイートを見かけました。

超意訳すると「おい、担保率110%～150%のお前！鯨がお前のポジションを精算しにくることは技術的に可能だぞ！」という内容です。

そもそもLiquityにはノーマルモードとリカバリーモードという2種類のモードがあります。
ノーマルモードの際には担保率が110%を下回ると担保が精算され、リカバリーモードの時には担保率が150%を下回ると担保が精算されます。 そしてリカバリーモードの条件はプロトコル全体での担保率が150%を下回った場合です。

つまり、このツイートをしている方は「鯨が意図的に全体での担保率を下げてリカバリーモードに突入させて精算できるんだぞ！」ということです。

また、HashHub Researchさんのレポートでも鯨の動向を注意するよう注意喚起がなされています。

なので、今回はLiquityにおける鯨の影響について考察したいと思います。

今の状況

4月14日現在、1ETH2379USDでLiquityには350580ETHが預け入れられており413,515,932LUSDが流通しています。 そのため、プロトコル全体の担保率は約200.89%と安全な水準です。

f:id:vividot:20210414214259p:plain

この情報はフロントエンドのTroveページにだいたいあると思います。

鯨がポジションを閉じることによる影響

「全体の担保率を下げる」行動とは、プロトコル全体の担保率より高い担保率のポジションを閉じる行動です。 そのため鯨の動向に注意、と言われています。

全体の担保がいくらで担保率がいくつだからー…と検討することも出来ると思いますが、今回は実際にLiquityにおける鯨のポジションをチェックしてみたいと思います。

以下に3000ETH以上を担保としているポジションを列挙します。 左から、鯨のアドレス・担保・ポジションの担保率・ポジションが閉じられた場合のプロトコル全体の担保率を示しています。

 1 0x72A916702BD97923E55D78ea5A3F413dEC7F7F85  4840 ETH 139.03% 202.15%  
 2 0xB58C4358669bb70DF715B6747447eb63AFea8916  3637 ETH 143.64% 201.73% 
 3 0x3Ee505bA316879d246a8fD2b3d7eE63b51B44FAB  7200 ETH 148.49% 202.39% 
 4 0x220AbD48f2b444E1a352B6927c885C4579738081  5929 ETH 156.13% 201.89% 
 5 0x6b7Ac46d09d2ADF4CeBe2995EbF9d97E13E9E257 12499 ETH 174.23% 202.03% 
 6 0x9987F4ab821927556bE111Eff044BdB0a8f51027 13000 ETH 181.20% 201.74% 
 7 0x31A47094C6325D357c7331c621d6768Ba041916e 10000 ETH 182.27% 201.50% 
 8 0x66F6d639199342619CAF8617bf80eA738e5960A3  5400 ETH 182.79% 201.20% 
 9 0x86b0BE38A41eE669Fb2d8cb5854a3C89a0a2b8Fe  3127 ETH 189.99% 200.99% 
10 0x139F904d6c441F0D4018166BeDe353A3EC492c3b  3847 ETH 198.17% 200.92% 
11 0xDa658221bA0Ed1791a975c1EDa4b5AAb1B39e139  3380 ETH 205.36% 200.85% 
12 0xa4FC81A7AB93360543eb1e814D0127f466012CED 33005 ETH 205.81% 200.39% 
13 0xE05fD1304C1CfE19dcc6AAb0767848CC4A8f54aa 11390 ETH 207.61% 200.67% 
14 0x254fa1c366505B4665Be0A18527fc7d78ec346Da  5963 ETH 207.79% 200.78% 
15 0x6555e1CC97d3cbA6eAddebBCD7Ca51d75771e0B8 21950 ETH 236.42% 198.89% 
16 0x681ada67950d96DCc9F2951d32353663Ed6e59c9  4000 ETH 236.96% 200.54% 
17 0x54664c16c3f5D0BC33bf914bC82dA9A2275f0EA2  8400 ETH 243.33% 200.03% 
18 0x805C559B43565505CEC1273801D5aAb30Fb91004  6046 ETH 263.35% 200.06% 
19 0x024BCbCAad82E67F721799E259ca60bc7d363419  8650 ETH 266.19% 199.65% 
20 0xBc79855178842FDBA0c353494895DEEf509E26bB 20000 ETH 338.51% 196.07%
21 0x1BEb1715899a355dfca4c763080E88F35286d025  3600 ETH 341.21% 200.04%

全体の担保率はもともと200.89%であり、20番目の20,000ETHの鯨の影響が200.89%-196.07%=4.82%とそこそこ大きいことが分かります。
もちろん何かあった際には鯨1頭だけが動くわけではないですが、仮に今のプロトコル全体の担保率が154%のときにこの鯨に抜けられてしまうとリカバリーモード突入…！となってしまう訳です。

しかし、鯨の動きに依存してはいますが、今のようにETHが集まっていればEthereumの値動きによる影響の方が大きいかとは思います。

意図的に精算させにくる可能性

次に（鯨に限らず）リカバリーモードを使って意図的に精算させにくる可能性について考えたいと思います。 そもそもLiquityの精算報酬は0.5%なので担保10ETHとかのポジションを狩りにくることはないでしょう。

あるとすれば、鯨のポジションを狩ることです。 例えば、上であげた3番目の鯨の担保は7200ETHであり精算報酬は36ETHです。 狩りにきてもおかしくはないと思いますが、そもそも技術的に可能なのかについて見ていきます。

攻撃シナリオとしては、
①大きなポジションを110%ギリギリに開き、全体の担保率を150%以下にする
②狩りたい鯨のポジションを精算する
③自分のポジションを閉じる
です。

ではまず、大きなポジションを110%ギリギリに開いて全体の担保率を150%以下にするには何ETH必要でしょうか。 適当に計算してみると250,000ETHで540,000,000LUSD借りると全体の担保率を150%以下にできるようです。 鯨でなくても、フラッシュローンでがっと借りてがっと狩ることができなくもなさそうですね。

しかし、この問題は開発チームの想定のうちでポジションを開くときに担保率チェックが入ります。 UIからだと110%以上であれば何でも開けるように見えますが、実際はポジションを開いてリカバリーモードに突入する場合には150%以上の担保率が要求されます。

なので、この攻撃は①からして既に破綻しています。

本当に攻撃を実行することは不可能か？

いいえ、鯨には可能です。 上記の攻撃が破綻した理由は、全てを1つのTXに押し込もうとしたためです。

そこで攻撃を複数TXに分けてやります。
①大きなポジションを110%ギリギリに開き、全体の担保率を150%ギリギリにする（1TX目）
②ETHが値下がりする方向のオラクルの更新を待つ
③狩りたい鯨のポジションを精算する（2TX目）
④自分のポジションを閉じる（2TX目）

オラクルの更新を待つ、が意味不明かと思いますが、mempoolでオラクル更新のTXを監視しておけば、次にプロトコルで使われるETHの価格が分かるため担保率の計算が可能です。

そしてオラクルの更新によって全体の担保率が150%以下になれば、好きなポジションを精算することが可能です。 また、オラクル更新のTXをサンドイッチするようにすれば他のユーザによる介入を受けずに攻撃の実行が可能です。

ただし攻撃に25万ETH必要であり、そもそも25万ETH用意できる鯨がどんぐらいいるのかという問題や、たった数十ETHのためにExploiter認定されたい鯨がいるとは思えないので実行されることはないでしょう。

まとめ

本ブログではLiquityにおける鯨の影響の考察を行いました。

結論として、過剰反応するほど鯨の影響を受けるわけではありませんが、単体で全体の担保率に約5%の影響を与える鯨が存在することは記憶の片隅に留めておくと良いかもしれません。
※状況が変わるとまた話が変わってくるので参考程度

以上、せっかくなので共有しておくかシリーズでした。