B A S I L KHAN

#dusk $DUSK @Dusk Today I went back through the NPEX/Dusk announcement history in order, instead of reading the most recent hype post first, and the actual timeline looks different once you line it up chronologically.
December 2025: Dusk and NPEX partner to launch what's described as Europe's first blockchain-powered securities exchange, with NPEX operating as a licensed Dutch MTF. February 2025: Cordial Systems joins as the custody layer. November 2025: Dusk and NPEX adopt Chainlink's CCIP and DataLink standards specifically so NPEX's official exchange data can be published on-chain. The Dusk Trade dApp itself is described as running on DuskEVM, starting with tokenized assets from NPEX, 21X, and other institutional players, with figures like €300M in assets referenced in earlier coverage.
That's a genuinely serious regulatory stack — MTF, Broker, ECSP licenses, with a DLT-TSS license described as forthcoming. This isn't a paper partnership; NPEX already runs a real, licensed secondary market for securities in the Netherlands.
But going through every source I could find dated in the last few months, I couldn't locate a single confirmed number for how many assets are actually live and tradable on Dusk Trade today, versus how many exist only as named partners in announcements. Every reference I found described capability, licensing, and integration work — not a current listings count. Treating "€300M in assets" as already tokenized and trading would be reading a target as a result, and I don't have evidence for that yet.
What I'm actually going to check going forward: whether Dusk Trade publishes a public, queryable listings count the way exchanges normally do, whether NPEX's own investor-facing site references live Dusk-based trading rather than the partnership itself, and whether the Chainlink DataLink feed is actually pushing live NPEX market data on-chain right now or is still in integration testing.

#dusk $DUSK @Dusk Today I tried to pull live numbers directly off the DuskEVM testnet explorer instead of trusting the announcement threads, and ran into something that changed what I was actually looking for.
The testnet explorer runs on Blockscout, which normally serves data through a queryable API — but the page itself renders client-side, so I couldn't extract the current transaction/contract counts through a direct fetch. That's a real limitation of checking this from outside a browser, and I don't want to state a number I didn't actually verify.
What I did find, though, was more interesting than a raw count. DuskEVM's public testnet launched December 5, 2025, described at the time as "the final step before mainnet launch." A separate Blockscout instance for DuskEVM Mainnet already exists and is indexing data as of today. That timeline is tighter than the "final step before mainnet" framing suggested eight months ago — and a Dusk-tagged post from August 10, 2026 was still promoting the testnet for Solidity/Hardhat testing, which raises a real question about which environment developers are actually being pointed toward right now.
I also noticed DuskEVM's architecture has a structural quirk worth flagging: it currently runs sequencer-only, with no public mempool. That's normal for an OP Stack rollup in this phase, but it means "activity" here isn't measured the same way as an L1 — a low testnet transaction count doesn't necessarily mean low developer interest, since sequencer-only chains don't show pending activity the way Ethereum's mempool does.
Rather than guess a number I can't verify, what I'm actually tracking now: whether Dusk's own channels start directing developers to the mainnet explorer instead of testnet, whether the testnet gets explicitly deprecated or kept running in parallel, and whether verified-contract counts on the mainnet Blockscout instance start climbing from real deployments rather than test scripts.

#dusk $DUSK @Dusk Today I went through the actual GitHub repos behind Citadel instead of just reading the announcement page, and the gap between the two was bigger than I expected.
Citadel was formally presented back in January 2023 a full research paper, a working protocol design, three defined parties (user, license provider, service provider), and a private NFT model built specifically to solve a real problem other SSI systems had: even when zero-knowledge proofs hide the content of a credential, the credential itself is usually stored as a public, traceable on-chain value. Citadel's whole contribution was fixing that leak.
The tooling exists too — Moat, the Citadel SDK, is live on GitHub, with a CLI and remote-access API for building on the protocol, requiring a running Rusk node and connected wallet. That's not vaporware; the code is real and open.
But checking the current documentation hub, I found a note that stopped me: the SDK "exists but needs updates for the current Rusk model." That's a meaningful gap between "protocol was designed and published" and "protocol is actively maintained against the network's current implementation." A three-year-old cryptographic design being technically sound doesn't tell you whether the integration layer keeps pace with a chain that's since gone through a multilayer architecture shift.
I don't think that means Citadel is abandoned — research-grade privacy tooling often sits dormant between bursts of integration work, especially while the team's attention was on DuskDS/DuskEVM/DuskVM. But it does mean citing Citadel as evidence of "live compliance infrastructure" right now overstates where the SDK actually is.
What I'm tracking going forward: whether Moat gets a commit updating it for the current Rusk model, whether any named institution or KYC provider actually deploys Citadel in production rather than referencing it as a use case, and whether Citadel gets folded explicitly into the DuskEVM/DuskVM roadmap or stays a standalone 2023 artifact.

