User-AlphaRadar

After the Tornado Cash sanctions hit in August 2022, something quietly changed on Ethereum. A big chunk of blocks started getting built by relays that refused to include transactions touching sanctioned addresses — not because the protocol required it, but because the entities running those relays decided compliance was safer than neutrality. At points, over half of new blocks were coming from OFAC-compliant builders. The chain itself didn't change. Who was allowed to get included in it did.
That's the dramatic version — a whole network's censorship-resistance quietly depending on which builder happened to win that slot. But the same risk shows up anywhere one entity sits in the middle, routing things, even briefly.
Whoever holds that seat decides what gets seen.
Not a hack. Not against any rule. Just leverage nobody planned for.
I didn't expect a compliance-infrastructure whitepaper to take this seriously as a risk to itself. But Newton actually designed around it, and it's a small architectural detail most people would skip past.
It was never really about the Gateway
Newton has a Gateway — the entry point that routes transaction intents to the operator network and orchestrates the response. Obvious question: what stops the Gateway from becoming exactly what those Ethereum relays became?
Silent filtering — quietly refusing to route certain intents without ever admitting it
Response tampering — altering what comes back from operators before it reaches the application
Permanent control — one entity holding the routing seat indefinitely, becoming a chokepoint by default
None of these require breaking a rule. They just require sitting in the one seat that sees everything before anyone else does.
What Newton's actually doing about it
The Gateway isn't a fixed piece of infrastructure. It's a rotating role — every registered operator is a candidate, and the seat changes hands each epoch through leader selection, the same basic idea Ethereum itself uses for choosing block proposers.
Even mid-rotation, the Gateway can't forge signatures or alter results without it being provable — operators sign their own outputs independently, so tampering shows up immediately. And if an application suspects the Gateway is stalling or filtering something on purpose, it can submit directly to the operator network and skip the Gateway completely.
Same instinct as the operator-challenge system elsewhere in Newton, basically. Don't just trust the seat. Build a way around it.
Where I'm stuck, honestly
This solves the "one relay holds all the power" problem specifically. It doesn't solve coordinated censorship — if enough operators independently decide to filter the same category of transaction, rotating who orchestrates doesn't help, because the problem isn't the seat anymore, it's the operators themselves agreeing on what to exclude. That's exactly what happened with Ethereum's relays — it wasn't one bad actor, it was many separate ones making the same compliance call independently.
There's also a coordination cost the whitepaper doesn't dwell on. Rotating leadership every epoch means constant handoffs, and handoffs are where latency and edge-case bugs tend to live. A system that's harder to censor by design is also a system with more moving parts to get exactly right.
Bigger than just the Gateway
Newton uses this same "don't concentrate the seat, and build an escape hatch anyway" logic in its dispute system too — anyone, not just registered operators, can challenge a bad attestation. Different problem, same refusal to let one role become permanently trusted by default.
Does rotating who holds the gate actually stop censorship, or does it just mean you need more people to agree before it happens?
#Newt $NEWT @NewtonProtocol

The Data That's Already Been Stolen, Just Not Decrypted Yet
Security researchers have been saying this for years now, and it still doesn't fully land the first time you hear it: someone doesn't need to break your encryption today to read your data eventually. They just need to copy the ciphertext now and wait. "Harvest now, decrypt later" isn't theoretical — NIST finalized post-quantum standards (ML-KEM, ML-DSA) in 2024 specifically because governments and intelligence agencies are already assumed to be doing this, right now, at scale.
That's the dramatic version — nation-states hoarding encrypted traffic. But the same math problem applies to anything encrypted today with current cryptography, including identity data sitting on a blockchain protocol you're using this year.
Nobody's system is exempt just because it's new.
Not urgent yet. Not nothing either.
I didn't expect a compliance protocol's whitepaper to address this directly, buried near the very end, almost as a footnote. But Newton actually built for it.
It was never really about today's encryption
The real problem isn't that current encryption is weak. It's fine, for now. The problem is architectural:
Hardcoded crypto — a system built assuming one encryption scheme forever can't swap it out without a full redesign later
Harvested ciphertext — data encrypted today under current standards can be copied and stored by anyone, decrypted whenever the math catches up
Migration paralysis — protocols that didn't plan for this end up needing years of coordinated upgrades once the threat becomes concrete instead of theoretical
None of these are failures happening yet. They're failures waiting for a timeline nobody can predict precisely.
What Newton's actually doing about it
Newton's privacy layer runs on HPKE (RFC 9180) — and the whitepaper specifically calls out that HPKE was designed for algorithm agility from the start. The encryption, key exchange, and hashing components are modular, not fused together. Swapping the key-exchange method from today's X25519 to a post-quantum one like ML-KEM becomes a configuration change, not a protocol rewrite.
Same pattern they use elsewhere in the system, basically. Build the pipes so the part that needs replacing later can actually be replaced.
Where I'm stuck, honestly
This solves the migration problem. It does nothing for data already harvested today, encrypted under current standards, sitting in someone's storage right now waiting for better hardware. If NIST's 2024 standards exist because harvest-now-decrypt-later is already happening, Newton being ready to migrate in five years doesn't un-harvest what got copied last year. The architecture readiness and the harvesting risk are two separate clocks, and only one of them is under anyone's control.
There's also the part whitepapers gloss over: being technically capable of migrating isn't the same as the entire operator network actually coordinating and executing that migration on a real timeline, under real pressure, before it matters instead of after.
Bigger than just quantum
Newton uses this same "build for a future upgrade, don't force it now" logic elsewhere too — the MPC-based privacy layer is explicitly framed as a stepping stone toward eventual fully homomorphic encryption, once that's fast enough to be practical. Same philosophy, different timeline, same honesty that today's version isn't the final one.
Does designing for a future you can't schedule actually protect you, or does it just push the real risk further out without removing it?
#Newt $NEWT @NewtonProtocol

Una vez vi cómo mi propio intercambio quedó en medio. No fue nada dramático: envié una operación, la revisé un minuto después y el precio ya había cambiado en mi contra antes de que mi transacción siquiera se confirmara. Alguien vio la orden en el mempool, operó antes, y luego volvió a operar justo después. Un sándwich de manual, y solo me di cuenta porque el deslizamiento fue mayor de lo que debería haber sido.
Sabía que MEV existía en teoría. Verlo ocurrir en una operación de tamaño normal es diferente a leer sobre ello.
La parte que realmente está rota

Un amigo mío perdió alrededor de $3,000 el año pasado. No por un hack en el sentido técnico: él firmó una transacción desde una ventana emergente falsa de wallet-connect que parecía lo suficientemente real. Un clic, una firma, listo. Sin advertencias, sin segundo paso, nada que se interponga entre "Yo aprobé esto" y el dinero saliendo realmente.
Sigo pensando en lo normal que es ese sistema. Tu clave privada puede moverse cualquier cantidad, en cualquier momento, con cero fricción más allá de la firma inicial. Si la pasas por alto una vez, no hay una segunda oportunidad incorporada al sistema para atraparte.