RPC infrastructure for RWA: EVM node requirements

Introduction

Real-world asset tokenization is moving fast. Real estate, government treasuries, corporate bonds, and private credit are increasingly being brought on-chain, and unlike most DeFi activity, many of these transactions carry regulatory and operational requirements. A failed RPC call does not just mean a bad user experience. It can mean a broken compliance check or a missed settlement that puts institutional participants at risk.

This article focuses on Ethereum, BNB Chain, and Arbitrum and breaks down exactly what their RPC requirements look like for protocols operating in this space.

Deep dive into RWA protocols

ERC-1400 and ERC-3643 are two of the most widely used permissioned token standards for RWA issuance. ERC-1400 introduced partitioned balances and document attachments for securities. ERC-3643 uses an identity registry architecture in which transfers are checked against on-chain verification logic before execution. If the receiving address is not authorized, the transfer reverts.

From the user’s perspective this is a single transaction, but for indexers it creates a tracking problem across multiple contracts. The identity registry and the token contract are separate on-chain components that both need to be monitored independently. Compliance state changes in the registry may not appear on the token contract itself, so an indexer watching only token transfers can miss registry updates that affect who can legally hold the asset. That is where the RPC complexity compounds.

Tokenized treasuries, real estate funds, and private credit instruments depend on oracle networks and custodian attestation services for NAV updates, proof-of-reserve data, and yield accruals. Unlike high-frequency price feeds, NAV for private credit or real estate is typically pushed once daily or weekly. The requirement is not high frequency, it is guaranteed delivery. If an RPC connection drops during the one window a custodian attempts to push a NAV update, the fund becomes untradable until the state is corrected.

Why RPC matters for RWA

RWA protocols run continuous background workloads independent of user activity. Compliance checks, oracle state polling, custodian attestation monitoring, and transfer event indexing all run on schedules tied to regulatory and operational requirements, not transaction volume. A tokenized treasury fund generates the same RPC load at 2am on a Sunday as it does during peak trading hours.

Public RPC endpoints fail this workload in predictable ways. Rate limits get hit during oracle update windows. Nodes under high traffic inconsistently prune event logs, meaning a ComplianceCheck event can silently drop from your indexer’s view. No data residency guarantees create jurisdictional problems when regulators like the SEC or BaFin require logs to be stored and processed in specific regions. And when a missed Transfer event corrupts your view of token ownership, re-scanning from archive fixes it, but in a regulated environment being wrong for even ten minutes is ten minutes of potential illegal transfers with no real-time recourse.

Required RPC methods for RWA and limits

Not all RPC methods carry the same weight in an RWA context. The methods that matter are the ones tied directly to compliance execution, event indexing, and historical state access. Each chain in this article exposes a slightly different RPC surface, and in BNB Chain’s case, actively restricts certain methods on public endpoints. 

Understanding which methods your protocol depends on, and where those methods hit limits, is what determines whether your infrastructure holds up under real operating conditions.

Ethereum

Ethereum’s RPC surface for RWA protocols centers on three methods. eth_call handles synchronous compliance checks against ERC-1400 and ERC-3643 identity registries on every token transfer simulation. This is a read-only execution against the current state, so it runs before any transaction is broadcast, meaning your RPC endpoint absorbs this load continuously as users attempt transfers.

eth_getLogs is where Ethereum RWA infrastructure tends to break down at scale. Indexing Transfer, ComplianceCheck, and OracleUpdate events across multiple RWA contracts simultaneously generates heavy log filter queries. Public endpoints throttle these aggressively, and missing a log means your compliance state is out of sync with the chain.

For historical queries, two methods require archive node access:

• eth_getStorageAt for reading contract storage at a specific past block, used in NAV reconstruction and proof-of-reserve verification
• debug_traceTransaction for full execution traces, which regulators expect when auditing specific settlement transactions

BNB Smart Chain

eth_getLogs  is not available on many public BNB Smart Chain mainnet endpoints, so RWA protocols that rely on log indexing generally need dedicated RPC access. This is not a rate limit issue, it is a hard restriction. Any RWA protocol that relies on event indexing for compliance or settlement cannot run on a public BNB Chain endpoint at all. Dedicated RPC is a baseline requirement, not an optimization. Chainstack covers this with full and archive BNB Chain nodes and eth_getLogs access enabled.

eth_call and eth_sendRawTransaction use the same JSON-RPC interface as Ethereum but operate against BNB Chain’s PoSA validator network. The consensus model affects how quickly state is finalized and therefore how soon a compliance check result can be trusted after a block is produced.

BNB Smart Chain produces blocks roughly every three seconds at significantly higher throughput than Ethereum mainnet. eth_subscribe WebSocket connections need to stay live and handle burst event volume during high-traffic windows. A dropped subscription means missing multiple blocks worth of compliance and transfer events before reconnection.

Arbitrum

Arbitrum Nitro supports the full standard eth_* method set. The key difference from Ethereum is sequencer behavior: transactions are processed by a central sequencer before being posted to L1, which affects how latency is measured and how quickly RPC responses reflect confirmed state.

