Rand Protocol
Dokumentation
Referenz

Explorer-API

Eine Zusammenfassung der REST-API und des WebSocket-Feeds von RandScan unter randscan.org – was der Explorer einer abgeschirmten Chain bereitstellen kann, die Endpunkte und die Ratenbegrenzungen – mit einem Link zur vollständigen Anleitung.

Verwenden Sie die API des Explorers, um chain 20 aus einem Skript, einem Bot oder einem Backend zu lesen, ohne einen Node zu betreiben. Die vollständige Anleitung mit allen Feldern steht im Explorer-Repository unter randscan.org/docs/api.md; diese Seite ist die Zusammenfassung.

Basis-URLhttps://randscan.org/api/v1
WebSocketwss://randscan.org/ws
anonym60 Anfragen pro Minute und IP
mit API-Schlüssel600 Anfragen pro Minute; Schlüssel unter randscan.org/dashboard, gesendet als Authorization: Bearer rsk_… oder X-API-Key

Was der Explorer einer abgeschirmten Chain anzeigen kann

Diese API kennt nirgends Konten, Guthaben, Absender oder Empfänger, und seit chain 14 gibt es auf einem Bundle auch kein öffentliches Asset mehr: Ein Transfer von RAND und ein Transfer eines beliebigen RPL-Tokens haben dieselbe Form. Geliefert werden: jeder Block; das Hidden-Asset-Bundle jeder Transaktion, wie veröffentlicht (Anchor, vier Nullifier, vier Commitments, Gebühr, burn_a, burn_r, burn_asset, Zeit, Größen von Proof und Envelope und seit chain 17 die auth_commit und die Größe des Auth-Proofs); die Aktion, die eine Transaktion ausgeführt hat, und ihre öffentlichen Felder, einschließlich der Registrierung, der Mints und der Burns eines RPL-Tokens, der Bridge-Governance-Aktionen und des Zustandsübergangs eines RPL-2-invoke; das RPL-Token-Register; die Zellen und der Vault eines Programms; der Commitment-Baum Blatt für Blatt; die Nullifier-Menge; das Validator-Register; das Supply-Audit; der öffentliche Zustand der Bridge, einschließlich ihrer Mint-Pause und des PQ-Guardian-Sets. Welches Asset ein Transfer bewegt hat, zeigt nur ein Viewing-Key oder ein Transaktionsschlüssel, im Browser. GET /accounts/:address antwortet mit 410 { "error": "no_accounts" }.

Konventionen: Beträge sind Dezimalzeichenketten in Einheiten. Ein Betrag, dessen asset_index einen anderen Token als RAND (Index 0) benennt, steht in der kleinsten Einheit dieses Tokens, nicht in den neun Dezimalstellen von RAND; lösen Sie den Index über GET /tokens/:id auf, bevor Sie dividieren. registration_fee und next_index sind die beiden Felder, die der Explorer als einfache JSON-Zahlen liefert; Hashes, Programm-IDs, Commitments und Nullifier bestehen aus 64 kleingeschriebenen Hexadezimalzeichen; Validator-Adressen sind base58; Höhen sind Dezimalzahlen ab 0; indiziert werden nur committete Blöcke, ein Block in der API ist also final. Listen akzeptieren page (ab 1) und limit (1 bis 100, Standard 20), liefern { "data": [...], "pagination": { page, limit, total, total_pages, has_next, has_prev } } und sind nach Neuheit sortiert, neueste zuerst. Fehler haben die Form { "error", "message", "code" } mit 400, 404, 410, 429 oder 500.

Endpunkte

