見出し画像

PlayToEarnの死にゆく運命からシミュレータを使って脱出する

垂水ケイ

こんにちは。垂水ケイです。

Machinationsというシミュレータを使ったBCG解説記事の第三弾です。

前回は「PlayToEarnの死にゆく運命をシミュレータを使って理解する」というタイトルで、ガンガン発行されたトークンが売られて値段が下がっていく様子をシミュレーションしました。

シミュレーションは所詮シミュレーションなんですが、ある程度モデルを作っておけば、パラメータを調整して精度を上げていくことができます。そして我々がプレイしているのはトークンの発行数やプレイヤー数などの詳細情報が公開されているBCGです（オンチェーンなら）。

そこで今回の記事のテーマは、オンチェーンデータをうまいこと取得し、モデルに組み込んでいこう！というもの。オンチェーンデータから最適ムーブを導き出すのはBCGの醍醐味の一つです。PlayToEarnのゲームが死ぬ前に離脱するヒントにも繋がってきますしね。

本記事では、実際のオンチェーンデータを取ってくるので、オンチェーンメインで稼働しているMyCryptoHeroesのRaysMiningを題材にしています。

  1. RaysMiningのモデル構築

  2. オンチェーンデータの取得

  3. 実際のデータとのフィッティング

  4. ケーススタディ

今回はこのような流れで進めていきます。Machinationsで構築したマクロモデルに、流動性・ユーザー数・トークンmint/burn数といったオンチェーンデータを組み込んでいきます。

実際のデータと比較しながらモデルの微調整を行い、どのパラメータがどうなったらヤバいのか？というケーススタディをします。あらかじめ撤退ラインを決めておくことで、BCGが死ぬ前に脱出しようぜというのが目標です。

まぁ所詮シミュレーションではあるので、想定外のことも起こりますんで参考程度に。ただ、トークン価格だけで撤退ラインを決めておくよりも多角的視点を持てるようになるはずです。

それではやっていきましょう！

RaysMiningのモデル構築


RaysMiningはMyCryptoHeroes（MCH）のエントリーモデルでPlayToEarn系（稼げるとは言ってない）のゲームです。歴史上のヒーロー3体セットのNFT（Soul）を使ってバトルをすると宝箱がもらえ、開封するとユーティリティトークン（UT）のRAYSがもらえます。ガバナンストークン（GT）はMCHCです。

エコシステム概略はこんな感じです。ポイントだけまとめます。

  • RAYSとMCHCでSoulをサモン（mint）

  • Soulを使ってゲームをプレイ

  • プレイによりRAYSをゲット

  • Soulはburnして強化できる

  • 強化したSoulはAuraとしてMCH本編で使える

ここで、ゲームプレイで入手したRAYSの売却が売り圧、Soulをburnして覚醒値を上げAuraとしてMCHで使っていくのが買い圧に相当します。AuraはMCHでヒーローにセットして使う、強化アイテムみたいなものです。デュエルで上位を狙いたい人たちが欲しがるものです。

ちょっと情報が少ないかもしれませんが、このエコシステムのマクロモデルをMachinationsで作ってみたのが下図です。最近はモデルを作る時に、左側に売り圧要素、センターにDEX、右側に買い圧要素って感じでレイアウトしています。買い圧vs売り圧ってのが見やすいかなと。

ちなみに今回はMachinations上に公開してみました。アカウント作れば下記リンクからアクセスして動かせると思います。

モデルの要点をまとめます。DEX部分については、前回の記事で説明していますのでそちらを参照。

  • RaysMining側でのMCHCへの影響は軽微なので割愛

  • 小数点の都合で、1kRAYSを1単位としてシミュレーション

  • 1日あたり8個の宝箱ゲットできるので、宝箱から獲得できるRAYSの期待値にユーザー数と8を掛けた数字がおおよそのゲーム由来の売り圧

  • サモンには9kRAYS必要なので、買い圧は9kRAYS×サモン数

  • RAYSの価格はプールのトークン比率で決まる

  • 実際はETH/RAYSプールだがわかりやすくするためにETH/USDの仮想プールでシミュレーション

先ほどの図は完成版なので既に数値が入ってしまっていますが、実際にはゲームの仕様やオンチェーンデータが必要になってきます。具体的に挙げていくと以下のような数字ですね。

  • ゲームの仕様

    • 宝箱の獲得数→1日8箱まで

    • サモンコスト→9kRAYS

  • オンチェーンデータ

    • ユーザー数（DAU）

    • RAYSの獲得数

    • サモン数

    • RAYSの流動性

ゲームの仕様は、プレイするなりドキュメントを読むなりすればOKです。というわけで、ここからはオンチェーンデータを取っていきます。

オンチェーンデータを取得する

オンチェーンデータの取得にはDuneAnalyticsというサービスを使います。これは、オンチェーンデータベースに対してクエリを書いて必要なデータを取得できるサービスです。クエリをもとにグラフを作り、それを組み合わせてダッシュボードを作成することもできます。

作ったクエリやダッシュボードは公開できるので、ある程度の規模のBCGになってくると、有志がコアデータを取得して公開していてくれたりします。

