Direkt zum Hauptinhalt

Solanas Kora Signing Node ist der stille UX-Drehpunkt, der das Rennen um Consumer Crypto neu ausrichten könnte

· 12 Min. Lesezeit
Dora Noda
Dora Noda
Software Engineer

Seit fünf Jahren ist „insufficient SOL for transaction“ die teuerste Fehlermeldung von Solana. Jede Consumer-App, die jemals einen Nicht-Krypto-Nutzer gewinnen wollte, hat genau dort einen Teil von ihnen verloren – beim Checkout-Schritt, wenn ein Fremder einen zweiten Token erwerben muss, nur um den ersten auszugeben. Im April 2026 veröffentlichte die Solana Foundation schließlich die Antwort: Kora, ein Fee-Relayer und Signierknoten, der es dApps ermöglicht, Transaktionen nativ zu sponsern, Gebühren in jedem SPL-Token zu bezahlen und das Signieren an TEEs oder KMS-gestützte Vaults auszulagern. Es ist kein glanzvoller Launch. Es ist ein Infrastruktur-Upgrade. Und Infrastruktur-Upgrades sind der Weg, wie Base und Abstract in den letzten zwölf Monaten still und leise das Consumer-Onboarding für sich gewonnen haben.

Die Frage ist nicht mehr, ob Solana mit der gaslosen UX von EVM-Consumer-Chains mithalten kann. Kora macht diesen Teil trivial. Die Frage ist, ob das Schließen der Last-Mile-Lücke ausreicht, um die Entwickler zurückzugewinnen, die bereits woanders gebaut haben.

Was Kora tatsächlich liefert​

Wenn man das Marketing weglässt, besteht Kora aus drei miteinander verknüpften Komponenten: einem Transaktions-Relayer, einem Remote-Signer und einer Policy-Engine. Eine dApp erstellt eine Transaktion, legt einen Kora-Knoten als Gebührenzahler (Fee Payer) fest, der Nutzer signiert die Payload über ein Embedded Wallet, und der Kora-Betreiber signiert mit und sendet die Transaktion. Validatoren werden weiterhin in SOL bezahlt. Der Nutzer hält jedoch nie welche.

Was es interessant macht, ist die Validierungsebene. Ein Kora-Knoten leitet nicht blind alles weiter, was Nutzer ihm übergeben. Er führt vor dem Signieren drei Prüfungen durch:

  • Instruktions-Validierung gegen die zugehörigen Solana-Programme, damit fehlerhafte oder bösartige Instruktionen abgelehnt werden, bevor sie einen Leader erreichen.
  • Oracle-gestützte Gebührenangemessenheit, bei der der angebotene SPL-Token-Betrag mit dem aktuellen SOL-Preis plus der Betreibermarge verglichen wird, sodass der Relayer niemals mit Verlust arbeitet.
  • Allowlist- und Blocklist-Erzwingung auf Programm- und Token-Ebene, damit ein Betreiber, der einen Kora-Knoten für eine einzelne dApp betreibt, niemals versehentlich eine Transaktion sponsert, die auf einen zufälligen, ungeprüften Kontrakt abzielt.

Der Signierpfad ist der Punkt, an dem die Architektur ehrgeizig wird. Kora unterstützt standardmäßig das Remote-Signing über Turnkey und AWS KMS, was bedeutet, dass der private Schlüssel, der die Gebühren bezahlt, niemals auf der Festplatte des Relayers liegt. Für ein Fintech, das auf Solana aufbaut, ist das der Unterschied zwischen „wir haben unseren eigenen Paymaster gebastelt und die Daumen gedrückt“ und „unsere Key-Custody-Lösung besteht ein SOC 2-Audit“.

Das Ganze wurde von Runtime Verification geprüft und differenziell mittels Fuzz-Testing getestet – ein Detail, das man nur erwähnt, wenn man erwartet, dass Institutionen die Spezifikationen lesen.

Warum „nativ“ hier „Smart Contract“ schlägt​

Die Versuchung ist groß, Kora mit ERC-4337 zu vergleichen und anzunehmen, dass Solana nur aufholt. Die Architekturen verfolgen jedoch unterschiedliche Ansätze, und dieser Unterschied ist entscheidend.

