OpenSea-Handels-API: Daten, Orders und Bestätigung

Die benötigte API-Fähigkeit definieren

Beginnen Sie mit der Handlung, die die Anwendung unterstützen muss. Kollektionsrecherche benötigt andere Endpunkte und Aufzeichnungen als Angebotserstellung, Erfüllung von Verkaufsangeboten oder Portfolioabgleich. Eine erfolgreiche Metadatenanfrage belegt nicht, dass der übrige Handelslebenszyklus umgesetzt ist.

Listen Sie erforderliche Fähigkeiten getrennt auf: Kollektionen und Stücke identifizieren, relevante Orders untersuchen, erlaubte Handlungen konstruieren, Verpflichtungen verfolgen und Ergebnisse verifizieren. Ordnen Sie dann jede Fähigkeit der aktuellen offiziellen Dokumentation und den von ihr unterstützten Netzwerken oder Vermögenswertstandards zu.

Die Fähigkeitsliste sollte Grenzen enthalten. Eine Datenquelle kann einen Vermögenswert anzeigen, ohne seinen Kauf über den gewählten Weg zu unterstützen. Ein Erfüllungsendpunkt kann für EVM-Orders gelten, während eine andere Blockchain andere Behandlung benötigt.

Diese Unterschiede ausdrücklich zu halten, ergibt einen genaueren Integrationsplan als eine breite Anzeige „API verbunden“. Jede unterstützte Handlung sollte eigene Belege für korrektes Verhalten haben.

Authentifizierung der OpenSea-Handels-API ist keine Wallet-Signierung

Die Authentifizierung der OpenSea-Handels-API identifiziert den Dienstzugriff. Wallet-Signierung autorisiert Nachrichten oder Transaktionen unter Kontrolle eines Kontos. Das sind getrennte Zugangsdaten und Vertrauensgrenzen, selbst wenn eine Anwendung beides in einem Ablauf verwendet.

Die offizielle API-Schlüssel-Dokumentation erklärt Schlüsselzugriff und den Anfrageheader X-API-KEY. Ein Dienstschlüssel sollte außerhalb öffentlicher Pakete, Bildschirmfotos und gewöhnlicher Diagnoseausgaben bleiben. Die Integration sollte auch Ablauf oder Ersatz behandeln, ohne den Wert offenzulegen.

Privates Signierungsmaterial der Wallet sollte weder in API-Header kopiert noch an einen Marktplatz-Datenendpunkt gesendet werden. Eine vorbereitete Handlung kann über einen kontrollierten lokalen oder anderweitig angemessen isolierten Signierungsprozess geprüft und signiert werden.

Ein nützlicher Entwurf kann im reinen Beobachtungsmodus ohne Handelsbefugnisse arbeiten. Das ermöglicht die Bewertung von Datenabdeckung und Anfragebehandlung, bevor irgendeine Kontohandlung aktiviert wird.

Die aktuelle Dokumentation als Schnittstellenvertrag behandeln

Endpunktnamen, Antwortformate und unterstützte Vorgänge können sich ändern. Lesen Sie die Referenz für genau den Vorgang, statt ein altes Beispiel wegen vertrauter Markenbezeichnungen zu kopieren. Ein für eine Blockchain oder einen Ordertyp funktionierender Weg deckt möglicherweise keinen anderen ab.

Bewahren Sie die Version oder das Dokumentationsdatum, auf dem wichtige Annahmen beruhen. Tests sollten zeigen, wenn eine Antwort diese Annahmen nicht mehr erfüllt. Ein unbekanntes Feld kann harmlos sein, doch eine fehlende Vermögenswertkennung oder geänderte Transaktionsstruktur kann die Handlung ungültig machen.

Erraten Sie fehlende Werte nicht stillschweigend. Fehlen der Antwort Informationen, die zur Feststellung von Zahlung, Empfänger oder Eignung nötig sind, sollte die Anwendung einen unvollständigen Vorschlag melden, statt die Lücke mit einem ausgabenautorisierenden Standardwert zu füllen.

Der Leitfaden zum NFT-Smart-Contract-Handel erklärt, warum die Transaktionsbedeutung über gültiges JSON hinaus wichtig ist. Eine korrekt eingelesene Antwort muss weiterhin zur beabsichtigten wirtschaftlichen Handlung passen.

Eine stabile Identitätsaufzeichnung aufbauen

