Nova_eth_20
422 Beiträge
Nova_eth_20
129 Following
1.5K+ Follower
450 Like gegeben
Beiträge
Alle
Zitierungen
#baby $BABY @BabylonLabs_io
Ich habe Validatoren für meine BABY-Delegierung verglichen und wäre fast an „jailing“ vorbeigegangen, also an dem Standard-Cosmos-Boilerplate, das jede Chain hat: fehlende Blocks, temporärer Timeout, nichts Spezifisches zu Babylon. Dann habe ich gelesen, was Validatoren tatsächlich zweimal signieren, nicht nur einmal.
Jeder Babylon-Genesis-Validator übernimmt zwei getrennte Aufgaben. Erstens das reguläre CometBFT-Blocksignieren – die gewöhnliche Arbeit, die jeder Cosmos-Validator macht. Und zweitens: BLS-Voting am Ende jedes Epochenabschnitts, bei dem die Validator-Signaturen in einem Checkpoint aggregiert werden, der direkt mit einem Zeitstempel auf Bitcoin abgelegt wird. Diese zweite Signatur ist der Grund, warum viele sagen, diese Chain sei „Bitcoin-gesichert“.
Downtime-Jailing betrifft nur die erste Aufgabe – und das auf dessen eigene Weise, mit standardmäßiger Liveness-Überwachung, ohne etwas Dramatisches. Was mir allerdings nicht eindeutig klar werden konnte, ist die genaue Interaktion: Ob ein Jailing, das mitten in einer Epoche passiert, stillschweigend den BLS-Beitrag der gesamten Epoche disqualifiziert, oder nur dann relevant ist, wenn der Validator im Moment des Epochenendes noch aktiv ist. Babylons Dokumentation bestätigt, dass die beiden Aufgaben getrennt sind. Nirgendwo in dem, was ich gefunden habe, wird diese konkrete zeitliche Grenze jedoch ausdrücklich erklärt.
Wie auch immer: Beide Aufgaben teilen sich einen gemeinsamen Uptime-Record. Ein Validator, der wegen gewöhnlich verpasster Blocks gejailt wurde – nach derselben Regel, die jede Cosmos-Chain ausführt – wird nicht davor geschützt, in derselben Epoche auch die Signatur zu verpassen, die tatsächlich auf Bitcoin verankert wird, aus einem Grund, der überhaupt nichts mit Bitcoin-Sicherheit zu tun hat.
Ich glaube nicht, dass das ein Designfehler ist. Es gibt keine saubere Möglichkeit, jemanden für eine Rolle zu jailen und für die andere nicht – mit demselben Schlüssel. Was ich vorhin im Kopf noch nicht getrennt hatte, ist: Die Downtime-Historie geht nicht nur darum, welche Rewards verpasst wurden. Sie ist eher ein grober Indikator dafür, wie oft ein Validator wirklich für die Signatur anwesend war, die „Bitcoin-gesichert“ überhaupt wahr macht.
Ich habe meine Shortlist-Jailing-Historie nochmal geprüft. Zwei Namen hatten jeweils genau einen Eintrag, beide waren älter als ein Jahr, und beide folgten langen, sauberen Phasen seitdem. Kein Warnsignal. Nur eben nicht genau die Null, die ich als sauberer Uptime-Prozentsatz automatisch angenommen hatte.
$BLESS
🤔 Was ist das Erste, was du prüfst, bevor du dein Baby delegierst
Ich habe Validatoren für meine BABY-Delegierung verglichen und wäre fast an „jailing“ vorbeigegangen, also an dem Standard-Cosmos-Boilerplate, das jede Chain hat: fehlende Blocks, temporärer Timeout, nichts Spezifisches zu Babylon. Dann habe ich gelesen, was Validatoren tatsächlich zweimal signieren, nicht nur einmal.
Jeder Babylon-Genesis-Validator übernimmt zwei getrennte Aufgaben. Erstens das reguläre CometBFT-Blocksignieren – die gewöhnliche Arbeit, die jeder Cosmos-Validator macht. Und zweitens: BLS-Voting am Ende jedes Epochenabschnitts, bei dem die Validator-Signaturen in einem Checkpoint aggregiert werden, der direkt mit einem Zeitstempel auf Bitcoin abgelegt wird. Diese zweite Signatur ist der Grund, warum viele sagen, diese Chain sei „Bitcoin-gesichert“.
Downtime-Jailing betrifft nur die erste Aufgabe – und das auf dessen eigene Weise, mit standardmäßiger Liveness-Überwachung, ohne etwas Dramatisches. Was mir allerdings nicht eindeutig klar werden konnte, ist die genaue Interaktion: Ob ein Jailing, das mitten in einer Epoche passiert, stillschweigend den BLS-Beitrag der gesamten Epoche disqualifiziert, oder nur dann relevant ist, wenn der Validator im Moment des Epochenendes noch aktiv ist. Babylons Dokumentation bestätigt, dass die beiden Aufgaben getrennt sind. Nirgendwo in dem, was ich gefunden habe, wird diese konkrete zeitliche Grenze jedoch ausdrücklich erklärt.
Wie auch immer: Beide Aufgaben teilen sich einen gemeinsamen Uptime-Record. Ein Validator, der wegen gewöhnlich verpasster Blocks gejailt wurde – nach derselben Regel, die jede Cosmos-Chain ausführt – wird nicht davor geschützt, in derselben Epoche auch die Signatur zu verpassen, die tatsächlich auf Bitcoin verankert wird, aus einem Grund, der überhaupt nichts mit Bitcoin-Sicherheit zu tun hat.
Ich glaube nicht, dass das ein Designfehler ist. Es gibt keine saubere Möglichkeit, jemanden für eine Rolle zu jailen und für die andere nicht – mit demselben Schlüssel. Was ich vorhin im Kopf noch nicht getrennt hatte, ist: Die Downtime-Historie geht nicht nur darum, welche Rewards verpasst wurden. Sie ist eher ein grober Indikator dafür, wie oft ein Validator wirklich für die Signatur anwesend war, die „Bitcoin-gesichert“ überhaupt wahr macht.
Ich habe meine Shortlist-Jailing-Historie nochmal geprüft. Zwei Namen hatten jeweils genau einen Eintrag, beide waren älter als ein Jahr, und beide folgten langen, sauberen Phasen seitdem. Kein Warnsignal. Nur eben nicht genau die Null, die ich als sauberer Uptime-Prozentsatz automatisch angenommen hatte.
$BLESS
🤔 Was ist das Erste, was du prüfst, bevor du dein Baby delegierst
Validator uptime 📈
34%
Jailing history 🚨
0%
Commission fees 💰
33%
Reputation & community 🌟
33%
3 Stimmen • Abstimmung beendet
$CYS
Mù 穆涵
·
--
$BABY #baby @BabylonLabs_io
Ich habe einen Finality-Provider anhand der Größe der von ihm delegierten BTC sowie anhand seiner Uptime-Historie ausgewählt – genau die Zahlen, die jedes Dashboard anzeigt. Erst später habe ich gelesen, was diesen Provider tatsächlich Tag für Tag am Laufen hält, und das ist nicht etwa BTC.
Jeder Finality-Provider benötigt einen separaten Betriebsschlüssel, der mit BABY (kleinen Beträgen) finanziert ist. Damit werden Gas-Kosten für das verpflichtende Einreichen von frischem Zufall auf einem wiederkehrenden Zeitplan bezahlt. Vote-Einreichungen werden automatisch zurückerstattet – Babylons eigene Operator-Dokumentation bestätigt das direkt. Andere Transaktionen auf demselben Schlüssel, einschließlich der wiederkehrenden Zufalls-Commits, benötigen Gas, das nicht zurückkommt. In den Doks wird es fast als Nebensache beschrieben: mit einem Mindestbetrag finanzieren, lange am Laufen halten – ein einzelner Satz neben der Sicherheitsmaschinerie, nach der ich eigentlich gesucht habe.
Wenn dieses Nachfüllen ausbleibt, ist der Provider nicht heimlich kompromittiert: Ihre BTC-Delegation ist weiterhin genauso groß und ehrlich wie gestern. Sie können nur nicht weiter teilnehmen, bis jemand eine leere Wallet bemerkt und sie auffüllt. Ein Provider kann in jedem Kennwert, den ich vor der Delegation geprüft habe, makellos gewesen sein – und trotzdem ausfallen, nur wegen etwas so Kleinem wie einem Gas-Key, an den sich niemand erinnert hatte, nachzufüllen.
Delegations-Dashboards zeigen Kommission, Delegationsgröße und Uptime-Historie. Keines davon zeigt, ob der Betriebsschlüssel eines Providers komfortabel mit Mitteln versorgt ist oder auf dem letzten Rest läuft, denn diese Zahl war von vornherein nicht dafür gedacht, öffentlich zu sein.
Ich glaube nicht, dass das ein Designfehler ist: Der Betriebsschlüssel minimal zu halten und ihn von den echten Beständen eines Providers zu trennen, ist eine vernünftige Sicherheitsentscheidung – keine Fahrlässigkeit. Was das für jemanden bedeutet, der delegiert, ist geringer: Der Provider, den du wegen seines BTC-Track-Records ausgewählt hast, ist auch, ganz leise, damit beschäftigt, daran zu denken, Gas nachzukaufen.
$HEI
Wusstest du, dass der Betriebsschlüssel eines Finality-Providers leer laufen kann, selbst während ihre BTC-Delegation völlig gesund aussieht?
Ich habe einen Finality-Provider anhand der Größe der von ihm delegierten BTC sowie anhand seiner Uptime-Historie ausgewählt – genau die Zahlen, die jedes Dashboard anzeigt. Erst später habe ich gelesen, was diesen Provider tatsächlich Tag für Tag am Laufen hält, und das ist nicht etwa BTC.
Jeder Finality-Provider benötigt einen separaten Betriebsschlüssel, der mit BABY (kleinen Beträgen) finanziert ist. Damit werden Gas-Kosten für das verpflichtende Einreichen von frischem Zufall auf einem wiederkehrenden Zeitplan bezahlt. Vote-Einreichungen werden automatisch zurückerstattet – Babylons eigene Operator-Dokumentation bestätigt das direkt. Andere Transaktionen auf demselben Schlüssel, einschließlich der wiederkehrenden Zufalls-Commits, benötigen Gas, das nicht zurückkommt. In den Doks wird es fast als Nebensache beschrieben: mit einem Mindestbetrag finanzieren, lange am Laufen halten – ein einzelner Satz neben der Sicherheitsmaschinerie, nach der ich eigentlich gesucht habe.
Wenn dieses Nachfüllen ausbleibt, ist der Provider nicht heimlich kompromittiert: Ihre BTC-Delegation ist weiterhin genauso groß und ehrlich wie gestern. Sie können nur nicht weiter teilnehmen, bis jemand eine leere Wallet bemerkt und sie auffüllt. Ein Provider kann in jedem Kennwert, den ich vor der Delegation geprüft habe, makellos gewesen sein – und trotzdem ausfallen, nur wegen etwas so Kleinem wie einem Gas-Key, an den sich niemand erinnert hatte, nachzufüllen.
Delegations-Dashboards zeigen Kommission, Delegationsgröße und Uptime-Historie. Keines davon zeigt, ob der Betriebsschlüssel eines Providers komfortabel mit Mitteln versorgt ist oder auf dem letzten Rest läuft, denn diese Zahl war von vornherein nicht dafür gedacht, öffentlich zu sein.
Ich glaube nicht, dass das ein Designfehler ist: Der Betriebsschlüssel minimal zu halten und ihn von den echten Beständen eines Providers zu trennen, ist eine vernünftige Sicherheitsentscheidung – keine Fahrlässigkeit. Was das für jemanden bedeutet, der delegiert, ist geringer: Der Provider, den du wegen seines BTC-Track-Records ausgewählt hast, ist auch, ganz leise, damit beschäftigt, daran zu denken, Gas nachzukaufen.
$HEI
Wusstest du, dass der Betriebsschlüssel eines Finality-Providers leer laufen kann, selbst während ihre BTC-Delegation völlig gesund aussieht?
#baby @BabylonLabs_io
Letzte Nacht habe ich eine grausame Aufschlüsselung gelesen, auf der Suche nach der exakten BTC-Strafnummer. Gefunden: 0,1% der gestakten BTC für doppeltes Signieren. Dann habe ich die Zeile direkt daneben entdeckt, nach der ich gar nicht gesucht habe: Bereits verdiente Belohnungen werden nicht zurückgefordert.
Der Anbieter wird dauerhaft gebannt, eingesperrt für immer, keine weiteren Delegationen mehr, keine weiteren Provisionen. Aber was an Provisionen sie bereits vor dem Verstoß eingesammelt haben, bleibt ihnen. Die Strafe läuft vorwärts ab dem Moment, in dem sie erwischt werden. Sie läuft nicht rückwärts durch, wie lange sie zuvor operiert haben.
Für einen brandneuen Anbieter spielt diese Lücke kaum eine Rolle: Es ist noch nichts angesammelt, das man zurückholen könnte. Für einen, der seit einem Jahr Delegationen betreibt, in jeder Reward-Periode eine Provisionskürzung verdient und das die ganze Zeit über, ändert sich die Rechnung. Ein einzelner 0,1%-Slash trifft alle, die an sie delegiert haben, anteilig — Anbieter und Delegatoren gleichermaßen. Was dabei nicht angetastet wird, ist die Provisionshistorie, egal wie viel sie bereits mitgenommen haben.
Ich weiß nicht, was ein einzelner Anbieter tatsächlich über ihre gesamte Amtszeit verdient hat — das ist nirgendwo öffentlich, wo ich es gefunden habe — daher kann ich dir nicht sagen, ob diese Lücke trivial oder real ist. Was ich sagen kann: Die Abschreckung wurde absichtlich so gebaut, dass sie nur vorwärts wirkt. Historische Belohnungen zurückzuklammern würde bedeuten, jede vergangene Reward-Periode erneut aufzuschließen — ein eigenes Chaos, das man beim Design berücksichtigen müsste.
„Für immer gebannt“ und „pleite“ sind zwei unterschiedliche Ergebnisse, und Babylons eigenes Slashing-Design garantiert nur das erste.
$CYS $BABY
Letzte Nacht habe ich eine grausame Aufschlüsselung gelesen, auf der Suche nach der exakten BTC-Strafnummer. Gefunden: 0,1% der gestakten BTC für doppeltes Signieren. Dann habe ich die Zeile direkt daneben entdeckt, nach der ich gar nicht gesucht habe: Bereits verdiente Belohnungen werden nicht zurückgefordert.
Der Anbieter wird dauerhaft gebannt, eingesperrt für immer, keine weiteren Delegationen mehr, keine weiteren Provisionen. Aber was an Provisionen sie bereits vor dem Verstoß eingesammelt haben, bleibt ihnen. Die Strafe läuft vorwärts ab dem Moment, in dem sie erwischt werden. Sie läuft nicht rückwärts durch, wie lange sie zuvor operiert haben.
Für einen brandneuen Anbieter spielt diese Lücke kaum eine Rolle: Es ist noch nichts angesammelt, das man zurückholen könnte. Für einen, der seit einem Jahr Delegationen betreibt, in jeder Reward-Periode eine Provisionskürzung verdient und das die ganze Zeit über, ändert sich die Rechnung. Ein einzelner 0,1%-Slash trifft alle, die an sie delegiert haben, anteilig — Anbieter und Delegatoren gleichermaßen. Was dabei nicht angetastet wird, ist die Provisionshistorie, egal wie viel sie bereits mitgenommen haben.
Ich weiß nicht, was ein einzelner Anbieter tatsächlich über ihre gesamte Amtszeit verdient hat — das ist nirgendwo öffentlich, wo ich es gefunden habe — daher kann ich dir nicht sagen, ob diese Lücke trivial oder real ist. Was ich sagen kann: Die Abschreckung wurde absichtlich so gebaut, dass sie nur vorwärts wirkt. Historische Belohnungen zurückzuklammern würde bedeuten, jede vergangene Reward-Periode erneut aufzuschließen — ein eigenes Chaos, das man beim Design berücksichtigen müsste.
„Für immer gebannt“ und „pleite“ sind zwei unterschiedliche Ergebnisse, und Babylons eigenes Slashing-Design garantiert nur das erste.
$CYS $BABY
$BICO
Mù 穆涵
·
--
#baby $BABY @BabylonLabs_io
Ich habe die Provision eines Finality-Providers überprüft, bevor ich letzte Nacht delegiert habe: 5 %, sah im Vergleich zu den anderen in der Liste durchaus vernünftig aus. Beinahe hätte ich nur anhand dieser Zahl delegiert. Dann habe ich festgestellt, dass hinter dem Registrierungsbefehl Babylon tatsächlich noch etwas anderes steckt.
Jeder Finality-Provider setzt bei der Registrierung drei Zahlen, nicht nur eine. Der aktuelle Provisionssatz, ein maximaler Satz, den er niemals überschreiten kann, und eine maximale Änderungsrate – also wie schnell er in Richtung dieser Obergrenze steigen darf. Die 5 %, auf die ich geschaut habe, war nie das gesamte Bild; es war nur ein Schnappschuss auf einem Zifferblatt, mit einer eigenen, separaten höheren Stoppschwelle, die von Anfang an eingebaut war.
Nichts hindert einen Provider daran, sich mit 5 % zu registrieren, mit einer Maximalrate von 50 %, und diese dann in kleinen, rechtssicheren Schritten pro Periode anzuheben – bis Delegatoren, die bei 5 % eingestiegen sind, mit einer sehr anderen Zahl rechnen. Keine Regel gebrochen, kein Raubzug – nur eine Obergrenze, die die ganze Zeit öffentlich war.
Ich bin auf die Suche gegangen, wo diese Obergrenze tatsächlich für einen Delegator sichtbar wird, der entscheiden muss, wen er auswählt. Nach allem, was ich herausfinden konnte, zeigen Babylons eigene Staking-Dokumente und die API, die das Dashboard speist, in diesem Stadium genau ein Feld: commission. Niedriger bedeutet höhere Rewards, und nicht mehr Details als das. Nicht die Maximalrate, die eine Ebene darüber in den eigenen Registrierungsdaten des Providers steht.
Ich glaube nicht, dass das die Mechanik räuberisch macht. Eine Änderungsraten-Begrenzung existiert genau dafür, damit die Provision nicht über Nacht sprunghaft steigt – und dieser Schutz ist real. Was fehlt, ist etwas Kleineres: die Zahl, die deine zukünftigen Einnahmen tatsächlich begrenzt, war nie dafür gebaut, auf dem Bildschirm zu erscheinen, von dem aus du deine Entscheidung triffst. Die Doku sagt nicht, wie viele aktive Provider bereits von ihrem Startsatz weggegangen sind, noch wie nah irgendeiner von ihnen im Moment an seiner Obergrenze ist – daher kann ich nicht beurteilen, ob das ein echtes Live-Risiko ist oder nur theoretisch.
Die 5 %, die du siehst, ist ein Foto. Die Obergrenze war immer die eigentliche Vereinbarung.
Wusstest du, dass die Provision deines Finality-Providers über die Zahl hinaus steigen kann, die du heute siehst? 📈
Ich habe die Provision eines Finality-Providers überprüft, bevor ich letzte Nacht delegiert habe: 5 %, sah im Vergleich zu den anderen in der Liste durchaus vernünftig aus. Beinahe hätte ich nur anhand dieser Zahl delegiert. Dann habe ich festgestellt, dass hinter dem Registrierungsbefehl Babylon tatsächlich noch etwas anderes steckt.
Jeder Finality-Provider setzt bei der Registrierung drei Zahlen, nicht nur eine. Der aktuelle Provisionssatz, ein maximaler Satz, den er niemals überschreiten kann, und eine maximale Änderungsrate – also wie schnell er in Richtung dieser Obergrenze steigen darf. Die 5 %, auf die ich geschaut habe, war nie das gesamte Bild; es war nur ein Schnappschuss auf einem Zifferblatt, mit einer eigenen, separaten höheren Stoppschwelle, die von Anfang an eingebaut war.
Nichts hindert einen Provider daran, sich mit 5 % zu registrieren, mit einer Maximalrate von 50 %, und diese dann in kleinen, rechtssicheren Schritten pro Periode anzuheben – bis Delegatoren, die bei 5 % eingestiegen sind, mit einer sehr anderen Zahl rechnen. Keine Regel gebrochen, kein Raubzug – nur eine Obergrenze, die die ganze Zeit öffentlich war.
Ich bin auf die Suche gegangen, wo diese Obergrenze tatsächlich für einen Delegator sichtbar wird, der entscheiden muss, wen er auswählt. Nach allem, was ich herausfinden konnte, zeigen Babylons eigene Staking-Dokumente und die API, die das Dashboard speist, in diesem Stadium genau ein Feld: commission. Niedriger bedeutet höhere Rewards, und nicht mehr Details als das. Nicht die Maximalrate, die eine Ebene darüber in den eigenen Registrierungsdaten des Providers steht.
Ich glaube nicht, dass das die Mechanik räuberisch macht. Eine Änderungsraten-Begrenzung existiert genau dafür, damit die Provision nicht über Nacht sprunghaft steigt – und dieser Schutz ist real. Was fehlt, ist etwas Kleineres: die Zahl, die deine zukünftigen Einnahmen tatsächlich begrenzt, war nie dafür gebaut, auf dem Bildschirm zu erscheinen, von dem aus du deine Entscheidung triffst. Die Doku sagt nicht, wie viele aktive Provider bereits von ihrem Startsatz weggegangen sind, noch wie nah irgendeiner von ihnen im Moment an seiner Obergrenze ist – daher kann ich nicht beurteilen, ob das ein echtes Live-Risiko ist oder nur theoretisch.
Die 5 %, die du siehst, ist ein Foto. Die Obergrenze war immer die eigentliche Vereinbarung.
Wusstest du, dass die Provision deines Finality-Providers über die Zahl hinaus steigen kann, die du heute siehst? 📈
#baby @BabylonLabs_io
Ich habe im Moment BTC über Babylon gestaked. Als ich also gestern Abend das Wort „overflow“ (Überlauf) in alter Cap-3-Dokumentation begraben fand, habe ich es nicht als Geschichte gelesen. Ich habe es als Frage zu meiner eigenen Position verstanden: Könnte mir so etwas passieren.
In Phase 1 sperrten Staking-Transaktionen, die bestätigt wurden, nachdem der Cap bereits voll war, das BTC genau wie bei allen anderen ebenfalls in den Vertrag. Sie verdienten jedoch nichts: keine Punkte, keine Zuteilung. Die Coins kamen auch nicht automatisch zurück; die Doku ist eindeutig: Overflow-Stakes mussten erst unbonded und ausbezahlt werden – mit derselben Wartezeit wie bei einer aktiven Position. Für einen Stake, der die ganze Zeit im Lock lag und in der Summe null ausgezahlt hatte.
Was entschied, wer es „rein“ geschafft hat, war nicht, wann jemand auf „stake“ geklickt hat. Entscheidend war, in welchem Bitcoin-Block die Transaktion tatsächlich bestätigt wurde – eine Zahl, die niemand vollständig kontrolliert, sobald sie die Wallet verlässt. Zwei Personen konnten Minuten auseinander senden und je nach Gebühren, Mempool-Stau oder danach, welcher Miner den nächsten Block zuerst findet, in umgekehrter Reihenfolge landen.
Die Caps von Phase 1 sind zwar weg, aber der Mechanismus, der den Overflow erzeugt hat, ist nicht nur auf diese Phase beschränkt. Jeder zukünftige capped round, ein neues BSN-Onboarding mit fester Zuteilung, eine Integration mit begrenzten Slots übernimmt denselben Wettlauf, sobald es Blockbestätigungen statt einer Warteschlange verwendet. Nichts an diesem Designfehler wurde gefixt. Er wurde nur überholt, als die Caps verschwanden.
Ich glaube nicht, dass das ursprüngliche Design unfair war. Ein harter Cap braucht einen Cutoff, und Blockbestätigungen kann man nicht so „faken“, wie man es mit einem Zeitstempel kann. Was bei mir bleibt, ist nur Kleineres: Mein eigenes BTC, das gerade gesperrt ist, war nie durch Können oder gutes Timing geschützt. Es hat einfach eine von Minern gezogene Linie durchlaufen – nicht durch mich. Und wenn diese Linie beim nächsten Mal gezogen wird, dann wird sie es wieder.
$SKYAI $BICO $BABY
„Würde dich dieses Overflow-Risiko davon abhalten, in einem zukünftigen capped round zu staken?“ 🎯
Ich habe im Moment BTC über Babylon gestaked. Als ich also gestern Abend das Wort „overflow“ (Überlauf) in alter Cap-3-Dokumentation begraben fand, habe ich es nicht als Geschichte gelesen. Ich habe es als Frage zu meiner eigenen Position verstanden: Könnte mir so etwas passieren.
In Phase 1 sperrten Staking-Transaktionen, die bestätigt wurden, nachdem der Cap bereits voll war, das BTC genau wie bei allen anderen ebenfalls in den Vertrag. Sie verdienten jedoch nichts: keine Punkte, keine Zuteilung. Die Coins kamen auch nicht automatisch zurück; die Doku ist eindeutig: Overflow-Stakes mussten erst unbonded und ausbezahlt werden – mit derselben Wartezeit wie bei einer aktiven Position. Für einen Stake, der die ganze Zeit im Lock lag und in der Summe null ausgezahlt hatte.
Was entschied, wer es „rein“ geschafft hat, war nicht, wann jemand auf „stake“ geklickt hat. Entscheidend war, in welchem Bitcoin-Block die Transaktion tatsächlich bestätigt wurde – eine Zahl, die niemand vollständig kontrolliert, sobald sie die Wallet verlässt. Zwei Personen konnten Minuten auseinander senden und je nach Gebühren, Mempool-Stau oder danach, welcher Miner den nächsten Block zuerst findet, in umgekehrter Reihenfolge landen.
Die Caps von Phase 1 sind zwar weg, aber der Mechanismus, der den Overflow erzeugt hat, ist nicht nur auf diese Phase beschränkt. Jeder zukünftige capped round, ein neues BSN-Onboarding mit fester Zuteilung, eine Integration mit begrenzten Slots übernimmt denselben Wettlauf, sobald es Blockbestätigungen statt einer Warteschlange verwendet. Nichts an diesem Designfehler wurde gefixt. Er wurde nur überholt, als die Caps verschwanden.
Ich glaube nicht, dass das ursprüngliche Design unfair war. Ein harter Cap braucht einen Cutoff, und Blockbestätigungen kann man nicht so „faken“, wie man es mit einem Zeitstempel kann. Was bei mir bleibt, ist nur Kleineres: Mein eigenes BTC, das gerade gesperrt ist, war nie durch Können oder gutes Timing geschützt. Es hat einfach eine von Minern gezogene Linie durchlaufen – nicht durch mich. Und wenn diese Linie beim nächsten Mal gezogen wird, dann wird sie es wieder.
$SKYAI $BICO $BABY
„Würde dich dieses Overflow-Risiko davon abhalten, in einem zukünftigen capped round zu staken?“ 🎯
😰 Yeah, dealbreaker
34%
😌 Nah, worth the risk
33%
🤔 Depends on the cap size
33%
🙈 Didn't know this existed
0%
3 Stimmen • Abstimmung beendet
$BLESS
Mù 穆涵
·
--
$BABY $BLESS #baby
Vor drei Wochen habe ich meine Co-Staking-Quote festgelegt – 20.000 BABY pro BTC, das von Babylon selbst empfohlene Verhältnis. Letzte Nacht habe ich meine Belohnungen geprüft. Niedriger als die Zahl, die ich an dem Tag berechnet hatte, an dem ich gestaktet habe.
Meine Position ist keinen Millimeter weitergekommen. Aber irgendetwas anderes schon.
Der 2,35%-Co-Staking-Boost ist kein Satz. Es ist ein Pool fester Größe, der anteilig auf jedes Wallet aufgeteilt wird, das genau dann Co-Staking betreibt. Babylon sagt das ganz offen in seinen eigenen Dokus: Mehr Co-Staker, kleinere individuelle Belohnungen. Wenn du das Verhältnis perfekt triffst, hängt dein tatsächlicher Anteil immer noch davon ab, wie viele andere Wallets es ebenfalls schaffen – und diese Zahl verschiebt sich, ohne dass du deine Position anfasst.
Es gibt kein Dashboard, das diese Zahl in Echtzeit verfolgt. Du kannst dein eigenes Gewicht sehen. Du kannst nicht sehen, wie sich das Gesamtgewicht des Pools darunter verändert.
Anders als andere Babylon-Risiken, die sich in fehlender Infrastruktur oder konzentrierten Betreibern verstecken, liegt dieses hier offen zutage – die Formel ist vollständig öffentlich. Es fehlt nur, wer sie sonst noch nutzt.
Eine Sache, die es zu beobachten gilt: Diese 2,35% sind kein Fundament, sondern eine Governance-Zahl. Sie existiert nur, weil ein Vorschlag im vergangenen September Babylons Inflation in feste Tranchen aufgeteilt hat: 1% für BTC-Staker, 2% für BABY-Staker, 2,35% für Co-Staker, der Rest wird anderweitig aufgeteilt. Eine zukünftige Abstimmung könnte diese Spanne genauso neu bemessen, wie diese sie geschaffen hat. Bisher hat niemand vorgeschlagen, sie zu verkleinern – also bleibt das ein Sitz, den du im Blick behältst, nicht ein Tisch, der dir garantiert bleibt.
Es gibt noch eine zweite Kante, die in die Formel eingebaut ist. Das zulässige Gewicht ist gedeckelt auf das, was kleiner ist: dein BABY geteilt durch 20.000 oder dein BTC. Wenn du das Verhältnis überschreitest, wird das zusätzliche BABY nur zum normalen Staking-Satz gutgeschrieben. Wenn du darunter bleibst, wird nur ein Teil deines BTC geboostet.
Die Kombination aus BTC und BABY wurde dafür gebaut, diese Verbindung zu stärken, und ein geteilter Pool ist ein naheliegender Weg, das zu finanzieren. Das Design ist nicht das Problem. Dass du nicht sehen kannst, wie sich dein Anteil verschiebt, bevor es passiert, ist es.
Wenn du das Verhältnis exakt getroffen hast, so wie ich es getan habe, verdienst du keine feste 2,35%. Du mietet dir einen Platz an einem Tisch, der nach seinem eigenen Fahrplan immer voller wird – mit Menschen, die du nie ankommen sehen wirst.
Vor drei Wochen habe ich meine Co-Staking-Quote festgelegt – 20.000 BABY pro BTC, das von Babylon selbst empfohlene Verhältnis. Letzte Nacht habe ich meine Belohnungen geprüft. Niedriger als die Zahl, die ich an dem Tag berechnet hatte, an dem ich gestaktet habe.
Meine Position ist keinen Millimeter weitergekommen. Aber irgendetwas anderes schon.
Der 2,35%-Co-Staking-Boost ist kein Satz. Es ist ein Pool fester Größe, der anteilig auf jedes Wallet aufgeteilt wird, das genau dann Co-Staking betreibt. Babylon sagt das ganz offen in seinen eigenen Dokus: Mehr Co-Staker, kleinere individuelle Belohnungen. Wenn du das Verhältnis perfekt triffst, hängt dein tatsächlicher Anteil immer noch davon ab, wie viele andere Wallets es ebenfalls schaffen – und diese Zahl verschiebt sich, ohne dass du deine Position anfasst.
Es gibt kein Dashboard, das diese Zahl in Echtzeit verfolgt. Du kannst dein eigenes Gewicht sehen. Du kannst nicht sehen, wie sich das Gesamtgewicht des Pools darunter verändert.
Anders als andere Babylon-Risiken, die sich in fehlender Infrastruktur oder konzentrierten Betreibern verstecken, liegt dieses hier offen zutage – die Formel ist vollständig öffentlich. Es fehlt nur, wer sie sonst noch nutzt.
Eine Sache, die es zu beobachten gilt: Diese 2,35% sind kein Fundament, sondern eine Governance-Zahl. Sie existiert nur, weil ein Vorschlag im vergangenen September Babylons Inflation in feste Tranchen aufgeteilt hat: 1% für BTC-Staker, 2% für BABY-Staker, 2,35% für Co-Staker, der Rest wird anderweitig aufgeteilt. Eine zukünftige Abstimmung könnte diese Spanne genauso neu bemessen, wie diese sie geschaffen hat. Bisher hat niemand vorgeschlagen, sie zu verkleinern – also bleibt das ein Sitz, den du im Blick behältst, nicht ein Tisch, der dir garantiert bleibt.
Es gibt noch eine zweite Kante, die in die Formel eingebaut ist. Das zulässige Gewicht ist gedeckelt auf das, was kleiner ist: dein BABY geteilt durch 20.000 oder dein BTC. Wenn du das Verhältnis überschreitest, wird das zusätzliche BABY nur zum normalen Staking-Satz gutgeschrieben. Wenn du darunter bleibst, wird nur ein Teil deines BTC geboostet.
Die Kombination aus BTC und BABY wurde dafür gebaut, diese Verbindung zu stärken, und ein geteilter Pool ist ein naheliegender Weg, das zu finanzieren. Das Design ist nicht das Problem. Dass du nicht sehen kannst, wie sich dein Anteil verschiebt, bevor es passiert, ist es.
Wenn du das Verhältnis exakt getroffen hast, so wie ich es getan habe, verdienst du keine feste 2,35%. Du mietet dir einen Platz an einem Tisch, der nach seinem eigenen Fahrplan immer voller wird – mit Menschen, die du nie ankommen sehen wirst.
#baby $BABY @BabylonLabs_io
Halb mein BTC ist derzeit über Babylon gestaket. Ich habe nie gefragt, was damit passiert, wenn auf einmal die Hälfte der Validatoren ausfällt — bis ich letzte Nacht einen Teil des Gründungspapiers von Babylon gelesen habe, den ich übersprungen hatte.
Bitcoin-Checkpointing sorgt für Sicherheit. Ein ehrlicher Validator, der einen Nachweis an Bitcoin übermittelt, reicht aus, um die Lügner zu bestrafen und festzulegen, welche Historie die echte ist. Die Lebendigkeit ist eine andere Frage: Produziert die Kette überhaupt weiterhin Blöcke.
Hier kommt der Teil, den Bitcoin nicht berühren kann. Kein Proof-of-Stake-Protokoll garantiert Lebendigkeit, sobald adversarische Validatoren die Hälfte der aktiven Menge überschreiten. Nicht mit Bitcoin als Grundlage, nicht mit irgendeinem Zeitstempeldienst — es sei denn, die Daten jedes Validators werden on-chain gepostet, und die Durchsatzleistung von Bitcoin wurde nie dafür gebaut.
Der Nachweis gilt gegen Arglist. Er sagt nichts über Validatoren, die einfach nicht mehr auftauchen. Die Kette steht in beiden Fällen exakt genauso still, und Bitcoin kann dir nicht sagen, welches davon passiert ist.
„Gesichert durch Bitcoin“ klingt wie eine Garantie. Es sind zwei. Bitcoin kauft dir Gewissheit darüber, welche Historie wahr ist. Es kauft dir keinen Versprechen, dass die Kette weiterläuft, wenn auf einmal die Hälfte der Validatoren verschwindet — Ausfall, Exit oder ein Angriff, den niemand rechtzeitig erkannt hat.
Ein Komitee, das einen ehrlichen Unterzeichner braucht, ein Relayer, der einen braucht, um online zu bleiben — das wird behoben, indem mehr Operatoren auftauchen. Diese Grenze ist bewiesene Mathematik, kein Personalproblem. Noch genauer hinzuschauen macht das nicht besser.
Mein BTC ist in beiden Fällen gesperrt. Bitcoin wird mir eine Quittung für den exakten Moment geben, in dem die Kette gestorben ist. Dass sie danach wieder atmet, war nie Teil des Beweises.
$BLESS $HOME
Wenn heute Nacht die Hälfte der Validatoren von Babylon dunkel wird, was passiert dann mit deinem BTC?
Halb mein BTC ist derzeit über Babylon gestaket. Ich habe nie gefragt, was damit passiert, wenn auf einmal die Hälfte der Validatoren ausfällt — bis ich letzte Nacht einen Teil des Gründungspapiers von Babylon gelesen habe, den ich übersprungen hatte.
Bitcoin-Checkpointing sorgt für Sicherheit. Ein ehrlicher Validator, der einen Nachweis an Bitcoin übermittelt, reicht aus, um die Lügner zu bestrafen und festzulegen, welche Historie die echte ist. Die Lebendigkeit ist eine andere Frage: Produziert die Kette überhaupt weiterhin Blöcke.
Hier kommt der Teil, den Bitcoin nicht berühren kann. Kein Proof-of-Stake-Protokoll garantiert Lebendigkeit, sobald adversarische Validatoren die Hälfte der aktiven Menge überschreiten. Nicht mit Bitcoin als Grundlage, nicht mit irgendeinem Zeitstempeldienst — es sei denn, die Daten jedes Validators werden on-chain gepostet, und die Durchsatzleistung von Bitcoin wurde nie dafür gebaut.
Der Nachweis gilt gegen Arglist. Er sagt nichts über Validatoren, die einfach nicht mehr auftauchen. Die Kette steht in beiden Fällen exakt genauso still, und Bitcoin kann dir nicht sagen, welches davon passiert ist.
„Gesichert durch Bitcoin“ klingt wie eine Garantie. Es sind zwei. Bitcoin kauft dir Gewissheit darüber, welche Historie wahr ist. Es kauft dir keinen Versprechen, dass die Kette weiterläuft, wenn auf einmal die Hälfte der Validatoren verschwindet — Ausfall, Exit oder ein Angriff, den niemand rechtzeitig erkannt hat.
Ein Komitee, das einen ehrlichen Unterzeichner braucht, ein Relayer, der einen braucht, um online zu bleiben — das wird behoben, indem mehr Operatoren auftauchen. Diese Grenze ist bewiesene Mathematik, kein Personalproblem. Noch genauer hinzuschauen macht das nicht besser.
Mein BTC ist in beiden Fällen gesperrt. Bitcoin wird mir eine Quittung für den exakten Moment geben, in dem die Kette gestorben ist. Dass sie danach wieder atmet, war nie Teil des Beweises.
$BLESS $HOME
Wenn heute Nacht die Hälfte der Validatoren von Babylon dunkel wird, was passiert dann mit deinem BTC?
🔐 Safety's covered, I'm fine
33%
🛑 Liveness could still stall
0%
🧊 Frozen either way
0%
⚡ Didn't know
67%
3 Stimmen • Abstimmung beendet
Verifiziert
@BabylonLabs_io $BABY #baby
Jedes Mal, wenn du BTC aus Babylon ausbondest, stehen neun Schlüssel zwischen deinem Bitcoin und deinem Wallet. Sechs davon müssen zustimmen, bevor du deine Gelder zurückbekommst.
Einer dieser neun gehört Babylon Labs.
Das Versprechen ist „trustless“: kein Custodian, keine Firma, die deine BTC hält, sondern nur Bitcoin Script, das die Regeln durchsetzt. Und das ist echt – kein einzelner Schlüssel kann allein auf deine Gelder zugreifen. Aber Ausbonding ist die einzige Tür zurück zu deinen Coins, bevor die 15-monatige Time-lock-Frist abläuft, und das Team, das die Tür gebaut hat, hält auch einen der Schlüssel, um sie zu öffnen.
Das ist kein Skandal. Die anderen acht Schlüssel liegen bei benannten, renommierten Einrichtungen, und das Komitee kann nur Standardtransaktionen genehmigen oder ablehnen – es wurde nie so gebaut, dass es mit den BTC irgendjemandes durchbrennen kann. Trotzdem: Wenn du die eigenen Dokumente von Babylon genau genug liest, wirst du den Builder als Signer im System finden, das er gebaut hat – sodass er keine Signer benötigt.
Frag einen Babylon-Staker, warum sie BTC in das Protokoll verschoben haben, und „trustless“ ist in der Regel das erste Wort, das aus seinem Mund kommt. Frag sie, wer Schlüsselnummer eins hält, und die meisten werden die Antwort nicht kennen: Babylon Labs.
$IDOL
Ändert es deine Sicht auf „trustless“, dass der Builder einen der Unbonding-Schlüssel hält?
Jedes Mal, wenn du BTC aus Babylon ausbondest, stehen neun Schlüssel zwischen deinem Bitcoin und deinem Wallet. Sechs davon müssen zustimmen, bevor du deine Gelder zurückbekommst.
Einer dieser neun gehört Babylon Labs.
Das Versprechen ist „trustless“: kein Custodian, keine Firma, die deine BTC hält, sondern nur Bitcoin Script, das die Regeln durchsetzt. Und das ist echt – kein einzelner Schlüssel kann allein auf deine Gelder zugreifen. Aber Ausbonding ist die einzige Tür zurück zu deinen Coins, bevor die 15-monatige Time-lock-Frist abläuft, und das Team, das die Tür gebaut hat, hält auch einen der Schlüssel, um sie zu öffnen.
Das ist kein Skandal. Die anderen acht Schlüssel liegen bei benannten, renommierten Einrichtungen, und das Komitee kann nur Standardtransaktionen genehmigen oder ablehnen – es wurde nie so gebaut, dass es mit den BTC irgendjemandes durchbrennen kann. Trotzdem: Wenn du die eigenen Dokumente von Babylon genau genug liest, wirst du den Builder als Signer im System finden, das er gebaut hat – sodass er keine Signer benötigt.
Frag einen Babylon-Staker, warum sie BTC in das Protokoll verschoben haben, und „trustless“ ist in der Regel das erste Wort, das aus seinem Mund kommt. Frag sie, wer Schlüsselnummer eins hält, und die meisten werden die Antwort nicht kennen: Babylon Labs.
$IDOL
Ändert es deine Sicht auf „trustless“, dass der Builder einen der Unbonding-Schlüssel hält?
🔑 No, still trustless
100%
🔒 Slightly concerning
0%
🚨 Yes, big issue
0%
❓ Didn't know this
0%
1 Stimmen • Abstimmung beendet
2 Uhr morgens, immer noch wach, und lese Babylons Dokumente zur Checkpoint-Erstellung aus reiner Langeweile – weil ich nicht schlafen konnte. Eine Zeile hat mein Scrollen gestoppt: Ein ehrlicher und aktiver Vigilant über das gesamte Netzwerk hinweg reicht aus, um erfolgreiche und sichere Checkpoints für Bitcoin zu garantieren.
Lies schnell, das klingt nach Dezentralisierung, die genau ihren Job macht. Dutzende unabhängige Betreiber, und es muss nur einer richtig funktionieren.
Ich bin zu Babylons eigener akademischer Arbeit aus dem Jahr 2022 zurückgegangen, die von seinen Gründern mitverfasst wurde – die, welche diese Behauptung als formales Theorem beweist, statt als Marketing-Satz. Der Beweis gilt unter einer einzigen Bedingung: Es gibt zu jeder Zeit einen ehrlichen Validator, der aktiv ist. Das steht dort auch ganz klar.
Nur das hier wird nicht explizit ausgeschrieben. „Einer ist mathematisch ausreichend“ und „einer ist gerade online“ sind zwei verschiedene Garantien. Nur die erste kommt mit einem angehängten Beweis.
Dann tauchte der gleiche Satz wieder auf – diesmal neben dem Covenant-Emulator und dem IBC-Relayer, die als eigene separate Programme benannt sind: Sichere Funktionsweise erfordert mindestens einen ehrlichen Operator für jedes der aufgelisteten Programme, sonst löst das System einen Alarm aus. Nicht sicher, ob das alle drei gleich abdeckt oder ob es nur mit der Vigilanten-Suite im Hinterkopf geschrieben wurde. Wie auch immer: Die genaue Anzahl bleibt unveröffentlicht.
Babylon nennt das freiwillig – jeder kann eines davon betreiben. Stimmt, und trotzdem sagt es nicht, wie viele derzeit tatsächlich laufen, oder ob diese Zahl auch während eines Bitcoin-Gebühren-Spikes Bestand hat, den niemand bezahlen will.
Es gibt einen Grund, warum diese Zahl niemand veröffentlicht. Wenn man zeigt, wie dünn der Puffer ist, hilft das einem Angreifer mehr als dir.
Wenn du gerade über Babylon stakest, liegt diese Annahme unter deinem BTC, die dir kein Dashboard zeigt: nicht ob die Mathematik funktioniert, sondern ob überhaupt jemand wirklich wach ist, um sie heute Nacht und jede Nacht danach auszuführen.
@BabylonLabs_io $BABY #baby
$1000RATS $KOMA
Würdest du staken, wenn die Anzahl „eines ehrlichen Operators“ unbekannt ist? 👀
Lies schnell, das klingt nach Dezentralisierung, die genau ihren Job macht. Dutzende unabhängige Betreiber, und es muss nur einer richtig funktionieren.
Ich bin zu Babylons eigener akademischer Arbeit aus dem Jahr 2022 zurückgegangen, die von seinen Gründern mitverfasst wurde – die, welche diese Behauptung als formales Theorem beweist, statt als Marketing-Satz. Der Beweis gilt unter einer einzigen Bedingung: Es gibt zu jeder Zeit einen ehrlichen Validator, der aktiv ist. Das steht dort auch ganz klar.
Nur das hier wird nicht explizit ausgeschrieben. „Einer ist mathematisch ausreichend“ und „einer ist gerade online“ sind zwei verschiedene Garantien. Nur die erste kommt mit einem angehängten Beweis.
Dann tauchte der gleiche Satz wieder auf – diesmal neben dem Covenant-Emulator und dem IBC-Relayer, die als eigene separate Programme benannt sind: Sichere Funktionsweise erfordert mindestens einen ehrlichen Operator für jedes der aufgelisteten Programme, sonst löst das System einen Alarm aus. Nicht sicher, ob das alle drei gleich abdeckt oder ob es nur mit der Vigilanten-Suite im Hinterkopf geschrieben wurde. Wie auch immer: Die genaue Anzahl bleibt unveröffentlicht.
Babylon nennt das freiwillig – jeder kann eines davon betreiben. Stimmt, und trotzdem sagt es nicht, wie viele derzeit tatsächlich laufen, oder ob diese Zahl auch während eines Bitcoin-Gebühren-Spikes Bestand hat, den niemand bezahlen will.
Es gibt einen Grund, warum diese Zahl niemand veröffentlicht. Wenn man zeigt, wie dünn der Puffer ist, hilft das einem Angreifer mehr als dir.
Wenn du gerade über Babylon stakest, liegt diese Annahme unter deinem BTC, die dir kein Dashboard zeigt: nicht ob die Mathematik funktioniert, sondern ob überhaupt jemand wirklich wach ist, um sie heute Nacht und jede Nacht danach auszuführen.
@BabylonLabs_io $BABY #baby
$1000RATS $KOMA
Würdest du staken, wenn die Anzahl „eines ehrlichen Operators“ unbekannt ist? 👀
✨ Yes, the math is enough
100%
🤌🏻I'd wnt live operator data
0%
⚠️ That’s a real concern
0%
❓ Didn’t know this
0%
1 Stimmen • Abstimmung beendet
Verifiziert
#baby $BABY @BabylonLabs_io
Früher dachte ich, das Abschlachten sei Bablyons Art, Unehrlichkeit zu bestrafen. Das änderte sich um 2 Uhr nachts, als ich durch einen unabhängigen Security-Audit zur EOTS-Implementierung scrollte – also durch ein Dokument, das niemand öffnet, ohne einen Grund.
Der Mechanismus ist an sich elegant. Ein Finality-Provider verpflichtet sich, vor dem Signieren eines Blocks in einer bestimmten Höhe einen Zufallswert festzulegen. Signiere ihn einmal, es passiert nichts. Signiere ihn zweimal – mit zwei unterschiedlichen Nachrichten – und die Mathematik hinter Schnorr-Signaturen macht aus demselben Zufall den offengelegten privaten Schlüssel des Providers. Absichtliches Doppelsignieren wird dadurch konstruktionsbedingt selbstbestrafend, und dafür gibt es einen Grund: Ein Protokoll kann Signaturen lesen, nicht die Absicht. Deshalb kann eine Regel, die streng genug ist, um einen Angreifer zu erwischen, nicht zwischen einem Angreifer und einem Unfall unterscheiden.
Dieser Trade-off wurde im Audit als Problem markiert. Ein gezielter Angriff und ein ehrliches Failover eines Backup-Nodes, der zur gleichen Höhe anspringt, erzeugen exakt dasselbe Signaturmuster. Beide sehen für EOTS identisch aus. Beide werden auf die gleiche Weise bestraft: gekürzt, tombstoned, keine Wiederherstellung.
Das ist nicht nur Theorie. Hex Trust, ein institutioneller Verwahrer, der Finality-Provider-Infrastruktur auf Babylon betreibt, nennt konkrete Schutzmaßnahmen genau gegen dieses Szenario: keine Wiederverwendung privater Schlüssel auf unterschiedlichen Maschinen, manuelles Failover statt automatischem – weil automatisches Failover genau das erzeugen kann, was zwei aktive Signer für denselben Schlüssel gleichzeitig ermöglicht.
Hier kommt der Teil ohne saubere Antwort. Es gibt keinen öffentlichen Standard dafür, welche Failover-Konfiguration ein Provider betreibt. Man kann Provision, Uptime, Anzahl der Delegatoren prüfen. Aber nicht das – und nicht, bevor dein BTC bereits gesperrt ist.
Das Delegieren war nie nur eine Wette darauf, dass der Betreiber dich nicht angreift. Es ist auch eine Wette darauf, dass deren Infrastruktur nie einen schlechten Tag hat, solange dein BTC gesperrt ist – und zwar auf einem Detail, das das Protokoll im Voraus nicht vorhersagen lässt.
$KOMA
Früher dachte ich, das Abschlachten sei Bablyons Art, Unehrlichkeit zu bestrafen. Das änderte sich um 2 Uhr nachts, als ich durch einen unabhängigen Security-Audit zur EOTS-Implementierung scrollte – also durch ein Dokument, das niemand öffnet, ohne einen Grund.
Der Mechanismus ist an sich elegant. Ein Finality-Provider verpflichtet sich, vor dem Signieren eines Blocks in einer bestimmten Höhe einen Zufallswert festzulegen. Signiere ihn einmal, es passiert nichts. Signiere ihn zweimal – mit zwei unterschiedlichen Nachrichten – und die Mathematik hinter Schnorr-Signaturen macht aus demselben Zufall den offengelegten privaten Schlüssel des Providers. Absichtliches Doppelsignieren wird dadurch konstruktionsbedingt selbstbestrafend, und dafür gibt es einen Grund: Ein Protokoll kann Signaturen lesen, nicht die Absicht. Deshalb kann eine Regel, die streng genug ist, um einen Angreifer zu erwischen, nicht zwischen einem Angreifer und einem Unfall unterscheiden.
Dieser Trade-off wurde im Audit als Problem markiert. Ein gezielter Angriff und ein ehrliches Failover eines Backup-Nodes, der zur gleichen Höhe anspringt, erzeugen exakt dasselbe Signaturmuster. Beide sehen für EOTS identisch aus. Beide werden auf die gleiche Weise bestraft: gekürzt, tombstoned, keine Wiederherstellung.
Das ist nicht nur Theorie. Hex Trust, ein institutioneller Verwahrer, der Finality-Provider-Infrastruktur auf Babylon betreibt, nennt konkrete Schutzmaßnahmen genau gegen dieses Szenario: keine Wiederverwendung privater Schlüssel auf unterschiedlichen Maschinen, manuelles Failover statt automatischem – weil automatisches Failover genau das erzeugen kann, was zwei aktive Signer für denselben Schlüssel gleichzeitig ermöglicht.
Hier kommt der Teil ohne saubere Antwort. Es gibt keinen öffentlichen Standard dafür, welche Failover-Konfiguration ein Provider betreibt. Man kann Provision, Uptime, Anzahl der Delegatoren prüfen. Aber nicht das – und nicht, bevor dein BTC bereits gesperrt ist.
Das Delegieren war nie nur eine Wette darauf, dass der Betreiber dich nicht angreift. Es ist auch eine Wette darauf, dass deren Infrastruktur nie einen schlechten Tag hat, solange dein BTC gesperrt ist – und zwar auf einem Detail, das das Protokoll im Voraus nicht vorhersagen lässt.
$KOMA
Verifiziert
$BABY $UAI $COTI #baby @BabylonLabs_io
Zuerst nahm ich an, dass der Covenant-Ausschuss ein „Bootstrap“-Schritt sei, etwas, das Babylon zurückziehen würde, sobald die eigene Roadmap gereift ist—so wie die meisten jungen Protokolle versprechen, sich zu ihrer eigenen Zeit zu dezentralisieren. Die Dokumentation sagt jedoch etwas Leiseres und Seltsameres als das.
Der Ausschuss existiert, weil Bitcoin selbst keine native Möglichkeit hat, Covernments durchzusetzen—keinen Opcode, der eine UTXO dazu zwingen kann, nur nach vorab vereinbarten Regeln ausgegeben zu werden. Deshalb hat Babylon eine 6-von-9-Multisig gebaut, um diese fehlende Funktion nachzubilden: es überwacht Staking-Anfragen, co-signiert Unbonding und Slashing und steht für eine Fähigkeit ein, die Bitcoin Script schlicht noch nicht hat. Dieser Teil ist ehrentechnisches Schließen einer realen Lücke, und die Vertrauensannahme ist tatsächlich leichter als bei einer normalen custodial Multisig—existenzielle Ehrlichkeit statt Mehrheits-Ehrlichkeit: Ein ehrlicher Signer reicht aus, um einen Diebstahl zu stoppen.
Was mich aufgehalten hat, war die Exit-Bedingung. Babylons eigene Dokumentation sagt nicht, dass der Ausschuss zurücktritt, sobald die Governance reift, oder sobald ein bestimmter TVL-Schwellenwert erreicht ist, oder sobald irgendein internes Meilenstein „ausliefert“. Sie sagt vielmehr, dass der Ausschuss bleibt, bis die Covenant-Funktionalität nativ in Bitcoin verfügbar wird—durch Opcodes wie OP-CAT oder OP-CTV, die Bitcoin Core nicht übernommen hat und für die es auch keinen verbindlichen Zeitplan für eine Übernahme gibt. Das Rückzugsdatum steht nicht auf Babylons Roadmap. Es steckt in einem Governance-Prozess eines anderen Protokolls—einem, bei dem Babylon keine Stimme hat und das es nicht beschleunigen kann.
Also verschwand das Vertrauen nicht, als Babylon es als ein „Bitcoin-gesichertes System“ bezeichnete. Es wanderte eine Ebene weiter weg: von einer Multisig mit definierter Mitgliedschaft hin auf einen Bitcoin-Softfork, der in dieser Dekade möglicherweise kommt oder auch nicht. Sechs von neun bekannte Signer ist zumindest eine Vertrauensannahme, die man benennen kann. Ein aufkommendes Opcode-Upgrade ohne Deadline ist eine Vertrauensannahme, auf die man nur warten kann.
Der Covenant-Ausschuss bleibt bestehen, bis Bitcoin Covenant-Opcodes hinzufügt. Keine Babylons-Timeline steuert das.
Dein Take? 👀
Zuerst nahm ich an, dass der Covenant-Ausschuss ein „Bootstrap“-Schritt sei, etwas, das Babylon zurückziehen würde, sobald die eigene Roadmap gereift ist—so wie die meisten jungen Protokolle versprechen, sich zu ihrer eigenen Zeit zu dezentralisieren. Die Dokumentation sagt jedoch etwas Leiseres und Seltsameres als das.
Der Ausschuss existiert, weil Bitcoin selbst keine native Möglichkeit hat, Covernments durchzusetzen—keinen Opcode, der eine UTXO dazu zwingen kann, nur nach vorab vereinbarten Regeln ausgegeben zu werden. Deshalb hat Babylon eine 6-von-9-Multisig gebaut, um diese fehlende Funktion nachzubilden: es überwacht Staking-Anfragen, co-signiert Unbonding und Slashing und steht für eine Fähigkeit ein, die Bitcoin Script schlicht noch nicht hat. Dieser Teil ist ehrentechnisches Schließen einer realen Lücke, und die Vertrauensannahme ist tatsächlich leichter als bei einer normalen custodial Multisig—existenzielle Ehrlichkeit statt Mehrheits-Ehrlichkeit: Ein ehrlicher Signer reicht aus, um einen Diebstahl zu stoppen.
Was mich aufgehalten hat, war die Exit-Bedingung. Babylons eigene Dokumentation sagt nicht, dass der Ausschuss zurücktritt, sobald die Governance reift, oder sobald ein bestimmter TVL-Schwellenwert erreicht ist, oder sobald irgendein internes Meilenstein „ausliefert“. Sie sagt vielmehr, dass der Ausschuss bleibt, bis die Covenant-Funktionalität nativ in Bitcoin verfügbar wird—durch Opcodes wie OP-CAT oder OP-CTV, die Bitcoin Core nicht übernommen hat und für die es auch keinen verbindlichen Zeitplan für eine Übernahme gibt. Das Rückzugsdatum steht nicht auf Babylons Roadmap. Es steckt in einem Governance-Prozess eines anderen Protokolls—einem, bei dem Babylon keine Stimme hat und das es nicht beschleunigen kann.
Also verschwand das Vertrauen nicht, als Babylon es als ein „Bitcoin-gesichertes System“ bezeichnete. Es wanderte eine Ebene weiter weg: von einer Multisig mit definierter Mitgliedschaft hin auf einen Bitcoin-Softfork, der in dieser Dekade möglicherweise kommt oder auch nicht. Sechs von neun bekannte Signer ist zumindest eine Vertrauensannahme, die man benennen kann. Ein aufkommendes Opcode-Upgrade ohne Deadline ist eine Vertrauensannahme, auf die man nur warten kann.
Der Covenant-Ausschuss bleibt bestehen, bis Bitcoin Covenant-Opcodes hinzufügt. Keine Babylons-Timeline steuert das.
Dein Take? 👀
Safest for now ✅
25%
Uncomfortable, but fair 😕
0%
🚩 Real red flag
75%
Didn’t know this🥱
0%
4 Stimmen • Abstimmung beendet
Als ich letzte Woche einen Finality-Provider auswählte, starrte ich auf eine Liste mit etwa 30 verifizierten Namen und ertappte mich dabei, wie ich auf den klicken wollte, der bereits die meisten Delegatoren hatte. Dieselbe Reflexbewegung, die einen großen Teil des Ethereum-Stakings in eine Lido-Story verwandelt hat.
Dann habe ich tatsächlich Babylons eigenes Staking-Guide gelesen.
Darin wird das Risiko direkt benannt: Die Delegation an die beliebtesten Provider erhöht das Risiko der Zentralisierung. Keine Beobachtung eines Kritikers – das steht in ihrer eigenen Dokumentation.
➡ Rund 30 Provider tragen im App eine verifizierte Prüfmarke.
➡ In dieser Liste ist nicht begrenzt, wie viel Delegation ein einzelner übernehmen kann.
Babylon gebührt Anerkennung dafür, dass sie das offen aussprechen; die meisten Staking-Produkte warnen den Endnutzer nie, bevor er klickt.
Das ist mir geblieben: Die Prüfmarke soll Vertrauen aufbauen. Aber wenn die meisten Staker standardmäßig auf den bereits verifizierten Namen setzen, der die meisten Delegatoren hat – genau das Muster, das Ethereum durchlebt hat, also das, was Vertrauen aufbauen sollte –, dann wird das Ganze zur Mechanik, die das zentrale Risiko bündelt, vor dem gewarnt wird.
Ich habe nach echten Kennzahlen zum Delegationsanteil gesucht – wie viel die Top-5- oder Top-10-Finality-Provider insgesamt kontrollieren. Öffentlich fand ich nichts. Ein eigener Beitrag einer Krypto-Börse zum Protokoll bezeichnete das als „bedarf noch weiterer Diskussion“, ein offenes Problem, das von einer externen Quelle markiert wurde – nicht etwas, das Babylon selbst in der Vergangenheit dokumentiert hat.
Ich habe meine Delegation auf drei kleinere Provider aufgeteilt, statt auf einen großen. In diesem Maßstab ist das wahrscheinlich eher ein symbolisches Zeichen als eine echte Lösung – und ich weiß das.
@BabylonLabs_io $BABY #baby $ON
„Würdest du absichtlich an einen kleineren Finality-Provider delegieren?“
Dann habe ich tatsächlich Babylons eigenes Staking-Guide gelesen.
Darin wird das Risiko direkt benannt: Die Delegation an die beliebtesten Provider erhöht das Risiko der Zentralisierung. Keine Beobachtung eines Kritikers – das steht in ihrer eigenen Dokumentation.
➡ Rund 30 Provider tragen im App eine verifizierte Prüfmarke.
➡ In dieser Liste ist nicht begrenzt, wie viel Delegation ein einzelner übernehmen kann.
Babylon gebührt Anerkennung dafür, dass sie das offen aussprechen; die meisten Staking-Produkte warnen den Endnutzer nie, bevor er klickt.
Das ist mir geblieben: Die Prüfmarke soll Vertrauen aufbauen. Aber wenn die meisten Staker standardmäßig auf den bereits verifizierten Namen setzen, der die meisten Delegatoren hat – genau das Muster, das Ethereum durchlebt hat, also das, was Vertrauen aufbauen sollte –, dann wird das Ganze zur Mechanik, die das zentrale Risiko bündelt, vor dem gewarnt wird.
Ich habe nach echten Kennzahlen zum Delegationsanteil gesucht – wie viel die Top-5- oder Top-10-Finality-Provider insgesamt kontrollieren. Öffentlich fand ich nichts. Ein eigener Beitrag einer Krypto-Börse zum Protokoll bezeichnete das als „bedarf noch weiterer Diskussion“, ein offenes Problem, das von einer externen Quelle markiert wurde – nicht etwas, das Babylon selbst in der Vergangenheit dokumentiert hat.
Ich habe meine Delegation auf drei kleinere Provider aufgeteilt, statt auf einen großen. In diesem Maßstab ist das wahrscheinlich eher ein symbolisches Zeichen als eine echte Lösung – und ich weiß das.
@BabylonLabs_io $BABY #baby $ON
„Würdest du absichtlich an einen kleineren Finality-Provider delegieren?“
🔀 Yes, spread it out
0%
🛡️ No, biggest is safest
0%
💰 Depends on commission
0%
🤷 Never thought about it
100%
1 Stimmen • Abstimmung beendet
#baby @BabylonLabs_io
Beinahe hätte ich letzte Woche eine kleine Menge BTC in eine vault-gestützte Kreditposition gesteckt. Bevor ich es tat, wollte ich eine Sache wissen: Wenn sich der Markt schnell gegen mich bewegt, was entscheidet dann tatsächlich darüber, wann ich liquidiert werde? Diese Frage hat mich dazu gebracht, jenseits des Marketings auf Babylons eigene Seite zu schauen — dorthin, wo das Wort „trustless“ nicht mehr wirklich zutrifft. Es war nicht versteckt. Es überlebt einfach nicht die Übersetzung in jede Schlagzeile, die um genau dieses eine Wort herum gebaut ist. ➡ Auf der eigenen Learn-Seite von Babylon steht ganz offen, dass das echte Risiko auf der DeFi-Seite sitzt, nicht im Vault selbst, und Liquidation im Lending als Beispiel nennt. ➡ Das Whitepaper untermauert das: Liquidation erfordert eine Signatur eines Preis-Orakels, das als separate Abhängigkeit vom Kern-Design des Vaults behandelt wird. Gebt Babylon Anerkennung — sie haben das selbst so aufgeschrieben. Niemand musste es ihnen aus den Tiefen herauskramen. Hier ist der Teil, der mir besonders hängen blieb — der Teil, der tatsächlich beeinflusst hat, wie viel ich gleich einzahlen wollte. „Ein Preis-Orakel“ klingt abstrakt, bis ein Bericht über genau dieses System die Netzwerke nennt, die diese Beziehung mit Babylon tatsächlich herstellen: Band Protocol und Pyth — dieselben generalistischen Netzwerke, die Dutzende anderer Chains gleichzeitig bepreisen. Babylons eigene Materialien nennen sie nicht direkt, also behandle diese konkrete Kombination als berichtet, nicht als von Babylon selbst bestätigt. Wenn einer dieser Feeds bei einer schnellen Bewegung verspätet oder falsch ist, löst meine Liquidation trotzdem genau so aus, wie es programmiert ist. Richtig: Handeln auf Basis falscher Informationen. Die Bitcoin-Basisschicht hat in diesem Ausgang kein Mitspracherecht. Der Vault macht genau das, was er versprochen hat. Das Orakel liefert ihm nur etwas Falsches. Das ist kein Versagen des Vaults. Das ist DeFi-Risiko, das ein „trustless“-Label trägt und übernimmt, welche Ausfallhistorie sein konkreter Preisfeed bereits von anderen Chains mitbringt — Chains, die ich nicht einmal nutze. Ich habe die Einzahlung trotzdem gemacht. Nur kleiner, als ich es noch vor einer Stunde getan hätte. Trustless beschreibt, was mit deinem BTC passiert. Es war nie ein Versprechen dafür, was mit deinem Geld passiert, sobald es den Vault verlässt.
$BROCCOLIF3B $ON $BABY
Beinahe hätte ich letzte Woche eine kleine Menge BTC in eine vault-gestützte Kreditposition gesteckt. Bevor ich es tat, wollte ich eine Sache wissen: Wenn sich der Markt schnell gegen mich bewegt, was entscheidet dann tatsächlich darüber, wann ich liquidiert werde? Diese Frage hat mich dazu gebracht, jenseits des Marketings auf Babylons eigene Seite zu schauen — dorthin, wo das Wort „trustless“ nicht mehr wirklich zutrifft. Es war nicht versteckt. Es überlebt einfach nicht die Übersetzung in jede Schlagzeile, die um genau dieses eine Wort herum gebaut ist. ➡ Auf der eigenen Learn-Seite von Babylon steht ganz offen, dass das echte Risiko auf der DeFi-Seite sitzt, nicht im Vault selbst, und Liquidation im Lending als Beispiel nennt. ➡ Das Whitepaper untermauert das: Liquidation erfordert eine Signatur eines Preis-Orakels, das als separate Abhängigkeit vom Kern-Design des Vaults behandelt wird. Gebt Babylon Anerkennung — sie haben das selbst so aufgeschrieben. Niemand musste es ihnen aus den Tiefen herauskramen. Hier ist der Teil, der mir besonders hängen blieb — der Teil, der tatsächlich beeinflusst hat, wie viel ich gleich einzahlen wollte. „Ein Preis-Orakel“ klingt abstrakt, bis ein Bericht über genau dieses System die Netzwerke nennt, die diese Beziehung mit Babylon tatsächlich herstellen: Band Protocol und Pyth — dieselben generalistischen Netzwerke, die Dutzende anderer Chains gleichzeitig bepreisen. Babylons eigene Materialien nennen sie nicht direkt, also behandle diese konkrete Kombination als berichtet, nicht als von Babylon selbst bestätigt. Wenn einer dieser Feeds bei einer schnellen Bewegung verspätet oder falsch ist, löst meine Liquidation trotzdem genau so aus, wie es programmiert ist. Richtig: Handeln auf Basis falscher Informationen. Die Bitcoin-Basisschicht hat in diesem Ausgang kein Mitspracherecht. Der Vault macht genau das, was er versprochen hat. Das Orakel liefert ihm nur etwas Falsches. Das ist kein Versagen des Vaults. Das ist DeFi-Risiko, das ein „trustless“-Label trägt und übernimmt, welche Ausfallhistorie sein konkreter Preisfeed bereits von anderen Chains mitbringt — Chains, die ich nicht einmal nutze. Ich habe die Einzahlung trotzdem gemacht. Nur kleiner, als ich es noch vor einer Stunde getan hätte. Trustless beschreibt, was mit deinem BTC passiert. Es war nie ein Versprechen dafür, was mit deinem Geld passiert, sobald es den Vault verlässt.
$BROCCOLIF3B $ON $BABY
✅ Bitcoin security
0%
📈 Oracle accuracy
0%
⚖️ Both equally
0%
❓Depends on the protocol
0%
0 Stimmen • Abstimmung beendet
Teilweise korrekt
#baby $BABY @BabylonLabs_io
Fast hätte ich letzte Woche eine kleine Menge BTC in eine schuldenbasierte Position gesteckt, die durch einen Tresor abgesichert ist. Bevor ich das tat, wollte ich nur wissen, eine Sache: Wenn sich der Markt schnell gegen mich bewegt, was entscheidet dann eigentlich darüber, wann ich liquidiert werde?
Diese Frage hat mich dazu gebracht, über das Marketing hinaus auf die eigene Website von Babylon zu schauen — dorthin, wo das Wort „trustless“ (vertrauenslos) offenbar aufhört, zuzutreffen.
Es war nicht versteckt. Es überlebt nur nicht die Übersetzung in jede Schlagzeile, die um genau dieses eine Wort herum gebaut wird.
➡ Babylons eigene Learn-Seite sagt ganz offen, dass das eigentliche Risiko auf der DeFi-Seite sitzt — nicht im Tresor selbst — und nennt Liquidationen im Lending als Beispiel.
➡ Das Whitepaper bestätigt das: Für Liquidationen braucht es eine Signatur von einem Price-Oracle (Preisorakel), das als separate Abhängigkeit von Babylons Kerndesign behandelt wird.
Gibt Babylon die Anerkennung — sie haben das selbst so aufgeschrieben. Niemand musste es ihnen erst aus den Tiefen herauskramen.
Der Teil, der bei mir hängen blieb, der Teil, der tatsächlich beeinflusst hat, wie viel ich gleich einzahlen wollte: „Ein Preisorakel“ klingt abstrakt, bis ein einziger Bericht zu genau diesem System die Netzwerke benennt, die diese Beziehung mit Babylon tatsächlich abbilden: Band Protocol und Pyth — dieselben allgemeinen Preis-Netzwerke, die Dutzende anderer Chains gleichzeitig bepreisen. Babylons eigenes Material nennt sie nicht direkt, also behandle diese konkrete Kombination als berichtet, nicht als durch Babylon selbst bestätigt.
Wenn einer dieser Feeds bei einer schnellen Bewegung zu spät oder falsch ist, triggert meine Liquidation trotzdem exakt so, wie sie programmiert ist. Korrekt handelnd — auf Basis von schlechten Informationen. Die Bitcoin-Basisschicht bekommt in dieser Entscheidung keine Stimme. Der Tresor macht genau das, was er versprochen hat. Das Orakel liefert ihm nur etwas Falsches.
Das ist kein Versagen des Tresors. Das ist DeFi-Risiko, das eine trustless-Label trägt und sich das gesamte Ausfall-/Outage-History-Kapital mitnimmt, das sein tatsächlicher Preis-Feed bereits aus anderen Chains mitbringt — Chains, die ich nicht einmal nutze.
Ich habe die Einzahlung trotzdem gemacht. Nur kleiner, als ich es noch vor einer Stunde getan hätte.
Trustless beschreibt, was mit deinem BTC passiert. Es war nie ein Versprechen darüber, was mit deinem Geld passiert, sobald es den Tresor verlässt.
$EUL
Kann ein trustless Tresor noch auf Oracles angewiesen sein?
Fast hätte ich letzte Woche eine kleine Menge BTC in eine schuldenbasierte Position gesteckt, die durch einen Tresor abgesichert ist. Bevor ich das tat, wollte ich nur wissen, eine Sache: Wenn sich der Markt schnell gegen mich bewegt, was entscheidet dann eigentlich darüber, wann ich liquidiert werde?
Diese Frage hat mich dazu gebracht, über das Marketing hinaus auf die eigene Website von Babylon zu schauen — dorthin, wo das Wort „trustless“ (vertrauenslos) offenbar aufhört, zuzutreffen.
Es war nicht versteckt. Es überlebt nur nicht die Übersetzung in jede Schlagzeile, die um genau dieses eine Wort herum gebaut wird.
➡ Babylons eigene Learn-Seite sagt ganz offen, dass das eigentliche Risiko auf der DeFi-Seite sitzt — nicht im Tresor selbst — und nennt Liquidationen im Lending als Beispiel.
➡ Das Whitepaper bestätigt das: Für Liquidationen braucht es eine Signatur von einem Price-Oracle (Preisorakel), das als separate Abhängigkeit von Babylons Kerndesign behandelt wird.
Gibt Babylon die Anerkennung — sie haben das selbst so aufgeschrieben. Niemand musste es ihnen erst aus den Tiefen herauskramen.
Der Teil, der bei mir hängen blieb, der Teil, der tatsächlich beeinflusst hat, wie viel ich gleich einzahlen wollte: „Ein Preisorakel“ klingt abstrakt, bis ein einziger Bericht zu genau diesem System die Netzwerke benennt, die diese Beziehung mit Babylon tatsächlich abbilden: Band Protocol und Pyth — dieselben allgemeinen Preis-Netzwerke, die Dutzende anderer Chains gleichzeitig bepreisen. Babylons eigenes Material nennt sie nicht direkt, also behandle diese konkrete Kombination als berichtet, nicht als durch Babylon selbst bestätigt.
Wenn einer dieser Feeds bei einer schnellen Bewegung zu spät oder falsch ist, triggert meine Liquidation trotzdem exakt so, wie sie programmiert ist. Korrekt handelnd — auf Basis von schlechten Informationen. Die Bitcoin-Basisschicht bekommt in dieser Entscheidung keine Stimme. Der Tresor macht genau das, was er versprochen hat. Das Orakel liefert ihm nur etwas Falsches.
Das ist kein Versagen des Tresors. Das ist DeFi-Risiko, das eine trustless-Label trägt und sich das gesamte Ausfall-/Outage-History-Kapital mitnimmt, das sein tatsächlicher Preis-Feed bereits aus anderen Chains mitbringt — Chains, die ich nicht einmal nutze.
Ich habe die Einzahlung trotzdem gemacht. Nur kleiner, als ich es noch vor einer Stunde getan hätte.
Trustless beschreibt, was mit deinem BTC passiert. Es war nie ein Versprechen darüber, was mit deinem Geld passiert, sobald es den Tresor verlässt.
$EUL
Kann ein trustless Tresor noch auf Oracles angewiesen sein?
✅ Yes, already knew
0%
🤯 No,I asumed it covered both
0%
0 Stimmen • Abstimmung beendet
⚡✨
Nova_eth_20
·
--
#baby $BABY @BabylonLabs_io
Ich konnte letzte Nacht nicht schlafen, also habe ich drei separate Ausarbeitungen zur Aave-Temp-Check-Seite von Babylon nebeneinander geöffnet – mehr aus Gewohnheit als aus einem bestimmten Grund.
Ein Wort hat mich einfach nicht losgelassen.
Bitcoin.com, Cointribune und LiveBitcoinNews beschreiben den TBV-Liquidationsablauf alle auf dieselbe Weise. Ein permissionless Liquidator tauscht eine beschlagnahmte Vault sofort gegen WBTC – zu einem kleinen Aufschlag. Eine separate Gruppe von „permissionierten Arbitrageuren“ kauft dann diese Position und löst das echte BTC später ein, nach dem Zeitplan von Bitcoin selbst.
Geben wir Babylon für die erste Hälfte recht: Die permissionless-Liquidation funktioniert genau so, wie es beworben wird.
Es ist die zweite Hälfte, in der ich weiter zurückgeschaut habe als der Aave-Vorschlag. Babylons eigenes August-Whitepaper zu Trustless Bitcoin Vaults sagt nie „permissioned“ – es heißt dort, dass Liquidationen über „whitelisted liquidators“ laufen, die den Preis und den Vault-Status überwachen. Anderes Wort, gleiche Form. Ein unabhängiger Analyst, der auf X Nachrichten mit Babylons Team ausgetauscht hat, brachte denselben Punkt direkt bei ihnen an: Genug dieser whitelisted Parteien, die sich korrekt verhalten, ist eine Vertrauensannahme, die das Marketing nicht erwähnt.
Also war das Wort am Ende zutreffend. Die eigentliche Frage ist, warum diese Rolle überhaupt eingeschränkt sein muss, wenn die WBTC-Tausch-Seite es nicht ist. BItcoins Skriptsprache kann keinen beliebigen Off-Chain-Status auswerten. BitVM3 löst das, indem es einen Zero-Knowledge-Proof-Verifizierer in einen garbled circuit einbettet, aber jemand muss diesen Proof immer noch erzeugen und einreichen, um die Redemption auszulösen. Die WBTC-Tausch-Seite ist leicht permissionless zu lassen – jeder Liquidator mit Kapital kann den Trade machen. Proof-Einreichung ist das schwierigere Problem, das BitVM3 bisher noch nicht gelöst hat.
Das ist keine Frage, ob die Vault vertrauenslos ist. Babylon hat die Whitelist in seinem eigenen Whitepaper nicht versteckt. Trustlessness verschwindet hier nicht. Sie endet nur eine Stufe früher, als es der Großteil der Berichterstattung glauben macht.
$EUL
Was definiert eine wirklich vertrauenslose BTC-Vault?
Ich konnte letzte Nacht nicht schlafen, also habe ich drei separate Ausarbeitungen zur Aave-Temp-Check-Seite von Babylon nebeneinander geöffnet – mehr aus Gewohnheit als aus einem bestimmten Grund.
Ein Wort hat mich einfach nicht losgelassen.
Bitcoin.com, Cointribune und LiveBitcoinNews beschreiben den TBV-Liquidationsablauf alle auf dieselbe Weise. Ein permissionless Liquidator tauscht eine beschlagnahmte Vault sofort gegen WBTC – zu einem kleinen Aufschlag. Eine separate Gruppe von „permissionierten Arbitrageuren“ kauft dann diese Position und löst das echte BTC später ein, nach dem Zeitplan von Bitcoin selbst.
Geben wir Babylon für die erste Hälfte recht: Die permissionless-Liquidation funktioniert genau so, wie es beworben wird.
Es ist die zweite Hälfte, in der ich weiter zurückgeschaut habe als der Aave-Vorschlag. Babylons eigenes August-Whitepaper zu Trustless Bitcoin Vaults sagt nie „permissioned“ – es heißt dort, dass Liquidationen über „whitelisted liquidators“ laufen, die den Preis und den Vault-Status überwachen. Anderes Wort, gleiche Form. Ein unabhängiger Analyst, der auf X Nachrichten mit Babylons Team ausgetauscht hat, brachte denselben Punkt direkt bei ihnen an: Genug dieser whitelisted Parteien, die sich korrekt verhalten, ist eine Vertrauensannahme, die das Marketing nicht erwähnt.
Also war das Wort am Ende zutreffend. Die eigentliche Frage ist, warum diese Rolle überhaupt eingeschränkt sein muss, wenn die WBTC-Tausch-Seite es nicht ist. BItcoins Skriptsprache kann keinen beliebigen Off-Chain-Status auswerten. BitVM3 löst das, indem es einen Zero-Knowledge-Proof-Verifizierer in einen garbled circuit einbettet, aber jemand muss diesen Proof immer noch erzeugen und einreichen, um die Redemption auszulösen. Die WBTC-Tausch-Seite ist leicht permissionless zu lassen – jeder Liquidator mit Kapital kann den Trade machen. Proof-Einreichung ist das schwierigere Problem, das BitVM3 bisher noch nicht gelöst hat.
Das ist keine Frage, ob die Vault vertrauenslos ist. Babylon hat die Whitelist in seinem eigenen Whitepaper nicht versteckt. Trustlessness verschwindet hier nicht. Sie endet nur eine Stufe früher, als es der Großteil der Berichterstattung glauben macht.
$EUL
Was definiert eine wirklich vertrauenslose BTC-Vault?
$EUL $CHILLGUY Goooo
und gib mir Feedback
und gib mir Feedback
Nova_eth_20
·
--
#baby $BABY @BabylonLabs_io
Ich konnte letzte Nacht nicht schlafen, also habe ich drei separate Ausarbeitungen zur Aave-Temp-Check-Seite von Babylon nebeneinander geöffnet – mehr aus Gewohnheit als aus einem bestimmten Grund.
Ein Wort hat mich einfach nicht losgelassen.
Bitcoin.com, Cointribune und LiveBitcoinNews beschreiben den TBV-Liquidationsablauf alle auf dieselbe Weise. Ein permissionless Liquidator tauscht eine beschlagnahmte Vault sofort gegen WBTC – zu einem kleinen Aufschlag. Eine separate Gruppe von „permissionierten Arbitrageuren“ kauft dann diese Position und löst das echte BTC später ein, nach dem Zeitplan von Bitcoin selbst.
Geben wir Babylon für die erste Hälfte recht: Die permissionless-Liquidation funktioniert genau so, wie es beworben wird.
Es ist die zweite Hälfte, in der ich weiter zurückgeschaut habe als der Aave-Vorschlag. Babylons eigenes August-Whitepaper zu Trustless Bitcoin Vaults sagt nie „permissioned“ – es heißt dort, dass Liquidationen über „whitelisted liquidators“ laufen, die den Preis und den Vault-Status überwachen. Anderes Wort, gleiche Form. Ein unabhängiger Analyst, der auf X Nachrichten mit Babylons Team ausgetauscht hat, brachte denselben Punkt direkt bei ihnen an: Genug dieser whitelisted Parteien, die sich korrekt verhalten, ist eine Vertrauensannahme, die das Marketing nicht erwähnt.
Also war das Wort am Ende zutreffend. Die eigentliche Frage ist, warum diese Rolle überhaupt eingeschränkt sein muss, wenn die WBTC-Tausch-Seite es nicht ist. BItcoins Skriptsprache kann keinen beliebigen Off-Chain-Status auswerten. BitVM3 löst das, indem es einen Zero-Knowledge-Proof-Verifizierer in einen garbled circuit einbettet, aber jemand muss diesen Proof immer noch erzeugen und einreichen, um die Redemption auszulösen. Die WBTC-Tausch-Seite ist leicht permissionless zu lassen – jeder Liquidator mit Kapital kann den Trade machen. Proof-Einreichung ist das schwierigere Problem, das BitVM3 bisher noch nicht gelöst hat.
Das ist keine Frage, ob die Vault vertrauenslos ist. Babylon hat die Whitelist in seinem eigenen Whitepaper nicht versteckt. Trustlessness verschwindet hier nicht. Sie endet nur eine Stufe früher, als es der Großteil der Berichterstattung glauben macht.
$EUL
Was definiert eine wirklich vertrauenslose BTC-Vault?
Ich konnte letzte Nacht nicht schlafen, also habe ich drei separate Ausarbeitungen zur Aave-Temp-Check-Seite von Babylon nebeneinander geöffnet – mehr aus Gewohnheit als aus einem bestimmten Grund.
Ein Wort hat mich einfach nicht losgelassen.
Bitcoin.com, Cointribune und LiveBitcoinNews beschreiben den TBV-Liquidationsablauf alle auf dieselbe Weise. Ein permissionless Liquidator tauscht eine beschlagnahmte Vault sofort gegen WBTC – zu einem kleinen Aufschlag. Eine separate Gruppe von „permissionierten Arbitrageuren“ kauft dann diese Position und löst das echte BTC später ein, nach dem Zeitplan von Bitcoin selbst.
Geben wir Babylon für die erste Hälfte recht: Die permissionless-Liquidation funktioniert genau so, wie es beworben wird.
Es ist die zweite Hälfte, in der ich weiter zurückgeschaut habe als der Aave-Vorschlag. Babylons eigenes August-Whitepaper zu Trustless Bitcoin Vaults sagt nie „permissioned“ – es heißt dort, dass Liquidationen über „whitelisted liquidators“ laufen, die den Preis und den Vault-Status überwachen. Anderes Wort, gleiche Form. Ein unabhängiger Analyst, der auf X Nachrichten mit Babylons Team ausgetauscht hat, brachte denselben Punkt direkt bei ihnen an: Genug dieser whitelisted Parteien, die sich korrekt verhalten, ist eine Vertrauensannahme, die das Marketing nicht erwähnt.
Also war das Wort am Ende zutreffend. Die eigentliche Frage ist, warum diese Rolle überhaupt eingeschränkt sein muss, wenn die WBTC-Tausch-Seite es nicht ist. BItcoins Skriptsprache kann keinen beliebigen Off-Chain-Status auswerten. BitVM3 löst das, indem es einen Zero-Knowledge-Proof-Verifizierer in einen garbled circuit einbettet, aber jemand muss diesen Proof immer noch erzeugen und einreichen, um die Redemption auszulösen. Die WBTC-Tausch-Seite ist leicht permissionless zu lassen – jeder Liquidator mit Kapital kann den Trade machen. Proof-Einreichung ist das schwierigere Problem, das BitVM3 bisher noch nicht gelöst hat.
Das ist keine Frage, ob die Vault vertrauenslos ist. Babylon hat die Whitelist in seinem eigenen Whitepaper nicht versteckt. Trustlessness verschwindet hier nicht. Sie endet nur eine Stufe früher, als es der Großteil der Berichterstattung glauben macht.
$EUL
Was definiert eine wirklich vertrauenslose BTC-Vault?
#baby $BABY @BabylonLabs_io
Ich konnte letzte Nacht nicht schlafen, also habe ich drei separate Ausarbeitungen zur Aave-Temp-Check-Seite von Babylon nebeneinander geöffnet – mehr aus Gewohnheit als aus einem bestimmten Grund.
Ein Wort hat mich einfach nicht losgelassen.
Bitcoin.com, Cointribune und LiveBitcoinNews beschreiben den TBV-Liquidationsablauf alle auf dieselbe Weise. Ein permissionless Liquidator tauscht eine beschlagnahmte Vault sofort gegen WBTC – zu einem kleinen Aufschlag. Eine separate Gruppe von „permissionierten Arbitrageuren“ kauft dann diese Position und löst das echte BTC später ein, nach dem Zeitplan von Bitcoin selbst.
Geben wir Babylon für die erste Hälfte recht: Die permissionless-Liquidation funktioniert genau so, wie es beworben wird.
Es ist die zweite Hälfte, in der ich weiter zurückgeschaut habe als der Aave-Vorschlag. Babylons eigenes August-Whitepaper zu Trustless Bitcoin Vaults sagt nie „permissioned“ – es heißt dort, dass Liquidationen über „whitelisted liquidators“ laufen, die den Preis und den Vault-Status überwachen. Anderes Wort, gleiche Form. Ein unabhängiger Analyst, der auf X Nachrichten mit Babylons Team ausgetauscht hat, brachte denselben Punkt direkt bei ihnen an: Genug dieser whitelisted Parteien, die sich korrekt verhalten, ist eine Vertrauensannahme, die das Marketing nicht erwähnt.
Also war das Wort am Ende zutreffend. Die eigentliche Frage ist, warum diese Rolle überhaupt eingeschränkt sein muss, wenn die WBTC-Tausch-Seite es nicht ist. BItcoins Skriptsprache kann keinen beliebigen Off-Chain-Status auswerten. BitVM3 löst das, indem es einen Zero-Knowledge-Proof-Verifizierer in einen garbled circuit einbettet, aber jemand muss diesen Proof immer noch erzeugen und einreichen, um die Redemption auszulösen. Die WBTC-Tausch-Seite ist leicht permissionless zu lassen – jeder Liquidator mit Kapital kann den Trade machen. Proof-Einreichung ist das schwierigere Problem, das BitVM3 bisher noch nicht gelöst hat.
Das ist keine Frage, ob die Vault vertrauenslos ist. Babylon hat die Whitelist in seinem eigenen Whitepaper nicht versteckt. Trustlessness verschwindet hier nicht. Sie endet nur eine Stufe früher, als es der Großteil der Berichterstattung glauben macht.
$EUL
Was definiert eine wirklich vertrauenslose BTC-Vault?
Ich konnte letzte Nacht nicht schlafen, also habe ich drei separate Ausarbeitungen zur Aave-Temp-Check-Seite von Babylon nebeneinander geöffnet – mehr aus Gewohnheit als aus einem bestimmten Grund.
Ein Wort hat mich einfach nicht losgelassen.
Bitcoin.com, Cointribune und LiveBitcoinNews beschreiben den TBV-Liquidationsablauf alle auf dieselbe Weise. Ein permissionless Liquidator tauscht eine beschlagnahmte Vault sofort gegen WBTC – zu einem kleinen Aufschlag. Eine separate Gruppe von „permissionierten Arbitrageuren“ kauft dann diese Position und löst das echte BTC später ein, nach dem Zeitplan von Bitcoin selbst.
Geben wir Babylon für die erste Hälfte recht: Die permissionless-Liquidation funktioniert genau so, wie es beworben wird.
Es ist die zweite Hälfte, in der ich weiter zurückgeschaut habe als der Aave-Vorschlag. Babylons eigenes August-Whitepaper zu Trustless Bitcoin Vaults sagt nie „permissioned“ – es heißt dort, dass Liquidationen über „whitelisted liquidators“ laufen, die den Preis und den Vault-Status überwachen. Anderes Wort, gleiche Form. Ein unabhängiger Analyst, der auf X Nachrichten mit Babylons Team ausgetauscht hat, brachte denselben Punkt direkt bei ihnen an: Genug dieser whitelisted Parteien, die sich korrekt verhalten, ist eine Vertrauensannahme, die das Marketing nicht erwähnt.
Also war das Wort am Ende zutreffend. Die eigentliche Frage ist, warum diese Rolle überhaupt eingeschränkt sein muss, wenn die WBTC-Tausch-Seite es nicht ist. BItcoins Skriptsprache kann keinen beliebigen Off-Chain-Status auswerten. BitVM3 löst das, indem es einen Zero-Knowledge-Proof-Verifizierer in einen garbled circuit einbettet, aber jemand muss diesen Proof immer noch erzeugen und einreichen, um die Redemption auszulösen. Die WBTC-Tausch-Seite ist leicht permissionless zu lassen – jeder Liquidator mit Kapital kann den Trade machen. Proof-Einreichung ist das schwierigere Problem, das BitVM3 bisher noch nicht gelöst hat.
Das ist keine Frage, ob die Vault vertrauenslos ist. Babylon hat die Whitelist in seinem eigenen Whitepaper nicht versteckt. Trustlessness verschwindet hier nicht. Sie endet nur eine Stufe früher, als es der Großteil der Berichterstattung glauben macht.
$EUL
Was definiert eine wirklich vertrauenslose BTC-Vault?
⚡ Permissionless liquidation
100%
🔓 Permissionless redemption
0%
🤔 Not sure yet
0%
⚖️ Both are equally important
0%
1 Stimmen • Abstimmung beendet
Beitreten
英鸿³³₇
·
--
[Wiederholung] 🎙️ Lass uns über die Liebe und den Hass im Primärmarkt sprechen, und über das DCA-Investieren in BNB im Sekundärmarkt
02 h 17 m 48 s · 12.8k Zuhörer
$DEXE Goooooo 👉🏻
Mù 穆涵
·
--
#baby $BABY @BabylonLabs_io
gwei Pools desselben Assets, die ein paar Klicks auseinanderliegen und bis jetzt keinerlei Verbindung zueinander hatten. Aave hält ungefähr 5 Mrd. $ in WBTC, das auf der Borrow-Seite kaum bewegt wird. Babylon hält 4 Mrd. $+ an gestaktem BTC und verdient nichts zusätzlich über die Staking Rewards hinaus.
Das ist der konkrete Pitch, der in Babylons Temp Check steckt — nicht „trustless BTC“, sondern das Abgleichen von brachliegendem Angebot auf einer Plattform mit brachliegender Sicherheit auf einer anderen.
Aaves Hub-and-Spoke-Design in V4 ist das, was es möglich macht, ohne dass Babylon überhaupt in Aaves Kern-Lending-Pool eingreifen muss. Zwei neue Spokes werden als isolierte Module bereitgestellt — Babylon besitzt die Logik für die BTC-Sicherheit, und Aaves Haupt-Hub bleibt unberührt von welchem Risiko auch immer, das diese Einführung mit sich bringt.
Es lohnt sich zu erwähnen: Das ist kein Community-Vorschlag, der unbemerkt herumliegt. Aaves eigener Gründer hat es öffentlich unterstützt und dabei die Spoke-Implementierung explizit als neues Muster für V4 bezeichnet — nicht nur als weitere Asset-Listung.
Das ist noch immer die Temp-Check-Phase. Ein ARFC und eine On-Chain-Abstimmung müssen beide passieren, bevor überhaupt echtes BTC durch diesen Prozess bewegt wird.
Wenn beide Pools nach der Freigabe durch die Governance noch immer ein paar Monate lang untätig dasitzen, lag das Problem nie in der Verkabelung. Es lag am Appetit.
$DEXE
Was ist am wichtigsten, wenn das live geht?
gwei Pools desselben Assets, die ein paar Klicks auseinanderliegen und bis jetzt keinerlei Verbindung zueinander hatten. Aave hält ungefähr 5 Mrd. $ in WBTC, das auf der Borrow-Seite kaum bewegt wird. Babylon hält 4 Mrd. $+ an gestaktem BTC und verdient nichts zusätzlich über die Staking Rewards hinaus.
Das ist der konkrete Pitch, der in Babylons Temp Check steckt — nicht „trustless BTC“, sondern das Abgleichen von brachliegendem Angebot auf einer Plattform mit brachliegender Sicherheit auf einer anderen.
Aaves Hub-and-Spoke-Design in V4 ist das, was es möglich macht, ohne dass Babylon überhaupt in Aaves Kern-Lending-Pool eingreifen muss. Zwei neue Spokes werden als isolierte Module bereitgestellt — Babylon besitzt die Logik für die BTC-Sicherheit, und Aaves Haupt-Hub bleibt unberührt von welchem Risiko auch immer, das diese Einführung mit sich bringt.
Es lohnt sich zu erwähnen: Das ist kein Community-Vorschlag, der unbemerkt herumliegt. Aaves eigener Gründer hat es öffentlich unterstützt und dabei die Spoke-Implementierung explizit als neues Muster für V4 bezeichnet — nicht nur als weitere Asset-Listung.
Das ist noch immer die Temp-Check-Phase. Ein ARFC und eine On-Chain-Abstimmung müssen beide passieren, bevor überhaupt echtes BTC durch diesen Prozess bewegt wird.
Wenn beide Pools nach der Freigabe durch die Governance noch immer ein paar Monate lang untätig dasitzen, lag das Problem nie in der Verkabelung. Es lag am Appetit.
$DEXE
Was ist am wichtigsten, wenn das live geht?
Teilweise korrekt
#baby $BABY @BabylonLabs_io
Ich habe gestern Nacht aus Langeweile durch Aaves v3-zu-v4-Migrationsnotizen gelesen, und eine Zeile aus Babylons eigener Vault-Paper ist mir hängen geblieben, nachdem ich die Registerkarte geschlossen hatte: Die Ausgabebedingungen eines TBV-Vaults, inklusive des Zielvertrags, sind im Moment seiner Erstellung festgelegt. Das ist buchstäblich das, was es trustless macht: Niemand kann die BTC später umleiten, ohne diesen zuvor vereinbarten Pfad. Was das still bedeutet, ist: Wenn Aave jemals wieder Verträge migriert – so wie es gerade von v3 nach v4 gemacht hat –, dann kann ein bestehender Vault nicht einfach folgen. Er muss sich nach dem eigenen Zeitplan von Bitcoin auflösen und neu erstellt werden, sodass er auf das neue Ziel zeigt, jedes Mal, wenn das Zielprotokoll ein Upgrade bekommt. Trustlessness ist hier nicht gratis – man tauscht sie gegen Starrheit, und niemand kalkuliert das wirklich ein. Ich konnte keine öffentlichen Details finden, ob Babylon oder Aave Tools geplant haben, um diese Übergänge reibungsloser zu machen. Das geht nicht darum, wie sicher ein Vault an dem Tag aussieht, an dem du ihn erstellst, sondern darum, was passiert, an dem Tag die andere Seite sich ändern muss.
$DEXE
Was ist hier der größere Trade-off?
Ich habe gestern Nacht aus Langeweile durch Aaves v3-zu-v4-Migrationsnotizen gelesen, und eine Zeile aus Babylons eigener Vault-Paper ist mir hängen geblieben, nachdem ich die Registerkarte geschlossen hatte: Die Ausgabebedingungen eines TBV-Vaults, inklusive des Zielvertrags, sind im Moment seiner Erstellung festgelegt. Das ist buchstäblich das, was es trustless macht: Niemand kann die BTC später umleiten, ohne diesen zuvor vereinbarten Pfad. Was das still bedeutet, ist: Wenn Aave jemals wieder Verträge migriert – so wie es gerade von v3 nach v4 gemacht hat –, dann kann ein bestehender Vault nicht einfach folgen. Er muss sich nach dem eigenen Zeitplan von Bitcoin auflösen und neu erstellt werden, sodass er auf das neue Ziel zeigt, jedes Mal, wenn das Zielprotokoll ein Upgrade bekommt. Trustlessness ist hier nicht gratis – man tauscht sie gegen Starrheit, und niemand kalkuliert das wirklich ein. Ich konnte keine öffentlichen Details finden, ob Babylon oder Aave Tools geplant haben, um diese Übergänge reibungsloser zu machen. Das geht nicht darum, wie sicher ein Vault an dem Tag aussieht, an dem du ihn erstellst, sondern darum, was passiert, an dem Tag die andere Seite sich ändern muss.
$DEXE
Was ist hier der größere Trade-off?
🔒 Stronger security
33%
🔄 Easier upgrades
0%
⚖️ Need both
0%
🤔 Still researching
67%
6 Stimmen • Abstimmung beendet
Anmelden und weiter Inhalte entdecken