Looking back at the Newton Mainnet Beta, there’s a question that’s been turning in my mind: auditing isn’t a new concept in DeFi—why does it become even more critical in this kind of architecture than before?@NewtonProtocol
A common way of thinking is that once the audit is done, that should be enough—hire a good team, produce a detailed report, fix the vulnerabilities, and then go live. This process holds for most protocols, but it assumes a premise: the audit results remain valid after the protocol is deployed. For static smart contracts, this premise is only barely true—once deployed, the contract logic doesn’t change, and the audit report can serve as a long-term reference. But when part of a protocol’s execution logic runs off-chain—strategies can be updated, Operators can be rotated, and data sources can be changed—the validity window of the audit report starts counting down from the moment it’s submitted.$LAB
After the protocol went live, strategy versions were upgraded, but the audit team did not re-audit the logic of the new version; the Operator was replaced, and the audit report didn’t cover operational records for the new nodes; the data source changed, and the assumptions about data quality and update frequency used during the audit may not hold for the new source. Every change to a Rego policy line and every swap of a WASM data provider silently erodes the applicability boundary of that audit report.$TAG
This doesn’t mean audits have no value. The issue is that there’s a structural gap between static auditing and dynamic operation: audits cover a time slice before launch, while risk lies in the ongoing execution after launch.
Nathaniel Popper mentioned an observation in *Digital Gold*: Bitcoin’s core innovation wasn’t cryptography—SHA-256 and digital signatures existed before—but rather assembling cryptographic tools into a system that can run continuously without relying on centralized trust. Mainnet Beta faced the audit version of the same problem: not inventing new auditing methods, but making the verifiability of audits a structural feature of system operation rather than a one-time action before launch.
Before each transaction goes through, the Operator runs strategy evaluation inside a TEE, and then fixes the execution record on-chain in the form of a BLS signature. This record includes the input data, the strategy version number, and the evaluation result. At any time, auditors can fetch this record, rerun the evaluation locally using the same strategy version and input data, and independently verify whether Chainalysis’s tags match, whether RedStone’s prices are consistent, and whether Rego’s rule branches lead to the correct conclusion. This isn’t adding another audit gate to the process; it’s embedding the raw materials needed for auditing into every execution.
Rego’s determinism solves a more specific engineering problem: cross-execution reproducibility. If the same strategy, running in any Operator’s TEE at any point in time, always outputs the same results, then auditors only need to sample and verify one execution record to infer consistency of that strategy’s behavior across all executions. Without deterministic execution as a foundational assumption, auditors would have to verify the cost of every individual execution, which would grow linearly with transaction volume—eventually becoming economically unsustainable.
The trade-off is that the production process of audit materials is tightly coupled with the execution process. On-chain audit records can only prove that the execution process wasn’t tampered with, but they can’t prove that the data used during execution was correct. If RedStone’s price feed is delayed for a particular trading pair, the Operator—evaluating based on an incorrect price—produces an incorrect release outcome. The entire execution process leaves a complete, verifiable trail on-chain: every signature is valid, every rule branch runs, but the decision itself is wrong. This is an unavoidable gap between auditability and data correctness.
Going forward, whether an on-chain authorization system can hold up in compliant audits shouldn’t be judged by whether execution logs are preserved, but by whether those logs allow a third party that didn’t participate in that execution to independently reproduce the exact same evaluation conclusions using only the policy version and input data. Reproducibility is the anchor of audit trust—not the completeness of the record.
Returning to the positioning of $NEWT , if auditability is built into the system as a default output rather than a patch after the fact, the protocol’s reliance on audit services shifts from “paying for a report” to “having an evidence chain built into the system.” What changes isn’t the cost structure of auditing, but the way trust is established—from trusting an auditor company’s brand to trusting a structural feature by which the system’s on-chain data can be independently verified by anyone.