Hopr
Hopr supplied RPCh's relay path for wallet metadata protection
Updated
Hopr supplied the mixnet behind RPCh, which routed wallet requests and responses through relays to reduce IP exposure to RPC providers. RPCh development is paused. The routing design concerns connection metadata; it doesn't make public blockchain records private or cover requests that travel outside the mixnet.
Connection metadata and the wallet's query
A wallet's RPC provider handles requests for blockchain information; a direct connection gives that provider connection metadata alongside the query. RPC means remote procedure call: software asks another service to perform an operation and return an answer. The query states the blockchain question. Metadata describes the communication, including the connection's source IP address, its timing and the amount of traffic. An observer doesn't need to read a transaction's contents to learn something from those surrounding details.
The sensitive link is often the association between a public address and a device. An address can appear on a blockchain without revealing the IP address of someone viewing it. A direct request can bring those identifiers together when it asks a provider about that address. Repeated connections can reveal patterns across a session.
What changes at the RPC provider?
RPCh was an application-level gateway that put mixnet routing between wallet software and the RPC provider, while leaving the provider responsible for answering the blockchain request. Its design carried both requests and responses through the mixnet. An exit application handled the provider interaction at the far end. The provider therefore received requests through that exit connection, rather than directly from the wallet. This separation targeted the link between a query and its origin; it didn't remove information that the query itself disclosed.
Mixing obscures a request's path
The mixnet combines encrypted relaying with traffic mixing to make a request's journey harder to reconstruct from observations of neighboring connections. Routing through several nodes alone leaves timing and size patterns that an observer could examine.
Timing and size
Packet timing
Mixing lets a node combine traffic from different messages before forwarding it. Some packets wait for later mixing cycles, which weakens simple timing matches between arrivals and departures.
Packet size
The mixnet's Sphinx packet format gives packets a uniform size. Equal-sized packets remove one clue for following an individual packet between nodes. This property works alongside mixing: the packet format reduces size differences, while the mixing process disrupts associations between incoming and outgoing traffic.
A relay's limited view
A relay needs enough routing information to pass a packet to its next hop. Layered encryption limits its routing view to neighboring nodes involved in that handoff. It doesn't reveal the complete path. Mixing adds protection against an observer who watches beyond one relay, although its privacy effect still depends on the traffic moving through the network.
The same balance display through different routes
In this hypothetical comparison, a wallet can send the same balance query either directly or through a functioning RPCh integration. The queried public address and blockchain state stay the same and both routes return successfully. The question is whether an identical balance display means that the privacy route changed nothing.
The direct request gives the provider a public source IP alongside that query. Through the RPCh design, an exit application makes the provider connection after the request traverses the mixnet. The provider can answer the same question without receiving the wallet's IP address as the source of its incoming connection.
Both displays can therefore show the same balance. The difference concerns which connection delivered the query, not the blockchain fact returned in the answer. This conclusion applies only to requests that actually take the assumed RPCh route. A separate direct request from the application would retain its own metadata exposure.
Public records keep their own visibility
Mixnet routing leaves public blockchain records visible and leaves an RPC query's contents available to the service that must answer it. A request about an address still needs to identify the relevant address. The address inside that query is application data. The source IP attached to a direct connection is connection metadata. The routing design targets the association between that query and its network origin.
Private transport and private transaction records describe different protections. A wallet can change its connection path while continuing to read the same public ledger.
Token images can reveal a separate connection
A token image can expose an IP address through a request that travels outside the wallet's RPC connection. MyTokenTracker's Ethereum demonstration exposed an IP address through requests for token images. Its v3.0.0 documentation describes an interface that loaded assets for an entered address, then fetched their icons. Those image requests created a separate connection alongside the address lookup. The public address itself doesn't include the viewing device's IP address.
A protected RPC path doesn't automatically reroute a browser's image downloads. Those downloads have their own destinations and transport choices. Protecting the RPC connection therefore leaves asset loading as a separate part of the application's privacy design.
RPCh's pause and the underlying relay network
RPCh development is paused, while the underlying mixnet remains an active protocol project. Payment channels support relay compensation, while cover traffic adds packets that help obscure user traffic. Neither mechanism selects a wallet's RPC configuration by itself. Applications connect a specific task to that transport infrastructure. The project has directed resources toward other applications, including Gnosis VPN.
Helpful answers
Does a wallet have to broadcast a transaction before an RPC provider sees metadata?
A wallet can expose connection metadata while it only reads blockchain information. RPC communication can happen before a transaction is signed or broadcast. The privacy issue begins with that communication, so declining to make a transaction doesn't undo an IP-to-query association that a direct request has already exposed.
Which integration options did RPCh provide for wallet software?
RPCh provided a software development kit for application integration and an RPC server that exposed its functionality as a configurable endpoint. RPCh development is paused.
Why might a mixnet-routed RPC call take longer than a direct call?
Encrypted relaying and mixing add work compared with sending data directly. Total response time also includes the RPC provider's processing and the application's handling of the request. RPCh's diagnostic design distinguished mixnet transport time from provider response time. A single fixed delay wouldn't describe all those components.
What did MyTokenTracker's private mode show in its logs?
MyTokenTracker's documented private mode showed requests without the user's IP address appearing in the demonstration's logs. Its v3.0.0 instructions called that mode “I'm feeling private”. This result concerned the demonstration's use of the mixnet; it didn't establish that every wallet image request or all browser traffic would follow that route.
Would a VPN connection prove that wallet requests passed through RPCh?
A VPN connection doesn't establish that an RPC request used RPCh's application-specific route. The transport underneath a VPN depends on its implementation; Gnosis VPN is a separate application built on the mixnet. That relationship doesn't make its client an RPCh integration. An RPC request's route follows the software configuration that handles it.