Robinhood Chain Testnet-Faucet

Fordern Sie Test-ETH mit Ihrem eigenen API key an: Kontoanforderungen, Anforderungslimits, akzeptierte Transaktionen und Fehlerbehandlung.

Verwenden Sie das Faucet, um Test-ETH für Transaktionen im Robinhood Chain Testnet (robinhood_testnet, Chain ID 46630) zu erhalten. Die Anforderung ist kostenlos und verbraucht keine CU; nachfolgende Testnet-RPC-Aufrufe nutzen die reguläre CU-Abrechnung.

Erster Schritt: Eine Anforderung senden mit Ihrem eigenen API key und der Empfängeradresse unter Verwendung des unten stehenden curl-Beispiels.
Abgeschlossen, wenn: HTTP 202 und ein tx_hash die Annahme bestätigen; verwenden Sie die unten stehende Transaction-Receipt-Abfrage, um die Aufnahme auf der Blockchain zu prüfen, bevor Sie die Anforderung als bestätigt betrachten.

Testnet-Parameter und Zugriffsoptionen.

Vor der Anforderung

Registrieren Sie ein BlockVectra-Konto und verwenden Sie einen Ihrer eigenen API keys. Erstellen Sie einen Key in der Konsole oder folgen Sie dem Leitfaden zur programmatischen Registrierung.

Verwenden Sie 0x, gefolgt von 40 Hexadezimalzeichen, entweder in Kleinbuchstaben oder gemischter Groß-/Kleinschreibung mit gültiger EIP-55-Prüfsumme. Antworten verwenden Adressen in Kleinbuchstaben; unterschiedliche Schreibweisen derselben Adresse teilen sich dasselbe Anforderungslimit.

Eine Anforderung senden

Rufen Sie POST https://api.blockvectra.com/v1/faucet/robinhood_testnet mit Content-Type: application/json und Ihrem Key in x-api-key auf. Dieser Endpunkt liest keinen Key aus dem URL-Pfad oder aus Authorization.

Ersetzen Sie {api_key} durch Ihren Key und die Beispieladresse durch Ihre Empfängeradresse:

curl -i "https://api.blockvectra.com/v1/faucet/robinhood_testnet" \
  -H "Content-Type: application/json" \
  -H "x-api-key: {api_key}" \
  -d '{"address":"0x1111111111111111111111111111111111111111"}'

Der JSON-Body enthält nur address und darf maximal 64 KiB groß sein. Unbekannte Felder oder ungültiges JSON geben 400 invalid_request zurück. Verwenden Sie den exakten Endpunkt ohne Query-Parameter.

Anforderungsfenster und Limits

Jede akzeptierte Anforderung sendet 0,001 Test-ETH (1000000000000000 Wei).
Jedes Konto und jede Empfängeradresse kann eine neue Anforderung pro rollierenden 24 Stunden durchführen. Die Verwendung eines anderen Keys auf demselben Konto erhöht das Limit nicht.
Das Faucet akzeptiert maximal 1.000 neue Anforderungen pro UTC-Tag über alle Benutzer hinweg.
Anfragen teilen sich ein Limit von 5 Anfragen pro Sekunde pro Key mit /v1/account.

next_eligible_at ist der Annahmezeitpunkt plus 24 Stunden, angegeben als RFC 3339 UTC-Zeitstempel. Die Fenster für Konto und Adresse werden nicht um UTC-Mitternacht zurückgesetzt. Ein Anforderungslimit-429 enthält error.data.scope (account, address oder global) und error.data.next_eligible_at; bei global ist der Zeitstempel der Beginn des nächsten UTC-Tages. Ein Anforderungsfrequenz-429 hat keinen scope.

Akzeptiert bedeutet nicht bestätigt

HTTP 202 bedeutet akzeptiert, nicht erfolgreich in die Blockchain aufgenommen. Die JSON-Antwort enthält:

Feld	Bedeutung
`chain` / `chain_id`	`robinhood_testnet` / `46630`
`address`	Empfängeradresse in Kleinbuchstaben
`amount_wei`	Anforderungsbetrag als dezimale Ganzzahl-Zeichenkette
`tx_hash`	Stabiler Hash der akzeptierten Transaktion
`next_eligible_at`	Nächster Berechtigungszeitpunkt für das rollierende Fenster

Wiederholen Sie dieselbe normalisierte Adresse desselben Kontos innerhalb von 24 Stunden, wird die ursprüngliche 202-Antwort und derselbe tx_hash zurückgegeben, auch wenn ein anderer gültiger Key dieses Kontos verwendet wird. Es wird keine weitere Zahlung gesendet. Wenn eine Antwort verloren geht, wiederholen Sie die Anfrage für dieselbe Adresse mit demselben Konto.

Überprüfen Sie die Transaktion über den vorhandenen Testnet-RPC-Endpunkt. Ersetzen Sie {tx_hash} durch den Hash aus der akzeptierten Antwort; diese RPC-Abfrage nutzt die normale CU-Abrechnung:

curl -s "https://api.blockvectra.com/v1/robinhood_testnet" \
  -H "Content-Type: application/json" \
  -H "x-api-key: {api_key}" \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_getTransactionReceipt","params":["{tx_hash}"]}'

Fehler und Wiederholungsversuche

Der Fehler-Envelope enthält error.code, error.message und error.data. error.data.reason entspricht error.code; docs_url, retryable und request_id liefern die Fehlerreferenz, Wiederholungsrichtlinie und die Anfragekennung. Warten Sie bei jedem 429 oder 503 die im Response-Header Retry-After angegebene Anzahl an Sekunden ab, bevor Sie den Versuch wiederholen. Gehen Sie ohne eine akzeptierte Antwort nicht davon aus, dass Test-ETH gesendet wurde.

HTTP	Fehlercode	Vorgehensweise
400	`invalid_address`	Adressformat oder EIP-55-Prüfsumme korrigieren; `error.data.field` ist `/address`.
400	`invalid_request`	Gültiges JSON senden, das nur `address` enthält.
401	`missing_api_key` / `invalid_api_key`	Gültigen Key in `x-api-key` bereitstellen.
403	`key_expired`	Neuen API key erstellen.
404	`not_found`	Pfad, Chain, POST-Methode und das Fehlen von Query-Parametern prüfen; das Faucet ist möglicherweise nicht verfügbar.
413	`request_too_large`	Body verkleinern, sodass er in 64 KiB passt.
429	`rate_limited`	Auf `Retry-After` warten; `scope` und `next_eligible_at` prüfen, falls vorhanden.
503	`faucet_empty`	Das Faucet verfügt über unzureichende Mittel für die Anforderung und Gebühren. Auf `Retry-After` warten.
503	`service_unavailable`	Die Verarbeitung von Anforderungen ist vorübergehend nicht verfügbar, oder eine vorherige Anforderung hat noch keinen Receipt. Auf `Retry-After` warten.
503	`auth_unavailable` / `upstream_unavailable`	Auf `Retry-After` warten, dann wiederholen.

Siehe die Fehlerreferenz oder /errors.json für maschinenlesbare Hinweise und den Robinhood Chain-Leitfaden für den RPC-Zugriff.

Fahren Sie mit dem Robinhood Chain Testnet-RPC-Starter für schlüssellose Leseabfragen und WebSocket-Logs fort. Die öffentliche RPC-URL und unterstützte Methoden finden Sie auf der Testnet-Chain-Seite.