Web3天命人-阿明

#termmax @TermMax
最近看到比较火的帖子持续升温的一个方向，是代币化资产不再只讨论“能不能上链”，而是开始进入抵押品、流动性和风险管理的下一层。Ondo Perps 官方 8 月 4 日宣布 Arbitrum 上的 USDC 可直接为其交易提供抵押，原帖采集时约 11.2 万查看。这个事件并不代表 @TermMax 与 Ondo 存在合作，但它提出了一个更普遍的问题：当链上资产的交易入口越来越多，资金成本和期限风险由谁来管理？这正是 TermMax 值得被放进同一张金融基础设施地图的原因。固定利率市场不负责制造热点，却能让借贷双方先看清到期日、利息结构和抵押风险。FT、XT、GT 分别把固定期限凭证、利息部分和杠杆仓位拆开表达，重点不是承诺收益，而是把仓位的成本和风险边界变得更可计算。$TMX 的讨论可以关注，但不应替代对合约、期限和清算条件的核对。RWA 交易越活跃，利率确定性越值得被认真讨论。

#termmax @TermMax
固定利率借贷的价值，不是把收益率写得更高，而是让资金成本和到期时间先变得可计算。把期限市场拆成 FT、XT、GT：FT 对应固定期限的本金与收益凭证，XT 表示利息部分，GT 则把抵押品与杠杆债务封装成仓位 NFT。这样的结构让借贷、收益和杠杆不再只是一个浮动 APR 页面，而是可以组合的链上部件。TermMax 官方白皮书将 $TMX 定义为治理与效用代币，但 TGE 时间仍需等待官方公告；参与前仍应核对合约、期限、清算和智能合约风险。#TermMax

#dusk $DUSK
@Dusk
Kürzlich ist Dusk das am sehnlichsten empfohlene: Nicht „schon wieder eine neue Geldbörse“, sondern dass der Frontend-Einstieg von DuskDS standardisiert wird. Mit Dusk Connect, das im April für Entwickler als Vorschau geöffnet wurde, können dApps kompatible Wallets einheitlich entdecken, Konten anfragen, signieren und Transaktionen anstoßen; das reduziert die Reibung, die entsteht, wenn jede App um eine einzelne Wallet herum maßgeschneiderten Zugang benötigt.

Die passende neue Dusk Wallet deckt öffentliche/private Überweisungen ab, Shield/Unshield, Staking sowie das Einlösen von Belohnungen. Moonlight macht Kontostände und Transfers sichtbar und eignet sich für Pfade, die geprüft/auditiert werden müssen; Phoenix schützt Beträge und Transaktionszusammenhänge mit Zero-Knowledge-Beweisen. Beide Wege arbeiten am Ende auf derselben Abrechnungs-/Clearing-Schicht zusammen.

Für Dusk ist die eigentliche Prüfungsaufgabe nicht, ob es mehr Funktionen gibt, sondern ob Entwickler bereit sind, anzubinden, ob unterschiedliche Wallets miteinander kompatibel sind und ob diese Fähigkeiten in echte Prozesse zur Ausgabe von Vermögenswerten, zum Verwahren (Custody) und zur Abwicklung (Settlement) einfließen können.#DUSK

#dusk $DUSK @Dusk
Ich habe mir das Dusk-Whitepaper kürzlich aufmerksam angesehen, und ich finde das wirklich spannend – nicht nur als „Privacy-Blockchain“, sondern weil versucht wird, Privatsphäre, Compliance und reale Vermögenswerte in ein und derselben Infrastruktur zusammenzubringen.
Dusk schützt die Transaktionsprivatsphäre mit Zero-Knowledge-Proofs und erfüllt gleichzeitig die regulatorischen Anforderungen durch selektive Offenlegung.😁 Phoenix und Moonlight unterstützen jeweils private und öffentliche Transaktionen, während Succinct Attestation für schnelle, deterministische Finalität zuständig ist.😇 Ergänzt wird das Ganze durch DuskEVM und RWA-Szenarien. Das Ziel ist also klar: Wertpapiere, Fonds und andere regulierte Vermögenswerte sollen tatsächlich🤔 auf der Kette begeben, gehandelt und abgewickelt werden.
Wenn die nächste Phase von RWA vom „Narrativ“ hin zu einer „realen Finanzinfrastruktur“🤑 geht, dann lohnt sich es, Dusk weiter im Blick zu behalten.

