> ## Documentation Index
> Fetch the complete documentation index at: https://www.helius.dev/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Solana-API für historische Accounts (Beta)

> Lies mit Helius getHistoricalAccountInfo und getHistoricalTokenAccountsByOwner (Beta) den Zustand eines Solana-Accounts für einen beliebigen vergangenen slot oder eine beliebige vergangene Transaktion.

> [!NOTE]
>
> Der historische Account-Zustand befindet sich in der Beta-Phase. Parameter, Preise, response-Formate und Datenabdeckung können sich ändern.

## Was ist der historische Account-Zustand?

Standardmäßige Solana-RPC-Methoden wie `getAccountInfo` und `getTokenAccountsByOwner` geben nur den aktuellen Zustand eines Accounts zurück. Validatoren speichern nur die neueste Version jedes Accounts. Daher ersetzt jeder Schreibvorgang den vorherigen. Auch der Transaktionsverlauf schließt diese Lücke nicht: `getTransaction` und `getBlock` geben Anweisungen, Protokolle und Saldoänderungen zurück, aber nicht die Account-Daten, die ein Programm geschrieben hat.

Die Methoden von Helius für historische Accounts geben Accounts so zurück, wie sie an einem vergangenen slot oder unmittelbar nach einer bestimmten Transaktion innerhalb dieses slots vorlagen. Da du den Zustand zwischen zwei Transaktionen im selben slot lesen kannst, siehst du genau, was eine Transaktion geändert hat. Das gilt auch, wenn ein Account innerhalb eines einzigen slots mehrfach beschrieben wurde. Verwende die Methoden für folgende Aufgaben:

* Prüfe die token-Salden einer Wallet zu einem bestimmten Zeitpunkt, etwa für Audits, Buchhaltung oder Steuererklärungen
* Debugge eine Transaktion, indem du die von ihr verwendeten Accounts direkt vor und nach ihrer Ausführung liest
* Lies die Accounts eines Protokolls, etwa Pools, Vaults oder Oracles, an einem vergangenen slot, ohne das Ledger selbst erneut abzuspielen

Diese RPC-Methoden gibt es exklusiv bei Helius. Sie sind kein Bestandteil der standardmäßigen Solana-RPC.

## Welche Methode sollte ich verwenden?