#dusk $DUSK @Dusk If someone tells you a payment on Dusk is "confirmed," would you actually release goods, sign a contract, or send a wire based on that word?
Went back through the finality states after realizing I'd been treating "confirmed" and "done" as interchangeable, which isn't actually accurate on this chain.
A block moves through four separate states: Accepted, Confirmed, Stable, and Final. Only Final is deterministic and cryptographically guaranteed genuinely irreversible. Stable is the state just before it, and it's explicitly probabilistic, not absolute. It means the block is buried deep enough that reversal is extremely unlikely, not that reversal is mathematically impossible.
That distinction matters a lot more once real money is involved. If you're accepting a Stable-but-not-yet-Final transaction as settlement releasing an asset, confirming a trade, treating funds as cleared you're accepting a probability, not a guarantee, even though the difference isn't obvious just from reading a status label on a wallet or explorer. The number of blocks needed to actually reach true Final status isn't fixed either; Dusk moved to a "rolling finality" model where the count varies round to round based on network conditions, which means there's no single "wait X blocks and you're safe" rule you can rely on blindly.
@Dusk _Foundation I haven't found a clear, published worst-case number for how long the gap between Stable and Final can actually stretch under real network conditions, only that it's variable by design.
If you're using Dusk for anything involving real settlement, are you actually checking for Final before treating funds as safe or stopping at Stable because the word sounds finished enough?

#dusk $DUSK @Dusk If you send DUSK across the DuskEVM bridge, how do you actually know when your funds are safe to spend on the other side — and what happens if you guess wrong?
Went digging into this after almost making an assumption that could've cost me. My instinct was: inclusion looks confirmed on the block explorer, so the funds must be usable. Turns out that's exactly the wrong way to think about it.
Dusk's own developer docs are blunt about this: inclusion and settlement are two separate stages, and apps moving value between DuskEVM and the DuskDS layer are explicitly told to check protocol or wallet status directly — not to infer finality just because some amount of time has passed. Transaction inclusion on DuskEVM happens fast because it's a sequencer-based L2, but that's not the same moment your funds are actually settled and safe against the base layer.
Here's what that means practically: if you're bridging assets and you send or spend based on "it's probably done by now," you're relying on a guess the protocol itself explicitly warns against. The gap between "looks included" and "actually settled" is exactly the kind of window where acting too early creates real exposure — using funds that could still be reorganized or invalidated before they're truly final.
@Dusk _Foundation — I haven't found a published number for the actual typical wait time between DuskEVM inclusion and DuskDS settlement finality under normal network conditions, only the guidance to check status rather than count elapsed time.
If the protocol itself says don't estimate by elapsed time, are most wallets and bridge UIs actually surfacing real settlement status to users, or are people still just watching a timer and guessing?

#dusk $DUSK @Dusk Testing asset issuance flows on both layers side by side, I noticed the two protocols aren't just the same tool ported to different chains — they're solving privacy with genuinely different cryptography underneath.
Zedger runs natively on DuskDS and is UTXO-based, which means it can offer full anonymity in a way that's structurally hard to replicate on an account-based system. Hedger runs on DuskEVM instead, built for full EVM compatibility with standard Ethereum tooling — but because the EVM's account-based model can't support the same anonymity Zedger offers, Hedger takes a different technical route entirely. It stacks homomorphic encryption (ElGamal over elliptic curves) with zero-knowledge proofs, so balances and transfers stay encrypted end-to-end while still remaining computable and auditable, rather than just hidden.
The part I didn't expect: Hedger's proofs generate client-side, in-browser, in under two seconds. That's a real usability claim, not a marketing line — fast enough that institutional users don't need dedicated proving infrastructure just to transact privately on the EVM side.
So the actual choice between Zedger and Hedger isn't "which is more private." It's which trust and tooling model an issuer needs. Zedger gives UTXO-level anonymity but requires native Dusk tooling. Hedger gives full Ethereum compatibility and fast in-browser proving, but trades away that same anonymity ceiling because of the account model it's built on.
I haven't seen a clear answer yet on how an issuer is actually supposed to decide between the two once they need both EVM composability and Zedger-level anonymity in the same asset — whether that's even possible today, or if it forces a tradeoff nobody's fully solved.

