Setup, configuration and capabilities.

Local setup

npm install
cp .env.example .env.local   # optional: dedicated provider URLs, site URL, social links
npm run dev                  # http://localhost:12700
npm run test                 # deterministic evaluation, replay, stale-request tests
npm run typecheck && npm run build

Environment variables

Verified network configuration

Sources checked on 2026-09-15: Robinhood Chain developer docs — Connecting; viem chain definitions (robinhood, robinhoodTestnet). Public RPC endpoints: https://rpc.mainnet.chain.robinhood.com and https://rpc.testnet.chain.robinhood.com. Robinhood Chain is an Arbitrum-stack Layer 2 on Ethereum; ETH is the gas token.

Landing page data

Nothing on the landing page is sample data. GET /api/reference runs a real scan of the reference contract through the same pipeline as the inspector, reuses it for ten minutes, and returns the last successful report marked stale if the provider fails afterwards. The hero labels, the walkthrough card and the evidence desk read from it and say “unavailable” when it is. The machine geometry is a visual metaphor and is labelled as such.

Provider capabilities

• Reads go through a server-side relay that only forwards an allow-list of read methods. Hosts under robinhood.com are resolved via DNS-over-HTTPS because some ISPs hijack them; TLS still validates against the real hostname.
• The public endpoints throttle bursts. The relay retries 429s three times with backoff, then reports rate limiting honestly.
• The public nodes accept EIP-1898 block-hash objects with requireCanonical (verified 2026-09-15), so scans pin by hash when the probe succeeds and fall back to number-pinning with an end-of-scan hash check.
• Each scan verifies that the endpoint reports the configured chain id before reading anything.

Supported observations

Rule definitions (v1.0.0)

Inspected proxy slots: eip1967.implementation, eip1967.beacon, eip1967.admin, eip1822.proxiable, zeppelinos.implementation. Tracked selectors: 23 (15 privileged).

Deterministic replay

The evaluator is a pure function of (chainId, target, block, rulesetVersion, observations). Observations are normalized (hex lower-cased, sorted by id, duplicates rejected) before evaluation and hashing, so read order cannot change the result. The evidence id is sha256 over the canonical JSON (sorted keys, compact) of that input. Import a report on the inspector to validate it, recompute the id and re-run the rules locally.

Known limitations

• Blockscout for these networks challenges server-side callers, so explorer verification comes from Sourcify only. “Verification status unavailable” is shown when Sourcify cannot be reached.
• The rate limiter is per process. On serverless platforms each instance has its own bucket.
• Reports are cached in memory per exact (chain, target, block, rule version) only when every read completed; a new scan always pins a new block.
• Share links start a new scan. There is no server-side snapshot store; use the JSON export to keep a specific block’s report.
• Selector scanning and proxy slot inspection are heuristics with documented false negatives.

Deployment

npm run build && npm run start          # Node server on :12700
# or on Vercel: import the repo, set the RAGNALENS_* / NEXT_PUBLIC_* variables, deploy.
# API routes run on the Node runtime; /api/inspect streams NDJSON and allows up to 60 s.

Security notes

• All request inputs are validated server-side with Zod; addresses are re-parsed and checksummed.
• Only the two allow-listed endpoints are ever contacted; user input can never choose an RPC URL.
• No wallet connection, signatures, approvals or transactions exist anywhere in the product.
• Token metadata and explorer content are sanitized, length-bounded and rendered as plain text only.
• Imported reports are schema-validated and size-bounded before anything is rendered.