Rokyo

I wanted to know what "Connect Wallet" actually gives a dApp access to, so I tested the real flow on Dario and Pieswap on Dusk testnet. On both, the first connection returned only the profile ID and public account. The popup was explicit: "The site will only be able to use the selected profile's public account." Only when I requested the shielded receive address did a second consent step appear, and only then did the response include shieldedAddress. The popup changed too, naming the "shareable shielded receive address." Both integrations showed the same sequence.

Here's the flip: I was treating "Connect Wallet" as one permission event. It isn't. The controlled test separated public-account access from sharing the shielded receive address at the point of consent.

That separation puts part of the minimum-disclosure boundary in the wallet's consent flow, not entirely on the user to manage. In both tests, clicking "Connect" alone never granted the shielded-address scope; a dApp had to cross a separate consent step to get it.

I also got one thing wrong while investigating. I thought the 132-character account string might hint at shielded access. It doesn't. Both dApps returned the same account format on baseline, while shieldedAddress stayed absent until the explicit request.

There's still one unresolved question. An earlier Dario mainnet session behaved differently, but I haven't reproduced it under the same controlled conditions, so I'm not calling it a leak. I can only say the public-only permission boundary held across the two testnet integrations I checked, not that it is guaranteed across every environment.

"A wallet connection should expose the scope you approved, not leave you to infer it."

What I'd want to see next: the same controlled test on mainnet with the same wallet version, clean permissions, and identical instrumentation, to see whether the boundary holds across environments.

#dusk $DUSK @Dusk

I assumed that if I wanted to do three things on-chain, approve, swap, then stake, the chain would treat that as one thing happening or not happening at all. An open issue in Dusk's own Rusk repository says that's not how it works today.

A Dusk transaction today carries a single optional operation: one contract call, one deploy, or one memo, with one value, one recipient, one nonce, one signature. So approve, swap, and stake become three separate transactions, each independently included or dropped. Dusk's issue states it plainly: there is no atomicity guarantee across them. Land approve and swap but not stake, and you're left mid-flow with no protocol-level rollback.

The problem isn't only that multi-step flows can stop halfway. Fixing that changes who has to absorb the compatibility cost.

A batcher contract makes the whole sequence atomic, because a failed sub-call reverts the outer transaction. But a target contract checking who's calling it directly would see the batcher, not you, unless that contract is already written to look past the immediate caller. A protocol-level batch transaction keeps you as the caller at every step, but it doesn't ship without a new transaction format, consensus changes, a hard-fork, and every wallet SDK catching up.

Adding batching doesn't remove the tradeoff. It decides whether the compatibility burden sits in application authorization or in the protocol stack.

"Fixing atomicity doesn't remove the tradeoff; it decides where the compatibility burden and trust boundary move."

What I'd actually want to watch: whether Dusk chooses the application-level batcher or the protocol-level transaction, and what existing authorization assumptions that choice forces developers to change.

#dusk $DUSK @Dusk

I assumed a transaction's meaning was fixed the moment its bytes existed: decode it once, get the same answer everywhere. Dusk's own Rusk changelog for the Boreas upgrade treats that as something that has to be engineered, not assumed.

Boreas added version-aware transaction decoding tied to a specific hardfork, plus hardfork-governed format selection for how old blocks get replayed. The codebase now has two explicitly separate types, CanonicalTransaction and LedgerTransaction, splitting the in-memory representation of a transaction from the format it's actually persisted in on the ledger. There's even a dedicated regression test just for decoding pre-Aegis-era transactions correctly during block serialization.

That only becomes necessary once transaction decoding has to account for different protocol eras and processing stages: fresh off the wire from a client, sitting in memory as a canonical object, replayed from a block that predates the current rules.

Which means a protocol upgrade isn't safe just because new transactions work under the new rules. It's only safe if those new rules don't silently break the ability to correctly replay old ledger state under the rules that produced it. That is the class of version-mismatch failure the historical-replay compatibility and hardfork-gated decoding are designed to prevent.

"A transaction is only reliable if every stage that touches it agrees on what it means."

