Today isn’t about promoting a project. It’s about talking through a problem that many people still overlook: the trust gap in on-chain AI, and whether Newton Protocol really has what it takes to close it.
Right now, a lot of on-chain AI still operates like a black box. You hand over your assets to an AI agent, but you don’t really know what strategy it will follow, what risks it might take, or how it will react when market conditions change. Most of the time, you only find out after everything has already happened.
And that’s where the real issue starts.
Are there bugs in the code? Are there gaps in the risk-control logic? Is the strategy actually safe under different market conditions? The moment you authorize an AI agent, you’re placing a lot of trust in the developer and the logic written into the code. If the strategy is flawed or an oracle gets manipulated, your wallet could start losing funds before you even understand what went wrong.
That’s the trust gap of on-chain AI.
Newton Protocol is trying to solve this exact problem. Its approach is fairly straightforward: move trust away from people and toward code. Instead of checking whether a transaction was safe after it happens, the goal is to stop risky actions before they’re ever executed. Personally, I think that’s the right direction.
So how does it work?
It relies on two layers of protection.
The first layer is VaultKit’s pre-execution rules. Developers can define hard risk boundaries using Rego policy language, including identity verification, jurisdiction restrictions, spending limits, compliance requirements, and agent protection rules. These policies are enforced before any transaction is executed, not afterward. In theory, this creates a much stronger security baseline while still allowing flexibility where it’s needed.
The second layer is verifiable computation. Once a strategy is uploaded, it runs inside a Trusted Execution Environment (TEE), while the outside world verifies the execution through cryptographic proofs. That means users don’t have to blindly trust the platform. Instead, they can verify that the strategy followed the defined rules and that the execution wasn’t tampered with. You can think of it as giving every AI agent a real-time auditor instead of someone who only reviews the books after everything is finished.
For institutions and DAOs, this could make a meaningful difference. It reduces the cost of building trust. Instead of relying entirely on manual reviews or assumptions, both sides can depend on cryptographic verification to confirm that the agreed rules were actually followed.
That said, a good idea doesn’t automatically guarantee perfect execution.
There are still a few challenges worth paying attention to.
First, writing good strategies isn’t easy. Rego is a powerful language, but creating airtight policies requires experience. If the rules are too strict, legitimate transactions could get blocked. If they’re too loose, risky actions might still slip through. Either way, mistakes can become expensive.
Second, there’s the hardware trust assumption. TEEs improve security, but they still rely on hardware vendors. In other words, trust isn’t completely eliminated—it’s shifted from software developers to hardware manufacturers.
Third, there’s proof generation latency. Zero-knowledge verification offers strong security guarantees, but generating proofs still takes time. In high-frequency or fast-moving markets, even small delays can matter. By the time the proof is generated, market conditions may already have changed.
Then there’s NEWT.
As the native gas token of Newton Protocol, NEWT is used for strategy deployment, permission management, and verifiable proof submissions. That gives the token real utility within the ecosystem. At the same time, if large-scale deployments require many separate instances, gas costs can increase accordingly. The long-term value proposition will depend on how effectively the team continues optimizing the underlying infrastructure.
My view hasn’t changed.
I believe the pre-verification approach is the right direction. That’s the part of Newton Protocol that stands out to me. At the same time, the current mainnet beta still feels early, and the real test will be how the team improves the developer toolchain, reduces proof latency, and optimizes gas efficiency over time.
For now, I’m comfortable keeping a small position, following the project’s progress, and seeing how the engineering evolves before making any larger commitments.
Newton isn’t trying to build a god-like AI.
It’s trying to build an environment where AI agents operate inside clearly defined boundaries before anything goes wrong. The direction looks promising. Whether it ultimately succeeds will depend on how well the technology performs as the ecosystem continues to mature.
So I’ll leave you with one question:
Have you ever experienced a black-box problem while using an on-chain AI application? Let me know your thoughts below.