#dusk $DUSK @Dusk
Running proof generation locally to benchmark circuit performance, I noticed something that made me go back and read the cryptography team's own writeups instead of the marketing pages.
PLONK's actual numbers are what make the compliance case work, not just the privacy angle. Verification time stays around 6-9 milliseconds regardless of circuit size — proving time scales with circuit complexity (roughly 5.46 seconds for a 2^16-gate circuit on modest hardware), but the verifier's side stays fast and constant. That asymmetry matters more for regulated finance than people give it credit for: an auditor or counterparty checking a proof isn't burning meaningful compute every time, even as the underlying transaction logic gets more complex.
What I hadn't expected to find was that PLONK itself had a real disclosed vulnerability, not just theoretical risk. Dusk's research team found a critical issue in how the Fiat-Shamir transformation was implemented — the piece that turns an interactive proof into a non-interactive one by hashing challenges instead of a live verifier sending them. The original implementation didn't hash the public inputs early enough, which weakened the soundness guarantee. Trail of Bits coordinated the disclosure, Dusk patched it before mainnet, and pushed the fix publicly rather than sitting on it.
That's the detail I keep sitting with — a compliance-focused chain built on a cryptographic proof system that had an actual soundness bug in production-adjacent code, caught and fixed before it mattered. I don't know how many other implementations using PLONK elsewhere were still vulnerable when this became public, or how long the gap was between disclosure and other projects patching their own forks.

#dusk $DUSK Can a blockchain be genuinely private and still let regulators see what they legally need to see?
Didn't expect the answer to hinge on encrypting a key with another key. Most privacy coins solve privacy by removing visibility entirely nobody sees anything, ever. @Dusk works on a different assumption: privacy should be selective, not absolute.
A user's transaction payload is encrypted with a user key, and that key is itself encrypted with a separate auditor key, so only an authorized auditor can decrypt it. The chain stays shielded from the public, but zero-knowledge proofs let users prove the auditor key was used correctly and the payload follows the rules without exposing the contents to anyone else. That's structurally different from anonymous: someone can see, under defined conditions, even though the public chain never does.
This carries into identity too. Citadel, Dusk's identity layer, lets someone complete KYC once and then prove eligibility using zero-knowledge proofs, without re-exposing personal data every time. It also fixes a gap in earlier privacy ID systems, where even leak-proof proofs were still attached to public, traceable on-chain values.
Here's the tension I haven't seen resolved: selective disclosure only protects you if the auditor key never gets compromised or misused. A privacy coin has no such key to compromise its guarantee is that nobody sees, period. Dusk trades that absolute guarantee for regulatory usability, which is the whole point for institutions but its privacy ends up resting partly on how tightly auditor access is governed, not on math alone.
If privacy on Dusk partly depends on who holds auditor keys, how much of compliance-first privacy is cryptography, and how much is institutional trust wearing a zero-knowledge proof?

#dusk $DUSK @Dusk ハックなしで、自分のトークンをチェーン間で移行すると本当にお金がかかるのでしょうか？

これを書く前に、Duskの移行（migration）コントラクトのコードをある夜かけて確認しました。というのも、「ネイティブ vs ラップド」は、単なる見た目の違いのように説明されることが多いからです。でも違います。
目立ったのは次の点です。ネイティブのDUSKは小数点以下が9桁ですが、ERC20/BEP20のDUSKは18桁です。移行コントラクトは固定の係数で換算し、移行する量が「1 LUXのきれいな倍数」でない場合、コントラクトは静かに切り捨てます。つまり、その閾値を下回るダスト（余り）を含めて移行しても、その余剰分がネイティブDUSKとして戻ってきません。バグではなく、設計として消えるだけです。
さらに挙げるべきなのは、信頼モデルそのものです。メインネットのネイティブDUSKが、ブリッジでBEP20へ出す際の実際の真実（唯一の出どころ）です。プロトコルはまずメインネット側のあなたのトークンをロックし、その後にBSC上でミントを実行します。ラップされたBEP20トークンは、そのロックがあるから存在するだけで、独立して裏付けられているわけではありません。どちらもウォレット上では同じ残高に見えますが、ネイティブDUSKを直接保有するのとは、根本的にリスクプロファイルが異なります。
そして、これは設計上のトレードオフというより運用上のリスクです。ネイティブDUSKをBEP20へブリッジするには、宛先のBSCアドレスをメモ欄（memo field）に入れる必要があります。これを省略するか、間違えると、ドキュメントに明記されている通り、ブリッジは取引を無視し、資金は失われます。スマートコントラクトのリバートもなく、自動返金もありません。相手側でミントされたトークンに行き先がないので、単純に消えるのです。
ほとんどのホルダーは、資金を取引所やウォレット間で移動する前に、自分が実際にどのバージョンを持っているかを確認していないと思います。たいていは「DUSK」と見えるだけで、それが同じものとして交換可能だと考えてしまうからです。

