Methodology
What every value means, and what it does not.
DoriliusGen shows public on-chain data from Robinhood Chain with the provenance of every value. This page states the sources, the shape of an evidence record, how the rule engine decides, what the indexer covers, and the limits of every claim.
Network
Verified on 2026-10-16 (UTC) against the official documentation (docs.robinhood.com/chain/connecting): Robinhood Chain has chain id 4663, native currency ETH, public RPC https://rpc.mainnet.chain.robinhood.com and the Blockscout explorer https://robinhoodchain.blockscout.com. The testnet is chain id 46630. The deployment is pinned to one chain id; every RPC endpoint must answer eth_chainId with that id before it is used, and data from any other chain is refused. Testnet deployments are labelled TESTNET in the header.
Sources
- JSON-RPC (official endpoint, publicnode, dRPC, in failover order): block headers, code, balances, nonces, storage slots, eth_call reads, transactions, receipts. Event logs (eth_getLogs) come from the official endpoint only: publicnode needs a token for log queries and the free plan of dRPC refuses windows wider than about 100 blocks. State reads are pinned to one block per record. The public node serves historical state only a few thousand blocks behind the head; older state is reported as unavailable.
- Call traces (dRPC debug_traceTransaction, callTracer): internal native transfers and the call tree. A trace is a re-execution by the provider, not consensus data. When the configured endpoint refuses, the inspector says "Unavailable from configured provider".
- Blockscout v2 API: address records, indexed transactions and token transfers (newest first, 50 per page), token lists, holder lists and counters, verified-contract records. An indexer's view, not consensus data; it can lag or miss items, and its names and flags are its own opinion.
- Sourcify v2: verified sources and ABIs (exact or partial match). Etherscan API v2 is used only when a key is configured.
Kinds of statement
- Observed on-chain facts: an evidence record names the provider, method, block and retrieval time.
- Calculated metrics: evidence of type "derived" naming the calculation and the records it rests on (net changes, concentration shares, activity counts).
- Rule-based findings: versioned rules with a status, the observed inputs, the exact condition, evidence references and coverage limits.
- AI explanations: optional, labelled, citing evidence ids; never a source of facts.
- Unknown or unavailable: shown as such. Unavailable data never becomes zero.
The evidence record
Every meaningful value links to a record with: source provider; method or endpoint category; chain id; block number and hash; transaction hash and log index where relevant; block timestamp; retrieval timestamp; confirmation status against the policy; coverage range for list reads; freshness (fresh, cached, stale); the calculation and inputs for derived values; limitations; and the normalised raw fields. API keys and private endpoints are redacted.
Confirmation and finality
A receipt's status says whether execution reverted. Confirmation counts blocks behind the head seen at observation time against a configurable policy (default 64 blocks, about 6.5 seconds at the measured ~101 ms block time). Robinhood Chain is an Arbitrum-style L2: L2 confirmations are not Ethereum finality. Cached records are relabelled "cached" with their computation time; records older than their TTL that are served because a fresh read failed are labelled "stale".
Indexer and coverage
Basic RPC calls cannot enumerate an arbitrary wallet's history. The monitoring indexer therefore keeps two streams per monitored address with persisted cursors and covered ranges:
- explorer-activity: the explorer's indexed top-level transactions and token transfer events naming the address, newest first, back-filled page by page down to the configured depth. Native value, ERC-20, ERC-721 and ERC-1155 events are stored as separate kinds.
- rpc-logs (contract subjects): eth_getLogs with address = subject in bounded windows, decoded for the known standards only (Transfer, TransferSingle/Batch, OwnershipTransferred, Upgraded, BeaconUpgraded, AdminChanged, Paused/Unpaused, RoleGranted/Revoked). Unknown events are not stored.
Events are deduplicated by (chain, subject, kind, tx hash, log index). The newest covered block's hash is checked on every pass; a mismatch rolls the stream back by the confirmation policy and marks the affected rows removed. Windows or pages that fail after retries are recorded as gaps and shown in coverage; they are never silently skipped. Internal calls are a different source and are not indexed.
Rules (engine v1.0.0)
Each rule is a pure, versioned function of the indexed events, coverage, token metadata and parameters. Statuses: triggered, not triggered (condition not met inside the covered range), insufficient data (prerequisites unmet), unsupported (the subject or pattern is outside the rule's scope; an unrecognised pattern is unknown, not absent). There is no aggregate score, and "no rule triggered" is not "safe".
- transfer-threshold@v1Transfer exceeds thresholddefault severity: medium
Triggers for every indexed transfer involving the address (or, when the address is a token contract, every Transfer event it emits) whose amount is greater than or equal to a user-defined threshold, compared in exact integer token units.
Prerequisites
- Indexed activity for the address (explorer activity stream or log stream).
- Token decimals known for the compared asset (18 for the native asset).
Parameters
- threshold — Amount in token units (decimal string). Inclusive: a transfer equal to the threshold triggers. (e.g. 1000)
- token — "native" for ETH, "any" for every asset, or a token contract address. (e.g. any)
- direction — in = received by the address, out = sent by the address, any = both. (e.g. any)
- ownership-change@v1Ownership change observeddefault severity: high
Triggers when an OwnershipTransferred(address,address) event (the OpenZeppelin Ownable convention) emitted by the monitored contract is indexed.
Prerequisites
- The subject has bytecode (events are emitted by contracts).
- The log stream for the subject has covered at least one block range.
- proxy-upgrade@v1Proxy upgrade observeddefault severity: critical
Triggers when an EIP-1967 Upgraded(implementation), BeaconUpgraded(beacon) or AdminChanged(previousAdmin, newAdmin) event emitted by the monitored contract is indexed.
Prerequisites
- The subject has bytecode.
- A supported proxy pattern (EIP-1967 implementation or beacon slot) is recognised, or an upgrade event is observed.
- Log stream coverage.
- mint-burn@v1Token mint or burn event observeddefault severity: medium
Triggers when the monitored token contract emits a Transfer whose sender is the zero address (mint, by ERC-20 convention) or whose recipient is the zero address (burn, by convention).
Prerequisites
- The subject answers ERC-20 metadata reads (it is a token contract).
- Log stream coverage for the subject.
Parameters
- minAmount — Optional: ignore mints/burns smaller than this amount in token units. (e.g. 1000)
- elevated-activity@v1Elevated transfer activitydefault severity: low
Compares the number of indexed transfers in the most recent window with the average of the preceding baseline windows. Requires complete indexed coverage of the whole comparison span.
Prerequisites
- Complete explorer-activity coverage spanning (baselineWindows + 1) × windowHours with no recorded gaps.
- Block timestamps on the indexed events.
Parameters
- windowHours — Length of the recent window and of each baseline window. (e.g. 24)
- baselineWindows — How many preceding windows form the baseline average. (e.g. 7)
- multiplier — Triggers when recent count >= multiplier × baseline average (and >= minEvents). (e.g. 3)
- minEvents — Floor below which a window never triggers, so tiny baselines do not produce noise. (e.g. 20)
- holder-concentration@v1Holder concentrationdefault severity: medium
Share of total supply held by the top N holders at a snapshot block, computed only when a complete holder dataset exists. States the denominator, snapshot block, exclusions and completeness.
Prerequisites
- The subject is a token contract with totalSupply().
- A complete holder list for the token (every page read within the cap).
Parameters
- topN — How many of the largest holders are summed. (e.g. 10)
- thresholdPercent — Triggers when the top-N share of total supply is >= this percentage. (e.g. 50)
- excludeAddresses — Addresses removed from both numerator and denominator (e.g. a known vesting contract). Each exclusion is stated in the finding. (e.g. [])
Tracing
The trace workspace expands one address at a time into directional edges from the explorer's index: top-level transactions with value and token transfer events, each with asset, amount, transaction hash, block and timestamp. Depth and node limits are explicit, pages are explicit, and the coverage of every expansion is shown. A transfer between two addresses is a transfer; it does not establish common ownership, and no real-world identity is ever inferred from relationships.
AI explanation (optional)
When a model is configured, it receives the investigation's evidence and findings and must cite evidence ids for every fact, keep interpretation apart, list what is missing, and introduce no numbers, addresses or attributions absent from the bundle. Citations are validated server-side; invalid ones are dropped and counted. Token names and other chain text are treated as untrusted data. The model has no tools and cannot sign or execute anything. Without a key, the deterministic summary built by fixed code is shown instead.
Sign-in and data
Public reads need no wallet. Saving a server-side watchlist asks for one EIP-4361 message signature bound to this site's domain and a server-issued, single-use nonce that expires in ten minutes; the server verifies domain, chain id, nonce, times and the signature (EOA recovery or ERC-1271). Sessions are stored server-side; records are scoped to the signed-in address and never readable by another user. Nothing here asks for seed phrases, private keys, token approvals or transaction signatures. A device-local list exists for guests; it is not monitored.
Limitations
- Lists are bounded by what the sources return: counts are lower bounds, the earliest indexed item is not an account's creation date, and a token list is not a complete portfolio.
- Transfer events are emitted by token contracts and can be forged by spam tokens; an event is not a verified balance change.
- A missing owner() answer is not renounced ownership; empty EIP-1967 slots are not immutability. Only the listed patterns and events are recognised.
- Holder concentration is computed only over a complete holder dataset and states its denominator, snapshot block and exclusions.
- Nothing here is a verdict on legitimacy, safety or identity, and nothing here is financial advice.