| Was du brauchst | Verwende diese Methode | Rückgabe |
| - | - | - |
| Einen Account an einer vergangenen Position | [`getHistoricalAccountInfo`](https://www.helius.dev/docs/de/api-reference/rpc/http/gethistoricalaccountinfo) | Den Account oder `null`, wenn er nicht existierte |
| Die token-Accounts einer Wallet an einer vergangenen Position | [`getHistoricalTokenAccountsByOwner`](https://www.helius.dev/docs/de/api-reference/rpc/http/gethistoricaltokenaccountsbyowner) | Eine Seite mit SPL-Token- und Token-2022-Accounts, optional für eine einzelne Mint |

Beide erwarten dieselben drei Parameter: eine Adresse, ein Abfrageobjekt zur Auswahl der Position im Verlauf und ein Konfigurationsobjekt.

## Verfügbarkeit und Preise

* **Tarife**: Business-[Tarife](https://www.helius.dev/docs/de/billing/plans.md) und höher.
* **Kosten**: 0 Credits pro Aufruf während der Beta-Phase (Preise können sich ändern).
* **rate limit**: `getHistoricalAccountInfo` erlaubt 100 requests pro Sekunde mit maximal 100 requests auf einmal. `getHistoricalTokenAccountsByOwner` erlaubt 10 requests pro Sekunde mit maximal 10 requests auf einmal. Diese Limits gelten unabhängig vom RPC-rate limit deines Tarifs. Darüber hinausgehende requests geben HTTP `429` zurück. Siehe [rate limits](https://www.helius.dev/docs/de/billing/rate-limits.md).
* **Netzwerk**: Nur Mainnet. Rufe die Methoden über den standardmäßigen Mainnet-endpoint `https://mainnet.helius-rpc.com` oder den [Gatekeeper](https://www.helius.dev/docs/de/gatekeeper/overview.md)-endpoint `https://beta.helius-rpc.com` auf. Devnet gibt den Fehler `-32601` zurück.

## Datenabdeckung

Der Verlauf ist ab slot 444,959,999 (7. September 2026) verfügbar. Das ist der letzte slot der Epoche 1029. Er enthält daher den Zustand zu Beginn der Epoche 1030. requests für frühere slots geben den Fehler `-32018` ("Account history not available") zurück.

## Position im Verlauf auswählen

Der zweite Parameter ist ein Abfrageobjekt mit zwei optionalen Feldern: `slot` und `transactionIndex`:

| Abfrage | Zurückgegebener Zustand |
| - | - |
| Nicht angegeben oder `{}` | Am neuesten indizierten slot, begrenzt auf das angeforderte commitment |
| `{ "slot": 445000000 }` | Am Ende von slot 445,000,000, nach allen Transaktionen und allen nicht transaktionsbezogenen Schreibvorgängen wie Epochen-Rewards |
| `{ "slot": 445000000, "transactionIndex": 10 }` | Unmittelbar nach Ausführung der Transaktion mit Index 10 in slot 445,000,000 |

`transactionIndex` erfordert `slot`.

Nicht transaktionsbezogene Schreibvorgänge wie Epochen-Rewards werden am Ende des slots angewendet. Eine Abfrage mit `transactionIndex` enthält sie nie, auch nicht bei der letzten Transaktion im slot. Um sie einzubeziehen, frage `slot` ohne `transactionIndex` ab.

### Zustand vor und nach einer Transaktion lesen

Lies den Account zweimal, um die Änderungen einer Transaktion zu untersuchen:

* **Nach der Transaktion**: Frage ihre eigenen Werte für `slot` und `transactionIndex` ab.
* **Vor der Transaktion**: Frage denselben Wert für `slot` ab und ziehe 1 von `transactionIndex` ab. Wenn die Transaktion die erste in ihrem slot ist (Index 0), frage den vorherigen slot ohne `transactionIndex` ab.

[`getTransactionsForAddress`](https://www.helius.dev/docs/de/rpc/gettransactionsforaddress) gibt `slot` und `transactionIndex` für jede Transaktion zurück. So kannst du dort die Position einer Transaktion ermitteln und direkt an diese Methoden übergeben.

```bash theme={"system"}
# State of the account right after the transaction at index 10 in slot 445000000
curl https://mainnet.helius-rpc.com/?api-key=YOUR_API_KEY \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "id": "1",
    "method": "getHistoricalAccountInfo",
    "params": [
      "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v",
      { "slot": 445000000, "transactionIndex": 10 },
      { "encoding": "jsonParsed" }
    ]
  }'
```

## lastUpdatedAt verstehen

Jeder zurückgegebene Account enthält `lastUpdatedAt`. Das ist die Position des Schreibvorgangs, der den empfangenen Zustand erzeugt hat:

```json theme={"system"}
"lastUpdatedAt": { "slot": 444999837, "transactionIndex": 700 }
```

* **`slot` und `transactionIndex`** verweisen auf den letzten Schreibvorgang an oder vor der abgefragten Position. Im obigen Beispiel gab eine Abfrage für slot 445,000,000 den Zustand zurück, den zuletzt die Transaktion mit Index 700 in slot 444,999,837 geschrieben hatte.
* **`transactionIndex: null`** bedeutet, dass der Schreibvorgang außerhalb einer Transaktion stattfand, etwa durch Epochen-Rewards.
* **`slot: 444959999` mit `transactionIndex: null`** bedeutet, dass sich der Account seit Beginn der Verlaufsabdeckung nicht geändert hat. Es bedeutet nicht, dass der Account in diesem slot beschrieben wurde.

## Bedeutung eines null-Werts

`value` ist `null`, wenn der Account an der abgefragten Position nicht existierte. Entweder war er noch nicht erstellt oder bereits geschlossen worden.

* **Eine response mit `null` enthält kein `lastUpdatedAt`**. Sie zeigt daher nicht, wann der Account erstellt oder geschlossen wurde. Verwende [`getTransactionsForAddress`](https://www.helius.dev/docs/de/rpc/gettransactionsforaddress), um diese Transaktionen zu finden.
* **Eine Adresse, die nie existiert hat**, gibt ebenfalls `null` und keinen Fehler zurück.
* **Ein slot vor Beginn der Verlaufsabdeckung** gibt für jede Adresse den Fehler `-32018` zurück, unabhängig davon, ob der Account existierte.

## Account-Verlauf rückwärts durchlaufen

Verwende `lastUpdatedAt` als Cursor, um alle bisherigen Zustände eines Accounts aufzulisten, beginnend mit dem neuesten. Frage nach jedem Lesevorgang die Position direkt vor dem erhaltenen Schreibvorgang ab:

| Empfangenes `lastUpdatedAt` | Nächste Abfrage |
| - | - |
| `{ "slot": S, "transactionIndex": N }`, wobei N größer als 0 ist | `{ "slot": S, "transactionIndex": N - 1 }` |
| `{ "slot": S, "transactionIndex": 0 }` | `{ "slot": S - 1 }` |
| `{ "slot": S, "transactionIndex": null }` | `{ "slot": S - 1 }` |

Beende den Vorgang, wenn `value` den Wert `null` hat. Das bedeutet, dass der gerade übersprungene Schreibvorgang den Account erstellt hat. Beende den Vorgang auch, wenn `lastUpdatedAt.slot` den Wert 444,959,999 erreicht, an dem die Verlaufsabdeckung beginnt.

```typescript theme={"system"}
const url = `https://mainnet.helius-rpc.com/?api-key=${process.env.HELIUS_API_KEY}`;
const COVERAGE_START_SLOT = 444959999;

type Position = { slot?: number; transactionIndex?: number };

async function getAccountHistory(address: string, start: Position = {}, maxStates = 100) {
  const states = [];
  let position = start;

  while (states.length < maxStates) {
    const response = await fetch(url, {
      method: "POST",
      headers: { "Content-Type": "application/json" },
      body: JSON.stringify({
        jsonrpc: "2.0",
        id: "1",
        method: "getHistoricalAccountInfo",
        params: [address, position, { encoding: "base64" }],
      }),
    });
    const { result, error } = await response.json();
    if (error) throw new Error(`${error.code}: ${error.message}`);

    const account = result.value;
    if (!account) break; // The account didn't exist before this write

    states.push(account);
    const { slot, transactionIndex } = account.lastUpdatedAt;
    if (slot <= COVERAGE_START_SLOT) break; // Reached the start of history coverage

    // Step to the position just before this write
    position = transactionIndex ? { slot, transactionIndex: transactionIndex - 1 } : { slot: slot - 1 };
  }

  return states; // Newest first
}
```

* **Accounts, die inzwischen geschlossen wurden**, geben am neuesten slot `null` zurück. Übergib eine `start`-Position aus einem Zeitpunkt, an dem der Account noch existierte.
* **Nicht transaktionsbezogene Schreibvorgänge** springen zum vorherigen slot. Wenn derselbe Account zuvor in diesem slot auch durch eine Transaktion beschrieben wurde, überspringt der Durchlauf diesen Zustand.
* **Um den Verlauf vorwärts zu durchlaufen**, liste die Transaktionen des Accounts mit [`getTransactionsForAddress`](https://www.helius.dev/docs/de/rpc/gettransactionsforaddress) und `sortOrder: "asc"` von der ältesten zur neuesten auf. Lies dann den Zustand an den Werten `slot` und `transactionIndex` jeder Transaktion.

## response-Kontext

`context.slot` in jeder response ist der neueste slot, den Helius beim Verarbeiten des requests indiziert hatte. Es ist nicht der abgefragte slot. Verwende `slot` aus deinem request oder `lastUpdatedAt`, um die empfangenen Daten einzuordnen.

## Konsistent paginieren

`getHistoricalTokenAccountsByOwner` gibt die Ergebnisse seitenweise zurück. Jede response enthält `value.accounts` und `value.paginationKey`.

* **Übergib `paginationKey` erneut** im Konfigurationsobjekt, um die nächste Seite abzurufen.
* **Beende den Vorgang erst, wenn `paginationKey` den Wert `null` hat.** Eine Seite kann kurz oder leer sein und trotzdem weitere Ergebnisse enthalten.
* **Verwende für jede Seite denselben Wert für `slot`.** Wenn du `slot` weglässt, liest jede Seite den neuesten indizierten slot. Deine Seiten können dann von unterschiedlichen Zeitpunkten stammen.
* **Setze `limit`** auf einen Wert zwischen 1 und 5.000. Der Standardwert ist 5.000.

## Codierungen und geparste Daten

* **Unterstützte Codierungen** sind `base64` (Standard), `base64+zstd` und `jsonParsed`. `base58` und `binary` werden nicht unterstützt.
* **`jsonParsed`-token-Accounts** verwenden die Dezimalstellen der Mint an der abgefragten Position. Dadurch bleiben die Beträge korrekt, auch wenn sich die Mint inzwischen geändert hat. Wenn die Mint an dieser Position nicht gelesen werden kann, verwendet der Account stattdessen base64.
* **`dataSlice`** funktioniert genauso wie in `getAccountInfo`.

## Commitment

`commitment` akzeptiert `finalized` (Standard) und `confirmed`. `processed` wird nicht unterstützt. Ein `slot`, das neuer ist, als das angeforderte commitment zulässt, gibt den Fehler `-32004` zurück.

## Fehler

| Code | Bedeutung | Vorgehensweise |
| - | - | - |
| `-32018` | Der slot liegt vor Beginn der Verlaufsabdeckung | Frage slot 444,959,999 oder einen späteren slot ab |
| `-32004` | Der slot ist neuer, als das angeforderte commitment zulässt | Verwende `confirmed` oder frage einen älteren slot ab |
| `-32602` | Ungültige Parameter | Prüfe die Fehlermeldung für das jeweilige Feld |
| `-32601` | Methode nicht gefunden | Rufe deinen Helius-Mainnet- oder Gatekeeper-endpoint auf. Methoden für historische Accounts sind in Devnet nicht verfügbar |

## Häufig gestellte Fragen

### Wie erhalte ich den Zustand eines Solana-Accounts an einem bestimmten slot?

Rufe `getHistoricalAccountInfo` mit der Adresse und `{ "slot": S }` auf. Die Methode gibt den Account so zurück, wie er am Ende von slot S vorlag. Das Format entspricht `getAccountInfo`.

### Kann ich einen Account zwischen zwei Transaktionen im selben slot lesen?

Ja. Füge der Abfrage `transactionIndex` hinzu, um den Zustand des Accounts unmittelbar nach der Ausführung dieser Transaktion abzurufen. Siehe [Zustand vor und nach einer Transaktion lesen](#zustand-vor-und-nach-einer-transaktion-lesen).

### Wie weit kann ich zurückgehen?

Der Verlauf beginnt am 7. September 2026 bei slot 444,959,999. Frühere slots geben den Fehler `-32018` zurück.

### Welche Tarife enthalten Methoden für historische Accounts?

Business-Tarife und höher. Während der Beta-Phase kosten Aufrufe 0 Credits. Die Preise können sich ändern. Die Methoden sind nur in Mainnet verfügbar.

### Welche rate limits gelten?

`getHistoricalAccountInfo` erlaubt 100 requests pro Sekunde und `getHistoricalTokenAccountsByOwner` erlaubt 10 requests pro Sekunde. Beide Limits gelten unabhängig vom RPC-rate limit deines Tarifs. Siehe [Verfügbarkeit und Preise](#verfügbarkeit-und-preise).

### Wie erhalte ich jeden früheren Zustand eines Accounts?

Gehe mithilfe von `lastUpdatedAt` von einem Schreibvorgang rückwärts zum vorherigen. Siehe [Account-Verlauf rückwärts durchlaufen](#account-verlauf-rückwärts-durchlaufen).

### Benötige ich ein neues SDK?

Nein. Dies sind JSON-RPC-Methoden. Daher funktioniert jeder HTTP-Client. Standardmäßige Solana-Clientbibliotheken enthalten sie nicht. Sende den request deshalb wie in den obigen Beispielen direkt.

## Nächste Schritte

> [card] [getHistoricalAccountInfo](https://www.helius.dev/docs/de/api-reference/rpc/http/gethistoricalaccountinfo.md)
>
> Lies einen einzelnen Account an einem vergangenen slot oder einer vergangenen Transaktion

> [card] [getHistoricalTokenAccountsByOwner](https://www.helius.dev/docs/de/api-reference/rpc/http/gethistoricaltokenaccountsbyowner.md)
>
> Liste die token-Accounts einer Wallet an einem vergangenen slot auf

> [card] [getTransactionsForAddress](https://www.helius.dev/docs/de/rpc/gettransactionsforaddress.md)
>
> Ermittle den slot und den transactionIndex der Transaktionen, die du untersuchen möchtest

> [card] [Historical data overview](https://www.helius.dev/docs/de/rpc/historical-data.md)
>
> Transaktionsverlauf, Übertragungen und weitere Archivmethoden


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.