Zum Hauptinhalt springen
Die Wallet API befindet sich in der Betaphase. Endpoints und response-Formate können sich ändern.

Übersicht

Der Historical Balance endpoint beantwortet folgende Frage: Wie hoch war der Kontostand dieser Wallet für einen bestimmten token (oder natives SOL) zu einem bestimmten Zeitpunkt in der Vergangenheit? Während der Balances endpoint die aktuellen Bestände meldet, gibt balance-at die Bestände zu einem beliebigen Zeitstempel, Datum mit Uhrzeit oder slot zurück. Er sucht nach der einzelnen neuesten Transaktion zum oder vor dem angefragten Zeitpunkt, an der die Wallet und der token beteiligt waren. Anschließend liest er den Kontostand nach der Transaktion aus dieser Transaktion aus. Der Kontostand nach einer Transaktion gilt bis zur nächsten Transaktion. Daher entspricht der „Kontostand zum Zeitpunkt T“ dem Kontostand nach der letzten relevanten Transaktion, deren Blockzeit (oder slot) bei oder vor T liegt. Für typische Wallets ist dies ein exakter Wert und keine Schätzung.
  • Tokens (SPL / Token-2022): Wird aus den token-Kontoständen nach der Transaktion gelesen und über alle token-Konten der Wallet für diesen Mint summiert.
  • Natives SOL: Wird aus den Lamport-Kontoständen nach der Transaktion gelesen. Adressiere natives SOL mit dem Pseudo-Mint So11111111111111111111111111111111111111111.

Wann du dies verwenden solltest

Verwende die Historical Balance API für folgende Zwecke:
  • PnL-Berechnung: Ermittle die Bestände am Anfang und Ende eines Zeitraums.
  • Kostenbasis und Steuerlose: Rekonstruiere Kontostände bei Erwerbs- oder Veräußerungsereignissen.
  • Streitbeilegung: Weise nach, was eine Wallet zu einem bestimmten Zeitpunkt hielt.
  • Snapshot-Prüfung: Prüfe den Kontostand einer Wallet bei einem Airdrop- oder Governance-Snapshot.
  • Buchhaltung und Audits: Rekonstruiere den Wallet-Zustand an Periodengrenzen.

Schnellstart

token-Kontostand zu einem Zeitstempel

Rufe den USDC-Kontostand einer Wallet zu einem Unix-Zeitstempel ab:

token-Kontostand zu einem Datum mit Uhrzeit

Übergib statt eines Zeitstempels ein menschenlesbares Datum mit Uhrzeit. Denke daran, das Leerzeichen in der URL als %20 zu codieren:

Kontostand von nativem SOL an einem slot

Verwende für natives SOL den Pseudo-Mint So11111111111111111111111111111111111111111. slot-basierte Abfragen sind exakt und deterministisch:

Abfrageparameter

Du musst genau einen der Parameter time, datetime oder slot angeben. Wenn du keinen oder mehrere angibst, wird ein 400-Fehler zurückgegeben.

Datums- und Uhrzeitformate

Akzeptierte Formate:
  • Nur Datum: 2025-01-10 → Mitternacht UTC
  • Datum + Uhrzeit: 2025-01-10 19:20:00 oder 2025-01-10T19:20:00 (Sekunden optional) → UTC
  • Mit expliziter Zeitzone: 2025-01-10T19:20:00Z, 2025-01-10T19:20:00+02:00, 2025-01-10T19:20:00-05:00 → Wird wie angegeben berücksichtigt
Ungültige oder nicht unterstützte Formate (01/10/2025, 2025-13-10, 2025-02-30) geben einen 400-Fehler zurück.
Datums- und Uhrzeitangaben werden standardmäßig als UTC interpretiert. Eine Angabe ohne Zeitzone wie 2025-01-10 19:20:00 wird als UTC und nicht als deine lokale Zeit behandelt. Gib einen expliziten Zeitzonenversatz an, wenn du eine andere Zeitzone meinst. Das Feld requested.time der response zeigt die aufgelösten Epoch-Sekunden, damit du die Interpretation prüfen kannst.

response-Format