Bewahren Sie Netzwerk, Kollektionskennung, relevante Vermögenswertkennung, Token- oder Editionsmenge und Orderreferenz. Diese Felder verbinden Datenbeobachtungen mit der konkreten Transaktion und späteren Eigentumsbelegen.

Ein Kollektionsslug ist innerhalb der Marktplatz-API nützlich, sollte aber nicht die vom Ausführungsweg benötigte Onchain-Identität ersetzen. Anzeigenamen und Symbole können sich ändern oder nachgeahmt werden. Die Integration benötigt zu jeder Ebene passende stabile Kennungen.

Unterscheiden Sie außerdem einen Orderhash von einer Transaktionskennung. Eine Order kann beobachtet oder aktualisiert werden, bevor eine Transaktion existiert, und eine Transaktion kann mehrere relevante Ereignisse umfassen. Ein einziges allgemeines ID-Feld lässt sich leicht falsch verwenden.

Dieses Identitätsmodell ermöglicht Duplikatbereinigung und Wiederherstellung. Die Anwendung kann wiederholte Belege über eine Verpflichtung erkennen, ohne jede Antwort als neue Handelsgelegenheit oder weiteren Bestand zu behandeln.

Seitennavigation der OpenSea-Handels-API benötigt Abdeckungsverfolgung

Die Seitennavigation der OpenSea-Handels-API sollte Abfrageumfang und Fortsetzungszustand bewahren. Eine Antwortseite ist nicht unbedingt die vollständige Angebotsmenge. Eine kleine Ergebniszahl kann bedeuten, dass wenige Aufzeichnungen existieren, aber auch, dass die Anwendung vor Abruf der verbleibenden Seiten stoppte.

Die aktuelle Referenz zu Kollektions-Verkaufsangeboten dokumentiert Seitennavigation mit einem Seitenlimit und einem Fortsetzungsparameter. Verwenden Sie den für diesen Endpunkt dokumentierten Fortsetzungsmechanismus, statt Offset-Verhalten zu erfinden.

Erfassen Sie, welche Kollektion, Filter und welches Beobachtungsintervall der Abruf abdeckt. Ändert sich die Angebotsmenge während der Seitennavigation, bereinigen Sie Duplikate anhand stabiler Identitäten und erkennen Sie an, dass das Ergebnis möglicherweise keine vollkommen gleichzeitige Momentaufnahme darstellt.

Ein praktischer Abrufprozess benötigt außerdem eine Stoppregel, ein Anfragebudget und einen Status unvollständiger Abdeckung. Ein unterbrochener Scan sollte nicht als Beweis dargestellt werden, dass jede ausgelassene Order am Markt fehlt.

Rohe Antworten von vereinheitlichten Aufzeichnungen trennen

Vereinheitlichung macht unterschiedliche Antworten leichter nutzbar, darf aber ihre Bedeutung nicht auslöschen. Bewahren Sie ursprüngliche Währungsbeträge, Mengen, Quellzeitstempel und Orderkennungen neben den von der Strategie verwendeten Feldern.

Ein in den kleinsten Einheiten eines Tokens dargestellter Zahlungswert sollte beispielsweise anhand der tatsächlichen Dezimalstellen dieses Tokens interpretiert werden. Eine zu frühe Umrechnung über eine Gleitkommaanzeige kann Genauigkeit verlieren. Anzeigeformatierung und Transaktionsrechnung erfüllen unterschiedliche Zwecke.

Ein vereinheitlichtes Preisfeld sollte auch angeben, ob es einen Angebotspreis, ein Kaufangebot, einen abgeschlossenen Verkauf oder eine Schätzung darstellt. Diese Beobachtungen zu einer Zahl zu kombinieren, vereinfacht spätere Berechnungen auf Kosten der Korrektheit.

Bewahren Sie genug Quellkontext für die Untersuchung von Abweichungen, ohne Geheimnisse zu speichern. Eine von sensiblen Daten bereinigte Antwortreferenz und validierte wirtschaftliche Felder können Fehlerdiagnose unterstützen und dabei vollständige Anfrageprotokolle mit Zugangsdaten vermeiden.

Anfragegrenzen als Teil des Entwurfs respektieren

