Last night I took a different perspective @NewtonProtocol . In the past, the first thing that came to my mind when I heard “AI agent” was: “Automatically find opportunities, automatically place orders, automatically save me time.” But the more I thought about real-world scenarios, the more frightening it felt—not that the AI isn’t smart enough, but that it’s too diligent.

There’s a natural limitation when humans trade: we get tired, we hesitate, and we keep re-checking the amount. Even if we spot an opportunity at 2 a.m., with our finger hovering over the confirm button, we’ll pause and think: Did I click the wrong thing? Is the position too large? Have I already lost too much today? AI agents don’t have this problem. If it gets permission to access a wallet, it can run continuously according to the strategy: when it finds a price spread it moves, when it sees a signal it enters, when conditions are met it transfers, and when it encounters a protocol it calls it. Speed is an advantage—but speed without boundaries is also a risk.

So when I look at @NewtonProtocol Newton Protocol, what moved me most isn’t the words “AI automated trading,” but the authorization layer described in the whitepaper—the authorization layer between transaction intent and on-chain execution. In plain terms, it isn’t rebuilding a wallet, and it isn’t about saying something to make the AI smarter. Before the AI actually moves money, it asks a few very basic questions:

Can this money be spent?

To whom is the money going?

How much has been spent already today?

Did it enter an allowed protocol?

Have you encountered risk addresses?

If the amount is larger, do we need to upgrade the approval?

These problems don’t sound flashy at all, but I think they’re exactly what must be solved first for AI agents to go on-chain. On-chain execution is just too decisive: once the signature is broadcast, it’s not like a traditional back-office system where you can slowly withdraw it. Many incidents aren’t because people didn’t understand the risks, but because the risk rules weren’t truly enforced before execution.

Many projects now put risk control on the front-end pages, or in post-incident monitoring. Front-end warnings are useful, of course, but they can’t stop direct contract calls. Post-incident monitoring is useful too, but the funds are already gone—no matter how fancy the alarms are, they still feel like an accident report. Newton’s idea is to turn rules into policies, so the transaction has to pass this gate before execution. If it passes, the smart contract gets a verifiable proof to continue; if it doesn’t, don’t let it happen.#Newt

I especially like to think of it as an “AI agent braking system.” No matter how powerful a car’s engine is, if there are no brakes, no one would feel safe sitting in it. The same is true for AI agents. It can help me execute strategies, but I want to draw clear boundaries for it first: per transaction no more than 800 USDT; cumulative totals in 24 hours no more than 3,000 USDT; only allow interaction with a few allowlisted protocols; pause when abnormal price volatility occurs; directly reject high-risk addresses; and any amount beyond the limit requires manual confirmation.

Here’s a very ordinary example. Suppose I give an agent 5,000 USDT and ask it to move funds among three stable-yield pools. Before, I could only trust its strategy code, at most set a wallet limit. But the real risk isn’t just “will it lose money?”—there are plenty of gray areas: Will it enter a protocol I haven’t seen before just to chase an extra 0.3% in annualized yield? Will it keep executing when liquidity suddenly thins? Will it still call fake front ends and fake contract addresses? Will it do a dozen operations in a day, grinding down fees and slippage?

If all these questions rely on me checking logs after the fact, then it’s already too late. A more reasonable approach is to encode them as policies before execution: protocol allowlists only include A, B, and C; the single transfer amount cannot exceed 20% of the principal; at most 3 executions within 24 hours; refuse if the target pool’s TVL is below a certain threshold; and pause if the yield rate suddenly spikes—because that might be risk compensation, not a free lunch. That way, the agent isn’t unable to work—it can only work within boundaries I’m willing to accept.

If these rules are only written in chat logs, they’re meaningless. The truly valuable part is that machines can understand them, operators can evaluate them, smart contracts can check them, and there can be records left behind later. In the Newton whitepaper, it mentions Rego / OPA. My understanding is that it turns “don’t waste money, don’t enter protocols blindly, don’t do out-of-scope operations” into machine-executable rules. It’s not like human verbal agreements that you remember today and forget tomorrow—it’s more like an on-chain work code of conduct.

Another very down-to-earth point: compliance receipts. Every time a policy evaluation happens, it leaves a record—binding the transaction intent, the rules, the operator’s response, the aggregated signature, and the block information. To ordinary users this might not seem obvious at first, but when something goes wrong, it’s extremely important. You can’t just tell me “the system judged it passed”—I also want to know why it passed. You can’t just tell me “the transaction was rejected”—I also want to know which rule it got stuck on.

I think this “where did it get stuck” is really important. Many products fail not because they have no rules, but because users don’t know how the rules take effect. For example, when a transaction is rejected, what ordinary people see is just failure. But if they can see the reason—“daily quota is exhausted,” “the target protocol isn’t in the allowlist,” “price data hasn’t reached consensus,” or “requires manual confirmation”—users won’t interpret every failure as the system being broken. Conversely, project teams don’t have to rely on customer support explanations every time either. The on-chain authorization receipt itself is evidence.

This is also where I think $NEWT has differentiation. It’s not just talking about AI concepts—it addresses the permission issues of AI agents that are easiest to overlook. In the future, if everyone can create their own automation strategies, the question won’t be whether “the robot will operate”—it will be whether “the robot has the right to operate, how far it can operate, and whether we can trace it back if it gets it wrong.”

I don’t want to hand my wallet to an agent that only knows how to say “trust me.” Even if it has a very high win rate, I still wouldn’t feel at ease. I’d rather give permissions to a system that can execute rules, leave receipts, and be challenged and reviewed. AI can run fast, but the funds can’t just run on bare legs.

So when I look at Newton Protocol now, I don’t simply categorize it as an AI trading project. It’s more like putting traffic lights on-chain automation: green means go, red means stop, and yellow means upgrade handling. In the short term it might not have the hype of signal-pumping, but if AI agents really move into DeFi, stablecoin payments, RWA, and institutional asset management, this layer of authorization infrastructure will become increasingly important.

More realistically, in the future most users won’t read contracts themselves, and they won’t stare at low-level details like operators, signatures, or proofs every day. Users will only ask three questions: Is the permission I give capped? When the system rejects an operation, is there a reason? After something goes wrong, can I trace it back? If Newton can do these three things well, it has a chance to let ordinary people feel comfortable using on-chain automation. Otherwise, even if an AI agent is smart, it’s hard to turn from a “try-it-out tool” into a long-term custodial strategy.

This is also why I’ll keep paying attention to it. There are many AI projects that can tell stories, but there aren’t many that can explain clearly—what is basically dirty, hard work—the “permission boundaries.” When it’s truly deployed, what users often need most isn’t bigger slogans, but whether you dare to let the strategy keep running before you go to bed.

My take on $NEWT is also simple: real on-chain AI isn’t about giving robots infinite freedom—it’s about giving them freedom within clearly defined boundaries. The clearer the boundary, the more boldly you can use automation.