#baby $BABY
把 BABY 质押理解成“拿收益，治理随缘”，可能少算了一项权力：你不投票，验证者可能替你投。

Die Governance-Regeln von Babylon Genesis sind sehr direkt formuliert: BABY-Inhaber können abstimmen, aber wenn der Delegierende nicht abstimmt, wird die Abstimmung des Validators automatisch geerbt. Das bedeutet: Beim Staking geht es nicht einfach darum, die Token an einen Validator abzugeben und dann ist es erledigt—du legst zudem einen Teil deiner Governance-Entscheidungen in die Logik der Default-Delegation.

Diese Default-Regel hat eine leicht zu übersehende zeitliche Lücke. Wenn du abstimmst, bevor der Validator abgestimmt hat, übernimmt das System nicht die Stimme des Validators; wenn der Validator bereits abgestimmt hat, kannst du danach noch mit deiner eigenen Stimme überschreiben. Bei dringenden Vorschlägen ist die Abstimmungsfrist jedoch nur 1 Tag—es kann sein, dass sie endet, bevor du die Nachricht gesehen und die Diskussion vollständig gelesen hast. Für gewöhnliche Vorschläge beträgt die Abstimmungsfrist 3 Tage, das Tempo ist also etwas entspannter. Nach dem Absenden der Stimme kann man sie zudem nicht mehr ändern, „später nochmal nachsehen“ ist also nicht ohne Kosten.

Meine Einschätzung ist: Wenn du einen BABY-Validator auswählst, solltest du nicht nur auf Provision und erwartete Belohnungen schauen, sondern auch darauf, ob er kontinuierlich Governance-Themen verfolgt, ob er rechtzeitig abstimmt, und welche öffentliche Haltung er einnimmt, wenn er Delegationsgewicht repräsentiert. Hier geht es nicht darum, zu raten, was ein bestimmter Validator sicher tun wird, sondern darum, das Governance-Risiko einer Default-Delegation zu erkennen: Nicht teilzunehmen ist auch eine Art Ergebnis.

Beim nächsten Mal, wenn es um einen Vorschlag geht, schaue ich zuerst auf drei Zeitpunkte: Wann endet die Abstimmung, ob der Validator bereits abgestimmt hat und ob meine eigene Stimme bereits on-chain ist; danach bestätige ich, ob es sich um einen normalen oder um einen dringenden Vorschlag handelt. Wenn im Wallet nur ein Staking-Saldo ist, aber keine Governance-Erinnerungen, könnte das „passive Staking“ von BABY auch dazu führen, dass du die Entscheidungsgewalt passiv aus der Hand gibst.#baby $BABY @BabylonLabs_io

#baby $BABY
Wenn du wegen der jüngsten COLDCARD-Diskussionen begonnen hast, deine Wallets neu zu überprüfen, dann beeile dich nicht damit, „Cold Wallet“ (Kaltlagerung) einfach gleichzusetzen mit „kann BABY staken“.
Die offizielle Positionierung von COLDCARD ist sehr eindeutig: eine Hardware-Wallet, die nur für Bitcoin gedacht ist. Der Kern sind Offline-Signaturen und der Schutz der Bitcoin-Private-Keys. Die offiziellen BABY Staking Tools von Babylon führen COLDCARD derzeit auch nicht in der Support-Tabelle. In derselben Tabelle sind die „BABY Address“ und „BABY Staking“ bei Keplr, Cosmostation und Leap aufgeführt; wenn dort „Coldlar“ steht, dann ist es „Address BABY Staking“. Coldlar und COLDCARD sind jedoch kein gleiches Produkt – der Name klingt ähnlich, aber die Funktionsgrenzen dürfen keinesfalls vermischt werden.
Für BABY-User ist das Wesentliche, dass drei Ebenen wirklich kompatibel sind: ob du eine Babylon-Adresse erstellen oder verbinden kannst, ob du eine BABY-Delegation (Auftrag) auslösen kannst und ob du innerhalb derselben Adresse ein gemeinsames BTC-BABY-Staking durchführen kannst. Auf der Babylon-Website wird der Zweck von BABY als Staking, BTC-BABY-Co-Staking und Governance beschrieben – aber das bedeutet nicht, dass jede beliebige Bitcoin-Hardware-Wallet diese Vorgänge direkt ausführen kann.
Darum ist die robustere Einschätzung: COLDCARD eignet sich für Bitcoin-only Offline-Aufbewahrung und Signaturen; BABY Staking sollte vor allem nach den aktuell in der Babylon-Tooltabelle als unterstützt markierten Lösungen ausgewählt werden, und anschließend müssen Version, Netzwerk und Anforderungen an die gleiche Adresse bestätigt werden. Die offiziellen Dokumente machen zudem klar, dass sich die Listen ändern können. Wenn das nächste Mal wieder ein Hot Topic aufkommt, schau zuerst, ob „BABY Address“ und „BABY Staking“ wirklich zusammenpassen – und sieh nicht nur darauf, dass ein Wallet „Cold Wallet“ genannt wird.@BabylonLabs_io