Hinweise zu den Feldern

  • wallet: Gibt die abgefragte Wallet-Adresse unverändert zurück.
  • mint: Gibt den abgefragten Mint unverändert zurück, bei nativem SOL den SOL-Pseudo-Mint.
  • isNative: true, wenn das Ergebnis natives SOL ist.
  • balance: Menschenlesbarer Betrag als Dezimalzeichenfolge. Es handelt sich um eine Zeichenfolge und nicht um eine Zahl, damit große Kontostände nicht an Genauigkeit verlieren. Nachgestellte Nullen werden entfernt ("1.5" statt "1.500000").
  • balanceRaw: Exakter Betrag in der kleinsten Einheit (Lamports für SOL) als Zeichenfolge.
  • decimals: Dezimalstellen des tokens (9 für SOL).
  • requested: Gibt die Abfrage unverändert zurück. Wenn datetime verwendet wird, enthält time zusätzlich die aufgelösten Epoch-Sekunden. Dadurch ist die UTC-Interpretation sichtbar.
  • asOf: Die Transaktion, aus der der Kontostand gelesen wurde (slot, blockTime, signature).
asOf: null bedeutet null und ist kein Fehler. Wenn für die Wallet zum oder vor dem angefragten Zeitpunkt keine passende Transaktion vorhanden war, gibt der endpoint 200 mit balance: "0" und asOf: null zurück. Die Wallet hatte den token bis dahin schlicht nicht gehalten.

Anwendungsfälle

Kontostandsänderung über einen Zeitraum

Vergleiche die Bestände zu zwei Zeitpunkten:

Prüfung der Snapshot-Berechtigung

Prüfe, ob eine Wallet an einem Snapshot-slot einen token hielt:

Best Practices

  • Verwende slot für deterministische Ergebnisse. time und datetime werden über die von Validatoren gemeldeten Blockzeiten aufgelöst, die um einige Sekunden abweichen können. Wenn exakte Reproduzierbarkeit wichtig ist, etwa bei Snapshots oder Audits, frage nach slot ab.
  • Parse Kontostände als Zeichenfolgen. balance und balanceRaw sind Zeichenfolgen, um die Genauigkeit zu erhalten. Verwende BigInt(balanceRaw) oder Ganzzahlen mit beliebiger Genauigkeit in deiner Sprache für Berechnungen. Konvertiere die Werte nicht in Gleitkommazahlen.
  • Behandle asOf: null als null. Ein null asOf ist eine erfolgreiche response und bedeutet, dass die Wallet bis zum angefragten Zeitpunkt keine Aktivität für diesen token hatte. Behandle dies nicht als Fehler.
  • Speichere historische Ergebnisse im Cache. Ein Kontostand zu einem vergangenen Zeitpunkt ändert sich nie. Speichere die Ergebnisse dauerhaft im Cache, um wiederholte API-Aufrufe zu vermeiden.

Häufige Fehler

Einschränkungen

  • Bei Wallets mit mehreren token-Konten kann der Wert zu niedrig sein. Der Kontostand wird aus der einzelnen neuesten passenden Transaktion gelesen. Der übliche Fall mit einem zugeordneten token-Konto pro Mint ist exakt. Wenn eine Wallet denselben Mint über mehrere token-Konten hält und die neueste Transaktion nur einige davon betraf, kann der ermittelte Wert zu niedrig sein.
  • Genauigkeit von nativem SOL bei sehr großen Kontoständen. Bei SOL-Kontoständen über etwa 9.007.199 SOL (2⁵³ Lamports) kann vorgelagert Genauigkeit verloren gehen. token-Beträge sind davon nicht betroffen.
  • Die Genauigkeit von time/datetime hängt von den durch Validatoren gemeldeten Blockzeiten ab, die um einige Sekunden abweichen können. Verwende slot für exakte, deterministische Ergebnisse.
  • Ein token pro request. Es gibt keine Batch-Form für mehrere Mints oder „alle Kontostände zum Zeitpunkt T“.

Nächste Schritte

Wallet Balances

Rufe die aktuellen token- und NFT-Bestände einer Wallet mit USD-Werten ab.

Wallet API Overview

Alle Endpoints der Wallet API und gemeinsamen Konventionen.

API Reference

request- und response-Schemas für historische Kontostände.