Eine Integration benötigt begrenzte Anfrageraten, Zwischenspeicherung und Warteabstände. Ratenbegrenzung ist keine außergewöhnliche Bedingung, die eine sofortige Wiederholungsschleife rechtfertigt. Dieselbe zurückgewiesene Anfrage wiederholt zu senden, kann die Wiederherstellung verlangsamen und Ressourcen verbrauchen, ohne Datenaktualität zu verbessern.

Die aktuelle OpenSea-API-Schlüssel-Dokumentation beschreibt Antwortheader für Grenzen und Wiederholungszeitpunkte sowie gemeinsame kontoweite Grenzen über mehrere Schlüssel hinweg. Verwenden Sie die aktuell zurückgegebenen Hinweise, statt einen angenommenen universellen Durchsatz fest einzubauen oder zusätzliche Schlüssel zur Umgehung von Grenzen zu erstellen.

Trennen Sie häufig veränderte Daten von länger zwischenspeicherbaren Metadaten. Aktualisierungsrichtlinien sollten der Datennutzung folgen: Eine Kollektionsbeschreibung und eine unmittelbar zu erfüllende Order benötigen nicht dieselbe Aktualitätsregel.

Messen Sie den Anfragebedarf, bevor Sie die Abdeckung erhöhen. Eine Anwendung, die wenige Kollektionen verlässlich überwacht, kann nützlicher sein als eine, die nominell alles abdeckt und ständig mit unvollständigen oder veralteten Antworten arbeitet.

Streaming als Beobachtungen und nicht als vollständiges Kontobuch interpretieren

Die Referenz zur Stream API dokumentiert Marktplatzereignisse über WebSocket. Sie besagt außerdem, dass Ereignisse in falscher Reihenfolge eintreffen können und bei Verbindungsfehlern verpasste Nachrichten nicht erneut abgespielt werden. Diese Grenzen beeinflussen die Wiederherstellung eines lokalen Zustandsmodells.

Verwenden Sie Ereigniszeitstempel und stabile Identitäten, damit späte oder wiederholte Beobachtungen aktuelle Aufzeichnungen nicht beschädigen. Empfangsreihenfolge ist nicht immer dasselbe wie Marktereignisreihenfolge. Eine Wiederverbindung sollte angemessenen Abgleich auslösen und nicht die Annahme, dass nichts verpasst wurde.

Eine aktuelle Momentaufnahme kann gegenwärtige Orders oder Bestände wiederherstellen, ohne jedes Ereignis während einer Lücke zu rekonstruieren. Die Anwendung sollte betriebliche Wiederherstellung von vollständiger historischer Abdeckung unterscheiden.

Diese Unterscheidung ist auch für Analysen wichtig. Ein über ein unbeobachtetes Intervall berechneter Trend benötigt eine Abdeckungswarnung. Fehlende Ereignisse durch Nullen zu ersetzen, kann ein falsches Marktsignal erzeugen.

Erfüllung über die OpenSea-Handels-API ist eine Vorbereitungsphase

Erfüllungsantworten der OpenSea-Handels-API benötigen sorgfältige Interpretation. Der aktuelle Endpunkt zur Erfüllung von Verkaufsangeboten liefert Informationen, die zur Onchain-Erfüllung eines unterstützten Angebots nötig sind. Ihr Empfang überträgt das NFT nicht selbst und beweist nicht, dass das Konto den Verkäufer bezahlte.

Prüfen Sie Blockchain, Protokoll, Empfänger, Menge, Zahlung und erforderliche Gebühren anhand des freigegebenen Vorschlags. Die aktuelle Endpunktreferenz benennt EVM- und unterstützte Seaport-Beschränkungen; ein Aufrufer sollte diese Struktur nicht als universelles Solana-Transaktionsformat wiederverwenden.

Erforderliche Erstellergebühren entfallen nicht allein dadurch, dass optionale Erstellergebühren abgelehnt werden. Die endgültige Handlung muss die tatsächlichen Order- und Wegbedingungen respektieren, statt einen Komfortparameter als Befugnis zur Umgehung erforderlicher Gegenleistung zu behandeln.

Nach der Vorbereitung benötigt der Ablauf weiterhin kontrollierte Signierung, Übermittlung und Bestätigung. Jede Phase sollte die ursprüngliche Absicht bewahren, damit das Konto unerwartete Änderungen erkennen kann, bevor Mittel gebunden werden.

Die Unterschiede zwischen Wallet-Rollen bewahren

