Usa la API del explorador para leer la chain 20 desde un script, un bot o un backend sin ejecutar un nodo. La guía completa con todos los campos está en el repositorio del explorador, randscan.org/docs/api.md; esta página es el resumen.
| URL base | https://randscan.org/api/v1 |
| WebSocket | wss://randscan.org/ws |
| anónimo | 60 solicitudes por minuto por IP |
| con una clave de API | 600 solicitudes por minuto; las claves se obtienen en randscan.org/dashboard y se envían como Authorization: Bearer rsk_… o X-API-Key |
Qué puede mostrar el explorador de una chain blindada
En esta API no hay cuentas, saldos, remitentes ni destinatarios, y desde la chain 14 tampoco hay ningún activo público en un bundle: una transferencia de RAND y una transferencia de cualquier token RPL tienen la misma forma. Lo que sirve es cada bloque; el bundle de activo oculto de cada transacción tal como se publica (ancla, cuatro nullifiers, cuatro compromisos, comisión, burn_a, burn_r, burn_asset, hora, tamaños de la prueba y del sobre y, desde la chain 17, el auth_commit y el tamaño de la prueba de autorización); la acción que llevaba una transacción y sus campos públicos, incluidos el registro, las emisiones y las quemas de un token RPL, las acciones de gobernanza del puente y la transición de estado de un invoke de RPL-2; el registro de tokens RPL; las celdas y la bóveda de un programa; el árbol de compromisos hoja por hoja; el conjunto de nullifiers; el registro de validadores; la auditoría del suministro; el estado público del puente, incluida su pausa de emisiones y su conjunto de guardianes PQ. Qué activo movió una transferencia solo lo muestra una clave de visualización o una clave de transacción, en el navegador. GET /accounts/:address responde 410 { "error": "no_accounts" }.
Convenciones: los importes son cadenas decimales de unidades. Un importe cuyo asset_index designa un token distinto de RAND (índice 0) está en la unidad mínima propia de ese token, no en los nueve decimales de RAND; resuelve el índice mediante GET /tokens/:id antes de dividir. registration_fee y next_index son los dos campos que el explorador sirve como números JSON simples; los hashes, los ids de programa, los compromisos y los nullifiers son 64 caracteres hexadecimales en minúscula; las direcciones de validador están en base58; las alturas son enteros decimales desde 0; solo se indexan los bloques confirmados, de modo que un bloque en la API es definitivo. Las listas aceptan page (desde 1) y limit (de 1 a 100, 20 por defecto), devuelven { "data": [...], "pagination": { page, limit, total, total_pages, has_next, has_prev } } y se ordenan de más reciente a más antiguo. Los errores son { "error", "message", "code" } con 400, 404, 410, 429 o 500.
Endpoints
| método y ruta | devuelve |
|---|---|
GET /health | estado del explorador y retraso del indexador |
GET /stats | id de la chain, altura, vista, tamaño del árbol, recuentos de validadores, stake total, suministro, número de programas, tiempo medio de bloque, época, el hash del génesis y la compilación del nodo; hc_bundle y hc_auth; limits (los cinco límites del génesis, luego envelope_bytes, hardening_v6, hc_auth, el gas_price y el byte_price del génesis, gas_metering, bundle_gas_limit, adjust_bps y, en un nodo desde v0.6.8, program_state); gas_prices, los precios vigentes en la punta. limits no incluye los demás campos nuevos de v0.6.8 (binding_domain, proof_window_blocks, los techos de precio, admission_by_vote, testnet): léelos con rand_getLimits del nodo |
GET /supply | la auditoría del suministro del nodo tal cual, incluidos los cuatro contadores vesting_*, todos "0" en la chain 20, cuyo génesis no tiene sección vesting, y program_rand_out y program_rand_held de RPL-2, el RAND pagado desde las bóvedas de programas y el RAND que aún conservan |
GET /bridge | el estado público del puente: emitter, emitters, guardian_set_index, guardians, pq_guardians, mint_paused, pause_nonce, list_nonce, pause_key, registration_fee, burn_sequence, next_index (null desde la chain 14), rotation_nonce, rules_v2 (con global_minted_in_window y global_mint_headroom), min_inbound_sequence, assets y endpoints, la representación propia del explorador de cada emisor tal como la imprime su chain de origen. No sirve los fees, rotation_rules ni pending_rotations de v0.6.8 del nodo: léelos con rand_getBridgeState |
GET /bridge/assets | una fila por respaldo: la fila del registro (index, chain, token, asset_id, locked, minted_today, mint_cap_per_day y, en un nodo v0.6.8, minted_in_window, mint_window_secs y mint_headroom, el mayor depósito que admiten ahora los límites) unida con symbol, name, decimals y backings, y los totales indexados. Por respaldo: burns, burned, outstanding (el locked del registro) y deposits/deposited solo cuando el token tiene un único respaldo (null en caso contrario: un depósito nombra el token que emitió, no la moneda bloqueada para ello). Por token, idénticos en cada fila con el mismo index: token_deposits, token_deposited, token_burns, token_burned, first_height, last_height; cuenta cada index una sola vez al totalizar |
GET /bridge/tokens | la lista de tokens permitidos, una lista estática: USDT y USDC en Ethereum, BSC, Tron y Solana, con USDC en Tron discontinuado |
GET /tokens | el registro completo de tokens RPL tal como lo almacena en caché el nodo: enabled, registration_fee, next_index, tokens |
GET /tokens/:id | un token por índice de registro, id de 64 hex o forma de texto rpl1…, más deploy_tx y supply_history; 404 cuando ninguno coincide |
GET /nodes | el nodo del explorador y sus pares, con geolocalización |
GET /provers | los provers delegados que conoce el explorador (su propia lista; la chain no guarda registro de ellos): si cada uno responde a su prover_info, su capacidad y su comisión, y dónde están sus hosts |
GET /blocks?page&limit&proposer, GET /blocks/latest?limit, GET /blocks/:id | bloques, por altura o por hash |
GET /transactions?page&limit&kind&height&validator&program, GET /transactions/latest, GET /transactions/:hash | transacciones; kind es 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. No existe token_transfer: una transferencia de cualquier token RPL es transfer |
GET /transactions/:hash/envelopes | las notas que creó una transacción con sus sobres: las cuatro ranuras del bundle, incluidos los señuelos, más las notas calculadas por la chain que añade un depósito bridge_attest, un token_mint, la emisión inicial de un register_token o los pagos de un invoke; para una llamada, h_in y la transcripción de entrada sellada |
GET /envelopes?from_leaf&limit | hojas con sobres, de más antigua a más reciente, hasta 1,000 por página, para un escaneo del historial |
GET /notes?page&limit, GET /notes/:id | hojas del árbol, por compromiso o por índice de hoja |
GET /nullifiers/:nf | la transacción que publicó un nullifier |
GET /validators, GET /validators/:address | el registro, con share_percent, blocks_proposed y la última altura propuesta |
GET /programs?page&limit, GET /programs/:id | programas desplegados (base_pc, words_len, code_hash, public_words_len, public_digest) con recuentos de llamadas e invocaciones; las llamadas e invocaciones recientes de un programa y su program_state, leído en vivo del nodo: vault (por activo), las primeras 100 cells en orden de clave y cells_next |
GET /programs/:id/cells?after&limit | una página de las celdas del programa en orden de clave, en vivo desde el nodo (limit de 1 a 1,000, 100 por defecto): { "cells", "next" }; 404 en una chain sin sección program_state |
GET /search?q= | bloques, transacciones, programas, notas, nullifiers y validadores |
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/8aa13d1f76d28f63a46c30bb09ef44b1ba35083ca80ba7301997f98e5f783666Un resumen de transacción (un mint del faucet de 10 RAND en la altura 102,197 de la 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 solo se rellena para los tipos con un importe público — mint, bond, unbond, withdraw, bridge_attest, bridge_burn, token_mint, token_burn y un register_token con emisión inicial — y es null para una transferencia, cuyo asset_index también es siempre null. has_bundle es falso para mint, unbond, withdraw, pause_mints y unpause_mints, que no llevan bundle y no pagan comisión. El detalle añade chain_id, bundle y, según el tipo: el words_len de un deploy; el call_proof_len, el input_envelope_len y el receipt de una llamada (tx, program, tier, outputs, height, index, h_in, h_pub); el registered de un bond; el action_nonce de un unbond o un withdraw; el attestation_len, recipient, note_time, deposit_r, commitment y pq_signers de una atestación del puente; el relayer_fee, to_chain, bridge_to y bridge_token de una quema del puente; el token_action de una acción RPL (los campos propios de la acción, etiquetados por kind), con recipient, note_time y deposit_r para una nota emitida y action_nonce para un token_mint o set_authority; el bridge_governance de una acción de gobernanza del puente, con pq_signers en todas salvo pause_mints; el call_proof_len, input_envelope_len, receipt y transition de un invoke (la representación del nodo: las celdas leídas y escritas, el inflow y cada nota de pays y mints con su recipient, time, r y cm). Un tipo de v0.6.8 que esta compilación del explorador no conoce (admit_validator, slash_equivocation, las rotaciones _v2, cancel_rotation) se muestra como other.
En la chain 20, con comisiones del puente, el amount de un bridge_attest y de un bridge_burn es el bruto: el importe que firmaron los guardianes o el importe que quemó el bundle. El explorador no sirve el depósito neto, el importe liberado ni la nota de comisión; léelos con rand_getTransaction del nodo (deposit_amount, release_amount, fee_note) y rand_getBridgeBurn. La quema de 0.999 zUSD en la altura 2,899 figura aquí como "amount": "99900000"; los guardianes firmaron una liberación de 99800100.
El bundle de un detalle de transacción es el bundle de activo oculto, sin campo de activo y sin un segundo bundle en una quema. Este pagó la llamada del ejemplo con curl anterior, en la altura 98,335 de la chain 18; esa transacción no existe en la chain 20, donde el tercer curl responde 404:
"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 y auth_proof_len son la autorización dividida (chains 17 y posteriores, donde limits.hc_auth está definido): la prueba del bundle se genera con la clave de visualización y publica auth_commit, y una segunda prueba, pequeña, sobre la clave de gasto, ligada a la misma transacción, debe coincidir con él. Ambas pruebas se informan solo por su longitud. Cada sobre en la chain 20 ocupa 1,860 bytes (limits.envelope_bytes) y lleva un memo cifrado; las chains hasta la 17 sellaban 1,348 bytes. El límite de gas declarado de una llamada es un valor público de su prueba, no un campo del recibo, por lo que el explorador no lo muestra por transacción; la comisión que pagó está en fee.
burn_a es el activo privado quemado, distinto de cero solo en un token_burn, un bridge_burn o una invoke que deposita o quema un token, con burn_asset indicando el índice del registro; burn_r es el RAND quemado, distinto de cero solo en un bond o una invoke que deposita RAND en la bóveda del programa.
En chain 20, zUSD (“Shielded USD”, ocho decimales) ocupa el índice 1, figura en el génesis con los siete respaldos (registered_at 0, de modo que deploy_tx es null) y se trasladó desde chain 14 con el mismo id de activo. Por tanto, GET /bridge/assets devuelve siete filas bajo el índice 1. En chain 20 se registraron cinco tokens más durante su primer día, en los índices 2 a 6, tres de ellos con un programa como autoridad de acuñación; GET /tokens los enumera. En chain 20, GET /bridge informa rules_v2 con un límite global de acuñación de 4,000 zUSD ("400000000000") por ventana de 86,400 segundos, rotation_nonce 0, burn_sequence 13 en el génesis y un min_inbound_sequence de 3 para las cadenas de origen 2, 3 y 4 y de 7 para la cadena de origen 5 (1 y 4 en chain 19): el piso de repetición del génesis, la secuencia de bloqueo más baja que puede llevar la attestation de una cadena de origen para acuñarse aquí. En chain 14 se registró en la altura 256 mediante un register_bridged_token, con los otros seis respaldos añadidos mediante transacciones list_backing.
Abrir los sobres en el navegador
Un sobre es un dato público de la cadena, y el explorador no guarda ninguna clave. Su página de transacción y la página de Historial abren los sobres en el navegador con una compilación en WebAssembly del propio código del nodo (crates/randscan-viewing): pegue una clave de visualización (nk, 64 hex) para ver todas las notas que esa parte envió o recibió, una clave de transacción para abrir un pago, una clave de llamada para abrir las entradas de una llamada, o un archivo de clave de billetera, del cual solo se conserva la clave de visualización derivada. Una nota abierta se verifica recalculando su compromiso. Su asset divulgado es el índice del registro de tokens, resuelto mediante GET /tokens para obtener el símbolo y los decimales; es el único lugar donde un importe se vincula a un activo en una transferencia. Una ranura ficticia se abre con cualquier clave y se lee igual que una nota que no es suya. Nada de una clave viaja por la red; para construir la misma herramienta, obtenga /envelopes y /transactions/:hash/envelopes y use el crate.
Feed de WebSocket
Conéctese a wss://randscan.org/ws y suscríbase a blocks, transactions o stats:
{ "type": "subscribe", "channel": "blocks" }
{ "type": "new_block", "block": { … BlockSummary … } }
{ "type": "new_transaction", "transaction": { … TransactionSummary … } }
{ "type": "stats_update", "stats": { … } }Envíe { "type": "ping" } cada 30 segundos a través de proxies. El feed no tiene repetición: si se interrumpe, vuelva a conectarse y complete los datos con GET /transactions?height=.
Ejecutar su propio explorador
Todo lo que aquí se describe lo sirve el explorador de código abierto en randprotocol/randscan.org; el indexador solo necesita el JSON-RPC rand_* de un nodo y una base de datos PostgreSQL.