Polymarket-API-Handel verbindet eine Handelsentscheidung mit einer Folge von Anfragen, Orderzuständen, Handelsaufzeichnungen und Kontoänderungen. Die nützliche Betrachtungseinheit ist ein authentifizierter Orderlebenszyklus. Ein Programm, das eine Anfrage erfolgreich übermittelt, hat nur einen Teil der Arbeit abgeschlossen; es muss weiterhin feststellen, was geschehen ist und welche Exposition verbleibt.
Dieser Leitfaden betrifft den API-Kontext von Polymarket International. Polymarket US hat einen getrennten Handelsplatz- und Kontokontext, weshalb seine Schnittstellen und Befugnisse gesondert geprüft werden sollten. Auch aktuelle Dokumentation ist wichtig: Wallet-Regelungen, Clientbibliotheken und Einzelheiten zu Sicherheiten können sich ändern und ein altes Beispiel zur unzuverlässigen Spezifikation für eine neue Integration machen.
Das folgende Szenario verwendet erfundene Preise, Mengen und Gebühren, um einen Lebenszyklus zu erklären. Es führt keinen Handel aus und schreibt keine Anlage vor. Die Gestaltungsgrundsätze gelten für manuelle Prüfung, beaufsichtigte Werkzeuge und autorisierte automatisierte Abläufe, wobei der Kontoinhaber die Kontrolle darüber behält, welche Aktionen ein Programm ausführen darf.
Polymarket-API-Handel mit einer Kontraktaufzeichnung beginnen
Die erste Aufzeichnung sollte das tatsächliche Instrument identifizieren. Bewahren Sie Markt, Ergebnistoken, gewählte Seite, vollständige Regeln und relevante Fristen auf. Ein Titel allein kann ähnlich benannte Kontrakte nicht zuverlässig unterscheiden, und eine Tokenkennung ohne ihre Bedeutung ist für eine menschliche Prüfung schwer zu überprüfen.
Stellen Sie sich einen erfundenen binären Markt darüber vor, ob eine Genehmigung bis zu einem bestimmten Datum erteilt wird. Der beabsichtigte Kauf ist das Ja-Ergebnis für genau diese Frage. Ein verwandter Markt zu einem späteren Baubeginn ist ein anderes Instrument, selbst wenn beide Überschriften die meisten Wörter teilen.
Der ältere Leitfaden zur Polymarket-Handels-API trennt Marktdaten, Orders und Kontoinformationen. Die Kontraktsuche gehört zum ersten Teil dieser Struktur. Vor jeder privaten Anfrage sollte die Integration dem Leser zeigen können, welches Ergebnis sie handeln will und warum diese Kennung zur Rechercheentscheidung passt.
Die aktuelle Integrationsschnittstelle verwenden
Ein API-Client sollte an eine dokumentierte Version und eine bekannte Menge unterstützter Vorgänge gebunden sein. Nehmen Sie nicht an, dass ein alter Paketname, ein Wallet-Beispiel oder eine Anfrageform aktuell bleibt, weil sie in einem Tutorial erscheint. Prüfen Sie offizielle Dokumentation und installierte Bibliothek gemeinsam.
Polymarkets aktuelle Handelsübersicht beschreibt Abrechnung mit pUSD und Ergebnistoken. Eine Integration sollte daher keine frühere Sicherheitenannahme über sämtliche Kontovorgänge hinweg fest einprogrammieren. Finanzierung, Genehmigungen, Handel und Einlösung können unterschiedliche Aufzeichnungen betreffen, die jeweils eigene aktuelle Prüfungen verdienen.
Zeichnen Sie das Datum der Dokumentationsprüfung und die von der Anwendung verwendete Clientversion auf. Ändert sich eines davon, wiederholen Sie die Abnahmefälle, die von Signaturen, Betragskodierung und Statusinterpretation abhängen. Eine erfolgreiche Marktdatenanfrage belegt nicht, dass der authentifizierte Handelsweg mit derselben Version kompatibel ist.
Signierer und Konto-Wallet identifizieren
Die Adresse, die eine Anfrage signiert, und die Konto-Wallet, die Mittel oder Positionen hält, müssen nicht bei jeder Wallet-Konfiguration austauschbar sein. Die Integration muss ihre Beziehung anhand der aktuellen Kontoeinrichtung feststellen. Sie aus einem vertrauten Adressformat abzuleiten kann Autorisierungsfehler oder Kontoverwechslungen verursachen.
Zeigen Sie den erwarteten Kontokontext an, bevor Sie Handel aktivieren. Eine nützliche Prüfung umfasst Handelsplatz, Wallet-Identität, unterstützte Befugnisse und die Frage, ob aktuelle private Lesezugriffe dem beabsichtigten Konto entsprechen. So kann der Betreiber eine technisch gültige Konfiguration erkennen, die mit dem falschen Konto verbunden ist.
Der offizielle Leitfaden zu Wallets und Authentifizierung ist der passende Ausgangspunkt für die aktuelle wallet-spezifische Einrichtung. Halten Sie geheimes Material aus gewöhnlichen Protokollen und nutzerbezogenen Aufzeichnungen heraus. Das Lebenszyklusjournal benötigt Kennungen und Autorisierungsbelege und keine Kopien privater Schlüssel oder wiederverwendbarer Zugangsdaten.
Anfrageauthentifizierung von Orderautorisierung trennen
Authentifizierung stellt fest, welches Konto oder welche Zugangsdaten eine private Anfrage stellen. Orderautorisierung begründet die signierte Handelsanweisung selbst. Dieser Unterschied ist wichtig, weil eine gültige Anfragehülle keine Änderung der wirtschaftlichen Bedingungen innerhalb einer Order rechtfertigt.
Polymarkets API-Dokumentation beschreibt wallet-basierte Zugangsdaten-Einrichtung und authentifizierte CLOB-Anfragen mit einer getrennten Wallet-Signatur, die eine Order autorisiert. Eine Integration sollte den aktuellen Signieranforderungen folgen, statt sämtliche Signaturen als ein allgemeines Token zu behandeln.
Bewahren Sie auf Anwendungsebene vor dem Signieren genehmigten Preis, Menge, Seite und Laufzeit auf. Ändert sich eine dieser Bedingungen, sollte das Programm das Ergebnis als veränderte Anweisung behandeln, die die zutreffenden Autorisierungsprüfungen erfordert. Eine Hilfsfunktion, die die Übertragung wiederholt, darf nicht stillschweigend die Preisgrenze erweitern oder die Menge erhöhen, um eine erfolgreiche Antwort zu erhalten.
Marktbeschränkungen vor dem Orderaufbau lesen
Eine gültige Order muss zu den aktuellen Marktbeschränkungen passen, einschließlich Preisschritten und Mengenanforderungen. Das sind zu lesende und zu überprüfende Eigenschaften und keine Werte, die dauerhaft aus einem sachfremden Beispiel kopiert werden sollten. Eine geänderte Beschränkung kann eine ansonsten sinnvolle Anweisung ungültig machen.
Verwenden Sie Dezimalrechnung und ausdrückliche Einheiten, wenn Sie eine menschliche Entscheidung in Anfragebeträge übersetzen. Preis je Anteil, Zahl der Anteile und gesamte Sicherheitenkosten sind unterschiedliche Größen. Ein Feld, das eine davon trägt, sollte niemals in ein Feld übernommen werden, das eine andere erwartet, nur weil beide als Zahlen oder Zeichenfolgen dargestellt werden.
Der offizielle Leitfaden zur Orderplatzierung dokumentiert den aktuellen Aufbauweg. Für einen allgemeinen Ablauf ist die wesentliche Abnahmeprüfung, dass die kodierte Order in genau die vom Nutzer genehmigten wirtschaftlichen Bedingungen zurückdekodiert werden kann, nachdem jede erforderliche Rundung sichtbar gemacht und geprüft wurde.
Das Orderbuch für die beabsichtigte Größe prüfen
Eine Preisgrenze definiert, was das Konto zu bezahlen oder zu erhalten bereit ist. Sie verspricht nicht, dass die gewünschte Menge gehandelt wird. Prüfen Sie vor dem Aufbau einer sofortigen Order die verfügbare Markttiefe innerhalb dieser Grenze und bewahren Sie den von der Entscheidung verwendeten Beobachtungszeitpunkt auf.
Angenommen, das erfundene Orderbuch bietet zehn Anteile zu 0,41 $ und zwanzig zu 0,44 $. Der Kauf von dreißig würde vor Gebühren 4,10 $ plus 8,80 $, also 12,90 $, kosten, wenn diese Preisangebote verfügbar bleiben. Eine Kauf-Limitorder über dreißig Anteile zu 0,44 $ erlaubt höchstens 13,20 $ Kaufpreis ohne anfallende Gebühren.
Der Unterschied zwischen erwarteten Orderbuchkosten und maximal autorisierten Kosten ist nützlich. Erstere beschreiben die beobachtete Gelegenheit; Letztere begrenzen die Order. Keines garantiert die endgültige Ausführung. Preisangebote können sich nach der Prüfung ändern, und eine Order kann abhängig von ihrer Art und den aktuellen Marktbedingungen abgelehnt oder teilweise ausgeführt werden.
Die Regel für den Rest bewusst wählen
Die Orderart bestimmt, was geschieht, wenn die gesamte angefragte Menge nicht sofort ausgeführt werden kann. Eine ruhende Order kann eine unausgeführte Verpflichtung im Orderbuch hinterlassen. Eine Anweisung für sofortige Teilausführung kann mit einer Position und ohne aktiven Rest enden. Das sind unterschiedliche Kontozustände.
Die aktuelle Polymarket-Dokumentation unterscheidet FOK, das eine vollständige sofortige Ausführung oder Stornierung verlangt, von FAK, das die verfügbare Menge ausführt und den Rest storniert. Eine teilweise FAK-Ausführung lässt den unausgeführten Teil daher nicht ruhen. GTC und GTD haben jeweils eigenes Fortbestands- oder Ablaufverhalten.
Der ältere Leitfaden zur Automatisierung von Polymarket-Limitorders erklärt, warum Laufzeit und Ausführungen gemeinsam betrachtet werden müssen. Nennen Sie die beabsichtigte Restregel in der Aufzeichnung der Orderabsicht, damit der spätere Abgleich das tatsächliche Verhalten mit der genehmigten Anweisung vergleichen kann.
Kapazität vor der Übermittlung reservieren
Das Konto sollte die von einer autorisierten Order erforderliche Kapazität vor dem Senden reservieren. Das verhindert, dass zwei gleichzeitige Entscheidungen jeweils auf dieselben verfügbaren Mittel oder dieselbe Ereignisgrenze vertrauen. Die Reservierung ist eine Anwendungskontrolle und sollte mit der tatsächlichen Kontosemantik des Handelsplatzes abgeglichen werden.
Für die Limitorder über dreißig Anteile zu 0,44 $ könnte eine hypothetische lokale Regelung 13,20 $ plus einen Gebührenpuffer von 0,30 $, insgesamt 13,50 $, reservieren. Dieser Puffer ist für das Beispiel erfunden und darf nicht als aktuelles Gebührenangebot des Handelsplatzes behandelt werden. Die tatsächliche Gebührenbehandlung sollte die zutreffenden aktuellen Informationen verwenden.
Reservieren Sie einmal für die wirtschaftliche Absicht und nicht erneut für jeden Übertragungsversuch. Bleibt der Ausgang der Anfrage unbekannt, hilft die Beibehaltung der Reservierung zu verhindern, dass das Konto Kapazität ausgibt, die die ursprüngliche Anfrage möglicherweise bereits gebunden hat. Geben Sie sie erst frei oder passen Sie sie an, nachdem Order- und Handelsbelege den neuen Zustand stützen.
Die Aufzeichnung der Orderabsicht dauerhaft speichern
Eine Aufzeichnung der Orderabsicht verbindet Rechercheentscheidung, Risikofreigabe und spätere Anfrage. Sie sollte eine stabile lokale Kennung, Kontokontext, Kontrakt, Seite, Menge, Limit, Laufzeit und die zur Freigabe verwendeten Datenversionen enthalten. Speichern Sie sie dauerhaft, bevor die Aktion den Prozess verlassen kann.
Diese Aufzeichnung erlaubt Wiederherstellung nach einem Absturz. Ohne sie kann das Programm beim Neustart eine unbekannte aktive Order beobachten und sie nicht mit seiner eigenen früheren Aktion verbinden. Sie unterstützt auch menschliche Prüfung, wenn eine Anfrage übertragen wurde, ihre Antwort aber verloren ging.
Der Leitfaden zu einem Polymarket-API-Bot konzentriert sich auf begrenztes Verhalten bei solchen ungewissen Übermittlungen. Selbst ein manuell bedientes API-Werkzeug profitiert von demselben Journal. Der Zweck ist, die Bedeutung der Aktion unabhängig davon zu bewahren, ob der Netzwerkaustausch sauber abgeschlossen wurde.
Weiterempfehlen und USDC verdienen
Weiterempfehlen und USDC verdienenUnser Partnerprogramm zahlt in Echtzeit.
Die Übermittlungsantwort als Beleg behandeln
Eine erfolgreiche Übermittlungsantwort liefert Belege dafür, dass der Handelsplatz die Anfrage in einem bestimmten Zustand angenommen hat. Sie ist keine allgemeingültige Aussage, dass jeder angefragte Anteil zu einer endgültig abgerechneten Position geworden ist. Lesen Sie zurückgegebenen Status und Kennungen nach ihrer dokumentierten Bedeutung.
Speichern Sie die Antwort mit ursprünglicher Absicht und Anfragezeitpunkt. Bewahren Sie Ablehnungsgründe auf, statt sie durch eine allgemeine Kennzeichnung als fehlgeschlagen zu ersetzen. Eine Ablehnung wegen des Preisrasters, unzureichende Freigabe und eine Übertragungszeitüberschreitung erfordern unterschiedliche Folgeaktionen. Nur Letztere kann das Ausführungsergebnis aus lokaler Sicht unbekannt lassen.
Eine Annahmebestätigung sollte niemals als alleinige Grundlage für eine endgültige Positionsanzeige dienen. Die Anwendung sollte nach Bedarf „übermittelt“, „aktiv“, „teilweise ausgeführt“, „storniert“, „wartet auf Bestätigung“ oder „ungeklärt“ sagen können. Klare Zwischenzustände sind aufschlussreicher als eine einzige grüne Erfolgsanzeige.
Orders und Geschäfte getrennt verfolgen
Eine Order ist eine Anweisung, die ein oder mehrere Geschäfte erzeugen kann. Ihre verbleibende Menge und ihre zugehörigen Handelsaufzeichnungen beantworten verwandte, aber unterschiedliche Fragen. Bei einer vollständig mit Gegenorders abgeglichenen Order können weiterhin Abrechnungsinformationen zu den Geschäften zu verfolgen sein, während eine teilweise mit Gegenorders abgeglichene ruhende Order aktive Menge behalten kann.
Polymarkets Orderlebenszyklus unterscheidet den Abgleich mit Gegenorders von der endgültigen Bestätigung. Eine Lebenszyklusumsetzung sollte diesen Unterschied bewahren, wenn sie die Kontoansicht aktualisiert. Sie sollte nicht jeden Handelsstatus in demselben abgeschlossenen Zustand zusammenfassen.
Angenommen, bei einer erfundenen Teilausführung werden zwölf von dreißig Anteilen mit Gegenorders abgeglichen. Das Kontojournal sollte diese zwölf und den Status ihrer Geschäfte identifizieren und dann nach der Orderart feststellen, was mit den verbleibenden achtzehn geschah. Die Rechnung aus angefragter minus mit Gegenorders abgeglichener Menge ist nützlich, belegt für sich genommen aber nicht, ob der Rest noch aktiv ist.
Eine Teilausführung mit dem Rest abgleichen
Setzen Sie die hypothetische Order über dreißig Anteile fort, nehmen Sie aber an, dass nur zwölf Anteile zu 0,44 $ ausgeführt werden. Ihr Kaufpreis beträgt 5,28 $. War die Order FAK und bestätigt ihre endgültige Antwort die Stornierung des Rests, hat das Konto zwölf erworbene Anteile und keine verbleibende Orderverpflichtung aus den anderen achtzehn.
War es eine ruhende Order und bleiben achtzehn zu 0,44 $ aktiv, stellen diese Anteile bis zu weitere 7,92 $ Kaufpreisverpflichtung dar. Fügen Sie jede anwendbare Gebührenbehandlung nach der tatsächlichen Kontoregelung hinzu. Die beiden Fälle haben dieselbe ausgeführte Menge, aber unterschiedliche verbleibende Kapazität.
Eine spätere Stornierungsanfrage beeinflusst nur den noch stornierbaren Teil. Sie macht ausgeführte Anteile nicht rückgängig. Die endgültige Kontoaufzeichnung sollte daher ausgeführte Geschäfte, den endgültigen Reststatus und etwaige Gebühren verbinden, statt Stornierung so zu behandeln, als hätte die gesamte ursprüngliche Order nie existiert.
Stornierung als Wettlauf mit der Ausführung behandeln
Zwischen der Entscheidung zu stornieren und dem Empfang des Ergebnisses kann eine Order weiter ausgeführt werden. Das Programm muss sowohl die Stornierungsantwort als auch zugehörige Ausführungen abgleichen. Ein lokaler Tastendruck belegt nicht, dass die verbleibende Menge vor einem weiteren Abgleich mit einer Gegenorder entfernt wurde.
Angenommen, das Konto ging von achtzehn verbleibenden Anteilen aus, doch fünf weitere wurden während der Stornierungsbearbeitung ausgeführt. Die endgültige Position umfasst siebzehn Anteile, während dreizehn entfernt werden, wenn die Stornierung für den Rest gelingt. Das Journal sollte die zusätzliche Ausführung erklären, statt sie als unmöglich zu kennzeichnen, weil bereits eine Stornierung angefordert worden war.
Ersetzen Sie nicht unmittelbar die gesamte ursprüngliche Menge nach einem Stornierungsversuch. Stellen Sie zunächst die tatsächlich verbleibende Exposition fest. Ersatz ist eine neue wirtschaftliche Entscheidung, die aktuelle Preise, aktuellen Kontozustand und die Grenzen der ursprünglichen Strategie verwenden sollte, einschließlich jeder Frist, die während des Stornierungsprozesses abgelaufen sein könnte.
Eine Übermittlung mit unbekanntem Ausgang aufklären
Fällt eine Verbindung nach der Übertragung aus, kann die ursprüngliche Order angenommen worden sein. Der nächste Schritt ist, diese Absicht anhand verfügbarer Order-, Handels- und Kontobelege zu untersuchen. Eine neue unverbundene Order zu erzeugen kann Exposition verdoppeln, selbst wenn der erste Versuch lokal erfolglos aussah.
Bewahren Sie die ursprünglichen Kennungen und die Reservierung auf, während die Untersuchung läuft. Verwenden Sie begrenzte Abfragen und dokumentiertes Wiederherstellungsverhalten. Lässt sich der Kontozustand nicht feststellen, pausieren Sie verwandte neue Übermittlungen und zeigen Sie dem zuständigen Betreiber die Unsicherheit. Eine Zeitüberschreitung sollte zu einem ausdrücklichen ungeklärten Zustand werden und nicht zu einer erfundenen Ablehnung.
Der Vergleich mit Kalshi-API-Handel hilft, dieses allgemeine Problem verteilter Systeme von handelsplatzspezifischen Schnittstellen zu trennen. Beide Kontexte erfordern Abgleich, doch Kennungen, Authentifizierung, Schemata und Ordersemantik müssen nach der jeweils aktuellen Dokumentation des Handelsplatzes behandelt und nicht zwischen Adaptern kopiert werden.
Zustand nach einer Verbindungstrennung wieder aufbauen
Streaming-Aktualisierungen sind für rasche Beobachtung nützlich, doch ein getrennter Client braucht einen Wiederherstellungsplan. Beschaffen Sie aktuelle Kontoinformationen, gleichen Sie offene Orders ab und rufen Sie relevante Geschäfte über die dokumentierten Schnittstellen ab. Vergleichen Sie dann den wiederhergestellten Zustand mit dem lokalen Journal, bevor Sie neue Exposition erlauben.
Nehmen Sie nicht an, wiederholte Nachrichten seien neue wirtschaftliche Ereignisse. Ein vor und nach der Wiederverbindung beobachtetes Geschäft sollte einmal zur Positionsaufzeichnung beitragen. Stabile Kennungen und Revisionsbehandlung ermöglichen das. Ein doppeltes Transportereignis sollte weder die ausgeführte Menge noch Gebühren verdoppeln.
Zeichnen Sie das ungewisse Intervall und die zu seiner Klärung verwendeten Belege auf. Kann die Integration keine vollständige Abdeckung feststellen, bewahren Sie diese Einschränkung auf. Die Kontoanzeige kann überprüfte Bestände neben einem ungeklärten Abgleichproblem zeigen, statt eine falsch präzise Gesamtsumme aus unvollständigen Streams darzustellen.
Handelsabrechnung von Ereignisfeststellung unterscheiden
Die Abrechnung eines Geschäfts überträgt die mit dem Kauf oder Verkauf verbundenen Vermögenswerte. Die Ereignisfeststellung bestimmt das Ergebnis des Prognosekontrakts nach seinen Regeln. Das sind getrennte Stufen. Ein bestätigter Kauf bedeutet nicht, dass das Ereignis entschieden ist, und ein scheinbares Ereignisergebnis beweist nicht, dass das Konto seine endgültige Auszahlung erhalten hat.
Führen Sie getrennte Aufzeichnungen für erworbene Positionen, die Marktergebnisfeststellung und jeden für das Konto geltenden Einlösungs- oder Auszahlungsprozess. Die relevanten Kennungen und Belege können abweichen. Diese Trennung ist besonders hilfreich, wenn die Position nach der anfänglichen Order lange offen bleibt.
Der Leitfaden zur Polymarket-Automatisierung ordnet diese Stufen in manuelle, beaufsichtigte und delegierte Abläufe ein. Entscheiden Sie, welche Stufen die Anwendung durchführen darf und welche Prüfung erfordern. Eine Befugnis zur Übermittlung eines begrenzten Handels sollte nicht als unbegrenzte Befugnis über jeden nachfolgenden Wallet-Vorgang interpretiert werden.
Den Polymarket-Kontoabgleich erklärbar machen
Der Polymarket-Kontoabgleich vergleicht die Anwendungsaufzeichnungen mit maßgeblichen Kontobelegen. Die Ausgabe sollte Positionen, offene Verpflichtungen, ausgeführte Mengen, Gebühren und ungeklärte Punkte erklären. Eine Guthabendifferenz ist ein zu untersuchendes Symptom und keine Zahl, die mit einer unerklärten Anpassung verborgen werden sollte.
Beim Teilausführungsbeispiel sollte eine prüfende Person die ursprüngliche Absicht über dreißig Anteile bis zur Ausführung von zwölf Anteilen und zum endgültigen Restzustand zurückverfolgen können. Haben spätere Geschäfte die Position verändert, sollten sie als getrennte Aufzeichnungen mit eigenen Ursprüngen erscheinen. Die endgültige Gesamtsumme sollte aus diesen Bestandteilen reproduzierbar sein.
Halten Sie den Abgleich ausreichend unabhängig, um Fehler im Übermittlungsweg zu erkennen. Vertraut er lediglich denselben lokalen Annahmen, aus denen die Order entstand, kann er den Fehler wiederholen, statt ihn zu finden. Lesbare Erklärungen sind wertvoll, weil ein Betreiber eine falsche Kontrakt- oder Kontozuordnung häufig schneller erkennt, als ein allgemeiner Abweichungscode sie offenlegt.
Polymarket-API-Handel anhand vollständiger Fälle überprüfen
Die Abnahme sollte eine Vollausführung, eine Teilausführung mit aktivem Rest, eine sofortige Teilausführung mit storniertem Rest, eine Ablehnung, einen Stornierungswettlauf und eine unbekannte Übermittlung abdecken. Jeder Fall sollte mit einem erklärbaren Kontozustand oder einem ausdrücklichen ungeklärten Zustand enden, der unangemessene Fortsetzung blockiert.
Der ältere Leitfaden zum Polymarket-API-Trading-Bot bietet eine umfassendere Sicht auf einen prüfbaren Client. Verwenden Sie die Lebenszyklusaufzeichnung, um das Umsetzungsverhalten einschließlich Neustart und Wiederherstellung zu bewerten, statt nur zu testen, ob ein Orderendpunkt Erfolg zurückgibt.
Eine vollständige Integration macht jeden wichtigen Übergang sichtbar: was beabsichtigt, autorisiert und übermittelt wurde, was ausgeführt wurde und was das Konto jetzt hält. Diese Aufzeichnung unterstützt sorgfältigen Betrieb bei sich weiterentwickelnder Dokumentation und macht Fehler diagnostizierbar, ohne eine Netzwerkantwort, ein mit einer Gegenorder abgeglichenes Geschäft und eine endgültig abgeglichene Position zu verwechseln.