ネイティブDUSKが本当の真実で、ラップド版はロックとミントの証明があるから存在するだけなのだとしたら、なぜエコシステムは“メモ欄が1つ欠けるだけ”で資金を失いやすい形のままにしているのでしょうか？

#dusk $DUSK @Dusk
What does "trustless" actually mean when a bridge is moving your assets between two different execution layers?
Kept coming back to this question after reading how Dusk connects DuskDS to DuskEVM, because "trustless bridge" gets used as a marketing phrase almost everywhere, and it rarely survives close reading.
Here's what's actually happening: DuskDS is the settlement and consensus layer it's where finality, security, and data availability live. DuskEVM sits on top as a separate execution environment for Solidity contracts. Moving an asset between them isn't the same as moving it within one chain's own state — it means one layer has to prove to the other that a state change genuinely happened, without either side just taking the other's word for it.
The "native" part is what actually matters here. Instead of relying on an external validator set or a multisig custodian holding wrapped assets the classic bridge design that's caused most cross-chain exploits in this industry the bridge is built directly into the protocol's own settlement guarantees. DuskDS's finality (the "Final" state, cryptographically guaranteed and irreversible) is what the bridge leans on to confirm a transfer is actually safe to recognize on the other side.
That's a meaningfully different trust model than a bridge secured by a separate set of signers. But it also means the bridge's security is only as strong as DuskDS's own consensus assumptions — if there's ever a scenario where committee-based finality gets contested or delayed, the bridge inherits that same uncertainty, not a separate risk.
Haven't found a clear answer to this yet: what's the actual latency between DuskDS reaching "Final" and an asset becoming usable on DuskEVM and does that gap create any window where a rational actor could exploit timing rather than break the cryptography itself?
Is a bridge only as trustless as the settlement layer underneath it, or does DuskEVM add its own independent risk on top?

#baby @BabylonLabs_io If a validator turns malicious, does everyone delegated to them get punished together, or just the people they actually target?
Didn't expect the answer to involve encryption tricks rather than just "yes, everyone loses their stake." Naively, I assumed slashing worked like most PoS chains one bad validator, one collective penalty for anyone who delegated to them.
Babylon does something different using adaptor signatures. When a staker delegates, both the staker and the covenant committee pre-approve the arrangement, but the delegated validator's own signature is the only thing needed later to actually trigger slashing. To stop a rogue validator from slashing an innocent staker's funds unilaterally, the staker encrypts their pre-approval using the validator's own EOTS public key. That means if the validator ever tries to target that specific staker maliciously, decrypting the signature to do it forces the validator's own private key to leak — which then makes the validator's entire self-delegated stake and every other delegator's stake tied to them slashable too.
In other words, going after one person triggers the validator's own exposure across everyone attached to them. It's not isolation by policy it's isolation enforced by making the attack self-destructive for the attacker.
What I haven't found a satisfying answer to does this design create a perverse incentive where a validator, once compromised, has nothing left to lose and might as well maximize damage across every delegator at once, rather than targeting just one?
If slashing one person can cascade to everyone under that validator anyway, how much does the "isolated slashing" framing actually hold up in practice?
#baby $BABY

