@NewtonProtocol In the official documentation’s Section 8.3, the description of the Gateway’s automatic retry mechanism contains only one sentence: “If an Operator is unavailable, the Gateway will automatically put the Intent back into the queue to ensure execution success rate.” The phrase “ensure execution success rate” gives the impression of pure altruism. But as soon as you send a simulated Intent to the mainnet contract and then deliberately take the assigned Operator node offline, you’ll see the true invoice behind this “ensure.”

Test reproduced on the dev network: submit a token exchange Intent, locking $NEWT as the evaluation-fee collateral. The Intent enters the pending state, and the Gateway assigns it to Operator A. At this point, you cut off Operator A’s TEE network connection; about 45 seconds later, the first AssignedFailed event appears on-chain, and the evaluation fee is deducted. The Intent is re-queued and assigned again to Operator B. Since B is also unavailable, another 45 seconds later a second evaluation-fee deduction occurs. The loop runs 11 times in under ten minutes, and the total deducted evaluation fees reach 11 times the original estimate. Throughout the process, what the user sees in the wallet interface is always “pending—waiting for execution”; there is no “retrying,” no “failure count.” Even on the blockchain explorer, only the most recent assignment is shown—the historical failed assignments are folded away.

That is the destructive power of the infinite retry parameter: it strips away the “visibility” of execution failures, while quietly shifting the cost of failure to users. According to Section 10.1 of the white paper, the evaluation fee is deducted as soon as the Operator begins calculating. But in repeated allocations caused by Operator unavailability, each allocation re-triggers the evaluation step. TEE resources are indeed scheduled, yet from the user’s perspective, none of it produces valid output. It’s like handing a package to a courier station: the courier leaves and returns again and again, and every time they return, they charge you another shipping fee—yet all you see is the three words “Out for delivery.”

Deeper hidden risks lie beneath the bookkeeping of fees. Newton’s current accounting model does not distinguish between “deductions that produce valid evaluations” and “deductions caused by failed allocation.” These two categories of expenses are grouped together in the income statement, treated as “network fee revenue,” and included in the Operator’s and token holders’ revenue pool. If the Intent falls into a dead loop because a large portion of Operators across the entire network go offline, the network not only fails to complete the service—it becomes the sole beneficiary. This is no different in nature from traditional finance’s duplicate charges caused by a bank system failure; the difference is that on-chain there is no customer support to appeal—only code as the rule.$BTC

The fix path is actually not complicated. All it takes is setting a default retry limit in the Gateway configuration (e.g., 3 times), and during each retry, writing a retryCount field into the Intent state event so the frontend can display something like “Retrying (2/3).” This does not require changing the consensus layer—only adjusting default parameters and filling in the visible logic. However, since community calls for this change, it has already gone beyond two version updates, and still hasn’t been implemented. Is the technical difficulty too high, or is the evaluation-fee revenue brought by infinite retries more important to the system than anyone imagined? As a holder of NEWT, this question mark should not remain outside the bullish logic.#Newt $NEWT @NewtonProtocol