Methode und Pfadliefert
GET /healthStatus des Explorers und Verzug des Indexers
GET /statsChain-ID, Höhe, View, Baumgröße, Validator-Anzahlen, Gesamt-Stake, Supply, Anzahl der Programme, durchschnittliche Blockzeit, Epoche, den Genesis-Hash und den Build des Nodes; hc_bundle und hc_auth; limits (die fünf Genesis-Obergrenzen, dann envelope_bytes, hardening_v6, hc_auth, der Genesis-gas_price und byte_price, gas_metering, bundle_gas_limit, adjust_bps und auf einem Node ab v0.6.8 program_state); gas_prices, die aktuellen Preise an der Spitze. limits enthält nicht die übrigen neuen Felder von v0.6.8 (binding_domain, proof_window_blocks, die Preisobergrenzen, admission_by_vote, testnet): Lesen Sie diese über rand_getLimits des Nodes
GET /supplydas Supply-Audit des Nodes unverändert, einschließlich der vier vesting_*-Zähler, auf chain 20 alle "0", da dessen Genesis keinen vesting-Abschnitt hat, sowie program_rand_out und program_rand_held von RPL-2, das aus Programm-Vaults ausgezahlte RAND und das RAND, das sie noch halten
GET /bridgeder öffentliche Zustand der Bridge: emitter, emitters, guardian_set_index, guardians, pq_guardians, mint_paused, pause_nonce, list_nonce, pause_key, registration_fee, burn_sequence, next_index (seit chain 14 null), rotation_nonce, rules_v2 (mit global_minted_in_window und global_mint_headroom), min_inbound_sequence, assets und endpoints, die eigene Darstellung des Explorers für jeden Emitter, so wie ihn seine Quell-Chain ausgibt. Die fees, rotation_rules und pending_rotations des Nodes ab v0.6.8 liefert er nicht: Lesen Sie diese über rand_getBridgeState
GET /bridge/assetseine Zeile pro Backing: die Registerzeile (index, chain, token, asset_id, locked, minted_today, mint_cap_per_day und auf einem Node ab v0.6.8 minted_in_window, mint_window_secs und mint_headroom, die größte Einzahlung, die die Obergrenzen jetzt zulassen), verbunden mit symbol, name, decimals und backings sowie den indizierten Summen. Pro Backing: burns, burned, outstanding (das locked des Registers) und deposits/deposited nur, wenn der Token ein einziges Backing hat (sonst null: Eine Einzahlung benennt den Token, den sie geminted hat, nicht die dafür gesperrte Münze). Pro Token, identisch in jeder Zeile mit demselben index: token_deposits, token_deposited, token_burns, token_burned, first_height, last_height; zählen Sie beim Summieren jeden index einmal
GET /bridge/tokensdie Token-Allowlist, eine statische Liste: USDT und USDC auf Ethereum, BSC, Tron und Solana, wobei USDC auf Tron eingestellt wurde
GET /tokensdas gesamte RPL-Token-Register, wie vom Node zwischengespeichert: enabled, registration_fee, next_index, tokens
GET /tokens/:idein Token nach Registerindex, 64-stelliger Hex-ID oder Textform rpl1…, dazu deploy_tx und supply_history; 404, wenn keiner passt
GET /nodesder Node des Explorers und seine Peers, mit Geolokalisierung
GET /proversdie delegierten Prover, die der Explorer kennt (seine eigene Liste; die Chain führt kein Verzeichnis darüber): ob jeder auf seinen prover_info antwortet, seine Kapazität und Gebühr und wo seine Hosts stehen
GET /blocks?page&limit&proposer, GET /blocks/latest?limit, GET /blocks/:idBlöcke, nach Höhe oder Hash
GET /transactions?page&limit&kind&height&validator&program, GET /transactions/latest, GET /transactions/:hashTransaktionen; kind ist transfer, mint, deploy, call, bond, unbond, withdraw, bridge_attest, bridge_burn, register_token, token_mint, set_authority, token_burn, pause_mints, unpause_mints, register_bridged_token, list_backing, invoke. Ein token_transfer gibt es nicht: Ein Transfer eines beliebigen RPL-Tokens ist transfer
GET /transactions/:hash/envelopesdie Notes, die eine Transaktion samt ihren Envelopes erzeugt hat: die vier Slots des Bundles, Dummies eingeschlossen, dazu die von der Chain berechneten Notes, die eine bridge_attest-Einzahlung, ein token_mint, der anfängliche Mint eines register_token oder die Auszahlungen eines invoke anhängen; bei einem Call h_in und das versiegelte Eingabeprotokoll
GET /envelopes?from_leaf&limitBlätter mit Envelopes, älteste zuerst, bis zu 1.000 pro Seite, für einen Verlaufsscan
GET /notes?page&limit, GET /notes/:idBaumblätter, nach Commitment oder Blattindex
GET /nullifiers/:nfdie Transaktion, die einen Nullifier veröffentlicht hat
GET /validators, GET /validators/:addressdas Register, mit share_percent, blocks_proposed und zuletzt vorgeschlagener Höhe
GET /programs?page&limit, GET /programs/:iddeployte Programme (base_pc, words_len, code_hash, public_words_len, public_digest) mit Call- und Invoke-Anzahlen; die jüngsten Calls und Invokes eines Programms und sein program_state, live vom Node gelesen: vault (pro Asset), die ersten 100 cells in Schlüsselreihenfolge und cells_next
GET /programs/:id/cells?after&limiteine Seite der Zellen des Programms in Schlüsselreihenfolge, live vom Node (limit 1 bis 1.000, Standard 100): { "cells", "next" }; 404 auf einer Chain ohne program_state-Abschnitt
GET /search?q=Blöcke, Transaktionen, Programme, Notes, Nullifier und Validatoren
curl -s https://randscan.org/api/v1/stats
curl -s https://randscan.org/api/v1/tokens/1
curl -s https://randscan.org/api/v1/transactions/8aa13d1f76d28f63a46c30bb09ef44b1ba35083ca80ba7301997f98e5f783666