What I'd actually want to see: a real pre-Aegis block replayed on a current node without changing how its historical transactions are decoded under the applicable rules, not just a passing regression test in isolation.

#dusk $DUSK @Dusk

I assumed "DuskEVM supports Solidity" meant developers could show up with existing Ethereum tooling and be done. Dusk's own quickstart docs quietly add a step most people skip past: verifying the source.

Deploying is the easy part. DuskEVM uses Blockscout as its explorer, and getting a contract verified there, "Verify & Publish", means the relevant build settings, compiler version, optimizer configuration, source files, constructor arguments, have to reproduce the bytecode that's actually deployed.

That's a different bar than EVM compatibility. Deployment proves the code can run. Verification lets someone else check what's actually running. A contract can be deployed and functioning while still being unverified, leaving anyone else unable to independently check whether the published source actually matches what's live.

Which means "EVM-compatible" and "developer-ready" aren't quite the same claim. One is about whether your code runs here. The other is about whether an auditor, an institution, or a user can actually confirm what's running matches what's claimed.

"A chain can run your Solidity contract and still leave you unable to prove what that contract actually is."

What I'd want to see next: whether a contract deployed through the standard Solidity/Hardhat path can be reliably verified against its deployed bytecode, rather than merely deployed successfully.

#dusk $DUSK @Dusk

I assumed fractionalization was most of the liquidity story: split an asset into smaller pieces, and the pool of potential owners gets wider. Dusk's own writing on tokenization for SMEs, published this week, says that's a limited part of the picture, and an independent academic study of real tokenized assets shows why the gap matters.

Dusk says it plainly: "fractional ownership plays a limited role. Smaller units cannot create investor demand, legal certainty or liquidity." The value, they argue, comes from connecting the security to accountable operators, eligible buyers, reliable payment and settlement, and an authorized venue, not from how finely it's sliced.

A 2023 study published in Financial Innovation tested something close to this against real 58 tokenized residential properties in the US. On ownership, the results were clear: the average property had 254 separate owners. But on trading, the picture was different. Ownership changed hands about once a year on average, with properties on decentralized exchanges turning over more often than those traded peer-to-peer, though the yearly baseline stayed low either way.

Which means the two claims people conflate, "this asset is fractionalized" and "this asset is liquid," are actually describing two different things. Fractionalization is a property of the token. Liquidity is a property of the market around it.

"A smaller unit can widen who's allowed to own something without creating a market where they can actually trade it."

What I'd watch as NPEX-linked assets come onto Dusk: not how finely they're fractionalized at issuance, but whether secondary trading actually persists after that, the same gap the 58-property study found between wide ownership and active trading.

#dusk $DUSK @Dusk

I assumed a bridge hack meant someone found a bug in the code, a flaw in the cryptography, something a security audit missed. Dusk's own post-mortem on its January bridge incident describes something else.

On January 16, an attacker compromised a signing wallet used by the Dusk-to-EVM bridge, moving funds directly on Dusk before routing part of it onward to BNB Smart Chain. Dusk shut the bridge down mid-attack, which is what caused a final, roughly 8.9 million DUSK transfer attempt to fail.

This was not a consensus failure or a protocol exploit. Dusk says the direct cause was key compromise, and that the old design let the signing wallet, event handling, and network connectivity all operate inside one path. The weakness was concentrated operational authority, not weak cryptography.

The redesign that followed comes down to one sentence buried in the post-mortem: "ingestion is no longer equivalent to spending." Seeing that an event happened and having the authority to release funds because of it used to be the same step. Now they're not. Event ingestion gets checkpointed and queued as a job; a separate, explicit process actually moves funds against it.

"A protocol can work as designed while the operational layer around it gives one compromised path too much authority."

What I'd actually want to see: confirmation that the redesigned bridge actually keeps event ingestion and fund release on separate paths in practice, not just in the post-mortem's description of the new architecture.

#dusk $DUSK @Dusk

