Not long ago, I chatted with a friend who does on-chain fund management. He said something that really stuck with me.
He said, “Now, on-chain automation isn’t really a difficult problem anymore—the real challenge is whether I dare to let it make decisions for me.”
At first, I thought this statement was a bit contradictory.
After all these years of blockchain development, isn't it precisely to let code execute automatically?
Smart contracts are transparent and rules are written in advance, with transactions executed according to the program.
It seems that people should be involved less and less.
But later, when I thought it through carefully, the issue really isn’t that simple.
Because of past automation on the chain, most solutions addressed “how to execute.”
For example, swapping tokens.
For example, collateralized lending.
For example, a yield strategy.
Code tells the system what to do next, and the system executes accordingly.
But once the scale of funds keeps growing and the participants become more complex, a new problem emerges:
If something with this automatically executed mechanism goes wrong, who can prove why it did that?
In the past, many people understood blockchain security by focusing on attacks.
Has the private key been leaked?
Are there vulnerabilities in the contract?
Has the money been stolen?
These are all important.
But now, with the development of directions like AI Agents, automated strategies, and RWA, I feel the industry is facing a deeper issue:
In the future, many operations may not be completed by humans actively; the system will do it on their behalf.
Back then, the biggest risk might not be a hacker attack, but a system executing a thing that looks legitimate according to the wrong logic.
For example, an AI trading agent.
Every day it helps users adjust their positions.
It makes judgments based on market data.
It automatically executes the policy.
Under normal circumstances, this is a very wonderful thing.
But if one day:
Anomalies in the data source.
Model judgment deviation.
Strategy parameters are modified.
The execution environment has a problem.
In the end, it causes losses.
What the user should do?
Many times, you even don’t know which step the problem occurred at.
Is it an AI problem?
Is it a data problem?
Is it a problem with the strategy?
Or is it a problem with the executor?
This is the biggest challenge for automated finance in the future.
That’s also why I’ve come to re-understand the Newton Protocol.
When I used to see Newton, I only took it as a project combining AI and on-chain security.
But later it turns out it isn’t really about making the system “better at doing things.”
Instead, it makes it so “when systems do things, they have a basis.”
This difference is extremely important.
Because the future financial world isn’t short of automation.
What’s truly missing is trusted automation.
A robot helps you perform ten operations a day; if there are no boundaries, it’s just a faster tool for making mistakes.
But only if all its actions are constrained by rules, and the execution process can be verified, could it truly enter financial scenarios.
I think Newton’s core value is not any single technical component, but a change in mindset.
In the past:
A user authorizes a system, and then trusts it.
Future:
A user authorizes a system, but the system must prove it hasn’t gone out of bounds.
That’s why designs like Policy Engine and zkPermissions are meaningful.
It doesn’t simply tell the system:
“You can operate.”
Instead of telling the system:
“You may only operate within this range.”
For example:
[It] can only operate which assets.
What’s the maximum amount per day?
What conditions must it meet?
Under what circumstances must it stop?
These rules aren’t written in manuals—they become part of the execution process.
This direction is actually quite similar to real-world institutions.
Why won’t banks let an employee have unlimited permissions?
Why do corporate finances require approval workflows?
Why do large institutions need multiple layers of approvals to manage funds?
Not because they don’t trust employees.
Rather than because mature systems don’t build risk on human reliability.
It will establish boundaries.
I think what Newton wants to do is to bring these boundaries onto the chain.
So that future automation systems not only have capabilities, but also have responsibility constraints.
Of course, this path isn’t easy.
Because the hardest part of an infrastructure project isn’t coming up with a clever concept.
Instead, it allows the market to truly use it.
Newton will need to prove:
Are there developers who are willing to build applications on top of it?
Is there real capital running through this system?
Is there any complex financial scenario willing to adopt this kind of execution approach?
After all, there’s still a long distance between technical solutions and industry infrastructure.
Many project problems aren’t about having the wrong direction; they’re about not forming real user needs.
Also, I think one of the most worth watching things about Newton in the future is whether it can become the foundational rules layer in the AI era.
Because in the future, AI will participate in on-chain activities more and more.
Today it might just be automated dollar-cost averaging.
Tomorrow might be automated asset management.
The day after tomorrow might be an institutional-level AI fund.
When machines start handling value on humans’ behalf, what humans truly need isn’t a more powerful machine.
It’s instead a set of rules that prevent machines from crossing boundaries arbitrarily.
So when looking at Newton now, I won’t simply categorize it as an “AI project.”
I’d rather understand it as:
A layer of trusted execution infrastructure between AI and on-chain finance.
It doesn’t solve the problem of giving machines more power.
Rather, once machines have power, they still need to be constrained.
Because the biggest change in future finance isn’t that humans disappear.
Rather, more and more things will be handled by the system.
At that time, what the market ultimately chooses won’t necessarily be the fastest system.
Instead, it’s about being able to prove that:
“I know why I’m doing this, and I can prove I didn’t do anything wrong.”