# DeFi運用のAPYが100%付近で変動するため、ガス代の計算が事実上無駄とわかり複利運用方針を決定した（あとセキュリティをいじった）

**Published by:** [mayu2001](https://paragraph.com/@mayu2001/)
**Published on:** 2023-02-18
**URL:** https://paragraph.com/@mayu2001/defi-apy-100

## Content

こんにちわです<(｀･ω･´) web3に限らないのですが、セキュリティ周りを6時間ほどいじって利便性と安全性のトレードオフについて調べていました。こちらはまだ試行錯誤していますが、課題になっていたBalancerの流動性マイニングで運用中のAPY100%付近での手動による複利運用の件については、答えを出しました。バナーに示しましたように、1日とか半日とか、2日とか、期間を特に決めなくても、いつの間にか数十ドル溜まっています。そうであれば、その溜まったタイミングで複利運用の手動操作をしてもいいと判断します。イーサリアムチェーンと違ってPolygonであるため、毎回のトランザクションにかかるガス代は、数十ドルに比べれば微々たるものですから。複利運用の手順としては、BAL報酬トークンの引き出しBALからUSDCかWUSDRの流動性の足りないトークンへスワップスワップしたトークンを流動性マイニングの預け入れ預け入れた証拠トークンをステーキングの４つのトランザクションを行うことになりますが、これ全部ひっくるめても、絶対に１ドルもかかりません。Polygonでの直近のトランザクションにかかったガス代が右側の列に羅列されていますが、$マークがついているので、単位はドルだと思います。実際、以下に示すトランザンザクションの具体例でも0.037 MATIC = 0.057 USDですから。混んでいるタイミングだったのか、トランザクションの処理が重かったのか、一番かかっているトランザクションで0.08ドルですから、たまたま4回分、この大きさのガス代が続いたとしても、0.32ドルにしかなりません。その割に、1日当たりで今のところ20ドル程度は入ってきていますから、ガス代の方がおよそ2桁小さいわけです。 そうなると私のヒューマンエラーの方が問題です。複利運用の手順を間違えるとすれば、最もありえるのは、流動性の足りないのが稀なトークンであるWUSDRだと思い込み、実はUSDCの方が流動性足りないのに、逆のスワップと流動性の追加をしてしまって、変動損失に影響を与える2つのトークンの価値のバランスを乱す可能性がありえます。たぶん、流動性を追加する前にスワップのミスに気がついて、もう一度スワップをして最大0.08ドルのガス代を上乗せしてしまう場合の方が多いと思いますが💦 とにかくAPYが100%超えた付近で利益が変動し、またガス代の方も変動するからには、ガス代より2桁上の数十ドルの報酬が得られていて、落ち着いて複利運用の手順を行える、余裕のある時間帯に、ミスしないでこなしておく、これが結論です。今後APYが下がって50%といった数値になる時期もあるかと思われますが、その場合には、数十ドル貯まるまで待ってから複利運用の手順をとりつつ、APYが100%を下回る時期が長引いた場合には他のイールドファーミングを探すことになるかと。 一応今朝の時点の残高とAPRが分かるスクショを示しておきます。何回か複利運用の手順をやってみたのですが、少し違和感を覚えているのは、WSUDRではなくUSDCの流動性の方が足りない場合ばかりだったことですね。WUSDRの需要があるから、この流動性プールが、高いAPRで成り立っているはずなのですが、そうじゃなくてUSDCの方が不足するということは、WUSDRからUSDCへのスワップの需要が高いことを意味します。つまり、どこかのDeFiかCEXか、ともかく何らかの暗号資産のサービスで、それなりにWUSDRが得られていて、しかしWUSDRは需要がないため、USDCへとスワップして別の用途に用いている流れが存在するはずなのですが、まだ英語の海の中をのそのそと泳いでいる状態で、その仕組みがどこに存在するのか、調べている途上です。さて、ここまでのスクショで、バナーとして上げたBALトークンの引き出しの画面は、実は、Android12のBraveブラウザでもChromeブラウザでも、[Claim all]をタップしても反応なく、やむなく、MetaMaskに組み込まれているブラウザでやってみるとうまくいきました。ですから複利運用の手順は、今後はMetaMaskのブラウザで行おうと思います。 ここからが利便性とセキュリティの妥協点になって、しかも利便性が下がる理由がわからないことが多く悩ましい部分なのですが、実は、一番正常に動作すると期待していたGoogle Pixel4a(5G)にて、Braveブラウザに最初から内蔵されている簡易的なウォレットの指紋認証が通りません。毎回指紋認証の手順は表示されるので、スマホの裏に手を回して指紋認証をするのですが、その後なぜかパスワードの入力を要求されます。ウォレットをリセットしてシードフレーズから再構成しても同じ結果になりました。 これがZTE A103ZTという、Android13のPixelよりも明らかにグレードが落ちるYモバイルで1円販売していたAndroid12端末の方では、あっさりBraveウォレットの指紋認証も、MetaMaskの指紋認証も通ります。理由がまったくわかりません。しかも電源ボタン上に指紋認証のセンサーが載っているため、スマホの裏に手を回す必要さえなく、暗号資産を扱うのに快適です。チェーンを切り替えずにPolygonのままで作業するのにも向いているので、同じシードフレーズを設定して、SIM入りのPixelと使い分けて、SIM無しのA103ZTの方の暗号資産のミドルリスク運用機として用いています。もともとA103ZTは、安いだけあって、いろいろなアプリが仕様通りの動作をしないことが苦になり、Google純正のPixelの古い機種に乗り換えた経緯があって、なんだか複雑です。多くのAndroidアプリで、Pixelの方が開発の動作テストにもかけられる機会が多いはずで、実際に多くのアプリが仕様通りの動作をします。A103ZTの方は、ホームアプリでさえ、何がきっかけになったか分からないまま、工場出荷時の状態へと初期化されるというインシデントが過去にあったため、別のホームアプリを入れて利用している状態です。辻褄があわないのですが、今後も暗号資産の定番の手順は、A103ZTでやることなると思います。 先日のbitbankからウォレットに送金した際にセルフゴックスのように着金しなかった件は、まだ不明なままですが、1つだけ分かったことがあります。webacyというサービスの無料プランを利用して私のウォレットアドレスへの入出金をSMSアラートとして通知させているのですが、bitbankの未着金の出金については、正常なアラートが通知され、bitpointの正常着金のケースでは、webacyがアラートを通知しませんでした。もしかすると、それが未着金であった理由のヒントになるのではないかと考え、Discordで拙い英語で尋ねたところ、webacyのウォレットアドレスの監視サービスは、将来的には他のチェーンに対応する予定はあるものの、現段階ではイーサリアムL1チェーン上のトランザクションの場合だけ機能することがわかりました。bitpointの方は出金側もPolygonで、着金側もPolygonで閉じていたために、webacyのアラートが出ず、この点は仕様ということでした。 ついでにもう一つ尋ねたことがあって、webacyの暗号資産相続サービスの日本語対応についてです。実は、webacyの共同創業者は日本人女性です。 https://type.jp/et/feature/20142/ 6月以降に、7桁台の私にとっては大きな投資を行った、不動産クラウドファンディングの運用資産が利回り付きで連続的に償還されてくるのですが、私は既に身障者で小さな病気を複数かかえています。そのため暗号資産をハッキングから守るという意味に加えて、DeFiで運用中の状態であっても妻への相続可能にする意味でも、webacyのサービスはとても魅力的です。しかし妻が英語をほぼ理解しないため、日本語によるwebacyの暗号資産相続サービスのガイドか何かがないか、問い合わせています。多くのDeFiのドキュメントが英語と、ほんの僅かの中国語でしか記述されてきていないために、7桁の資産をDeFiでの運用に投入してしまうと、妻がそれを引き出すことはおそらく不可能になってしまうため、ローリスクなガチホBTCペーパーウォレット程度しか手を出せなくなってしまい、BTCでLightningが普及してガス代が解決しても、BTCのステーキングサービスでさえ利用できないという状態になります。 https://world.webacy.com/a-hardware-wallet-is-not-enough-behind-the-nft-god-hack/ 2023年2月13日付の上記のwebacyのウォレット監視サービスがハッキング被害を阻止するといった内容の記事が日本人女性によって記されているため、日本人が現在もまだwebacyの運営に携わっていることは間違いないのですが、Discordサーバには日本語チャネルは存在せず、なかなか難しいところです。6月までに解決策が見つかるといいのですが💦 あと、これはCEXを利用する際の二段階認証の場合に、Google Authenticatorでは、Androidの間でリアルタイムの同期機能がなく、CEXを追加する度に各スマホのAuthenticatorでエクスポートとインポートの作業を必要とし、またWindowsは非対応のため、別のAuthenticatorを選定に悩んでいました。結果的に導入したのは、Authyです。 https://authy.com/ 携帯電話番号を軸として、AndroidとWindowsの間で共通に用いることができ、日本語の解説記事も豊富です。 https://thoughts-make-things.com/entry/authy ただ、Google Autheticatorにはすでに20以上のサービスが登録済みで、これを全て一旦二段階認証をSMS認証へと切り替えて、再びAuthyに登録し直すというのは苦痛であったため、やむなく以下の方法でGoogle Authenticatorのエクスポート機能を、ある意味ハッキングするようにして、強引に秘密鍵を引き出す方法を試してみました。 https://shieldplanet.com/extract-secret-keys-from-google-authenticator-qr-code/#download-the-secret-key-extraction-software 実際にやってみると、この英文記事の時点ではPythonでの作業を必要とすることになっているのですが、README.mdを読むと、すでに実行形式ファイルとして完成されていて、要するにWindowsのEXEファイルをダウンロードして、作者不明なので実行前にWindowsが警告を出すものの、アンチウィルススキャナーでそのファイルをスキャンして問題なければ、実行してしまうと、Windowsパソコンのカメラが起動して、Google Authenticatorのエクスポート機能のQRコードを直接的に読み込めるところまで開発が進んでいました。 https://github.com/scito/extract_otp_secrets/blob/master/README.md そういうわけで、CEXへの登録が増えてきて、2段階認証の同期とWindowsでの利用が利便性のため必要になり、複数の端末で２段階認証がほぼ同じ手順でできてしまうという、多少のセキュリティ的な部分は妥協しながら、利便性の面では飛躍的に向上したのが、今日のところです。 まぁ、エンドツーエンド暗号化のクラウドストレージを無料で使うとか、Googleやツイッターの連携機能は信用できるサービスでないと絶対にやらずにエンドツーエンド暗号化のパスワードマネージャを使うとか、いろいろ気をつけてはいますが、話こんがらがるので、今日はこの辺で！ ではでは<(｀･ω･´)

## Publication Information

- [mayu2001](https://paragraph.com/@mayu2001/): Publication homepage
- [All Posts](https://paragraph.com/@mayu2001/): More posts from this publication
- [RSS Feed](https://api.paragraph.com/blogs/rss/@mayu2001): Subscribe to updates