KYC answers who qualified at onboarding. Transfer controls answer who is still eligible when the asset moves. Dusk's own market-infrastructure model treats those as separate stages, and that gap is the interesting part.

Dusk lists investor onboarding, "bind wallets to verified participants or credentials," separately from transfer controls, "enforce who can hold or transfer the asset." One establishes an initial eligibility state. The other is what makes that state enforceable when the asset actually moves.

The older XSC material goes further than onboarding: issuers can whitelist wallets and retain asset-level controls such as freezing or force-transfer. That matters because eligibility isn't only established once. It has to remain enforceable after the initial decision.

Which means "KYC passed" and "eligible to hold this asset" are two different claims that can quietly diverge. A wallet can stay verified in the identity sense while no longer being the kind of holder this specific asset is allowed to have. Compliance enforcement doesn't end at onboarding, it has to continue into the asset's transfer lifecycle.

"Passing a compliance check and staying eligible are two different claims."

That changes the actual evaluation question. Not "does this asset have eligibility checks." The real question is whether the current eligibility state is enforced when the asset moves, or whether the original onboarding status simply carries forward.

What I'd actually want to see: a wallet whose eligibility changes after onboarding, say a jurisdiction shift, while it still holds the asset, then an attempted transfer, and whether the asset's transfer logic catches that change.

#dusk $DUSK @Dusk

「“固定金利のマーケット”っていうのは、単一の金利のことだと考えました。つまり、取引の前に金利が確定していて、それ以上はない、というわけです。ところがTermMaxが実際にローンをどう価格付けしているかをよく見ると、その前提は成り立ちません。

金利は単一の数字として提示されるわけではありません。金利はカーブによって定義されます。Lending Range Orderでは、カーブはより低い金利から始まって、注文の約定が進むにつれて段階的に高くなります。これは、AMMが単一の価格を提示するのではなく、さまざまな価格水準を移動していくのに似ています。マーケットは同時に複数のレンジ注文を保持できるため、参加者によってカーブ上の異なる地点が約定に使われ得ます。

私が見落としていたのはこの点です。マーケットには固定の金利がひとつあるわけではありません。実行された各ポジションには、約定がカーブ上のどこに着地するかで決まる固定金利が適用されます。いったん約定すると、その金利は期間満了まで固定のままです。

また、そのカーブは実行時に恣意的に決まるものでもありません。キュレーターの操作は、ホワイトリスト化されたマーケットやタイムロック付きの変更など、プロトコル上の制約の中に収まっています。

だから、TermMaxがそれを「固定金利のマーケット」と呼ぶとき、単に“固定金利がいくらか”が重要な問いではありません。問題は、その金利のうちどれだけがカーブによって決まり、どれだけがあなたの流動性が実際にどこで約定するかによって決まるのか、ということです？

#termmax @TermMax

多くの人にプライバシーチェーンを評価して「それはプライベートですか？」と聞くと、チェックボックスを入れて「はい／いいえ」で答えるでしょう。Duskの場合、それは違う問いであり、Hedgerに関するDusk自身の記述がその理由を示しています。

Duskのネイティブなプライバシー保護プロトコルであるZedgerは、完全な匿名性を提供できます。DuskEVM向けに構築されたHedgerは、それができません。Duskははっきり言っています。EVMのアカウントベースのモデルでは完全な匿名性は妨げられる一方、Hedgerは同型暗号化とゼロ知識証明を用いて取引の詳細を暗号化しますが、同じ「完全匿名性」保証は提供しない、と。

これはDuskが隠しているバグではありません。明示されているのは、アーキテクチャが行うトレードオフです。EVM互換性を選ぶことには、Zedgerの完全匿名性とは異なるプライバシー保証が付いてきます。

では、そのトレードオフが実際に何を変えるのか。重要な違いは、単に取引詳細が暗号化されているかどうかではありません。違いは匿名性の保証です。Zedgerの道を使えば完全匿名性が利用可能です。EVM互換のHedgerの道を使っても、同じ保証はありません。同じブランド、同じ「confidential（機密）」という言葉の下で、しかし中身の保証は別物です。