#baby $BABY ビットコインには組み込みのスラッシング（削減・罰則）ロジックがないのに、ビットコイン上でバリデータをどのようにスラッシュするのですか？
これ、実際に理解するのに思った以上に時間がかかりました。というのも、答えはスマートコントラクトではなく、コードではなく数学で巧妙にやりくりする署名方式だからです。
@BabylonLabs_io では、ビットコインのネイティブなシュノー（Schnorr）署名に基づく「抽出可能ワンタイム署名（Extractable One-Time Signature: EOTS）」を使います。核となるトリックはこうです。最終性プロバイダ（finality provider）は、投票する各ブロック高（height）ごとに固有の鍵ペアを生成します。彼らがその高さに対して署名するのが常に1ブロックだけである限り、署名は完全に安全で、何も漏れません。しかし同じ高さで矛盾する2つのブロックに署名すると、数学が破綻します。その高さごとの鍵を2通りのメッセージに使い回すと、ノンス（nonce）が再利用されることによるシュノー署名の仕組みのために、プライベート鍵が直接露出してしまうのです。
最終性ラウンド自体は、ブロックを実際に確定（finalize）するには、ステークされたBTCの総重量の3分の2超からの署名が必要です。したがって、安全性違反が起きるには、定義上、ステークの3分の1超が二重署名している必要があります。これが、「完全にスラッシュ可能（fully slashable）」という保証が、政策（ポリシー）の約束ではなく、数学的に強制される理由です。鍵が漏れた時点で、バビロンだけでなく、ただのバリデータでもなく、誰でもスラッシング取引を構築してブロードキャストできます。その段階では委員会の投票も不要で、異議申し立てのプロセスもなく、ただ露出した数学があるだけです。
まだはっきりした答えを見たことがない点：各ブロック高のために鍵生成を行うことは、複数のBSNを同時に運用する最終性プロバイダにとって意味のある運用上のオーバーヘッドになりますか？また、そのオーバーヘッド自体が、悪意ではなく過負荷の状況でプロバイダが誤ってランダムネスを再利用してしまう、といった攻撃面（攻撃可能性）になり得ますか？
EOTSのセキュリティは純粋に数学的な保証なのか、それとも最終性プロバイダが堅牢な鍵管理インフラを持っていることに、静かに依存しているのでしょうか？
$BABY

#baby $BABY 私は、ビットコインの「休眠（アイドル）供給」は固定された限界のようなものだと思っていました。つまり、じっと保有しているほうが、運用に回すよりも価値が高くなるような資産です。ところが、「アイドル」と実際に何が積み上がっているのかを見てみると話は変わりました。

いま、流通しているビットコインの99%以上がまったくステークされていません。これは単なる誤差ではありません。仮想通貨市場全体で最大級の休眠資本のプールであり、約1兆ドル規模の経済的な重みが、何もしないでウォレットの中に眠っているのです。

これを私の中で捉え直したポイントはこうです。ほかの主要チェーンはすべて、安全性を「ゼロから」組み立てるところから始めました。つまり、ステークされる資本を新たに作り出し、インセンティブを与え、何年もかけて成長させる必要があったのです。ビットコインにはその問題がありません。資本はすでに存在しています。すでに、この領域で最も信頼される価値の保存手段です。唯一欠けていたのは、そもそも信頼される根拠になっているカストディ（保管）の保証を壊すことなく、それを運用に回すための仕組みでした。

本当の賭けは @BabylonLabs_io がしているものです。ビットコインに新しいユースケースが必要だという話ではありません。ユースケースはずっとそこに存在していたのに、需要がないからではなく、技術的なギャップによって使われないままになっていた、ということです。

これは一夜にして起こるとは思いません。実際の普及には、十分な数のBSNが立ち上がり、十分な数のファイナリティ・プロバイダが信頼できることを証明し、そして、私がこのキャンペーンを通じて書いてきたのと同じくらいの入念さを実際に委任者（デレゲータ）が持って示すことが必要です。仕組み自体は稼働しています。その仕組みが、その「1兆ドル」の資本のうち意味のある割合までスケールするかどうかは、まだ未確定であり、当然の結果とは言えません。

次のフェーズに入って私が注目しているのは、発表されたBSNの総数ではなく、その休眠している99%のうち、実際にどれだけの割合が動き出すかです。
$1000RATS $IDOL
@BabylonLabs_io #1000sats

#HedgeFundsAddBullishOilBets #OpenAIFindsMoreAgentsEscapedContainment #AmazonRaises2026CapexTo$220B

アイドル状態のビットコインはバビロンにどれくらい動くのでしょうか？

#baby $BABY @BabylonLabs_io

以前は「ステーキング」といえば、現金化するまでコインを誰かに預けることだと自動的に思い込んでいました。 しかし、Babylonのステーキング取引に自分のBTCが入った瞬間に、実際に何が起きるのかを調べてみたんです。

BTCは、私の管理下から決して離れません。

BTCは、鍵を保有するカストディ（預かり）も、実資産の代わりになるラップド・トークンも、悪用され得るブリッジ契約も介さず、ビットコインネイティブのスクリプトによって直接ロックされます。 そのロックはビットコインの自前のチェーン上に存在し、ビットコイン自身のルールによって強制されます。これは、私がこれまで行ってきたすべての取引をすでに支えているのと同じルールです。

