"Stake Abstraction"を"Hyperstaking"に翻訳した瞬間、それはプロトコルのパラメータから製品のコピー文句へと変わった——しかしドキュメントの底層まで辿ると、実際にやっていることは、質権をEOAの秘密鍵からスマートコントラクトへデカップルすることです。コントラクトはStake Contractのstake_from_contractを通し、Transfer Contract経由でコントラクト間呼び出しを行い、アクティベーションには依然として4320ブロック（約12時間）の成熟期間が必要。最低の門槛も同様に1000 #dusk 。

問題は、「コントラクトが質権者である」という一文に含意された点です。SBAのコンセンサスでは、Generator/Provisionerの抽出はProof-of-Blind Bidと決定論的なソーティションに基づき、重みはアクティブな質押に応じて決まります。ところがその重みがプライベート委任コントラクトに埋め込まれると、外部から見えるのはコントラクトアドレス全体の総質押だけで、その中身が300人の小口投資家なのか、1つの機関が5つのシェルに分けているのかは分かりません。@Dusk は自らauditable privacyを掲げていますが、Hyperstakingのプールは強制的にview keyを接続して監査を行う仕組みなのか——ドキュメントに明確に書かれていません。そうなると「分散度」は、検証可能な仮定から、信頼の宣言へと退化してしまいます。

LSDの層もさらにややこしいです。基礎プロトコルのunstakeは待機期間がなく、報酬は確率的で、ユーザーはそのまま引き揚げてstDUSKなどのプールで償還する方が自然でスムーズ。Lidoモデルを無理に当てはめると、需要は自然に湧くのではなく、コントラクトが供給してくれることになります。その結果、たぶん本来深くない$DUSK の流動性を、さらにいくつかの切片にしてしまうだけでしょう。

私は「ネイティブにプログラマブルな質押をサポートする」からといって加点しません。耐荷重壁（コンセンサスの安全性）に窓を1枚開けるたびに——プライベート委任、LSD、収益戦略——次のことを問うべきです。コントラクトの監査はreceive_reward/receive_unstakeのコールバックをカバーしているのか？プライベート・プールの重み分布は第三者のダッシュボードで可視化できるのか？Sozuのような最初期に発射されたプールでは、slashingの際にロックされる部分をどう処置するのか？これらに答えられないなら、Hyperstakingは質押のアップグレード版ではなく、元々の2状態のシンプルな機械を、1000個の未監査状態機械に置き換えて、同じコンセンサス鍵を使い回すだけです。