BTCJP ResearchResearch &
archive edition

Network experiments

A Custom RPC Endpoint Changes Your View of the Network

Separate a wallet's network label, the server answering its queries and the evidence behind the state that appears on screen.

1,158 words6 min readBTCJP Research Editorial Desk

New editorial guide, published 16 October 2026. The historical sources linked below are preserved separately and are not represented as current product or service information.

BTCJP's custom-RPC note records an experiment with changing the server a wallet uses to reach Ethereum. An earlier enterprise-network note records a different use of a similar setting: connecting to a private test environment. Together, they show why the words custom RPC do not describe one universal change. Sometimes the server changes while the intended network stays the same; sometimes the intended network changes too. This new guide explains how to record and verify that distinction. It does not reuse the archived provider settings as a current configuration recipe or make a present privacy claim about any named provider.

Give the label, endpoint and network separate fields

A wallet's friendly network name is a local description. An endpoint URL identifies a server that receives requests. The network identity describes the environment the experiment intends to use. These fields are related, but none should silently replace the others. A hypothetical researcher could name an entry mainnet while entering a server for a different environment. Conversely, two differently named entries could query the same network through different providers. Begin the notebook with all three fields so a later reader can tell which change the experiment actually made.

The historical BTCJP notes provide concrete motivation for this separation. One describes a public-network access change, while another describes a privately configured development network. A similar-looking wallet menu appears in both workflows, but their purposes differ. The record should therefore state the intended environment before discussing the endpoint. It should also identify whether the experiment is read-only or will create a transaction. That prevents a successful connection message from being mistaken for proof that every subsequent action is directed at the environment the researcher had in mind.

Check identity and freshness as different questions

Ethereum's JSON-RPC documentation defines methods for observations such as the chain identifier, block height and node synchronisation state. These answer different questions. A chain identifier helps establish the claimed environment; a height or synchronisation response concerns the node's view of progress. Neither should be stretched into a complete guarantee about every response. Record the requested method, observation time and result rather than writing simply connected. A connection can work while the server's view is delayed or the wallet's local configuration is not the one the experiment intended.

For a hypothetical read test, obtain an identity response and inspect a recent, known reference block through the selected endpoint. Compare that reference with an independently established observation. If the values disagree, distinguish a lagging view from a different environment or a data-format misunderstanding. Do not resolve the disagreement by repeatedly refreshing until one attractive number appears. The mismatch is evidence to investigate. It identifies a boundary between the request, the server's response and the interpretation shown by the application, which is exactly what a connection experiment should make visible.

An access service has an observation position

A server that receives a request can observe information associated with that request and its network connection. Which information is retained or processed depends on the actual implementation and current service practices. Changing an endpoint changes at least part of that observation path; it does not establish universal anonymity. A precise notebook records the chosen access arrangement and the privacy question being examined. It should not turn a historical provider comparison into a timeless claim that one setting removes every form of correlation or collection around a wallet.

Use a hypothetical dependency map to identify the remaining observers. The wallet application, endpoint operator, destination website and underlying network can have different views of the activity. An experiment that changes only one of these relationships should state that scope. Also distinguish a public unauthenticated endpoint from an account-specific URL. If the latter contains a credential, the endpoint string is not an appropriate public notebook field in full. A shareable record can describe the configuration while keeping the actual credential out of screenshots, exported logs and published examples.

Receiving a transaction is not the same as including it

The RPC path is also relevant when a wallet submits a transaction. A service can receive a submission and return a result without that being the final event the user cares about. The notebook should distinguish preparation, submission, propagation, inclusion and the application's completion condition. This distinction is useful when diagnosing a report that a payment was sent but has not appeared where expected. The investigation needs the intended network and transaction identifier, not only the name of the endpoint that accepted the request.

A hypothetical test can record the identifier returned at submission and then observe the transaction through a separate read path. If one path reports it and another does not, examine timing, environment and the meaning of each response before assuming the asset has disappeared. Repeatedly submitting new actions can make an unclear experiment harder to interpret. A cleaner method follows one identified operation through its stages and records the evidence for each stage. This turns a vague interface symptom into a question about an observable part of the transaction's journey.

Define independence before comparing providers

Two web pages showing the same block are not necessarily independent checks if both rely on the same upstream service. Likewise, two endpoint brands may share infrastructure. The practical question is whether the comparison addresses the failure the experiment is meant to detect. Ethereum's node documentation distinguishes operating node software from consuming data through services. A review can use that distinction without claiming that every researcher must operate the same setup. It should explain what each observation path depends on and what kind of disagreement the comparison could reveal.

Suppose a hypothetical application displays an unexpectedly old balance. Comparing two interfaces that query the same cache may reproduce the old value without resolving the cause. A different observation path might help identify whether the problem concerns the wallet's display, an access service or the intended account and network. Record those dependencies alongside the result. Independence is then a property of a specific comparison, not an adjective attached to a second browser tab. This makes the test more useful and avoids treating repetition of one upstream answer as several separate confirmations.

Leave a reproducible connection note

A complete connection record states the purpose, intended network, endpoint arrangement, wallet version and observations used to check identity and freshness. It describes any account-specific credential without publishing it and records whether the experiment involved a transaction. Include the outcome and unresolved discrepancies. This gives the next researcher a way to repeat the relevant check while recognising that endpoint availability and provider practices can change. The configuration is a dated observation, not a permanent endorsement of the service named in a screenshot.

The two BTCJP experiments remain useful because they expose the same setting in different contexts. Read them as laboratory records of access and network selection, then make the boundaries explicit in a new test. Separate labels from identity, inspect the server's view, follow transaction stages and define the independence of comparisons. A custom RPC endpoint can be a valuable tool for research and operations, but the change should be described accurately: it changes how an application reaches and observes a network, not the fundamental meaning of every asset, transaction or privacy claim shown on screen.