Das zahlende Konto, das ein NFT empfangende Konto und das eine Autorisierung signierende Konto können in manchen unterstützten Abläufen unterschiedliche Rollen haben. Die Anwendung sollte die vorgesehenen Rollen ausdrücklich identifizieren, statt alle Adressfelder als austauschbar anzunehmen.

Ein geänderter Empfänger ist wirtschaftlich bedeutsam, selbst wenn die Transaktion gültig bleibt. Vergleichen Sie ihn mit dem freigegebenen Ziel. Dasselbe gilt für einen Zahlungstoken oder eine Adresse des Ausgabenberechtigten, die von der Nutzererwartung abweicht.

Der Leitfaden zur Verwendung von WETH für den Handel auf OpenSea erklärt Zahlungstoken- und native Gebührenguthaben in Ethereum-Angebotsabläufen. Diese Unterschiede sollten sich in den Kontoprüfungen der Integration widerspiegeln.

Eine Dienstantwort sollte nie pauschale Befugnis zur Wahl unerwarteter Ziele erhalten. Der Aufrufer bleibt dafür verantwortlich zu bewerten, ob die vorbereitete Handlung dem beabsichtigten Handel und den Grenzen des Nutzers entspricht.

Sweep-Ersatzstücke und geordnete Handlungen berücksichtigen

Die aktuelle Referenz zum Kollektions-Sweep beschreibt einen ausschließlich für EVM vorgesehenen Vorgang, der eine geordnete Transaktionsliste zurückgibt. Sie dokumentiert außerdem automatischen Ersatz durch ein nächstgünstiges Verkaufsangebot, wenn ein angefordertes Stück nicht mehr verfügbar ist, standardmäßig aktiviert.

Dieses Verhalten macht die Ersatzrichtlinie wichtig. Ein Ersatzstück kann die Kollektionsbezeichnung erfüllen und trotzdem die ursprüngliche Merkmalsthese oder Ausstiegseignung verfehlen. Prüfen Sie die entstehende Vermögenswertmenge und Gesamtkosten erneut, bevor die vorbereitete Folge die Freigabe übernehmen darf.

Eine geordnete Transaktionsliste ist kein universelles Versprechen, dass der gesamte Korb atomar gelingt. Die Anwendung benötigt die tatsächlichen Ergebnisse jeder Handlung und eine Richtlinie für teilweisen Abschluss.

Eine nützliche Aufzeichnung bewahrt angeforderte Stücke, endgültig vorgeschlagene Stücke und erworbene Stücke getrennt. So lässt sich erklären, warum der entstehende Bestand vom ursprünglichen Bildschirm abweicht, ohne erfolgreiche Käufe zu erfinden, die nie stattfanden.

EVM- und Solana-Wege getrennt halten

OpenSea kann Vermögenswerte mehrerer Netzwerke zeigen, während einzelne Endpunkte engere Vorgänge unterstützen. Die Präsenz einer Kollektion in einer Datenantwort beweist nicht, dass jeder Ausführungsendpunkt ihre Blockchain oder ihren Standard akzeptiert.

Der Artikel zum Solana-Web3-Handelsbot untersucht blockchainspezifische Konto- und Transaktionsanforderungen. Solana-Angebotsfinanzierung, unterstützte NFT-Standards und Bestätigungsbelege sollten nach ihren eigenen Regeln geprüft werden, statt sie mechanisch aus EVM-Seaport-Konzepten zu übersetzen.

Deklarieren Sie Fähigkeiten auf Handlungsebene: Metadaten ansehen, Orders untersuchen, einen Kauf vorbereiten, ein Kaufangebot erstellen oder eine Verpflichtung stornieren. Ein Weg kann einige dieser Vorgänge unterstützen und andere nicht.

Nicht unterstützte Fälle sollten in Oberfläche und Tests ausdrücklich bleiben. Eine Transaktionsdarstellung zu erraten, weil der Vermögenswert einen vertrauten Kollektionsnamen verwendet, ist kein verlässlicher Weg zur Erweiterung der Abdeckung.

Lesewiederholungen von wirtschaftlichen Wiederholungen unterscheiden

Ein Lesen nach einem vorübergehenden Fehler zu wiederholen, unterscheidet sich von der Übermittlung einer weiteren Order oder Transaktion. Die Integration sollte Vorgänge nach ihren möglichen wirtschaftlichen Wirkungen klassifizieren und genug Identität zur Wiederherstellung ungewisser Ergebnisse bewahren.