これにより、この件で誰かが評価する際に問うべき「本当の問い」が変わります。「Duskは機密取引をサポートしていますか？」ではありません。どちらの経路もプライベートな取引フローに対応していますが、提供する匿名性保証は同じではありません。真の問いは、規制された資産に対する保証が、そもそもそのワークフローが必要とする内容と一致しているのか、ということです。

「取引の詳細を機密に保つプライバシー」と「完全な匿名性を提供するプライバシー」は、同じ保証ではありません。たとえ同じ言葉の下で、同じプロジェクトが両方を提供しているとしても。"

私が実際に見たいのは、規制対象の証券がDusk Trade内でどのプライバシー経路を使っているのか、そしてそのワークフローが、経路にどの情報を隠し続けることを要求しているのか、です。

#dusk $DUSK @Dusk

I assumed staking on a PoS chain meant one key controlling one thing: put DUSK in, get rewards out, same key handles it end to end.

Dusk's own operator docs split that in two.

The consensus key is the key a node uses to sign and vote in consensus. It has to live on an internet-connected node and participate as the validator operates. The owner key is separate: it's the key that can unstake or withdraw funds, and the docs say it doesn't need to touch the node at all.

The security benefit isn't simply that there are two keys. It's that the authority to participate in consensus and the authority to withdraw funds don't have to live in the same place. If the consensus key gets compromised because the server it's on gets breached, an attacker can interfere with consensus participation, but they still can't unstake or withdraw the stake. That authority never lived on the machine that's exposed to the internet in the first place. Which means the real security question isn't just how much is staked. It's where the authority to withdraw it actually sits relative to the machine that's exposed to attackers.

But there's a catch the docs don't hide: this separation isn't the default. If you stake without specifying a separate owner, the consensus key automatically becomes the owner too, one key, one boundary, back to the model I originally assumed. The safer setup is a choice an operator has to actively make, not something the protocol forces on them.

"A security boundary that has to be opted into is a different guarantee than one built into the default path, even when both are technically available."

What I'd actually want to know: how many active provisioners run with a separate owner key versus the default, because that would tell me whether the stronger boundary is actually being adopted, rather than merely being available.

#dusk $DUSK @Dusk

I assumed a locked fixed-term position meant exactly that: locked, full stop, until maturity. Then I found TermMax's Smart Unwind and assumed it simply solved that. It doesn't work the way I expected.

Smart Unwind doesn't pull exit liquidity from a pool. It works by making your position attractive enough that someone else wants to take it off your hands. A leverager sets a target APR or price. If the collateral appreciates enough, an arbitrageur buys the position at that fixed price and sells the collateral on the open market for a profit. If borrowing rates rise, a new leverager may take over the position at a premium instead of opening a fresh one.

So the protocol isn't guaranteeing the exit. The exit depends on someone else finding the trade attractive enough to take.

That's the part I hadn't considered: the conditions where a leverager most wants out, a falling collateral price or a stressed market, could plausibly be the conditions where an arbitrageur has no appreciation to capture and a new leverager has no reason to take over a losing position. The mechanism may work best exactly when you'd least need it, and go quiet exactly when you would.

Smart Unwind also isn't live yet, so none of this is observed behavior yet; it's only what the design implies.

Does an exit mechanism that depends on someone else's incentive actually solve the illiquidity of fixed-term positions, or does it just relocate the same problem to whoever needs to be found on the other side?

#termmax @TermMax

I looked past TermMax's "fixed-rate lending" label to see what's actually happening underneath.

The primitive looks less like a lending pool with a fixed APY and more like an onchain fixed-income market. Its FT is a zero-coupon bond-style token: lenders buy it below face value and redeem it at par at maturity, with yield fixed at entry. That changes how I think about the product: the fixed rate isn't just a parameter on a lending pool. It's embedded in a maturity-bound claim.

In January, the same fixed-rate model extended beyond crypto-native collateral into tokenized securities, launching fixed-rate borrowing against Ondo Global Markets' tokenized stocks.