#baby $BABY
把 BTC 抵押到借贷协议，最容易被忽略的不是借款利率，而是“另一条链能不能确认这笔 BTC 的状态”。

Babylon 官网现在把 Trustless Bitcoin Vaults（TBV）的流程写得很直白：先把原生 BTC 锁进 Vault，再让抵押状态在 Ethereum 上变得可验证，最后通过 Aave v4 获取稳定币流动性。这个顺序说明，TBV 的关键卖点不是“又多了一个借贷入口”，而是试图把 BTC 的抵押事实变成外部协议可以读取的状态。

这和把 BTC 包装成代币再跨链不是一回事。官网对 Babylon Bitcoin staking 的描述也强调不需要 wrapping、pegging 或 bridging；但“保持 BTC 托管的同时获取流动性”，与“借贷协议已经能安全接受这笔抵押”，是两个不同命题，不能混为一谈。

目前最该记住的不是某个收益数字，而是官网仍提供“Launch TBV Testnet”入口。因此，测试网能跑通流程，不等于主网已经开放，也不等于抵押率、清算、预言机和退出条件已经经过足够长时间的实战检验。尤其是借到稳定币后，BTC 的价格波动、合约状态异常或退出路径受阻，都会把“可验证抵押”变成实际风险。

后续值得观察三个指标：原生 BTC 是否仍在预期的 Vault 条件里、Ethereum 侧读取到的抵押状态是否持续一致、测试网之外是否出现公开的主网参数与风险披露。TBV 真正的分水岭，不是能不能点进借款页面，而是这三层状态能否被独立核验。#baby $BABY @BabylonLabs_io

#baby $BABY
Heute am Wochenende muss ich noch Überstunden machen. Wenn ich nach der Arbeit nach Hause komme und mir etwas liefere, passiert der häufigste Fehler nicht dadurch, dass man keinen Gutschein einlöst, sondern dass man mit zwei Mobiltelefonen Gutscheine einlöst – am Ende aber doch nicht für dieselbe Bestellung. Bei Babylons BTC-verbundener (Joint) Staking- bzw. Co-Staking-Struktur gibt es ein ähnliches „Abstimmungs“-Problem: BTC und BABY sind zwar jeweils gesperrt, aber das heißt nicht, dass das System sie automatisch als zusammengehörig verrechnet.

In den offiziellen Regeln von Babylon ist das Entscheidende nicht das gesprochene Kriterium „dieselbe Person“, sondern ob die beiden Delegationen mit derselben BABY-Adresse verknüpft sind. Wenn die Adresse nicht übereinstimmt, können die Belohnungen für das verbundene Staking direkt auf 0 fallen; außerdem reicht es nicht, dass BTC und BABY nur im Status VERIFIED verharren – beide müssen in den anrechenbaren, also den „aktiven“ (ACTIVE) Zustand wechseln.

Auch die Gewichtungs-/Mischungsformel hat einen „Shortboard“-Effekt: w = min（BABY-Anzahl ÷ 20.000，BTC-Anzahl）。 Wenn z. B. 0,1 BTC mit 1.000 BABY gekoppelt werden, beträgt das tatsächliche Joint-Gewicht nur 0,05 BTC. Um das Gewicht von 0,1 BTC voll auszuschöpfen, braucht man ungefähr 2.000 BABY. Wenn man eine Seite mehr aufstockt, überschreitet man nicht automatisch die Obergrenze der anderen Seite; bei kleinen Beträgen wird stattdessen proportional gerechnet – es ist nicht zwingend nötig, runde Schwellen „aufzufüllen“.