実際に起きるのは、組み込まれた2つの支払い（spending）経路を持つTaprootスクリプトです。1つは、タイムロックが終了した後に私がBTCを取り戻せるようにするものです。もう1つは、私が委任したバリデータがプロトコルを破った場合にのみ有効になります。これがスラッシング（没収）経路であり、私の資金が意図した経路の外に移動し得る唯一の状況です。

これはリスクがゼロだという意味ではありません。特定の条件を強制するためのコベナンツ（契約）委員会が関与しますし、最終性プロバイダ（finality provider）を不適切に選ぶことにも結果が伴います。とはいえ、「鍵を預けて1社を信頼する」のと、「ビットコインのスクリプトで強制され、定義されていて監査可能な仕組みを信頼する」のには本質的な違いがあります。カストディアルのステーキングは“約束”を信じるよう求めます。こちらは“コード”を検証するよう求めます。

誰かに依存したくないからこそ、特にBTCを保有していた人にとっては、この細部こそが本当に重要です。利回りの数字ではなく、その利回りを得ることによって、静かに、ビットコインが取り除くために作られた“まさにその依存”が再導入されてしまうのかどうかです。

@BabylonLabs_io 私はBabylonのファイナリティ・プロバイダーのモデルを通常のPoSデリゲーションと比較していて、ある点が際立っていました。それは、人々が想定しているようにはインセンティブ構造が対称ではないということです。
多くの委任型PoSシステムでは、バリデータが不正に振る舞った場合、あなたのステークもその罰を受けて、委任者のステークがバリデータと一緒にスラッシュされます。そこが肝です。つまり、委任者に対して「誰に委任しているのか」を実際に精査させる仕組みになっている。
Babylonの設定も、ビットコインに関しては同じコアの考え方を保っています。つまり、あなたのBTCは、あなたが選ぶファイナリティ・プロバイダーに基づいてスラッシングのリスクにさらされます。もっとも、あなたがそのコインの管理（カストディ）を渡してしまうわけではありません。
なぜ重要か：セルフ・カストディは通常「安全」として売り込まれますが、それで終わりです。しかしセルフ・カストディは、他人の悪い行動によるあなたのリスクをなくすわけではありません。なくなるのは、カストディに起因するリスクだけです。BTCは完全に自分で管理していても、うかつに委任すればスラッシングでBTCを失う可能性はあります。これは「取引所がハッキングされた」というリスクとは、意味合いがかなり異なりますが、ゼロではありません。ビットコインのステーキングに関するメッセージングが、その境界をときどき曖昧にしてしまっていると思います。
名前を挙げる価値のあるトレードオフ：この設計は、実際のデューデリジェンスをステーカー側に求めます。ファイナリティ・プロバイダーの選択は見た目の問題ではなく、能動的なリスクの意思決定です。稼働率、署名行動、運用上のセキュリティまでが、延いてはあなたの課題になります。初めてステーキングする多くのBTC保有者は、そうした考え方に慣れていません。なぜならBTCそのものが、人々に「主にカストディのリスクのことだけを考えればよい」と思わせる訓練をしてきたからです。
つまり、インセンティブ設計は紙の上では筋が通っています——理論上は、信頼できるファイナリティ・プロバイダーが信頼を得て、悪いものは委任が薄れていく、市場が形成されるはずです。ただ、その市場が実際に成立するかどうかは、設計が前提としているデューデリジェンスをステーカーが行うかにかかっています。#baby $BABY

今日、@BabylonLabs_io のドキュメントを理解するのに時間を費やし、最終的に「Finality Providers（ファイナリティ・プロバイダー）」が実際に何をしているのかが見えてきました。役割は、一見したとおりほど単純ではありません。

通常のPoSチェーンでは、バリデータがチェーンのネイティブトークンをステークして投票権（voting power）を得ます。ファイナリティ・プロバイダーは、それとは別のことをします。ステーカーからBTCの委任（delegations）を受け取り、その委任されたビットコインを、ブロックのファイナリティに関する投票の裏付けとなる経済的な重みとして使うのです。

ステーカーは自分のBTCを決して移転しません。秘密鍵は動きません。BTCはビットコイン上の自己管理（self-custodial）スクリプトの中にロックされたままです。委任されるのは、BTCが表す投票権だけであり、実体としてのBTCそのものが委任されるわけではありません。ファイナリティ・プロバイダーが投票します。そして、その投票を経済的に裏付けるのはビットコインであり、しかしそれは一度もステーカーの管理から外れることはありません。

