MICHAEL MOORE

Ich habe die Einladung zu CreatorPad am 16. Oktober erhalten und bin Binance Square für das Vertrauen dankbar. Ich wollte diesen Beitrag nicht überstürzen und habe deshalb die vergangenen Tage damit verbracht, die Roadmap @Nillion zu lesen. Immer wieder kam ich auf einen einfachen Gedanken in Dusk, der ersten Phase, zurück: Ein Covenant braucht keinen Keeper.

Laut der offiziellen Roadmap mit Stand vom 20. Oktober 2026 ist ein Covenant eine Anweisung, die auf Ethereum verborgen bleibt, bis ihre Bedingung erfüllt ist. Die Roadmap bringt es klar auf den Punkt: „Es ist kein Keeper erforderlich, und keine Partei entscheidet, ob gehandelt wird.“

Mit Keeper meine ich einen Bot oder eine Person, der oder die im richtigen Moment den Knopf drückt. Hier entschlüsseln gestakte Nodes das Ergebnis erst dann, wenn ein Live-Datenfeed anzeigt, dass die Bedingung erfüllt wurde.

So stelle ich es mir vor: Nehmen wir an, ich möchte ETH nur dann kaufen, wenn BTC einen von mir festgelegten Preis erreicht. Normalerweise würde ich ständig den Kurs beobachten, und meine Order läge offen im Orderbuch, bis sie ausgeführt wird. Mit einem Covenant könnte ich die Order jetzt aufgeben und an diese Bedingung knüpfen, sodass sie erst sichtbar wird, wenn sie ausgelöst wird.

Da begann ich zu verstehen, worum es bei Encrypted Markets geht: Orders, Gebote und Zahlungen bleiben bis zum entscheidenden Moment versiegelt. Nillion begann mit Berechnungen auf sensiblen Daten, die verschlüsselt bleiben, und Covenants übertragen diese Idee des Datenschutzes auf Marktaktionen.

Nillion bestätigt, dass Dusk im Ethereum-Mainnet live ist und Entwickler bereits damit bauen. Eine von Nillion vorgestellte App ist eine Auktion mit versiegelten Geboten, die bis zum Ende der Auktion verschlüsselt bleiben.

Als Nächstes sieht die Roadmap Darkfall vor, das Covenants in das breitere EVM-Ökosystem bringt.

Da jeder durch das Staking von NIL einen Node betreiben kann, werde ich die Beteiligung der Nodes im Auge behalten.

Ich habe selbst $NIL gehandelt, und der Trade ist unten zu sehen.

#nil

Ich stelle mir immer wieder eine Frage zu KI-Agenten, die eine Wallet besitzen: Wo liegt die Grenze? Bei Kite lautet die Antwort, die ich gefunden habe: in der Session.

Laut der Kite-Dokumentation folgt die Identität einer Hierarchie: erst User, dann Agent, dann Session. Auf der Architekturseite heißt es: „Constraints können selbst bei einer vollständigen Kompromittierung des Agenten nicht verletzt werden.“

Einfach gesagt ist eine Session ein vom Eigentümer genehmigtes Budget, und der Agent kann nur innerhalb dieses Rahmens handeln. Laut der am 15. Oktober 2026 veröffentlichten Dokumentation findet der Agent einen Dienst im Katalog, öffnet eine Session und wartet auf die Bestätigung des Eigentümers, bevor eine neue erstellt wird.

Deshalb halte ich das für die entscheidende Frage der Agentenökonomie. Einen Agenten bezahlen zu lassen, ist einfach umzusetzen. Ihn bezahlen zu lassen, ohne ihm die gesamte Wallet zu übergeben, ist der schwierige Teil.

Auch die Zahlungswege werden ausgebaut. Laut der am 8. Juli 2026 veröffentlichten Version können x402-Zahlungen – ein Standard, mit dem Agenten Webdienste bezahlen können – über Base, Tempo und Solana abgewickelt werden, wobei Base standardmäßig als Abwicklungskette dient.

Hier kommt $KITE in meinen Überlegungen ins Spiel. Auf der Tokenomics-Seite steht, dass das Protokoll bei jeder Transaktion für einen KI-Dienst eine kleine Provision erhebt und diese in KITE tauschen kann; Staking und Governance sind als Funktionen für Phase 2 vorgesehen.
Ich habe noch nicht herausgefunden, wie diese Provision anfällt, wenn eine Zahlung auf Base abgewickelt wird. Genau das werde ich also weiterverfolgen.
$KITE #KiteBBW @KITE AI 中文