Ich glaube, was man bei der BABY-verbundenen Mitverpfändung/Co-Staking wirklich im Blick behalten sollte, ist nicht die einzelne Ertragszahl aus der Werbung, sondern ob Adresse, Status und Gewichtung gleichzeitig zusammenpassen. Die 2,35 % sollte man außerdem als jährlichen Inflations-/Parametermodus des gemeinsamen Belohnungspools verstehen – nicht als festen APR für eine Person. Wenn sich die Zusammensetzung der Teilnehmer und das gesamte Gesamtgewicht im Netzwerk ändern, ändert sich auch die persönliche Zuteilung. Der nächste Schritt, den man am besten dokumentiert, ist der Delegationsstatus, das tatsächliche Gewicht und das gesamte Gesamtgewicht im Netzwerk. Jede Aktualisierung eines dieser Parameter kann dazu führen, dass alte Ertragsabschätzungen nicht mehr stimmen.#baby @BabylonLabs_io

#baby $BABY
Baby hat eine Goldene Kreuzung und macht wieder Geld. Dann habe ich meinen eigenen Einkauf gestartet: zwei Personen haben sich zusammengetan, um die Rabatte für die Mindestbestellmenge zu erreichen—Ware und Coupons waren korrekt ausgewählt. Beim Checkout stellte ich jedoch fest: Der Rabatt wurde nicht angewendet. Der Grund ist ganz einfach: Unter einem Konto bestellt man, unter einem anderen Konto löst man den Coupon ein. Die Plattform weiß nicht, dass beides zu derselben Bestellung gehört.
Auch das gemeinsame Staking von BTC-BABY hängt an diesem kleinen Detail. Es ist nicht so, dass „BTC ist gestaked und BABY ist auch gestaked“ automatisch eine zusätzliche Belohnung ergibt. Die beiden Staking-Positionen müssen so miteinander verknüpft sein, dass die BABY-Adressen **exakt** gleich sind. Wenn die Adressen unterschiedlich sind, ist das Ergebnis laut offizieller Dokumentation eindeutig: Die Belohnung für das gemeinsame Staking beträgt **0**.
Achte auch auf den Status: Sieh nicht nur „VERIFIED“ und schließ dann die Seite. Das BTC-Delegation muss bis **ACTIVE** laufen, und die BABY-Delegation muss ebenfalls im **active**-Zustand sein, erst dann kombiniert das System beide Seiten zu einer gemeinsamen Staking-Gewichtsberechnung. „Bereits verifiziert“ klingt, als sei alles erledigt, aber in Wahrheit bist du noch nicht in die Gewichtungsphase eingestiegen.
Die eigentliche Formel lautet: w = min（BABY-Staking-Menge ÷ 20.000, BTC-Staking-Menge）。Zum Beispiel: Bei 0,1 BTC mit 1.000 BABY beträgt das Gewicht beim gemeinsamen Staking nur 0,05 BTC. Um diese 0,1 BTC Gewicht komplett auszunutzen, brauchst du 2.000 BABY. Umgekehrt führt mehr BABY nicht dazu, dass das Gewicht über die bereits gestakete BTC-Menge hinaus steigt.
Hier gibt es keine Schwelle wie „mindestens 1 BTC oder 20.000 BABY“. Auch kleine Beträge werden proportional berechnet. BABY auf mehrere Validatoren zu verteilen macht nichts—solange es von **derselben Adresse** stammt, addiert das System die Mengen.
Noch eine Zahl, die man am leichtesten falsch liest: 2,35% ist kein persönlicher, fester APR, sondern ein jährlicher Inflations-Belohnungspool, den sich alle gemeinsamen Staker teilen. Wie viel du bekommst, hängt davon ab, welchen Anteil dein Gewicht am gesamten Gesamtgewicht im Netzwerk hat; je mehr Teilnehmer es gibt, desto kleiner ist der Anteil, der auf dieselbe Gewichtung entfällt.
Kurz gesagt: Es geht nicht nur darum, dass beide Coins gestaked sind, sondern dass **Adresse, Status und Quote** gleichzeitig zusammenpassen. Ich werde besonders vier Punkte prüfen: Sind die BABY-Adressen identisch? Ist BTC bereits ACTIVE? Ist das tatsächliche Gewicht nicht durch das „kleinere Glied“ ausgebremst? Und gibt es im gesamten Netzwerk insgesamt eine klar erkennbare Veränderung des Gesamtgewichts? Die Parameter können sich auch aktualisieren—vor der Umsetzung gilt weiterhin: immer erst die offiziellen Seiten prüfen. Beim gemeinsamen Staking wird am häufigsten etwas übersehen, und zwar nicht die Staking-Aktion an sich, sondern ob das System die beiden Buchungen überhaupt demselben Adresskonto zuordnet.#baby @BabylonLabs_io