今回使うのは、RaysMiningに関するデータが公開されているこちらのダッシュボード。作ってくれた人マジサンキューなやつです。

ダッシュボードを覗いてみると、RAYSをclaimしているアカウント数や、

サモンされたソウルの数なんかがまとまっています。

中身を見てみると、クエリが書かれているのがわかります。

上のコードの部分にクエリを書き、下の部分でグラフ化の設定をします。

select
  date_trunc('day', "block_time") as time,
  count(
    "to" = '\x9a2ea49af0ce66c99b1f46f74bc2e9e356f34259'
  )
from
  polygon."transactions"
where
  "success" = true
  and "block_time" >= date_trunc('day', now()) - '60 day':: interval
  and "block_time" < date_trunc('day', now())
  and "to" = '\x9a2ea49af0ce66c99b1f46f74bc2e9e356f34259'
group by
  1
order by
  1 desc

書かれているコードはこんな感じでした。

SQLは全然書けないんですが、とりあえずtoのコントラクトアドレスに送られたトランザクションの数をカウントして、デイリーで集計しているって雰囲気は伝わってきますね。

toのアドレスに0をつけてpolygonscanで検索してみると、Soulがサモンされているということがわかります。

あとは、コントラクトアドレスを変えたり、データを取得する期間を変更したりして必要なデータを入手します。SQL書けない人は誰かがダッシュボードを作ってくれるのを待つか、自分で勉強してなんとかやります。

参考になるクエリがたくさんあるので、他のブロックチェーンゲームのダッシュボードとか覗きながらやれば意外といけます。

トークンの流動性もDuneで取得できますが、これに関してはDEXのanalyticsを見にいくのが手っ取り早いですね。

RAYSの流動性はQuickswapにあるので、そこを見にいきます。

https://quickswap.exchange/#/analytics/v2/pair/0x8a2423d73d6790bd61b4da33eed33744dfa3e62d

これで流動性のデータが拾えましたね。

BCGのトークン価格は意外とコインゲッコーとかに載ってなかったりするので、DEXToolsなどのチャートサイトを見にいきましょう。RAYSはここ。

さて、ここまでで必要な情報が揃ってきたので、ここからはモデルに組み込んで調整していきます。

実際のデータと比較してモデルを調整する

今回はRAYSの価格と比較してモデルを調整していきます。直近90日間のチャートがこちら。

大量エアドロで一度は地に落ちたんですが、ここ最近は上昇トレンドになっていて、90日間で$0.00015→$0.0006まで上がっています。すごいぞマイクリ！

それでは、先ほど取得したデータを入れて、シミュレーションを走らせていきます。

DAUやSummon数/day、LPあたりを調整していきます。実際の値を正確に入れて合えばそれでいいんですが、モデルには組み込んでいない外乱での影響も当然受けますんで、そのあたりはざっくりで。外乱の影響をパラメータに内包させていくイメージでやってます。

今回は90日間で1kRAYSあたりの価格が$0.15から$0.6あたりまで上昇するように調整できればオッケーという感じです。

調整していった結果がこちら。90日目でトークン価格が$0.6になりました。

各種パラメータと実際の値の違いをみても、そこまで大きく乖離はしていなさそうです。モデルは一旦完成としましょう。

崩壊のケーススタディ

モデルが出来上がったので、ここからさらにパラメータをいじっていき、どうなったら崩壊するのかを考えていきます。

まずは何かのきっかけで人が増え過ぎたパターン。

90日目の時点で、DAUを130から2倍の260と、3倍の390に増やしてみました。2倍はまだ大丈夫ですが、3倍ともなるとトークン売却が増えるため、価格が落ちていきます。

買い圧がそのままでユーザー数が増えてきたら、DAU300あたりが撤退ラインかなと想定しておくことができますね。

次はサモン数を見ていきます。サモンされたSoulは覚醒でburnされてAuraとしてMCHのデュエルで使われていくんですが、デュエル人口が増えなければ需要はそのうち頭打ちとなります。

90日目の時点でサモン数を30から20に減らしたパターンと10まで減らしたパターンのシミュレーション結果がこちらです。

30が20になったくらいなら大丈夫そうですね。10まで減ってくると減少傾向です。1日あたりのサモン数が15あたりになってきたら要注意といったところですね。

ちなみに今回は楽をするために90日の時点でパラメータをガラッと変えましたが、関数で定義して徐々に変化させていくことも可能です。クリティカルに効いてくるパラメータは慎重に入力した方がいいです。

まとめ

マイクリRaysMiningのモデルをつくり、オンチェーンから取得してきたデータを使いながらパラメータを調整して崩壊パターンをシミュレーションしてみました。

パラメータを触っていくうちに、DAUやサモン数などがトークン価格の推移にどのように影響を及ぼしていくか見えてきます。ポンジ崩壊に巻き込まれないためにも、多角的な視点を持っておくといいですね。

まぁ個人的には、ポンジどうこうよりも、オンチェーンデータを使って最適ムーブを探るってのが実にBCGらしくて好きでやってます。

twitterのフォローもよろしく！

この記事が気に入ったらサポートをしてみませんか？