私の考え方を変えたのは、この仕組みが、このセキュリティに依存するPoSネットワークにとって何を意味するのかです。安全性が、ネイティブトークンの価値だけに依存しなくなります。あらゆる最終確定投票の背後に「ビットコインの経済的な重み」が座ることに依存するのです。これは、今日多くのPoSチェーンが持てるものとは根本的に異なるセキュリティ基盤です。

罰則（スラッシング）の側面も、この全体像を完成させます。もしファイナリティ・プロバイダーがダブルサインした場合、EOTSが彼らの秘密鍵を露呈し、スラッシング条件が自動的に実行されます。彼らに委任された投票権には、実際の結果（consequences）が伴っていたのです。

私が考え続けているのは、この中でのステーカーの立場です。あなたは、あなたが直接コントロールできない振る舞いをするファイナリティ・プロバイダーに委任します。暗号はあなたの元本（principal）を守ります。しかし、保護されるネットワークの健全性という観点では、どのプロバイダーを選ぶかは依然として重要です。
投票権が委任されていても、BTCは決して動かないのなら、委任先をどう選ぶかを決めるステーカーに対して、説明責任（accountability）は実際にはどう見えるのでしょうか？

#baby $BABY

#baby $BABY / @BabylonLabs_io
今日はBabylonのドキュメントを読みながら、1つの疑問で何度も立ち止まりました。

ビットコインにはスマートコントラクトがありません。では、ビットコインのチェーンから一度も出ていないBTCに対して、どのようにプロトコルがスラッシングを強制するのでしょうか？

答えはCovenant Committeeですが、最初に私が想定していたような形ではありません。

すべてのステーキング取引は、それが有効化される前に委員会によって審査されます。彼らは、アンボンディングとスラッシングの条件がBabylonのルールと一致していることを確認します。合意形成（quorum）に達すると、その場でアンボンディング取引とスラッシング取引の両方に対して事前署名を行います。署名は、ステーキング期間が始まる前からすでに用意されています。

この事前署名という細部が、私のモデル理解を根本から変えました。委員会は、不正行為を監視してそれに反応しているわけではありません。最初からすべてに署名しているのです。その後、スラッシングを実行するために残るのは、Finality Provider自身の署名だけ。そして、その署名が利用可能になるのは、プロバイダがダブルサインした場合のみで、まさにEOTSが暴き出すよう設計されています。

私の中に残ったのは、ステーカーを守るために組み込まれている保護です。委員会はあなたのステークを盗むことはできません。誤ったスラッシングを引き起こすこともできません。スラッシング条件には、あなた自身のEOTS鍵が必要で、それを保持しているのはあなただけです。委員会が完全に侵害されたとしても、あなたの意思に反してあなたのビットコインを動かすことはできません。

「トラストレスなビットコイン・ステーキング」をいたるところで見かけて、そのまま鵜呑みにしていました。ところが実際に、ステーキングのスクリプト仕様書を読んでみたんです。

そこには、コベナント（誓約）委員会があります。

ビットコインの公開鍵が、ステーキング取引に直接組み込まれている当事者のグループです。彼らの仕事は、特定の支出ルートに共同署名すること。そうすることで、プロトコルは、毎回オンチェーンでのコンセンサスを必要とせずに、スラッシングやアンボンディングを確実に執行できるようになります。

彼らがいなければ、仕組み全体が機能しません。アンボンディングは速くできず、スラッシングも強制できない。

だから、見出しでは誰も触れない本当のトレードオフがこれです。Babylonはカストディアン（管理者）を取り除くものの、すべての信頼できる当事者を取り除くわけではありません。信頼を、監査できない台帳を持つ単一企業から、暗号学的な制約を持つ定義された委員会へと縮小するだけです。

これは本質的に違います。公開されたルールを持つマルチシグ委員会は、あなたの口座を凍結できるカストディアンとはリスクが同じではありません。とはいえゼロ・トラストでもありませんし、それをそうだと扱うと、後から驚くことになります。

今日ステーキングしている多くの人は、その委員会に誰が入っているのか、資金を動かすのに必要な署名のしきい値がどれくらいかを確認しません。

でも私は確認しました。BTCを何かにロックする前にやっておく価値があります。

トラストレスは二値ではありません。グラデーションで、Babylonはカストディブリッジよりさらにその先へ進んだだけで、最後まで辿り着いたわけではない、ということです。

#baby $BABY @BabylonLabs_io

