私は Babylon の共同ステーキング手順をもう一度最初からやり直しました。一番不快なのは、重要な条件が多く、報酬を受け取れていないときになって初めてユーザーが気づくことです。

公式は手順を2ステップに要約しています。BTC を Finality Provider に委託し、BABY を検証者に再委託します。ですが、実際に操作すると、BTC は PENDING から VERIFIED を経由して最後に ACTIVE に入る必要があり、ACTIVE 状態になって初めて報酬の対象になります。さらに BTC と BABY は同じ BABY アドレスを使わなければならず、アドレスが一致しないと共同ステーキング報酬は即ゼロになります。報酬効率を最大限に引き出すには、約 1 BTC が 20,000 BABY に相当することも覚えておく必要があります。

問題は、普通のユーザーが「送信済み」や「検証済み」を見ると、すでに完了したものだと誤解しやすい点です。どのステップで詰まっているのか、なぜ報酬が出ないのか、選択した Finality Provider がまだ稼働中なのか、2つのアドレスが本当に一致しているのか——ページ側で最初から明確に説明されるべきで、ユーザーが自分でドキュメントをめくって推測する形にすべきではありません。

現在 Babylon のパネルには、約51,342枚の BTC が質押済みであること、132の Finality Provider のうち活発な状態は36のみであること、BTC の年化利回りは 0.04% から 0.70% の範囲であることが表示されています。規模はすでに立ち上がっていますが、ユーザー側はまだ自力でトラブルシューティングをしています。

退出(アンスタケ)手順も、見た目ほど簡単ではありません。公式の BTC 解質押ドキュメントには、最低待機時間が 301 ビットコイン・ブロックだと明記されています。CLI の故障切り分けでは、gas パラメータ、RPC、GRPC の設定などが絡む可能性があり、解決できなければ Discord に助けを求めることになります。

@BabylonLabs_io に対する私の疑念はかなり明確です。プロトコルが複雑なのは理解できますが、製品がその複雑さをそのままユーザーに丸投げしてはいけません。

本当に補うべきなのは、状態の説明、エラーの切り分け、そして明確な対処手順です。そうしないと、いわゆる「自己ホスティング」は、—理解できない問題はすべてユーザーが自分で責任を負う—という形に簡単に変わってしまいます。

#baby $BABY @BabylonLabs_io