A fixed rate removes rate uncertainty for the term. It doesn't remove the need to refinance when the term ends. TermMax already has one-click rollover, into a later fixed maturity or into Morpho's variable-rate markets, so the protocol has explicitly designed for that refinancing step. What's documented well is the architecture; what's scarce is data on how that path performs when many positions need to roll at once under stress.

With $90M+ TVL across 10 EVM chains and the $TMX TGE set for August 25, that's the part I'd watch next.

#termmax @TermMax

I expected the "eligibility checks" behind Dusk Trade to be something built specifically for trading. A compliance module bolted onto the exchange layer, the way most brokers build KYC into the platform itself.

That's not what's underneath it.

The identity layer Dusk Trade relies on is called Citadel, and it didn't start as a trading feature. Dusk launched it in January 2023 as a zero-knowledge KYC/identity protocol: prove you hold a valid credential without revealing what's in it, then reuse that proof across services instead of re-submitting your data every time.

That timing changes how I read "eligibility checks" in the docs. It looks less like bespoke compliance built for one product and more like an identity primitive that predates the product using it.

The interesting part is that Citadel was designed for service providers beyond a single trading workflow. Dusk described it as an identity layer that companies could tap into to verify whether someone meets their criteria without taking custody of all the underlying identity data.

"An eligibility check built for one product and an identity layer built to outlive the product are two different kinds of infrastructure, even when users experience both as 'proving who you are.'"

What I'd actually want to see: one credential proven through Citadel and accepted by another service provider outside Dusk Trade, the evidence that turns "shared identity primitive" from an architectural description into demonstrated cross-service reuse.

#dusk $DUSK @Dusk

I expected "Dusk partners with Chainlink" to mean the usual pitch. A bridge. Tokens moving across chains. The standard interoperability story every project eventually announces.

That's part of it, but it's the smaller part.

Announced back in November, the deal pairs Chainlink CCIP as the interoperability layer for NPEX's tokenized securities with something easy to skim past: Chainlink DataLink becoming the exclusive onchain data oracle for NPEX. Not one of several price feeds. The exclusive one. The same agreement also lets DUSK itself move natively between Ethereum and Solana through Chainlink's CCT standard, so the token gets the bridge story too.

Nine months on, that's the part worth separating out. CCIP lets an asset move across ecosystems. DataLink delivers the NPEX market data the receiving system can rely on. One is about reach. The other is about who gets to be believed. Any chain consuming that NPEX data is building on the same official market-data source.

I don't think that's automatically a flaw. Regulated markets already depend on authoritative market-data sources. But it does mean cross-chain composability here isn't completely neutral infrastructure. It's composability built around an exclusive source for NPEX's official market data, wherever that data eventually gets read.

"Being able to move an asset across chains and being the exclusive source for its official market data are two different kinds of power, even when one deal grants both."

What I'd actually want to know nine months in: what happens on the other chains if that exclusive NPEX data source becomes unavailable or disputed, and whether "composable" quietly means "dependent on one exclusive line back to NPEX."

#dusk $DUSK @Dusk

I used to think tokenization and native issuance were basically two ways of putting an asset onchain. Dusk's own comparison page changed that framing. They're not two degrees of the same thing. They're two different architectures entirely.

By Dusk's own definition, tokenization issues a token representing an asset or a claim on it, while the underlying asset can stay tied to whatever custody, registry, and settlement processes were already running off-chain. The token is a representation, not the underlying asset itself. Native issuance removes that layer: the asset exists on-chain as itself, and its lifecycle, being issued, transferred, serviced, settled, doesn't need a separate record somewhere else to point back to.

The catch is that a token can still depend on another system remaining the real source of truth. If that off-chain registry lags or breaks, the token's guarantee is only as strong as the reconciliation behind it.

Here's where it gets conditional. Dusk's own comparison says native issuance can reduce reliance on separate custody and registry layers, "depending on the legal structure." That qualifier is doing most of the work in this thesis. The efficiency case doesn't come from the technology existing. It depends on the legal structure actually letting the on-chain record carry that weight, instead of remaining just another copy of the real one.

