I spent some time thinking about what should happen when a decentralized network can't agree on a number.
Newton's Gateway runs a two-phase consensus for policy checks. In the Prepare phase, when a policy needs external data, every operator independently fetches that value and submits it back unsigned.
At first, that sounded like a formality.
Unsigned means nobody has committed to anything yet.
The Gateway takes all those submissions, computes the median, and checks each individual value against it. If every operator lands within tolerance, the value normalizes and consensus proceeds to signing.
Newton's default tolerance for that check is 10%.
That is the part that caught my attention.
Not 10% as a security parameter in the abstract. 10% as a hard ceiling that either passes or throws ToleranceExceeded, with no middle behavior documented in between.
Three operators reporting 100, 102, and 101 land inside that band without incident. The median comes out to 101, everyone agrees closely enough, and the check clears.
Change the middle value to 115 instead of 102, and the same mechanism stops cold.
Not because anyone did anything wrong.
Because nobody could get close enough to sign.
That distinction matters more than it looks. A system that drops outliers and keeps moving is optimizing for availability — it always gives you an answer, even a slightly wrong one. A system that halts the moment operators disagree by more than a fixed threshold is optimizing for something else entirely: making sure nobody ever signs off on a number that couldn't be verified against the group.
Newton chose the second one.
But something kept nagging.
A fixed percentage doesn't know what asset it's protecting.
10% divergence on a stablecoin pegged tightly to a dollar is a five-alarm signal that something is badly wrong with one operator's data source. 10% divergence on a volatile asset during a fast five-minute move is just Tuesday. The same threshold treats both situations identically, because the mechanism has no concept of what's normal for the thing being measured.
That is where this stops being a config detail and starts being a design bet.
For a rollup pitching itself at AI-driven trading strategies, live price checks are exactly the kind of external data that policy evaluations lean on. An arbitrage agent waiting on a price-dependent policy check during a genuinely volatile window can hit a wall that has nothing to do with fraud, manipulation, or a broken operator — just three honest data sources briefly disagreeing by more than a tenth.
Newton's own documentation lists the fix as either raising the tolerance manually or investigating the data source by hand. There's no automatic middle ground, no partial-consensus fallback, no documented behavior for what the waiting task is supposed to do while that investigation happens.
That gap is not something I can verify from outside the system — Newton hasn't published agent-side fallback guidance, so what happens to a stalled task in practice remains an open question rather than a documented one.
NEWT itself is trading around $0.049, with a market cap near $14.2 million against a circulating supply of roughly 291.7 million tokens out of a fixed 1 billion total supply, and about 14,800 holders on its Ethereum contract. The token is down more than 94% from its June 2025 all-time high of $0.83 and actually touched a new all-time low of $0.045 less than two weeks ago. That's a small, still-forming market for a protocol asking institutions and autonomous agents to trust its data pipeline during exactly the moments — fast, volatile ones — when a fixed 10% band is most likely to get tested.
None of this means the design choice is wrong.
Failing closed is a defensible instinct for a compliance-adjacent policy layer. Nobody wants a system that quietly signs off on a bad number because it was in a hurry to give an answer.
But defensible and free are different things.
The cost of that choice lands on whoever's transaction was waiting in the queue when three honest operators briefly couldn't agree, and right now there's no public data showing how often that actually happens versus how often it's theoretical.
Does a fixed 10% floor protect the network from bad attestations, or does it just relocate the volatility problem from the price feed onto whichever agent's task happens to be running when the market moves fast enough to trip it?