ERC-4337 ist Account Abstraction, die als paralleles System oben auf Ethereum implementiert wurde. Es führt einen separaten Mempool, ein UserOperation-Objekt, eine Bundler-Rolle und einen EntryPoint-Kontrakt ein – nichts davon wird vom Basisprotokoll nativ verstanden. Bundler bündeln Benutzeroperationen, Paymaster sponsern Gebühren und ein On-Chain-Kontrakt erzwingt die Validierung. Es funktioniert und wurde im Ethereum-Mainnet sowie auf wichtigen L2s bereitgestellt, aber es ist ein sechsjähriges Bauprojekt, um ein UX-Feature nachzurüsten, das das Protokoll nie vorgesehen hatte.

Solanas Design hat diese Komplexität bereits vor Jahren auf der Protokollebene absorbiert. Jede Transaktion hat bereits ein feePayer-Feld. Partielle Signaturen sind nativ. Programme können beliebige Instruktionen validieren. Kora ist keine Bundler-und-Paymaster-Konstruktion; es ist ein Knotenbetreiber, der den feePayer-Slot ausfüllt und mit einer der partiellen Signaturen signiert, die das Protokoll bereits akzeptiert.

Die praktische Konsequenz sind Latenz und die Angriffsfläche für Entwickler. ERC-4337-Transaktionen durchlaufen einen separaten Mempool mit eigenen Sortierungsregeln und Propagationsverzögerungen. Kora-Transaktionen durchlaufen denselben Pfad wie jede andere Solana-Transaktion, mit derselben Finalität von unter 400 ms. Es gibt keinen Bundler-Arbitrage-Markt, über den man nachdenken muss, keine EntryPoint-Kontraktversion, die man verfolgen muss, und keine UserOperation-Gas-Schätzung, die man debuggen muss.

Was dies für Solana-Entwickler bringt, kommt dem Motto „das Fee-Payer-Feld setzen, die dApp veröffentlichen“ sehr nahe. Was dabei verloren geht, sind einige der Optionen, die EVM-Smart-Accounts kostenlos erhalten – Multi-Key-Auth, Batch-Calls, On-Chain-Session-Policies – obwohl vieles davon separat auf Solana durch PDAs und programmgesteuerte Accounts entwickelt wird.

Die Last-Mile-Lücke, die Solana tatsächlich hatte​

Trotz all des Geredes über Solanas Entwickler-Dynamik in den Jahren 2025 und 2026 war die Consumer-Wallet-Ebene der Teil, der hinterherhinkte. Der Infrastruktur-Stack reifte schnell: Das DEX-Volumen von Pump.fun überstieg im ersten Quartal 2026 die Marke von 2 Mrd. $, Jito und Marinade dominieren das Liquid Staking, Tensor verwandelte den NFT-Handel in ein professionelles Terminal. Aber jedes dieser Produkte musste eine eigene Antwort auf die Frage finden: „Der Nutzer hat kein SOL.“

Die Workarounds wurden kreativ. Pump.fun leitete erste Token-Käufe über eingebettete Onramps. Jito stattete Benutzerkonten vorab mit Kleinstbeträgen (Dust) aus. Tensor verließ sich auf Phantom und Backpack, um den SOL-Erwerbsschritt zu handhaben, bevor die Nutzer überhaupt das Orderbuch erreichten. Jede dieser Lösungen funktionierte individuell, aber keine von ihnen war kompatibel. Ein Nutzer, der über den Flow von Pump.fun onboarded wurde, kam nicht mit einem gebührenfähigen Guthaben bei Tensor an.

Währenddessen lieferte Base den Passkey-Flow des Coinbase Smart Wallet, kostenloses Gas-Sponsoring über die Coinbase Developer Platform und ein Entwickler-SDK, das das gesamte Konzept eines privaten Schlüssels hinter einem E-Mail-Login verbirgt. Abstract ging mit Embedded Wallets, die sich wie Web2-Apps anfühlen, noch einen Schritt weiter. Das kombinierte Versprechen an einen Consumer-App-Entwickler im Jahr 2025 lautete: Baue auf Base, deine Nutzer werden nicht merken, dass sie on-chain sind, und wir übernehmen die Gebühren, während du skalierst.

Kora repliziert dieses Versprechen nicht eins zu eins. Was es tut, ist den architektonischen Grund zu beseitigen, warum eine Solana-dApp nicht dasselbe Versprechen abgeben könnte. Mit Kora kann ein Solana-Team nun Folgendes anbieten:

  • E-Mail- oder Passkey-Anmeldung über Privy, Turnkey oder Coinbase Embedded Wallets.
  • Kein SOL-Guthaben für Transaktionen erforderlich.
  • Gebührenzahlung in USDC, BONK oder dem nativen Token der dApp, falls vorhanden.
  • Finalität im Sub-Sekunden-Bereich ohne Bundler im Pfad.

