The counters have different purposes
On Robinhood Chain's Arbitrum stack, Solidity block.number is an estimate of the parent Ethereum block number. eth_blockNumber reports the latest Robinhood L2 block. Comparing the two as if they were the same counter creates false lag alarms and incorrect timeout logic.
Read the L2 height explicitly
// Contract-side interface, simplified:
interface ArbSys {
function arbBlockNumber() external view returns (uint256);
}
uint256 l2Height = ArbSys(address(0x64)).arbBlockNumber();Use the network's documented ArbSys precompile. For off-chain monitoring, read eth_blockNumber and attach the chain ID to the metric. Do not compare a Solidity-emitted parent-height estimate with an RPC L2-height series.
Choose a counter per feature
- For local L2 indexing, store L2 block number, hash and parent hash.
- For L1 settlement tracking, follow the documented parent-chain and batch signals.
- For elapsed-time policies, use the appropriate timestamp or clock rather than multiplying L2 blocks by an assumed Ethereum interval.
- For cross-chain messages, use their documented identifiers and settlement status instead of a guessed block conversion.
Test migration assumptions
Search an existing contract and backend for block.number, confirmation counts and block-based timeouts. A voting window, rate limiter or oracle cache written for Ethereum may behave differently on a faster L2. Add test fixtures that advance the relevant counter independently. Label dashboards with L1 or L2 in the metric name so an operator can tell which number a warning describes.