Dear community,
I would like to open a discussion regarding the recent proposal to include a GeoDNS/load-balancing wrapper within our Public RPC infrastructure.
While I appreciate the intent to improve user experience (UX) and network reliability through geographic routing, I have significant concerns regarding the long-term architectural implications of this approach. Specifically, I am concerned that introducing a centralized “wrapper” or load-balancing layer effectively re-introduces Web2-style single points of failure into our Web3 stack.
My primary concerns are as follows:
The “Centralized Chokepoint” Risk: By design, a GeoDNS wrapper acts as a central traffic director. If the routing logic or the administrative account governing this layer is compromised (via DNS hijacking or credential theft), all traffic flowing through the wrapper could be silently redirected to malicious RPC nodes, even if the individual underlying providers remain secure.
Opacity of Trust: Unlike direct RPC connections where users can verify their provider, a “wrapper” obscures the connection path. This shifts the trust model from decentralized validation to centralized administration, which contradicts the core ethos of an open RPC initiative.
Lack of Security Architecture: I have yet to see an explicit security framework that details how this admin account will be secured, who holds the keys, or what the recovery procedure is if the routing layer is subverted.
Questions for the proposers and the community:
Can we define the “threat model”? What specific measures are in place to ensure that the GeoDNS/LB layer cannot be used to poison or hijack user traffic?
Is this a necessary trade-off? Is there a way to achieve high availability and low latency without introducing a centralized routing layer? (e.g., client-side routing or decentralized DNS protocols).
Decentralization as a Priority: If we prioritize convenience (UX) over trustlessness (decentralization) today, how do we prevent this from becoming the “default” for all future infrastructure scaling?
I want to see the RPC initiative succeed, but I believe that scaling our infrastructure shouldn’t come at the cost of the security model that makes Polkadot valuable in the first place. I look forward to hearing the community’s thoughts and learning more about how these risks are being mitigated.
The rsETH Precedent: Why a Routing Wrapper is a Critical Vulnerability
To illustrate why these architectural concerns are not just theoretical, we only need to look at the devastating $292 million rsETH (KelpDAO/LayerZero) exploit from April of this year.
It is vital to understand that the rsETH incident was not a smart contract failure or a cryptographic bug. It was a highly sophisticated, targeted attack on off-chain infrastructure and RPC routing.
The attackers compromised specific internal RPC nodes and simultaneously executed a DDoS attack on the healthy, external RPC nodes. This forced the network’s verification traffic to “failover” and route entirely through the compromised infrastructure. Because the system relied on a centralized verification bottleneck, the attackers were able to feed falsified blockchain data to the bridge, tricking it into releasing nearly $300 million based on a phantom transaction.
The parallels to our current proposal are alarming.
The trend is clear: sophisticated attackers are shifting their focus away from heavily audited smart contracts and toward the Web2 routing and infrastructure layers that connect them. By introducing a centralized GeoDNS/load-balancing wrapper, we are actively designing the exact type of traffic bottleneck that malicious actors are now targeting.
If we establish a centralized load balancer—especially while simultaneously discussing budget cuts that reduce the total number of independent, decentralized RPC providers—we drastically reduce Polkadot’s resilience. We make it exponentially easier for an attacker to hijack the central wrapper, compromise the admin keys, or DDoS the honest endpoints to feed poisoned state data to our dApps, off-chain workers, and bridge relayers.
We cannot trade cryptographic trustlessness for Web2 convenience. If we need automated proximity routing and failover, it must be built safely on the client side to preserve strict end-to-end encryption. I urge the proposers and the community to restrict this bounty strictly to direct, decentralized RPC endpoints before we officially fund a critical vulnerability.
I’m assuming that people were not selecting providers evenly and some were being overloaded whilst others under utilised and the load needs balanced? Is this the case? If so, couldn’t we add a check to RPC calls that ensures secure random selection on the client side before a call is made - e.g. you randomly generate a number that selects a provider from the known finite list and you sign that number + timestamp. This would ensure an even spread across nodes and places the load balancing resonsibility with the client. Obviously geolocation becomes an issue but you can add checks for that during selection and on the host side using ip dbs.