Two features are specifically relevant for Arbitrum workloads:

• eth_getBlockByNumber with the finalized tag, which returns the most recently finalized Arbitrum block, giving protocols a reliable settlement marker for regulated transactions.
• The transaction receipts expose the Arbitrum-specific l1BlockNumber field, which ties each settlement back to its corresponding L1 block context

Bridge-related methods are also needed when tracking asset state across L1 and L2 simultaneously, a common requirement for RWA protocols that issue on Arbitrum but settle against Ethereum mainnet.

Chainstack provides full archive access for Arbitrum from genesis. Without it you cannot reconstruct asset state at an arbitrary past block, which makes historical audit trails and regulatory reporting unreliable.

Chain comparison

Ethereum, BNB Smart Chain, and Arbitrum each represent a different tradeoff for RWA issuers. Ethereum leads on TVL and security but carries the heaviest infrastructure requirements. BNB Chain offers high throughput and growing institutional adoption but forces dedicated RPC from day one due to public endpoint restrictions. Arbitrum runs the full EVM method set at L2 costs with L1 finality as the settlement anchor, and its RWA ecosystem has grown quickly off the back of institutional issuers like Securitize and Spiko alongside the DAO-funded STEP treasury program. 

The right chain for an RWA protocol is not purely a TVL or fee decision. It is an infrastructure decision. Ethereum’s archive requirements and log indexing demands are the price of operating on the most liquid and institutionally trusted network. BNB Smart Chain’s public endpoint restrictions make managed RPC non-negotiable from the first line of production code. Arbitrum’s sequencer model adds an L1 finality tracking layer that protocols need to account for when legal settlement thresholds are involved. Each chain has a distinct operational profile and your RPC infrastructure needs to match it.

Best practices for RWA RPC infrastructure

Dedicated private RPC endpoints are not optional for production RWA workloads. Public endpoints offer no data residency guarantees, which creates jurisdictional problems when regulators require logs to be stored and processed in specific regions. Beyond residency, dedicated endpoints give you predictable rate limits, SLA-backed uptime, and isolated infrastructure that does not degrade when another tenant spikes their call volume. For compliance-critical event monitoring, WebSocket connections should be configured with automatic reconnection logic. A dropped eth_subscribe connection on BNB Smart Chain or Arbitrum can mean missing several blocks worth of Transfer and ComplianceCheck events before your indexer recovers, and in a regulated context that gap has legal implications.

On the node side, archive access with redundancy is the baseline for any protocol that needs to reconstruct historical asset state. Running a single archive node with no failover is an audit risk as much as an uptime risk. Chain upgrades also deserve active monitoring rather than reactive patching. Ethereum’s upgrade cadence directly affects execution client behavior and available RPC methods. Arbitrum’s ArbOS releases can change sequencer behavior in ways that affect how quickly RPC responses reflect confirmed state. Staying ahead of these changes is part of operating compliant RWA infrastructure, not an afterthought.

For teams building on top of these standards, Chainstack’s open-source rwa-sdk provides a unified Python interface for querying RWA tokens across EVM chains, handling blocklist checks, KYC registry lookups, ERC-1404 restrictions depending on the protocol, all via direct eth_call with no indexer dependency.

from rwa_sdk import RWAChain
rwa = RWAChain(rpc_url="https://ethereum-mainnet.core.chainstack.com/YOUR_KEY")
# Unified compliance check — works across any supported token
check = rwa.can_transfer("USDY", sender, receiver)
print(check.can_transfer)          # True/False
print(check.method)                # ComplianceMethod.BLOCKLIST
print(check.restriction_message)   # "sender is on the blocklist"

Conclusion

RWA infrastructure failures are not like typical Web3 outages. A missed compliance event or a dropped NAV update does not just affect user experience, it affects the legal integrity of the asset itself. The chain you deploy on determines which RPC methods you depend on, where those methods hit limits, and how much infrastructure you need to run reliably underneath them. Ethereum demands archive access and high-throughput log indexing. BNB Chain forces dedicated RPC from day one. Arbitrum adds L1 finality tracking on top of a full EVM method set. None of these are problems you can solve at the application layer.

As RWA volumes grow and more institutional issuers bring regulated assets on-chain, the gap between protocols running on managed dedicated infrastructure and those relying on public endpoints will become increasingly visible. Getting the RPC layer right is not an infrastructure concern you revisit after launch. For regulated assets, it was always a day one requirement.

Dedicated archive nodes for Ethereum, BNB Smart Chain, and Arbitrum with full eth_getLogs access and archive depth from genesis are available on Chainstack.

FAQ

Additional resources

• EVM nodes: full nodes vs. archive nodes
• Archive nodes: Ethereum, BNB Chain, Arbitrum and more
• How to get a BNB Smart Chain RPC endpoint
• Getting logs and events of EVM smart contracts
• chainstacklabs/rwa-sdk