Die Puzzleteile existierten schon vorher. Octane war der Open-Source-Vorläufer. Circles Gas Station, Openfort, Portal, Gelato, Biconomy und ein halbes Dutzend anderer Anbieter boten das Fee-Relaying als Dienstleistung an. Was Kora ändert, ist, dass die Solana Foundation nun selbst die standardisierte, geprüfte und KMS-kompatible Referenzimplementierung ausliefert. Das entfernt die Frage „welchem Drittanbieter-Paymaster vertrauen wir“ aus dem Entscheidungsbaum für jedes Team, das bisher eine eigene Lösung entwickelt oder einen Anbieter bezahlt hat.

Die Anbieter-Schicht über Kora​

Interessant wird es bei der Frage, was mit den Anbietern von eingebetteten Wallets passiert, die bereits um die Lücke herum gebaut haben, die Kora nun geschlossen hat.

Privy, das im Juni 2025 von Stripe übernommen wurde, ist die bevorzugte Consumer-App-Wallet für Solana-dApps, die einen E-Mail-Login wünschen. Solana ist für Privy offiziell eine sekundäre Chain — die Tiefe liegt bei der EVM —, aber der Flow der eingebetteten Wallet erstreckt sich auch auf Solana, und Privy unterstützt bereits die Konfiguration einer Fee-Payer-Wallet, die von der App verwaltet wird. Kora ersetzt Privy nicht; es bietet Privy ein standardisiertes Backend zum Andocken, anstatt dass jeder Kunde seinen eigenen Paymaster-Service betreiben muss.

Turnkey ist der sicherheitsfokussierte eingebettete Signer, der natürlich mit der Remote-Signing-API von Kora harmoniert. Turnkey enthält explizit keine Paymaster-Infrastruktur, sodass Solana-Teams, die hardware-isolierte Keys plus gaslose UX wollten, gezwungen waren, zwei Anbieter zusammenzufügen. Kora lässt diese Integration verschmelzen.

Dynamic, das 2025 von Fireblocks übernommen wurde, bringt Multi-Chain-Auth für institutionelle Teams. Die von Fireblocks gestützte Positionierung macht Dynamic zur natürlichen Wahl für Fintechs, die sowohl Solana- als auch EVM-Abdeckung mit Enterprise-Compliance benötigen. Kora bietet Dynamic eine saubere Lösung zur Solana-Gebührenabstraktion, die es Fireblocks erspart, einen konkurrierenden Paymaster auszuliefern.

Coinbase Developer Platform ist der schwierige Fall. Coinbase hat massiv investiert, um Base durch die Coinbase Smart Wallet, kostenloses Base-Gas und das Embedded-Wallet-SDK zur Standard-Consumer-Chain zu machen. Kora verringert die Differenzierung, die Base verkauft hat, insbesondere für Apps, die USDC-native Flows wünschen, bei denen Solana bereits Skalenvorteile hat.

Das wahrscheinliche Ergebnis ist, dass Kora zum Standard-Solana-Backend für jeden Anbieter von eingebetteten Wallets wird, der keinen eigenen Paymaster-Service betreiben möchte. Die Anbieter konkurrieren über die Auth-UX, das Key-Management und die Richtlinienkontrollen. Kora kümmert sich im Hintergrund um das Fee-Relay. Das ist gesünder für das Ökosystem als der vorherige Zustand, in dem jede Solana-Consumer-dApp eine unabhängige Anbieterentscheidung treffen und die Sicherheit des selbstgebauten Relayers jedes Kandidaten bewerten musste.

Was dies löst und was nicht​

Kora schließt eine Lücke definitiv und lässt mehrere andere offen. Es lohnt sich, präzise zu unterscheiden.

Was Kora löst:

  • Die „User muss SOL halten“-UX-Hürde für jede dApp, die bereit ist, Gebühren in einem anderen Token zu subventionieren.
  • Die „Build vs. Buy“-Entscheidung für einen Paymaster für Teams, die sich zuvor zwischen operativem Aufwand und Vendor-Lock-in entscheiden mussten.
  • Die Lücke bei der institutionellen Akzeptanz, da das Audit und der KMS-Support es regulierten Einheiten ermöglichen, Kora-Nodes zu betreiben, ohne eine eigene Lösung zu entwickeln.