"A token that represents an asset and an asset that exists as the token are two different promises, even when both get sold as tokenization."

What I'd actually want to see before calling this real: one regulated security where the authoritative record lives onchain, not a settlement layer running alongside a registry that still has the final say.

#dusk $DUSK @Dusk

I found myself staring at DuskEVM's testnet explorer, and the number that jumps out, 845,113 transactions against 282 wallet addresses, is almost the wrong one to focus on. That's roughly 3,000 transactions per address, a ratio that says less about adoption than the headline suggests.

The two most recent transactions both showed Value 0 DUSK: fees paid, no native value moved. The latest feed was tagged as an L1→L2 deposit. Not proof of what the other 845K look like, but enough to make me stop reading this as one number. What the explorer is actually showing first is network activity: the chain processing transactions. Whether any of it is economic activity, value actually changing hands for a reason, is a separate question the transaction count can't answer on its own.

That distinction matters because Dusk is ultimately positioning this infrastructure for regulated financial assets, which is exactly what Dusk's plan to bring €300M of NPEX assets onchain would eventually need to prove out. A busy chain and a chain carrying real settlement volume can produce an identical-looking stats page.

"Network activity is not the same claim as financial activity, even when both surface as one number on an explorer."

What I'd actually watch as the signal that this shifts from network activity to financial usage: how much of it represents actual economic value settled, once NPEX gives us something real to check it against.

#dusk $DUSK @Dusk

Dusk's own writeup on Hedger puts client-side proof generation at under 2 seconds. Read that twice before it landed. That's fast enough that "confidential has to be slower" stopped feeling like a safe assumption. Went digging into what's actually being proved that fast. DuskEVM's public testnet has been live since December, and a few days ago the Dusk Foundation opened it up for Solidity and Hardhat testing — that's the update I was actually reading about. The line that stopped me: eligibility is checked before access or transfer. I initially thought that was the interesting compliance part. Left it open in one tab while I got coffee, came back, reread it, and realized it wasn't. Dusk says participant data, balances and transfer amounts can remain encrypted. That's the part that actually caught me — the gap between proving you're allowed in and exposing what you're carrying once you are. The eligibility step checks out in the docs — it's clearly defined, not just a vague compliance claim. I still couldn't find a concrete example of what an authorized reviewer actually sees when that audit path is used. Checked the docs twice. A few days into this Solidity/Hardhat opening, curious whether that example shows up as things mature, or whether "auditable" just stays the word nobody has to demonstrate yet — here or on any chain making the same claim.

#dusk $DUSK @Dusk

今夜、BABYのチャートを確認して、アンロックまで残り何日かをチェックしたんだけど、目立ったのはカウントダウンじゃなかった。

8月10日。5日後。136.11Mトークン、約$1.43M、供給の1.2%。主にチーム、アドバイザー、初期ラウンドの投資家へ——ここまでの数字は、すでに追っている人なら誰でも知っている同じ内容。

実際に見ていなかったのは、その前の7日間のことだった。

BABYは今週およそ10.3%下落。価格はだいたい$0.0105あたり、時価総額は約$45Mで、より広い暗号資産市場に対してアンダーパフォームしている。しかも同じ期間の広い市場はほぼ横ばいだ。

最初の読みは、なるほどアンロック関連の売りが早めに始まってるんだな、というものだった。

でもそうじゃないかもしれない。8月10日とは無関係な、より広い市場環境の影響かもしれない。私は、「『アンロックを先回りする人たち』」と「BABYが他のすべてと一緒にただ悪い1週間を過ごしているだけ」を分けて判断できる手段がない。

いずれにせよ、8月10日にそれらのウォレットへ着地するトークンは、すでに一週間前の水準から10%下がった価格に到着する。

今週売った人は、その下落局面に売り向かった。アンロックを受け取る側は、それが終わった後に残っているもののなかで売る。

同じ5日間の両側で、それぞれ別の半分の値動きを吸収している。

