The first time I read a protocol's own worked example for median consensus, it looked like a footnote. Three operators, three numbers, one median, done. It took a second pass, honestly, to notice what that footnote was actually admitting.
The protocol is Newton, and the mechanism is simple enough to explain in one sentence. In what Newton calls the Prepare phase, the Gateway sends newt_fetchPolicyData to a set of independent operators, each one asked to fetch the same external value, a price, a balance, whatever the policy needs, and report back unsigned.
Newton's own docs walk through this with three operators pulling a price feed: 100.0, 102.0, 101.0. Close enough to agree on, different enough to prove nobody copied anybody's homework. The Gateway computes a median of 101.0, checks that every value sits within a 10 percent tolerance band, and only then moves the round into the Commit phase, where newt_evaluateAndSign has operators sign off on a policy result built from that one shared number.
None of those three operators signs what it actually saw.
I keep coming back to that line, because it is such a specific design choice once you sit with it. Operator 1 never signs 100.0. What gets BLS-signed in the Commit phase is a Gateway computation, a median, not any operator's raw observation. That isn't sloppiness, it's forced by the math: signature aggregation only stays cheap on-chain if every signer signs an identical message, and three genuinely independent fetches will almost never produce one on their own. Newton manufactures the identical message by discarding the differences before anyone signs. The raw values don't disappear entirely, they survive in what the docs call the Full Digest, kept for challenge verification. But the object that actually carries the signature weight, the Consensus Digest, has individual attestations zeroed out.
The record built for disputes ends up holding more truth than the record built for consensus. Funny how that works.
There's a second cost riding on that same uniformity requirement, and it only shows up when something goes wrong. Newton can't quietly drop an outlier and continue with the operators who agree, not without breaking the identical-message rule BLS depends on. Which leaves exactly two outcomes: everyone lands inside the tolerance band, or the whole round fails with ToleranceExceeded. No setting where two good operators simply outvote one bad one.
A single stale feed. A misconfigured endpoint. A deliberately wrong number. None of them get outvoted. Any one of them stops the round for everyone.
Zoom out from the mechanics for a second and look at what that implies about incentives. Newton sets its quorum threshold at 67 percent of operator stake. The operator network itself runs as an EigenLayer AVS, so that stake is restaked security borrowed from Ethereum, not a validator set the protocol built from scratch. The quorum math is explicitly built to tolerate a meaningful minority of that stake disagreeing and still reach consensus, provided the disagreement happens at the signing stage. The median-tolerance check sits upstream of all of that. One operator outside the band never reaches a point where quorum even applies, the round simply never gets there.
Here's the part I haven't fully settled. Newton documents two slashing conditions, incorrect evaluation and equivocation, and both describe what happens after an operator signs something. ToleranceExceeded fires earlier than that, before any signature exists to judge against a policy. Does submitting an out-of-band number, repeatedly, cost an operator anything beyond the stake they'd have kept regardless? The docs don't say. If it doesn't, the cheapest way to disrupt a round isn't forging a signature or breaking BLS aggregation, both of which risk real restaked capital if caught. It's just running a slow feed and letting the tolerance check do the rest.
None of that makes the design wrong, and it's worth saying plainly. Quietly dropping whichever operator disagrees and proceeding with a clean median from the rest would solve the stalling problem and create a worse one: it would hide the disagreement entirely. A round that fails loudly tells every party watching that a specific input disagreed with the others, which is more honest than a tidy median that silently excludes a source and reports as if nothing happened. Keeping the raw values in the Full Digest, even while stripping them from what gets signed, means the disagreement isn't erased, just relocated to where challenges live instead of where consensus lives.
So is failing the whole round over one ToleranceExceeded a safeguard against bad data, or just a slower, quieter way for one misconfigured operator to hold everyone else's signature hostage? Depends, probably, on whether you're the one waiting on it, or the one whose feed landed outside the band today.