An institution that holds digital assets, custodies them or reports their value has usually negotiated a contract for the custodian, the auditor and the insurer. It has rarely negotiated one for the thing all three read the chain through: a node, and the RPC endpoint in front of it. Almost nothing in the application layer talks to a blockchain directly. It sends a request to a remote procedure call, or RPC, endpoint served by a node that someone, somewhere, is running and paying for. That someone is rarely the institution asking the question, and the arrangement is rarely written down anywhere a diligence file would look.
What a node actually serves
A node is software that keeps a copy of a blockchain's data and validates it against the protocol's rules. An RPC endpoint is the interface that lets other software ask it questions: what is this address's balance, was this transaction included, what events did this contract emit. A custodian's balance screen, a compliance tool's transaction monitor and a settlement system's finality check are all, underneath, RPC calls to somebody's node. Which node, and how much history it holds, changes what it can answer.
Full nodes versus archive nodes, and why history costs more
Ethereum's own documentation distinguishes a full node, which "only caches the past few states, e.g., the state associated with the last 128 blocks", from an archive node, which stores "not only the most recent states but every historical state created after each block". It puts archive storage at 3 to 12 terabytes depending on the client, with Erigon holding "the same data in under 3TB" and other implementations needing more than 12TB (ethereum.org, page last updated 3 April 2026). On 8 July 2025 the Ethereum Foundation confirmed that every execution client, Geth, Nethermind, Besu, Erigon and Reth, now supports partial history expiry under EIP-4444: a node can discard block data from before the Merge, which the Foundation says cuts 300 to 500 gigabytes from its disk footprint and lets it "fit comfortably on a 2 TB disk" (Ethereum Foundation blog, 8 July 2025). That is good news for anyone running a full node, and it also means a full node increasingly cannot answer a question about the chain's early history at all. Only an archive node, or a service built on one, still can.
Bitcoin's trade-off has the same shape with different numbers. Bitcoin Core's guidance puts the initial download at "roughly 740 gigabytes", with ongoing download usage of about 20 gigabytes a month, against a minimum pruned setting of 550 megabytes, which can bring disk use down "from over 750GB to around 7GB" (bitcoin.org, "Running A Full Node"). Pruning has costs. It is "incompatible with -txindex", the option that maps every transaction ID to its location on disk, because the blocks such an index would point at have been deleted. And when a pruned or full node approaches the maximum upload target it is configured with, its uploads are "cut by no longer serving historic blocks (blocks older than one week)", which is why the network still needs nodes willing to keep and serve full history for others to sync against.
The practical read-across: a service that needs only current balances and pending transactions can run cheaply and prune aggressively. A service that needs to know an address's balance or a contract's state at a past block, which is what audit, tax and some AML lookbacks require, and what the tools discussed in what blockchain data can tell you depend on, needs archive access specifically. That is the expensive tier, and it is the one most institutions never ask whether their vendor actually runs.
Public endpoints versus commercial providers
Below the archive question sits a cheaper one: is the node answering an application's queries a free public endpoint, or a paid commercial one. Public endpoints exist because someone absorbs the cost of serving requests they are not paid for, so they come with no service-level agreement and low, often unpublished, rate ceilings. Commercial providers sell tiers against that constraint, and even their entry tiers are metered rather than open: Infura's free plan is documented at 3,000,000 daily credits and a 500 credits per second rate limit, and Alchemy's at 30 million compute units a month with throughput capped at 300 compute units per second (Infura and Alchemy developer documentation, vendor material, accessed September 2026). Neither company publishes an audited share of Ethereum RPC traffic, so the concentration in this market is visible in its outages rather than in its numbers.
What an operator can see, and what it can do
An RPC provider sits roughly where an internet service provider sits, but for chain queries: it sees the request before it answers it. It sees the querying IP address, and because a wallet queries its own addresses when it unlocks or transacts, it can associate that IP address with the addresses behind it. ConsenSys made this explicit rather than theoretical on 23 November 2022, when its updated privacy policy stated that "when you use Infura as your default RPC provider in MetaMask, Infura will collect your IP address and your Ethereum wallet address when you send a transaction", and that a user pointing MetaMask at a self-hosted node or a third-party provider would have neither collected (ConsenSys privacy policy update, 23 November 2022; Decrypt, 24 November 2022).
An operator can also act on what it sees. It can throttle a client, and it can filter by jurisdiction. On 3 March 2022 MetaMask and Infura restricted access from jurisdictions they did not name, to comply with new sanctions directives, then acknowledged the same day that they had "mistakenly configured the settings more broadly than they needed to be" and restored service; users in Venezuela reported losing access, which the reporting could not independently confirm (CoinDesk, 3 March 2022). An operator, or an attacker reaching the same interface, can also degrade service without touching the chain at all: a 2021 NDSS Symposium paper tested nine production Ethereum RPC services and found all nine open to zero-cost denial-of-service requests that increased service latency by 2.1 to 50 times, with 150 such requests a second slowing a victim node's block synchronisation by 91% ("As Strong As Its Weakest Link: How to Break Blockchain DApps at RPC Service", NDSS Symposium, 2021; the underlying measurements were taken in 2020). None of that requires the chain itself to be compromised. It requires only the layer reading the chain to misbehave.
The failure record
The clearest case remains 11 November 2020. Infura's own post-mortem records automated alerting detecting a complete sync halt at 07:15 UTC, traced by 08:04 UTC to a consensus failure at block 11234873 affecting the Geth versions it was then running, v1.9.9 and v1.9.13. Its JSON-RPC subsystem returned to nominal health at 13:07 UTC and its archive data subsystem at 14:28 UTC (Infura post-mortem, vendor material, incident dated 11 November 2020). While it lasted, MetaMask users were cut off and exchanges including Binance suspended ether withdrawals (The Block, 11 November 2020). The applications had no bug. Their shared dependency did.
Outages a layer down show the same dependency from the other side, because an institution running its own node is still exposed if the chain stops. Solana's mainnet beta halted block finalisation at 09:53 UTC on 6 February 2024 and did not resume consensus until 14:55 UTC; the official report attributes it to a fault in the program cache, where an evicted legacy loader program was reinserted at the wrong effective slot height so that it always appeared unloaded, producing what the report calls a "classic infinite loop" of recompilation (Solana, mainnet beta outage report, 6 February 2024). Running your own RPC infrastructure would not have avoided that: the fault sat in validator software every node was running. Arbitrum One's sequencer stopped relaying transactions properly on 15 December 2023 after a sustained surge of inscription traffic, leaving users with failed transactions and abnormally high fees (Arbitrum status incident report, 15 December 2023). That is the failure mode behind the stale price problem set out in how price oracles work and fail: the infrastructure stopped, not the asset price.
Running your own node changes the picture, not the risk
Operating a node removes the third party: no external operator sees the query pattern, no external rate limit or jurisdiction filter applies, and no single vendor's outage takes an application down alongside everyone else's. It is not free. One infrastructure vendor's published figures put cloud hosting for an Ethereum archive node at $3,000 to $5,000 a month and a DevOps engineer to run it at about $150,000 a year, and headline a "real setup" above $250,000 a year, though that headline number also folds in a 32 ETH validator stake, which is a separate decision from reading the chain (Tatum, vendor sales material, accessed September 2026, not an audited benchmark). Bitcoin is cheaper on disk, a few hundred gigabytes, though bitcoin.org notes that full nodes on high-speed connections commonly use 200 gigabytes of upload a month or more.
What self-hosting does not remove is client risk. Infura's 2020 outage was a Geth bug, and an institution running the same Geth version on its own hardware would have stopped at the same block. The mitigation is client diversity, not self-hosting for its own sake, which is the same point about software concentration made in what institutions need from public blockchains. Nor does self-hosting remove a protocol-level halt like Solana's. It converts a vendor-concentration risk into an operations problem: keeping a node patched and client-diverse becomes the institution's own job, rather than a line it can audit in someone else's contract.
The regulatory backdrop, and the gap in it
Two frameworks put outsourced technology dependencies on a formal footing, and neither names node or RPC providers. That gap is where a firm's own diligence has to do the work regulation has not done for it. The EU's Digital Operational Resilience Act entered into force on 16 January 2023 and has applied since 17 January 2025 (European Securities and Markets Authority, accessed September 2026). Its Articles 28 to 30 require in-scope financial entities to keep a register of information on ICT third parties, to assess before signing whether an arrangement would create concentration risk, and to carry specific provisions into the contract itself. Whether a chain-data provider supports a critical or important function is a judgement the regulation leaves with the firm.
In the UK, the Bank of England, PRA and FCA rules on critical third parties took effect on 1 January 2025, following PS24/16 of 12 November 2024; they reach only the parties HM Treasury designates on the regulators' recommendation, not every vendor a firm relies on (FCA, accessed September 2026). A broader FCA requirement, to notify the regulator on entering or materially changing a material third-party arrangement and to file an annual register of those arrangements, was published in final form on 18 March 2026 as PS26/2 and does not come into force until 18 March 2027 (FCA, accessed September 2026). Adopted, not yet applying.
What a diligence file should contain
- For each chain relied on: which client and version serves it, and whether that deployment is a full, pruned or archive node.
- Every RPC vendor in the request path, including one a downstream custodian, analytics tool or wallet provider uses without saying so.
- Whether a second, independent vendor or a self-hosted node exists as a fallback, and how failover between them is tested, not merely documented.
- The vendor's data-handling terms: does it log IP addresses against wallet addresses, for how long, and is that disclosed in the way ConsenSys disclosed it for Infura in November 2022.
- The vendor's dated incident history for the past two years, read from its own post-mortems and status page rather than a sales page.
- Whether the arrangement has been assessed against the institution's applicable outsourcing or ICT third-party risk regime, and, where it has not, why not.
Controls that detect a bad answer
A diligence document only records intent. What catches an operator, or an attacker, actually returning stale or wrong data is a running control: querying block height and hash from at least two independent providers and alerting on divergence, rather than trusting a single endpoint by default. It is reconciling a sample of historical balance and event-log queries against an independently run archive node on a schedule, not only once something already looks wrong. And it is monitoring RPC latency and error rate as an operational metric in its own right, the way a firm already monitors a market data feed. None of that substitutes for the contractual and regulatory questions above. It confirms, or contradicts, the answers a vendor gives to them.
This describes an infrastructure dependency and the controls available against it. It is not tax, legal, accounting or investment advice.