Eine Zeitüberschreitung nach einer Orderanfrage kann den Aufrufer im Unklaren lassen, ob der Dienst sie angenommen hat. Eine Zeitüberschreitung nach Blockchain-Übermittlung kann auftreten, obwohl die Transaktion später ausgeführt wird. Sofort eine weitere unabhängige Handlung zu erstellen, kann Risiko verdoppeln.

Fragen Sie bei ungewissen Ergebnissen den ursprünglichen Versuch anhand unterstützter Belege ab und gleichen Sie ihn ab. Bewahren Sie die relevante Budgetreservierung, bis die Verpflichtung geklärt ist. Eine ausbleibende sofortige Antwort beweist nicht, dass nichts geschah.

Diese Regel sollte in Tests und Betreibermeldungen sichtbar sein. Die Anwendung kann erklären, dass sie einen früheren Versuch prüft, statt einen allgemeinen Fehler anzuzeigen und den Nutzer zum wiederholten Klicken auf die Kaufschaltfläche zu ermutigen.

Fehler anhand des Vorgangs interpretieren

Authentifizierungsfehler, ungültige Parameter, nicht unterstützte Blockchain, fehlende Order, Konflikt und Ratenbegrenzung benötigen unterschiedliche Reaktionen. Jeden Nichterfolgsstatus als vorübergehendes Serverproblem zu behandeln, kann endlose Wiederholungen einer Anfrage erzeugen, die nie gültig werden wird.

Untersuchen Sie strukturierte Fehlerinformationen, ohne Geheimnisse in Protokollen offenzulegen. Eine nützliche Meldung kann den fehlgeschlagenen Vorgang und einen sicheren nächsten Schritt identifizieren und dabei API-Schlüssel, Signierungsmaterial und unnötige Kontoeinzelheiten auslassen.

Unterscheiden Sie außerdem einen API-Fehler von einem Onchain-Fehlschlag. Eine Vorbereitungsanfrage kann scheitern, bevor eine Transaktion existiert, während eine übermittelte Handlung selbst bei gescheiterter Ausführung Kosten verbrauchen kann. Die finanzielle Behandlung im Konto hängt davon ab, was tatsächlich geschah.

Eine robuste Integration bewahrt ungeklärte Fälle für die Untersuchung. Sie sollte weder einen abgeschlossenen Erfolg noch einen kostenlosen Fehlschlag erfinden, nur weil ihrem Fehlerparser eine präzisere Kategorie fehlt.

Eigentum, Orders und Zahlungen gemeinsam abgleichen

Eine Handelsaufzeichnung ist erst vollständig, wenn relevante Vermögenswertbewegung, Orderergebnis und finanzielle Wirkungen übereinstimmen. Ein Marktplatzstatus kann Belege beitragen, sollte aber bei ungewissem Ergebnis nicht alle anderen Prüfungen ersetzen.

Verifizieren Sie bei einem Erwerb den vorgesehenen Vermögenswert und die Menge unter Kontrolle des richtigen Kontos. Verbinden Sie bei einem Verkauf die Abgabe mit tatsächlichen Erlösen und Ausgaben. Wiederholte Ereignisse sollten keine doppelten Bestands- oder Gewinnaufzeichnungen erzeugen.

Offene Orders bleiben Teil der Kontosicht, selbst wenn die Strategie keine neuen Vorschläge mehr erzeugt. Ihre verbleibende Gültigkeit kann Mittel oder Bestände weiterhin beeinflussen. Ein Pausenbefehl storniert frühere Autorisierungen nicht automatisch.

Diese Abgleichebene macht die Integration über eine Vorführung hinaus nützlich. Sie ermöglicht der Anwendung zu erklären, was sie besitzt, was sie verpflichtet hat und welche Handlungen nach Unterbrechungen ungeklärt bleiben.

Den Vertrag ohne Annahme perfekter Antworten testen

Verwenden Sie repräsentative gespeicherte öffentliche oder synthetische Antworten, um Einlesen, Seitennavigation, fehlende Felder, doppelte Ereignisse, unerwartete Währungen und nicht unterstützte Wege zu testen. Halten Sie Geheimnisse aus Testdaten heraus und verwenden Sie keine echten Handelsbefugnisse, nur um einen Parser zu erproben.

