#dusk $DUSK @Dusk 午後、ダスクのステーク抽象化ノートを掘り返していて、いつもの流動性ステーキングの話が出てくると半分は思っていました。
でも実際に刺さったのは、もっと静かな点でした。スマートコントラクトが自分自身でステークできるようになっているのです。コントラクトが入金を受け取り、ポジションを運用し、報酬がどう扱われるかを自分たちのルールに従って決めます。
本当に引っかかったのは、そのフローです。コントラクトは単に stake_from_contract を起動するだけではできません。資金はまずコントラクト内部に置かれ、その後、 contract_to_contract の呼び出しを通じて Transfer Contract に押し出され、そしてようやく genesis の Stake Contract がそれらに触れます。
それでも 1,000 DUSK の最低フロアは据え置き。アクティベーションは次のエポック境界に加えてさらに1つ待つ仕組みで、実際にはだいたい1〜2エポック程度です。アンステークと引き出しも同じように動き、コールバックによって資金と報酬がすぐにコントラクトのロジックへ戻されます。
Sozu は、すでにそこに存在する具体例です。誰も自分でプロビジョナノードを立ち上げる必要のない、自動化されたプール。肝心なのは利回りの数字ではありません。ステーキングが、ウォレット作業のようなものから脱して、他のコントラクトがただ接続するだけで済むものになれるかどうか—プール、報酬分配器、そして自律して動く完全な戦略へと広がっていけるかどうかです。
お茶を少し置いて、じっと見つめてしまいました。そうすると気になってくるんです。実際のアプリが積み上がっていく前に、すべてのネットワークが最終的に、このような形でセキュリティ層をプログラマブルにしなければならないのではないでしょうか。
でも実際に刺さったのは、もっと静かな点でした。スマートコントラクトが自分自身でステークできるようになっているのです。コントラクトが入金を受け取り、ポジションを運用し、報酬がどう扱われるかを自分たちのルールに従って決めます。
本当に引っかかったのは、そのフローです。コントラクトは単に stake_from_contract を起動するだけではできません。資金はまずコントラクト内部に置かれ、その後、 contract_to_contract の呼び出しを通じて Transfer Contract に押し出され、そしてようやく genesis の Stake Contract がそれらに触れます。
それでも 1,000 DUSK の最低フロアは据え置き。アクティベーションは次のエポック境界に加えてさらに1つ待つ仕組みで、実際にはだいたい1〜2エポック程度です。アンステークと引き出しも同じように動き、コールバックによって資金と報酬がすぐにコントラクトのロジックへ戻されます。
Sozu は、すでにそこに存在する具体例です。誰も自分でプロビジョナノードを立ち上げる必要のない、自動化されたプール。肝心なのは利回りの数字ではありません。ステーキングが、ウォレット作業のようなものから脱して、他のコントラクトがただ接続するだけで済むものになれるかどうか—プール、報酬分配器、そして自律して動く完全な戦略へと広がっていけるかどうかです。
お茶を少し置いて、じっと見つめてしまいました。そうすると気になってくるんです。実際のアプリが積み上がっていく前に、すべてのネットワークが最終的に、このような形でセキュリティ層をプログラマブルにしなければならないのではないでしょうか。