ただ、そのパターンが今回も当てはまるかは分からない。過去のBabylonのアンロックで、事前にどれだけ織り込まれていて、どれだけがその後の反応として現れたのか、その内訳を説明する情報を見つけられていない。

アンロックが起きる前に価格がすでに動いているのなら、アンロック当日そのものはいったい何を明らかにするのだろう？

@BabylonLabs_io #baby $BABY

今夜、エイギス案件についてのバビロンのブログ記事が、実際に発表されてから何週間も経った今でもフィードに何度も再浮上してきた。

今度はスクロールで済ませず、ちゃんと読んでみた。

6月25日。Babylon Trustless Bitcoin Vaults、Aave v4、そしてAegisの固定金利型インフラが、1つのクレジット商品に統合された。対象は財務（トレジャリー）、ファンド、マーケットメーカー。想定は2026年Q4。ただし開発・テストの進捗により変更の可能性あり。

最初の読みは、なるほど、また別のレンディング連携か。

でも違う。

これまでに出会ったネイティブのBTC担保ローンは、すべて利率が変動（フロート）している。
相場の動きに応じてレートが変わり、借り手が、その月のコストがどうなるかという意味を丸ごと引き受ける。

トレジャリーがその形でポジションを引き受けることはできない。レートが悪いかもしれないからではない——そうではなく、レートがそうでないことになるまで不明だからだ。

固定金利は、ビットコインをそれほどボラティリティの低いものにするわけではない。BTCは、BTCなりに振れる。

固定するのは価格ではない。トレジャリーが本当に固定したい、1つの数字だ。前もって決められる借入コストのこと。

私は、すべてのネイティブなBTC担保ローンは同じ仕組みだと思い込んでいた——レートはフロートで、借り手が吸収する。この案件は違う。

これは、私がこれまであまり出会ってこなかったタイプの「ネイティブBTC」だ。

BABYはまだ約$0.0105で取引されていて、今週は4%近く下落。時価総額は約$45M。一方で、プロダクト自体はまだローンチされていない。もしかすると、何かが稼働する前にこの状態であることこそが、ちょうどあるべき姿なのかもしれない。

固定金利が、機関投資家が本当に待っていたものなのか、それとも誰かが最初に提供して、見た目が馴染みにくいだけに感じられるものだったのかは分からない。

コストの確実性は、カストディ（保管）の確実性よりもトレジャリーにとって重要なのか？それとも、そもそも比較対象として間違ったトレードオフなのだろうか？

@BabylonLabs_io #baby $BABY

今夜はAaveのガバナンス・フォーラムを読んでいる。単に見出しだけを追う代わりに。

BTCFiで最も大変なのは、ビットコインが信頼不要性（trustless）を維持できることを証明することだろうと思い続けていた。

BabylonのTrustless Bitcoin Vaultの統合を追うほど、確信は薄れていった。

驚いたのは暗号技術ではない。

調整（コーディネーション）のほうだ。

BabylonのAave統合は、あのフォーラムに出された「Temp Check」にすぎない——5月25日に提出され、Aave自身の創設者によって公に支持されている。さらに、レビュー段階にはまだ入っていないにもかかわらず、すでに3つの別々の監査法人がレビューのために手配済みだ。

それは通常のプロセスかもしれない。あるいは、Aaveが何に対しても進めるやり方なのかもしれない。

同じ段落を実際に腑に落ちるまで3回読んだ。

統合の間で、ヴォールトは変わらない。

決定（ディシジョン）も変わらない。

すべての統合は同じコードを引き継ぐ。だが、完了した決定（completed decision）までは引き継がれない。

2回目のレビューが1回目より速くなるのか、それとも同じくらい遅いままなのかは、まだ分からない。読んだ内容はそれを分解して説明していない。

たぶんBTCFiは、統合を1つずつスケールするものではないのかもしれない。

たぶん、独立した決定を1つずつスケールするのかもしれない。

もしすべての統合が、それぞれ独立した決定を必要とするなら、BTCFiはより良いコードでスケールするのか——それとも、より速い調整でスケールするのか？

@BabylonLabs_io #baby $BABY