Eine Transaktionszusammenfassung (ein Faucet-mint von 10 RAND bei Höhe 102.197 von chain 18):

{
  "hash": "a20b…feb5", "height": 102197, "block_hash": "f362…a06f", "tx_index": 0,
  "kind": "mint", "fee": "0", "timestamp_ms": 1790777106034,
  "has_bundle": false, "program": null, "validator": "EdrEC2QRQrQF64iRXxF9927jNj6RidiHHByzx5xD6F1e",
  "amount": "10000000000", "asset_index": null
}

amount ist nur bei den Arten mit öffentlichem Betrag gefüllt — mint, bond, unbond, withdraw, bridge_attest, bridge_burn, token_mint, token_burn und ein register_token mit anfänglichem Mint — und ist bei einem Transfer null, dessen asset_index ebenfalls stets null ist. has_bundle ist false für mint, unbond, withdraw, pause_mints und unpause_mints, die kein Bundle tragen und keine Gebühr zahlen. Die Detailansicht ergänzt chain_id, bundle und je nach Art: bei einem Deploy words_len; bei einem Call call_proof_len, input_envelope_len und receipt (tx, program, tier, outputs, height, index, h_in, h_pub); bei einem Bond registered; bei einem Unbond oder Withdraw action_nonce; bei einer Bridge-Attestierung attestation_len, recipient, note_time, deposit_r, commitment, pq_signers; bei einem Bridge-Burn relayer_fee, to_chain, bridge_to, bridge_token; bei einer RPL-Aktion token_action (die eigenen Felder der Aktion, nach kind getaggt), mit recipient, note_time, deposit_r für eine geminte Note und action_nonce für einen token_mint oder set_authority; bei einer Bridge-Governance-Aktion bridge_governance, mit pq_signers bei allen außer pause_mints; bei einem invoke call_proof_len, input_envelope_len, receipt und transition (die Darstellung des Nodes: die gelesenen und geschriebenen Zellen, der inflow und jede pays- und mints-Note mit ihren recipient, time, r und cm). Eine Art von v0.6.8, die dieser Explorer-Build nicht kennt (admit_validator, slash_equivocation, die _v2-Rotationen, cancel_rotation), ist other.

Auf chain 20 ist mit Bridge-Gebühren der amount einer bridge_attest und eines bridge_burn der Bruttobetrag: der Betrag, den die Guardians signiert haben, oder der Betrag, den das Bundle verbrannt hat. Den Netto-Einzahlungsbetrag, den freigegebenen Betrag und die Gebühren-Note liefert der Explorer nicht; lesen Sie sie über rand_getTransaction des Nodes (deposit_amount, release_amount, fee_note) und rand_getBridgeBurn. Der Burn von 0.999 zUSD bei Höhe 2.899 steht hier als "amount": "99900000"; die Guardians haben eine Freigabe von 99800100 signiert.

Das Bundle in einer Transaktionsdetailansicht ist das Hidden-Asset-Bundle, ohne Asset-Feld und ohne zweites Bundle bei einem Burn. Dieses hat den Call im obigen curl-Beispiel bezahlt, bei Höhe 98.335 von chain 18; diese Transaktion gibt es auf chain 20 nicht, wo das dritte curl mit 404 antwortet:

"bundle": {
  "anchor": "b814…b1ed",
  "nullifiers": ["49d4…a766", "3363…61ea", "aac0…fcfc", "546c…3efd"],
  "commitments": ["b52b…4f7b", "9ddd…0448", "5fa7…1630", "2827…8343"],
  "fee": "6191437", "burn_a": "0", "burn_r": "0", "burn_asset": 0, "time": 98185,
  "proof_len": 1504260, "envelope_len": [1860, 1860, 1860, 1860],
  "auth_commit": "0bda…6512", "auth_proof_len": 1367303
}

auth_commit und auth_proof_len gehören zur geteilten Autorisierung (chain 17 und später, wo limits.hc_auth gesetzt ist): Der Bundle-Proof wird aus dem Viewing-Key erzeugt und veröffentlicht auth_commit; ein zweiter, kleiner Proof über den Spend-Key, an dieselbe Transaktion gebunden, muss damit übereinstimmen. Beide Proofs werden nur mit ihrer Länge angegeben. Jedes Envelope auf chain 20 hat 1.860 Bytes (limits.envelope_bytes) und trägt ein verschlüsseltes Memo; Chains bis 17 versiegelten 1.348 Bytes. Das deklarierte Gas-Limit eines Calls ist ein öffentlicher Wert seines Proofs, kein Feld des Receipts; der Explorer zeigt es daher nicht pro Transaktion an; die gezahlte Gebühr steht in fee.