#baby $BABY 今日、@BabylonLabs_io のステーキングドキュメントを確認していて、ここでいう「ネイティブ」というものをどう捉えるかについて、ある一つの点が私の考え方を組み替えてくれました。

ビットコインの利回りを得る既存のあらゆる道には、どこかで必ず資産のスワップが必要です。ラップ（ラッピング）によって、あなたのBTCは、ブリッジが保持しているものに価値が依存する合成デリバティブに置き換わります。ブリッジは、BTCを表す何かを別のチェーンへ移しつつ、元のBTCはどこかでロックされたままになります。どちらの場合も、あなたが最終的に持つのは「ビットコインそのもの」ではなく、ビットコインに対する請求権です。

一方で、バビロンのステーキングは仕組みが異なります。あなたのBTCは、ビットコイン側でスマートコントラクト・システムを必要とせず、ビットコイン自身のスクリプト言語、タイムロック、署名集約を使って、そのままビットコインに直接ロックされます。BTCは別の何かになりません。ステーカーが管理する自己保管型のスクリプトの中で、そのまま「ビットコインのUTXO」であり続けます。

ロックされている間、そのBTCが何をしているのか——そこが面白い部分です。これは、Finality Provider に委任されたステークとして、プルーフ・オブ・ステークのネットワークに経済的なセキュリティを提供します。Finality Provider が二重署名すれば、その裏にあるステークはスラッシュ可能です。実際の経済的担保としてのビットコインの存在こそが、それを参照するネットワークにとってセキュリティを信頼できるものにします。

アンボンド（資金引き出し可能になるまでの解除）に関する詳細が特に印象に残りました。タイムロック満了時のデフォルトの引き出しには、バビロンや外部オペレーターの協力は一切不要です。早期のアンボンドには、Covenant Committee の共同署名が必要で、その後7日間待てば資金を引き出せます。ステーカーは、外部の当事者が全員消えてしまっても、デフォルトの経路から常に退出できます。

この自立性は、多くの「ラップされたBTC」アプローチが再現できない性質です。退出経路は、ヴォルト作成時にビットコインのスクリプトへエンコードされており、誰か別の管理下にあるのではありません。

もし、ビットコインのステーキング利回りが、ビットコインから一度も出ることなく最終的に可能になるなら、時間とともにラップされた代替案への需要はどうなるのでしょう????

#baby $BABY
今日はバビロンのドキュメントを読んでいて、ある数字がずっと引っかかりました。ビットコインのうちDeFiで使われているのは1%だけです。

ビットコインは時価総額で最大の暗号資産です。しかも、分散型金融（DeFi）の世界では群を抜いて最も“アイドル”な資産です。理由は無関心ではありません。参入コストです。DeFiへの既存のあらゆる入口は、ビットコイン保有者に対して、(1) 第三者へ保管を委ねる、(2) チェーンをまたいでブリッジする、(3) 資産を合成（シンセティック）版にラップする、または(4) 支払い能力（ソルベンシー）が実質的なリスクになる仲介者を信頼する、いずれかを要求します。これらこそが、長年にわたってビットコイン保有者が「拒んできた」トレードオフです。

@BabylonLabs_io が作っているのは、まったく別の出発点です。BTCはビットコインから一度も出ません。預託者がバル ト作成時に共同署名するTaprootスクリプトにロックされます。正当な支出経路は、バ ルトが稼働する前にあらかじめ事前署名されています。その後は、どの当事者も新たな支出を捏造することはできません。プロトコルはBTCを外へ移動したり、別の場所へ貸し出したり、用途を転用したりすることができません。担保が行うのは、スクリプトが許すことだけです。

イーサリアム側では、プロトコルのコントラクトが各バル トを追跡し、統合されたDeFiアプリケーションがそれを担保として扱えるようにします。クロスチェーンの状態遷移は、信頼できる仲介者によるのではなく、暗号によって強制されます。信頼の前提が、カストディ（保管者）の支払い能力から、プロトコルの暗号技術と、その2つの基盤ネットワークへと移行します。

私に残った見方は、バビロンが“本来の意味で”言うところの「バル ト」です。多くのユーザーが共同でリスクを共有するプール型の資本契約ではありません。分離された、預託者が所有するビットコインのアウトプットです。DeFiの流動性プールというよりは、銀行の安全な区画に近い。

もし、既存のあらゆる入口で何かを差し出す必要があるからこそビットコインの99%がDeFiの外に置かれているのなら、その入口コストが本当に消えたとしたら、このスペースはどう見えるのでしょうか？？？