doyouknowthis

昨夜、ホワイトペーパーの「perps DEX」セクションに戻って、単にLendingsのマージンロジックが別名になっただけだろうと考えました。思ったより近いですが、完全には同一ではありません。$BABY

@BabylonLabs_io A トレーダーが Trustless Bitcoin Vaults（TBV）の vault に BTC IN を預け入れます。これは lending と同様です。vault のメタデータは、ライトクライアント基盤を通じて perps に対応したチェーンへ同期され、そこで collBTC が鋳造されます。しかし、ローンを担保するのではなく、ロング/ショートポジションのマージンになります。プロトコルのマージンエンジンが、PnL とリスク閾値を直接追跡します。

決済は lending の reDemption パターンを踏襲して、マージントークンをバーンし、vault に証明を提出し、タイムアウトを待って BTC を取り戻します。清算も同様で、反対側から清算人が買い取り、ポジションがメンテナンス閾値を下回ったときに collBTC をバーンします。

私は、lending のステーブルコインや perps にわたって vault プリミティブを再利用しているため、リスクプロファイルもどこでも基本的に同じだろうと思っていました。ですが、違います。perps は、固定のローン額で行う lending ポジションでは発生しない PnL のボラティリティを抱えています。

ここでの、より興味深い設計上の選択だと思います。つまり、別の用途ごとに別個の vault 設計を必要とするのではなく、異なるリスク形状を本当に異なるまま扱える「単一の担保プリミティブ」を採用している点です。

これは、どこかで既に確定した内容というよりホワイトペーパーにおける提案設計として記述されています。したがって、マージンエンジンの PnL 追跡が完全にオンチェーンで実行されるのか、それともオフチェーン要素に依存しているのかは、私はまだ把握できていません。資料には詳しく書かれていません。
#DoYouKnowThis
$EUL $BANK
#baby

Babylosの自社ブログには、私が予想していなかった投稿があります。自社製品を説明するプロジェクトからの、オープンな招待――その製品「Trustless Bitcoin Vaults（TBV）」を、その想定される弱点のチェックリストに照らして採点するように、です。#baby

SCRIPTは、ビットコイン担保ソリューションのための6つのリスクカテゴリの枠組みです。Sovereignty（主権）とは、清算されるまで保有者が名義を保つかどうか。Clarity（明確性）とは、事前に合意された、コミット済みかつ客観的な処分ルールがあるかどうか。Reuse Prohibited（再利用禁止）とは、同意なしでのレヒポテケーション（担保の再利用）が禁止されているかどうか。

Isolation（隔離）とは、各保有者の担保が個別に保管されているかどうか。Permissionless（許可不要）とは、第三者がシステムを検閲できるかどうか。Transparency（透明性）とは、オンチェーン上で各ポジションが監査可能かどうか。ブログは、Babylonsを含むあらゆるビットコイン担保ソリューションを評価するために、ビットコイン保有者やアプリケーションがSCRIPTを使えると、直接そう述べています。$BABY

私は、ある会社が自分の設計を持ち上げるようなフレームワークを公開することは、もちろんあり得ると思います。しかしこの投稿は、どちらのものでも――設計が実際に成り立っているかを確認するための「ちょうど6つの質問」をあなたに渡します。

そのリストをしばらく見ていると、6つのうちいくつかはTBVが簡単に通過できそうに見える一方で、1つか2つは本当に気まずい（不快感のある）ものにも見えました。自分のプロダクトなら当たり前に満点を取れるようなルーブリックを、わざわざ公開する価値があるとは思えません。

まだ自分ではTBVを6つすべてに照らして確認していません。きれいに通るのかもしれません。あるカテゴリがアスタリスク付きで返ってくるのかもしれません。そして、それを確かめるためにこそ、この枠組みが公開されたのだと私は思っています。
#DoYouKnowThis
@BabylonLabs_io
$BANK $UAI

Q4 2025レポートでのNeynarのFarcaster統合を読み、そこに組み込まれた前提（社会的評判のシグナルを簡単に見落とせる/通り過ぎられること）やアカウントの真正性、エンゲージメントの閾値をコンプライアンスに隣接するポリシーエンジンへの入力として使うことに立ち止まりました。

従来のコンプライアンスの枠組みでは、KYCが法的な本人確認を行い、制裁（サンクション）のスクリーニングは政府のリストに照らして確認し、AMLは取引パターンを監視してマネーロンダリングを検知する、というように、きれいに線引きされています。これらは通常、ソーシャルメディアのエンゲージメント指標や、プラットフォーム固有の評判スコアを、コンプライアンス判断の入力としては取り込みません。

NewtonのNeynar統合により、Farcasterのアイデンティティに対してポリシーベースの検証が可能になり、トランザクション実行前に、ソーシャルアイデンティティのシグナル（アカウントの真正性、評判、エンゲージメントの閾値）に紐づいたオンチェーンのガードレールをアプリケーションが適用できます。

では、制裁チェックと並んでソーシャルシグナルをポリシーエンジンに入れる実際のユースケースは何でしょうか。

最も筋の良い読み取りは、従来の意味でのコンプライアンスというより、Sybil耐性やスパム防止のため、という点です。以前の分析で取り上げた「Human Passport」統合がSybil検出に行動シグナルを使っていたのと同様です。アプリケーションは「この人が制裁対象かどうか」ではなく、「本当に確立されたアカウントかどうか」を基準に、特定の機能へのアクセスをゲートしたいのかもしれません。どちらもガードレールです。ただし、片方は規制上のコンプライアンスです。

私は、これらをポリシーエンジンのもとにまとめることで、Newtonがやっていることを、コンプライアンスに関する告知だけを追っていると見落としやすい形で広げているのだと思います。Newtonは純粋に規制対応のコンプライアンスツールというわけではなく、一般的なトランザクション前のガードレールシステムであり、ソーシャルアイデンティティの検証は、制裁やKYCに隣接しつつも別物の「ガードレール」カテゴリです。

まだ整理できていないのは、コンプライアンス・ポリシーエンジンと一般的なガードレールシステムを同じプロダクトにまとめることで、規制上のコンプライアンス・インフラを特に探している機関評価者に混乱が生じないかどうかです。$EVAA $LAB #DoYouKnowThis
@NewtonProtocol $NEWT #Newt