Tests sollten wirtschaftlich wichtige Grenzen verifizieren. Ein geänderter Empfänger sollte die Vorschlagsvalidierung nicht bestehen. Ein nicht verfügbares Verkaufsangebot sollte nicht stillschweigend zu einem anderen freigegebenen Stück werden. Ein Teilkorb sollte nur die tatsächlich erworbenen Bestände erzeugen.

Erproben Sie Ratenbegrenzungen und unterbrochene Seitennavigation ebenso wie erfolgreichen Abruf. Die Anwendung sollte unvollständige Abdeckung melden, statt die Teilmenge als vollständige Markt-Momentaufnahme zu interpretieren.

Bevor Sie einen Weg als betriebsfähig bezeichnen, verifizieren Sie seinen vollständigen Lebenszyklus mit angemessener Autorisierung und begrenzten Bedingungen. Ein erfolgreicher Datenaufruf belegt nur diesen Datenaufruf und nicht Signierung, Ausführung, Stornierung oder Abwicklung.

Einheiten mit kleinen bekannten Beispielen prüfen

Eine kleine Menge unabhängig berechneter Beispiele kann Fehler entdecken, die realistisch aussehende Antworttestdaten übersehen. Verwenden Sie erfundene Zahlungstoken mit ausdrücklich angegebenen Dezimalstellen und verifizieren Sie sowohl Anzeige- als auch Transaktionsbeträge, ohne für das erwartete Ergebnis dieselbe Umrechnungsfunktion zu verwenden.

Bei einem hypothetischen Token mit achtzehn Dezimalstellen entsprechen 27000000000000000 kleinste Einheiten 0,027 Token. Bei einem anderen Token mit sechs Dezimalstellen entsprechen 27000000 kleinste Einheiten 27 Token. Dezimalmetadaten wegzulassen oder für jeden Vermögenswert die erste Konvention anzunehmen, erzeugt einen schweren Zahlungsfehler, selbst wenn der Rohwert erfolgreich eingelesen wird.

Bewahren Sie Dezimalzeichenfolgen oder geeignete Ganzzahlarithmetik durch finanzielle Berechnungen hindurch. Ein gerundeter Anzeigewert kann für den Leser nützlich sein und zugleich ungeeignet, den genauen zu signierenden Betrag zu rekonstruieren. Die abschließende Transaktionsprüfung sollte die exakt autorisierten Einheiten verwenden.

Statistiken benötigen dieselbe Disziplin. Ein Mindestpreis und ein Gesamtvolumen können mit separaten Währungsfeldern eintreffen. Validieren Sie jeden Betrag gegen seine eigene Einheit, bevor Sie ihn vergleichen, umrechnen oder beschriften. Tests sollten zwei Kennzahlen mit unterschiedlichen Einheiten enthalten, damit die Anwendung nicht versehentlich besteht, weil sie für jedes Feld einer Antwort dieselbe Währung annimmt. Ein solches enges Beispiel verifiziert Bedeutung, statt lediglich zu beweisen, dass ein JSON-Objekt die erwarteten Schlüssel besitzt.

Die Integration beobachtbar halten, ohne Geheimnisse offenzulegen

Erfassen Sie Anfragekategorien, Latenz, Antwortstatus, Abdeckungslücken und ungeklärte Verpflichtungen. Diese Messungen helfen, ein Dienstproblem von einem Problem der Dateninterpretation oder Ausführung zu unterscheiden. Rohe Anfrageausgaben sind für den normalen Betrieb selten nötig.

Verwenden Sie Bereinigung und klare Trennung zwischen öffentlichen Kennungen und geheimen Zugangsdaten. Ein Diagnosebericht sollte einen Fehler erklären helfen, ohne zu einem weiteren Speicherort für einen API-Schlüssel oder privates Signierungsmaterial zu werden.

Die Arbeit mit der OpenSea-Handels-API ist erst vollständig, wenn die Anwendung Bedeutung und Grenzen jedes verwendeten Vorgangs erklären kann. Trennen Sie Zugriff von Befugnis, Daten von Ausführung und Bestätigung von Abwicklung. Diese Architektur macht aktuelle Fähigkeiten leichter testbar und künftige Änderungen leichter handhabbar, ohne über den Kontozustand zu raten.