Was Kora nicht löst:

  • Die Wallet-Akquise selbst — Nutzer benötigen immer noch eine eingebettete Wallet von irgendwoher, sei es von Phantom, Privy, Turnkey oder Coinbase.
  • Account-Abstraktions-Primitive wie Batched Calls und Session Keys, die auf Solana immer noch separat über PDAs und andere Muster auf Programmebene zusammengestellt werden.
  • Die wirtschaftliche Frage, wer für das SOL bezahlt, das die Kora-Betreiber vorstrecken. Für eine dApp mit Token-Einnahmen oder einem Stablecoin-Bestand ist das in Ordnung; für ein kostenloses Produkt ist das Gas-Sponsoring lediglich eine Kundenakquise-Kostenstelle.
  • Cross-Chain-UX, die immer noch erfordert, dass der Nutzer mit einer Bridge oder einer Chain-Abstraction-Schicht wie LayerZero, Wormhole oder Across interagiert.

Die These „Gaslose Infrastruktur als Protokoll-Primitiv“ ist zweischneidig. Solana hat nun die sauberste native Gebührenabstraktions-Story aller großen Chains. Es bedeutet aber auch, dass sich die Differenzierung in den Stack nach oben verlagert — hin zu Wallet-UX, Recovery-Flows und Account-Abstraktions-Features, bei denen die EVM einen mehrjährigen Vorsprung hat.

Die strategische Einschätzung für Entwickler​

Für ein Team, das Mitte 2026 eine Chain auswählt, hat sich die Kalkulation verschoben. Vor zwölf Monaten lautete die Antwort für das Consumer-Onboarding Base, Abstract oder eine der neuen EVM-Consumer-Chains, Punkt. Solana hatte die Aufmerksamkeit der Entwickler und infrastrukturellen Schwung, verlor aber Retail-Nutzer durch den Schritt der SOL-Beschaffung. Das ist nicht mehr der Fall.

Eine Consumer-dApp, die heute auf Solana mit Privy oder Turnkey im Frontend und Kora im Backend startet, hat funktionell die gleiche UX-Oberfläche wie der äquivalente Stack auf Base. E-Mail-Login, gaslose Transaktionen, Gebührenzahlung in USDC, Finalität in unter einer Sekunde. Die verbleibenden Unterschiede sind das Laufzeitmodell, das Tooling-Ökosystem und die verfügbare Liquidität. Für eine App, die den Durchsatz und die DEX-Tiefe von Solana nutzen möchte, ist das UX-Argument für die Wahl der EVM erheblich schwächer geworden.

Für Teams, die bereits auf Base ausliefern, ändert Kora die unmittelbare Entscheidung nicht. Es ändert jedoch den langfristigen Wettbewerbsdruck. Wenn die Consumer-dApps mit der saubersten UX auf Solana erscheinen, weil die neue Infrastruktur eine Integration weniger bedeutet, um die man sich kümmern muss, beginnt sich das Gewicht um den Consumer-Onboarding-Vorteil von Base zu verschieben.

Ehrlich betrachtet ist Kora notwendig, aber nicht ausreichend. Es beseitigt einen spezifischen Grund, warum Entwickler Solana nicht für Consumer-Apps gewählt haben. Es schafft für sich genommen noch keinen neuen Grund, Solana zu wählen. Die nächsten zwei Quartale werden zeigen, ob die Anbieter von eingebetteten Wallets tatsächlich standardmäßig auf Kora setzen, ob neue Consumer-dApps es als Grund für ihre Chain-Wahl anführen und ob die bestehenden EVM-Consumer-Chains reagieren, indem sie ihre eigenen Infrastruktur-Lösungen verbessern.

So oder so: „User muss SOL erwerben, bevor er transaktiert“ ist endlich ein Problem der Vergangenheit, kein aktuelles mehr. Das allein war die Veröffentlichung wert.

BlockEden.xyz betreibt produktionsreife Solana-RPC-Infrastruktur für Teams, die Consumer-dApps, Zahlungssysteme und Handelsplattformen entwickeln. Wenn Sie gaslose Flows integrieren oder ein Solana-Produkt skalieren, erkunden Sie unseren API-Marktplatz für Endpunkte mit niedriger Latenz, die für die nächste Generation von Consumer-Crypto entwickelt wurden.

Quellen​

Share on Twitter