#baby $BABY
Jemand hat ein Auto, das herumsteht, nicht genutzt. Am Wochenende verkauft er das gebrauchte Auto – der Käufer sagt am Telefon nur: „Ich komme“, aber das heißt nicht, dass das Geld bereits eingegangen ist. Wenn der Preis verhandelt und der Vertrag unterschrieben ist, hängt es am Ende davon ab, ob die andere Seite das Geld sofort als Cash auftreiben kann.
Auch bei TBV ist das ähnlich. Wenn der Health Factor unter 1.0 fällt, bedeutet das nur, dass der Liquidationsschalter auf „an“ gestellt ist – nicht, dass BTC bereits reibungslos realisiert wurde. Das native BTC liegt auf Bitcoin. Beim Rückkauf geht die Redemption über claim, challenge und payout; normalerweise dauert das einige Tage. Das lässt sich nicht wie die Entschuldungs-Aktionen auf Ethereum in einer einzigen Transaktion gleichzeitig erledigen.
Babylon geht jetzt einen anderen Weg: In der Mitte wird eine zusätzliche LLP-Schicht eingeführt. Der Standard „BTCVaultSwap“ stellt dabei eine sofortige Abwicklung bereit, indem er aus den WBTC-Reserven im Aave Hub Liquidität zieht. Zuerst zahlt der Liquidator die Schuld zurück und erhält WBTC. Die abgezogene Vault-Position wird dann in ein escrow überführt. Erst registrierte Arbitrageure kaufen sie anschließend auf und schließen die Bitcoin-seitige Redemption nach und nach ab. Ganz salopp: Erst WBTC vorstrecken und damit das Ethereum-Konto bereinigen.
Aber dieses Vorstrecken ist kein endloses Fass. In der offiziellen Dokumentation steht es ganz direkt: Wenn die WBTC-Liquidität im Aave Hub oder die Vault-Swap-allowance nicht ausreicht, wird eine permissionless Liquidation-Transaktion revertieren. Arbitrageure können zwar weiterhin eine direct redemption durchführen, aber es gibt deutlich weniger mögliche Käufer.
Außerdem gibt es eine leicht zu übersehende „UTXO-Stufe“. Ein Vault kann nicht halb liquidiert werden; wenn die Position nur aus einem einzigen Vault besteht, kann schon ein kleiner Ausreißer das Schließen der gesamten Position auslösen. Dann wird das komplette UTXO in die Liquidation eingelegt. Der Wert der überbesicherten Position wird nach einem Fairness-Mechanismus verrechnet, oder über WBTC kompensiert – nicht alles wird auf null gesetzt. Das offizielle Portal empfiehlt deshalb standardmäßig, in „Opfer-Vault + geschützter Vault“ aufzuteilen.
Die obigen aktuellen Parameter und das Demo-Setup basieren auf dem TBV-öffentlichen Testnet. Signet-BTC, Mock-WBTC und Stablecoins haben dort keinen Geldwert.
Deshalb schaue ich mir TBV jetzt nicht nur anhand des Health Factors an, sondern auch auf die Tiefe des WBTC im Hub, die Vault-Swap-allowance sowie darauf, wie lange es dauert, bis die Vaults im escrow gekauft werden. Die Liquidationslinie ist nur ein Schalter: Ob danach auch wirklich Cash vorhanden ist und ein Käufer da ist, entscheidet, ob dieses System in Stressphasen stabil bleibt.#baby @BabylonLabs_io