burn_a ist das verbrannte private Asset und nur bei einem token_burn, einem bridge_burn oder einem invoke ungleich null, der einen Token einzahlt oder verbrennt; burn_asset benennt dabei den Registerindex. burn_r ist das verbrannte RAND und nur bei einem bond oder einem invoke ungleich null, der RAND in den Vault des Programms einzahlt.

Auf chain 20 steht zUSD („Shielded USD”, acht Nachkommastellen) an Index 1; es ist im Genesis mit allen sieben Backings gelistet (registered_at 0, daher ist deploy_tx null) und wurde von chain 14 unter derselben Asset-ID übernommen. GET /bridge/assets liefert daher sieben Zeilen unter Index 1. Fünf weitere Token wurden auf chain 20 am ersten Tag registriert, an den Indizes 2 bis 6, drei davon mit einem Programm als Mint-Autorität; GET /tokens listet sie auf. Auf chain 20 meldet GET /bridge rules_v2 mit einem globalen Mint-Limit von 4.000 zUSD ("400000000000") pro Fenster von 86.400 Sekunden, rotation_nonce 0, burn_sequence 13 im Genesis sowie ein min_inbound_sequence von 3 für die Quell-Chains 2, 3 und 4 und 7 für die Quell-Chain 5 (1 und 4 auf chain 19): die Replay-Untergrenze des Genesis, also die niedrigste Lock-Sequenz, die die Attestierung einer Quell-Chain tragen darf, um hier geprägt zu werden. Auf chain 14 wurde es bei Höhe 256 durch ein register_bridged_token registriert, die anderen sechs Backings kamen über list_backing-Transaktionen hinzu.

Envelopes im Browser öffnen

Ein Envelope sind öffentliche Chain-Daten, und der Explorer hält keinen Schlüssel. Seine Transaktionsseite und die History-Seite öffnen Envelopes im Browser mit einem WebAssembly-Build des eigenen Codes des Nodes (crates/randscan-viewing): Fügen Sie einen Viewing Key (nk, 64 Hex) ein, um jede Note zu sehen, die diese Partei gesendet oder empfangen hat, einen Transaktionsschlüssel, um eine Zahlung zu öffnen, einen Call Key, um die Eingaben eines Calls zu öffnen, oder eine Wallet-Schlüsseldatei, von der nur der abgeleitete Viewing Key behalten wird. Eine geöffnete Note wird verifiziert, indem ihr Commitment neu berechnet wird. Ihr offengelegtes asset ist der Token-Registerindex, der über GET /tokens zu Symbol und Dezimalstellen aufgelöst wird; nur hier wird bei einer Überweisung ein Betrag an ein Asset gebunden. Ein Dummy-Slot lässt sich mit keinem Schlüssel öffnen und liest sich wie eine Note, die nicht Ihnen gehört. Über das Netzwerk läuft nichts von einem Schlüssel; um dasselbe Werkzeug zu bauen, rufen Sie /envelopes und /transactions/:hash/envelopes ab und verwenden Sie die Crate.

WebSocket-Feed

Verbinden Sie sich mit wss://randscan.org/ws und abonnieren Sie blocks, transactions oder stats:

{ "type": "subscribe", "channel": "blocks" }
{ "type": "new_block", "block": { … BlockSummary … } }
{ "type": "new_transaction", "transaction": { … TransactionSummary … } }
{ "type": "stats_update", "stats": { … } }

Senden Sie über Proxys alle 30 Sekunden { "type": "ping" }. Der Feed kennt kein Replay: Verbinden Sie sich nach einem Abbruch neu und füllen Sie die Lücke mit GET /transactions?height= auf.

Eigenen Betrieb aufsetzen

Alles hier wird vom Open-Source-Explorer in randprotocol/randscan.org bereitgestellt; der Indexer benötigt nur das rand_*-JSON-RPC eines Nodes und eine PostgreSQL-Datenbank.

Zuletzt geprüft gegen den fullnode-Commit c0878c3f (Chain 21) am 2026-10-12 und randscan commit fffa404 (docs/api.md), the live API at randscan.org, 2026-09-20, the live API at randscan.org on chain 18, 2026-09-30, the live API at randscan.org on chain 19, 2026-10-01, randscan commit 4390731 (docs/api.md: RPL-2, BRG-19 and `/provers`) and the live API at randscan.org on chain 20, 2026-10-01; `/stats` on chain 21, 2026-10-12. Wo Code und diese Seite voneinander abweichen, hat der Code recht; sagen Sie uns Bescheid.