BlockBreaker

Newton Protocol is built to decide whether certain blockchain transactions should be allowed before they are executed.
That makes its authorization layer more than a monitoring tool or a security alert system. It becomes part of the transaction itself. If Newton cannot complete an authorization request, a protected action may not move forward, even when the action is urgent.
This raises a question that ordinary uptime reports cannot answer. What happens when Newton Protocol’s authorization layer stops responding?
A status page may show that a server is online, experiencing delays, or temporarily unavailable. That information is useful, but it does not explain what happens to a vault manager who needs to move funds, reduce exposure, change an allocation, or react to a sudden market problem. The more important issue is how Newton behaves after authorization becomes unavailable and what options remain for the application using it.
Newton does have protections against several types of failure. Its network is designed so that one unavailable operator should not stop every authorization request. It can also replace an inactive gateway and continue operating when parts of its messaging infrastructure fail. However, these protections mainly help Newton keep its own network running. They do not create an automatic alternative if the authorization network as a whole cannot approve a transaction.
To understand the fallback, it helps to look at Newton’s place inside the transaction process.
An application first sends a proposed action to Newton. The network identifies the policy attached to that action and asks its operators to evaluate it. A policy might check the destination contract, the type of asset being used, the amount being moved, a risk score, a price feed, or another condition chosen by the policy developer.
The operators run the policy and sign their results. Once enough operator support has been collected, Newton produces an attestation. The application then checks that attestation before the transaction is sent for execution.
Several things can interrupt this process.
The gateway may not respond. Some operators may be offline. A policy may depend on an outside data provider that is unavailable. Operators may receive different data and fail to agree. The network may not collect enough signatures before the request times out. An attestation may also expire while the transaction is waiting to be processed onchain.
Newton’s documentation recognises these situations. It describes errors related to unavailable operators, failed data requests, insufficient quorum, expired attestations, invalid signatures and failed onchain validation. In many cases, the suggested response is to retry the request, increase the timeout, check operator health or request a fresh attestation.
That is reasonable for a temporary problem. A second attempt may work if one operator was briefly disconnected or a request was delayed. It becomes less helpful during a wider outage. Repeating the same request will not solve a failure affecting the full authorization network or a data provider that remains unavailable for several hours.
Newton’s internal design offers some protection before the situation reaches that point.
Authorization tasks are sent to multiple operators rather than relying on one machine. The network does not need every operator to respond. It only needs enough stake-backed support to reach the required quorum. If one or two operators are slow or offline, the remaining operators may still complete the decision.
For policies that depend on live information, Newton uses a two-stage process. Operators first collect data independently. The gateway then brings those results into a common form and sends them back for final policy evaluation and signing. Newton’s documentation describes a default quorum threshold of 67 percent of operator stake, along with separate time limits for collecting information and completing the final decision.
The communication system also includes redundancy. Newton uses NATS for messaging between its network components. Its whitepaper describes a clustered setup spread across different availability zones. This allows another part of the messaging network to continue working if one node fails.
The gateway role is also designed to rotate. If the active gateway stops sending the expected heartbeat signals, another eligible operator can take over.
These choices reduce dependence on a single server, operator or location. They are useful, and they make Newton harder to disrupt through one isolated failure.
Still, redundancy has limits.
The network can route around an unavailable operator only when enough other operators remain available. Gateway replacement helps only when the backup can still communicate with the operators and reach the required services. A messaging cluster can survive one failed node, but it cannot guarantee that every connected data provider, blockchain endpoint and authorization component will remain reachable.
When Newton cannot produce a valid authorization, the normal VaultKit response is to block the protected action.
VaultKit follows a fail-closed model. A transaction does not continue simply because the authorization system failed to respond. If the network cannot reach quorum, the attestation expires, the gateway is unavailable, operators reject the request or onchain validation fails, the Shield contract does not forward the action.
The transaction stops.
From a security perspective, that is the safer default. If protected actions were allowed whenever Newton became unavailable, an attacker could try to disable the authorization layer and use the outage as a way around the policy. The protection would disappear at the exact moment it was needed.
Failing closed avoids that weakness. No valid authorization means no protected transaction.
The problem is that a blocked transaction is not always harmless.
A vault manager may need to move funds away from a failing protocol, reduce exposure to an unstable asset or adjust collateral before a position becomes dangerous. During a fast market event, a delay of minutes can matter. If Newton cannot authorize the action, the manager may be unable to respond through the normal route.
Newton’s security model therefore protects the vault against unauthorized action, but it may also prevent legitimate action during an outage.
VaultKit limits some of this risk by separating manager actions from normal user activity. According to Newton’s documentation, the Shield generally protects actions performed by vault managers. Deposits and withdrawals by ordinary users do not normally pass through the same authorization path.
That distinction is valuable. A Newton outage may stop a manager from changing the vault without automatically stopping every depositor from leaving it. The exact outcome depends on how the vault has been designed, but user withdrawals do not necessarily need to rely on Newton’s availability.
For manager actions that remain blocked, VaultKit includes an emergency route.
The owner of the Shield can queue a bypass transaction. After the configured waiting period has passed, the owner may execute the action without receiving a normal Newton attestation.
This bypass is visible onchain. Other users and monitoring systems can see that it has been scheduled and can later see whether it was executed.
The waiting period is an important part of the design. The owner cannot instantly abandon the policy because one authorization request failed. The delay creates time for depositors, governance participants and security monitors to notice that an action without the usual checks is being prepared.
It also reduces the danger of a compromised owner account. Even if an attacker gains control of the owner, the attacker cannot necessarily carry out an unverified transaction immediately. The queued action remains visible during the timelock.
The same delay can become a serious limitation during a real emergency.
A vault may need to exit a risky position quickly, while its bypass requires a much longer wait. In that case, the timelock protects users from a dishonest owner but also slows down a legitimate response.
There is no perfect delay for every situation. A short timelock makes emergency action easier but gives users less time to react to abuse. A long timelock provides stronger warning but may leave the vault unable to respond quickly enough to market conditions.
Each VaultKit deployment must choose that balance for itself.
Newton’s legal terms also make the consequences of the bypass clear. A bypassed transaction is not checked by the normal policy, its data providers or the restrictions built around it. Responsibility for the action rests with the party that uses the bypass.
This means the bypass is not a backup authorization service. It is a controlled way to act without authorization.
That difference matters because the emergency route can remove several protections at once. A normal Newton policy may check prices, risk information, asset restrictions, contract addresses and transaction limits. The bypass can allow the owner to proceed without those checks.
The safety of the fallback therefore depends heavily on who controls the Shield.
Newton does not retain control over every deployed Shield contract. The deployer owns and manages it. Newton or Magic cannot simply step in, pause it or operate it during an incident.
This reduces the risk of a hidden central administrator controlling every vault. At the same time, it places more responsibility on each deployment.
The Shield owner could be one wallet, a multisignature account, a governance contract or another control system. These setups are not equally safe.
A single wallet creates an obvious point of failure. If its private key is stolen, an attacker may be able to queue a transaction that avoids Newton’s normal policy checks.
A multisignature wallet can reduce that risk by requiring approval from several people or systems. It still depends on those signers remaining independent, reachable and willing to follow an agreed emergency process.
The protocol can enforce a waiting period. It cannot guarantee that the owner structure has been designed responsibly.
A vault using Newton should therefore make its emergency controls clear before users deposit funds. People should know who controls the Shield, how many approvals are required, how long the bypass delay lasts, whether a queued transaction can be cancelled and what types of action may be executed through the emergency route.
Without that information, users know that a fallback exists but cannot properly judge the risk attached to it.
Outside data services create another area of concern.
Newton policies can use information that does not originate inside the protocol. A policy may depend on an asset price, depeg history, sanctions result, collateral level, oracle health check or risk score.
Newton’s work with Webacy provides a useful example. A vault policy may use live risk information to stop a manager from allocating funds to an asset that has experienced repeated depegs or other warning signs.
This can make the policy more useful, but it also introduces another dependency.
Every Newton operator may be online and still be unable to complete the authorization if the required data provider is down.
Using several operators does not automatically solve that problem. If all of them request information from the same provider, they may all fail together.
Newton allows developers to include several data sources inside one policy. That gives policy designers more choice, but it does not automatically create a fallback. The result depends on how the policy is written.
A policy might require every data source to respond successfully. That can provide stronger confirmation under normal conditions, but it also means one failed provider may block the full transaction.
Another policy might allow a secondary source to replace the main provider. That can improve availability, but it introduces questions about data quality, freshness and disagreement. The developer must decide which provider has priority, how old a result may be and what should happen when two sources return different values.
Newton provides the tools to combine data sources. It does not provide one universal rule for handling a failed provider. The policy developer remains responsible for defining that behaviour.
This is an area where fail-closed logic can be both protective and restrictive. If the policy denies the transaction whenever a data source returns an error, missing information will not be mistaken for safe information. The trade-off is that an outside service can stop a legitimate transaction even though Newton itself is still operating.
Notifications do not solve this issue.
Newton can report operator errors, timeouts, quorum failures, invalid signatures, expired attestations and onchain validation problems. Applications can receive updates through WebSockets or webhooks.
These tools are useful for monitoring. They allow a team to see that something has failed and begin investigating.
They do not provide transaction continuity.
A webhook retry only tries to deliver the notification again. It does not move the protected transaction through another authorization network. It does not automatically activate the VaultKit bypass. It does not replace an unavailable data source.
The same caution applies to changing the quorum threshold.
Newton’s documentation mentions that lowering the threshold may help when the network cannot collect enough operator support. That is not a routine availability adjustment.
Increasing a timeout only changes how long the system waits. Lowering quorum changes how much operator backing is needed to approve a transaction. It alters the security model.
A lower threshold may help the network continue operating, but it also allows a smaller share of operator stake to authorize actions. Such a change should require a formal process, clear limits and a plan for restoring the original threshold.
The larger weakness in Newton’s public fallback story is not the absence of technical safeguards. It is the lack of one clear operational plan that connects them.
The whitepaper explains gateway replacement, operator coordination and messaging redundancy. The developer documentation explains errors and retries. VaultKit explains fail-closed behaviour and the timelocked bypass.
What is harder to find is a simple explanation of what a real deployment should do during a prolonged outage.
How long should the application keep retrying?
At what point should the event be treated as a serious authorization failure?
Which types of transaction should qualify for the bypass?
Should a transaction that reduces risk be treated differently from one that creates new exposure?
Who decides that Newton has been unavailable long enough?
What should happen if the network recovers while a bypass transaction is still waiting?
How should normal policy enforcement be restored after the bypass has been used?
These decisions are likely to vary between vaults, but they are central to the safety of the system. Leaving them entirely to each deployment creates room for confusion during a stressful event.
A practical fallback plan should divide transactions by their purpose.
Routine management actions may be able to wait.
Actions that increase risk could remain blocked until full Newton authorization returns.
Actions that reduce exposure may need a different emergency process.
User withdrawals should remain outside the authorization layer wherever the vault design allows it.
Administrative changes may need stricter controls than ordinary portfolio adjustments.
The emergency process should also require more than one failed request. A short network delay should not immediately trigger an attempt to bypass the policy.
A vault could require repeated failures over a defined period, confirmation that the gateway or quorum is unavailable and approval from several independent signers before an emergency action is queued.
Testing matters just as much as written rules.
A team should test what happens when the gateway stops responding, enough operators go offline to prevent quorum, a data provider becomes unreachable or an attestation expires before execution.
It should also test the emergency bypass itself. The team needs to know whether the correct owner can queue it, whether monitoring systems notice it, whether it can be cancelled and whether the vault returns to normal operation after the incident.
These tests reveal much more than a status page.
An uptime percentage may show how often Newton responds. It does not show how many authorization requests reach quorum, how long approvals take under stress, how often outside data sources fail or how many protected actions are blocked.
It also does not show how often bypass transactions are queued, cancelled or executed.
Newton Protocol does have a fallback structure, but it is made of several separate layers.
Its internal network can continue operating when individual operators fail. Its messaging system includes redundancy, and an inactive gateway can be replaced.
If the network still cannot produce valid authorization, the protected action fails closed.
For VaultKit deployments, the Shield owner can use a delayed, visible bypass. That route allows the transaction to proceed, but it removes the policy checks that Newton would normally provide.
If the failure comes from an outside data provider, the transaction may remain blocked unless the policy developer has created another acceptable route.
The basic behaviour is therefore clear. Newton tries to route around smaller internal failures. If authorization remains unavailable, the normal transaction stops. VaultKit then offers a timelocked manual escape for deployments that have configured and secured it properly.
What remains less clear is the human process around that escape.
Newton provides the mechanism, but each project must decide who may use it, how long they should wait, which transactions deserve an exception and how users will be protected while the normal authorization system is unavailable.
That is where the quality of the fallback will ultimately be decided. Not only in Newton’s code, but in the rules, ownership structure and emergency planning of every project that depends on it.
#Newt @NewtonProtocol $NEWT #newt

I keep coming back to one thought: a lot of what we call “blockchain security” is really just execution security, and those are not the same thing.
Crypto has spent years convincing itself that if the contract is sound, the system is sound. I’ve seen enough to know that is only partly true. A contract can do exactly what it was written to do and still let the wrong thing happen. That gap between what is technically valid and what is actually sensible is where most of the damage lives. And that is why Newton Protocol feels worth paying attention to. Not because it is loud. Not because it is trying to sell me a new future. More because it seems to understand that the real problem is not always the transaction itself. Sometimes the problem is whether the transaction should have been allowed at all.
That idea feels simple, but I do not think it is simple in practice. We have built an entire culture around smart contracts, and I still think we overestimate them sometimes. They are powerful, yes. They are useful, obviously. But they are also blind in ways people do not like to admit. They do not know context. They do not know whether an action fits a rule someone forgot to write down. They do not know whether an AI agent is acting inside its limits or drifting into something dangerous. They just execute. That is the part Newton seems to be pushing against.
What I find interesting is that Newton is not talking like a project that wants to replace everything with more complexity. It feels more like it is trying to put a boundary around the mess. The whole idea of moving from smart contracts to smart permissions makes sense to me because permissions are where the real decisions happen. Who can do what. Under what conditions. With what limits. With what proof. That is where the system actually becomes safe or unsafe. Not in the abstract promise of automation, but in the exact shape of the permissions behind it.
I’ve seen this before in different forms. Every cycle brings a new version of the same optimism. First it was trustless finance. Then it was modularity. Then it was AI agents. Then it was “autonomous” everything. And each time, the pitch gets cleaner while the edge cases get uglier. The market loves the idea of systems that can run themselves until those systems do something nobody planned for. Then everybody suddenly remembers that autonomy without restraint is just a faster way to make a mistake.
That is why the authorization layer matters to me more than the headline layer. Newton seems to be saying that a transaction should not just be possible. It should be permitted. That sounds like a small difference until you actually think about how many bad outcomes in crypto came from letting the wrong thing happen too easily. A wallet gets drained. An agent interacts with the wrong contract. A strategy gets executed outside policy. A transfer slips through that should have been blocked. The chain did not fail to execute. The system failed to decide.
I do not fully trust any project the first time it sounds neat, because neatness is usually the first thing that breaks. But I will say this: something about this feels different from the usual noise. Not because it is perfect. Probably because it is not trying to be. It is dealing with friction directly. And friction is the part people avoid in crypto, even though it is usually the thing that keeps the whole machine from spinning out.
If this works, it will not be because crypto suddenly became more honest overnight. It will be because someone took seriously the idea that security is not only about protecting assets after they move. It is about deciding, before anything moves, whether the move belongs. That is a much more uncomfortable standard. It is also a much more useful one.
And maybe that is why I keep coming back to it. Not because Newton solves everything. It probably does not. Not because I expect the market to reward restraint. It usually does not. But because after enough years watching the same promises get recycled, a protocol that focuses on permissions instead of performance feels less like a pitch and more like an actual attempt to fix something real.
@NewtonProtocol #Newt $NEWT

I’ve become a little suspicious whenever a crypto project uses the word “verifiable.”
It sounds reassuring, but it often means less than people assume. A transaction can be verified. A signature can be checked. A smart contract can prove that certain conditions were met. None of that automatically makes the entire system transparent.
That is the part I keep coming back to with Newton Protocol.
Newton may be able to prove that an AI agent followed the limits set by a user. It can help show that a trade stayed under a spending cap, used an approved venue, interacted with an allowed contract and received the required authorization before execution.
That is useful. It is also very different from explaining why the agent wanted to make the trade in the first place.
Imagine an automated strategy wants to swap ETH into a smaller token. Newton can potentially check whether that token is on the approved list, whether the trade size is within the user’s limit and whether the permission is still active. Operators can evaluate the request against a policy, sign the result and create a record showing that the action passed the required checks.
Compared with a normal off-chain trading bot, that is a real improvement.
Most trading bots operate behind closed systems. Users see the final order, the wallet movement and the profit or loss, but they usually have no independent way to verify what limits were applied before the trade happened. They are mostly trusting the developer’s dashboard and the bot’s own logs.
Newton can provide stronger evidence that a particular action was checked against a particular rule set.
But it still may not tell me why the model believed the trade was worth taking.
Did it react to price momentum? Was it using sentiment data? Did it detect an arbitrage opportunity? Was the market data delayed? Did the developer change the strategy earlier that day? Did the agent ignore a warning signal? Was a backup model used after the main one failed?
Those questions sit outside the final permission check.
The blockchain can record what the agent tried to do. It can record which policy was used and whether the transaction passed. It cannot automatically reveal the full path that produced the decision.
That is why I think Newton is better understood as a system that verifies boundaries around AI, not a system that makes AI itself fully transparent.
The distinction matters.
A question like “Was this wallet allowed to spend more than 10,000 USDC?” has a clear answer. The same is true for “Was this contract approved?” or “Had the permission expired?”
Those are the kinds of questions Newton can handle well because they are based on defined rules.
“Was this a good trade?” is different.
A trade can look reasonable when it is opened and terrible ten minutes later. A strategy can follow its own process correctly and still lose money. The model may be wrong, liquidity may disappear or the market may simply move faster than expected.
I’ve seen this before in DeFi. The smart contract works exactly as designed, but something feeding the contract is wrong. The oracle is delayed, the market is manipulated or the assumptions behind the system no longer hold. The loss becomes visible on-chain, so people blame the contract, even though the original failure happened somewhere else.
The same risk exists with AI agents.
Newton may prove that the agent stayed inside the user’s permission limits while the strategy itself relied on weak data, a bad model or a poor assumption.
That does not mean the policy system failed.
It means permission enforcement and investment judgment are two separate problems.
Newton may help with the first. It should not be expected to solve the second.
Suppose an agent is only allowed to trade approved assets, use selected exchanges and remain below a daily limit. It follows every rule and still loses 30%.
What exactly has been verified?
The system may prove that the agent acted within its authority. It cannot prove that the market thesis was intelligent.
That may sound obvious, but crypto projects often blur the line because “verifiable AI” sounds more powerful than “verifiable permissions.”
I actually think the narrower version is more useful.
Users do not need a blockchain to certify that an AI model is smart. I’m not sure any system can do that in a meaningful way. What users need is a way to limit the damage when the model is wrong.
A trader may never understand every signal inside a complex strategy. They can still decide that the agent should never spend more than a certain amount, trade outside approved markets or send funds to an unknown address.
The agent may make mistakes inside those limits.
The important thing is that it cannot quietly move beyond them.
There is also a difficult balance between transparency and privacy.
Serious trading strategies do not want to reveal everything publicly. If every signal, position and planned transaction is visible, other traders can copy it, front-run it or trade against it.
So Newton cannot simply publish every piece of information and call that transparency.
Users need enough information to verify that the system behaved correctly. Developers need to protect their models and strategy logic. Institutions may need private records for compliance teams or auditors.
The more practical approach is probably layered access.
The public might see proof that a transaction followed a policy. The user might see the complete intent and relevant data. An approved auditor might receive a deeper record. Sensitive model logic could remain private while cryptographic commitments prove that the same version was used at the time of execution.
That sounds reasonable, but it creates another problem: users must understand what the proof actually covers.
A green “verified” label is not enough.
Was the trade verified against a spending limit? Was the model output verified? Were the data sources checked? Did operators only confirm that the transaction was allowed, or did they also confirm that the strategy behaved as advertised?
Those are very different claims.
I don’t fully trust systems that hide all of that behind one badge. The proof may be valid while the user completely misunderstands what it proves.
A transaction history is also not the same thing as an audit trail.
A block explorer can show that a trade happened. A useful audit trail should help explain how it reached that point.
For an AI-driven strategy, that could include the model version, the policy version, the data sources, the time those inputs were collected, the proposed action, the operator approvals and the final on-chain result.
It should also show what changed.
Was the strategy updated? Did the user raise the spending limit? Was there a manual override? Did the developer replace the model? Did an external data source fail?
Without that history, it becomes much harder to understand responsibility after something goes wrong.
This is where Newton could become genuinely valuable.
The protocol sits between an agent’s proposal and the final transaction. That position allows it to create evidence that does not come only from the agent itself.
That matters because an automated system should not be the only source of truth about its own behavior. A compromised agent can leave out details, rewrite logs or produce a convincing explanation after the damage has already happened.
Independent operator attestations and on-chain receipts are harder to change later.
Still, I’m not sure Newton provides the full picture yet. Its strongest evidence seems focused on the authorization stage: what the agent requested, which policy applied and whether the action was approved.
That is important, but it does not capture the entire decision environment.
Maybe it never will.
Complex AI systems are not naturally good at explaining themselves. Even when they produce a clear explanation, the explanation may be generated after the decision rather than reflecting the real process behind it.
That is why I would not judge Newton by whether it can make every AI trade understandable.
I would judge it by whether it can help answer a few practical questions after something goes wrong.
What did the agent try to do? What rules applied at that moment? What information was used to check those rules? Who approved the action? What transaction finally reached the chain?
If Newton can answer those clearly, it has created something useful.
There will still be one difficult question left: why did the AI believe this was the right trade?
No signature, proof or transaction receipt can fully answer that.
But I do not need an agent to tell me a perfect story about every decision. Models are already very good at producing explanations that sound convincing.
What I need is evidence that the agent stayed within the authority I gave it, followed the rules I approved and left enough of a trail for someone else to reconstruct what happened.
Newton may not make AI thinking transparent.
It may make AI behavior accountable.
In finance, that is probably the more important goal.
#Newt @NewtonProtocol $NEWT

暗号資産のマーケットプレイスを十分に見てきたので、だいたいこの手の展開がどうなるかは分かっています。
最初はすべて公平に聞こえます。誰でも公開できます。ユーザーは機能したものを評価できます。優れた開発者は注目を集め、最高の戦略はゆっくりと上位に浮上していきます。
そして誰かがショートカットを見つけます。
戦略がうまく機能し始めると、それがコピーされます。いくつかの設定が変更され、新しい名前が追加され、そのフォークが新しいウォレットの下に現れます。すると、連携されたアカウント、ボット、あるいはほとんど実際の資金を危険にさらしていない人たちによるレビューが続きます。

ニュートンのキーストア・ロールアップが、また別の「高速チェーン」という物語になるのは望みません。
暗号資産には、そうしたものはもう十分あります。
新しいロールアップが出てくるたびに、人々は同じ質問をします。どれくらいのトランザクションを処理できるのか？手数料はどれくらい安いのか？どれほどのTVLを呼び込めるのか？それにどれくらいのアプリが出てくるのか？
それらの質問は、通常のL2なら妥当です。
でも、ニュートンはそんなふうに評価されるべきではないと思います。
もしキーストア・ロールアップが出荷されるなら、その最も重要な仕事は、無限に続くDeFiの活動をホストすることではありません。パーミッション（許可）状態を管理することです。

ニュートンをめぐる最も興味深い問いが、TEEsが良いのか悪いのかというだけだとは思いません。
その議論は簡単すぎる。
暗号の人たちは、きれいな議論を好みます。ある側は、ハードウェアの信頼は弱点だと言います。もう一方の側は、TEEsは実用的で有用だと言います。そして誰もが同じ論点を繰り返し、会話が実際の問題以上に大きく感じられるようになります。
ニュートンでは、より良い問いはもっと静かなものだと思います。
信頼は実際どこに隠れているのか？
それが、私がずっと立ち返ってしまう点です。
ニュートンは、AIエージェントが実行する場所を用意しようとしているだけではありません。少なくとも、スタックの形になってきている様子を見る限りでは、ニュートンは実行の前に座って、そもそもその行動が許可されるべきかどうかを決めたいように見えます。

私はそうした暗号の比較チャートが好きではありません。
彼らは、本当はそうではないのに、すべてがずっと簡単に見えるようにします。
あるプロジェクトには「AIエージェント」というラベルが付いています。別のプロジェクトは「推論（inference）」です。さらに別のプロジェクトは「計算（compute）」です。そして「マーケットプレイス（marketplace）」です。すると人々は、どれが勝つのかと議論を始めます。まるで、それらが同じ問題を解こうとしているかのように。
私はそうは思いません。
だからこそ、ニュートンを通常のやり方で比較するのは難しいと感じます。
問題は、それがギザ（Giza）やアロラ（Allora）、リチュアル（Ritual）、オラス（Olas）より優れているかどうかではありません。
より良い問いは、こうです：

1つのきれいな数値として提示されるときは、暗号のパフォーマンス主張を信じません。
TPS。ファイナリティ。1トランザクションあたりのコスト。レイテンシ。
これらの数値は役に立つこともありますが、物事が混乱したときにシステムがどう振る舞うかを、めったに教えてくれません。プロトコルは、整ったテストでは速く見えても、実際のポリシー、外部データ、署名、リトライ、有効期限切れのアテステーション、そして市場のストレスが現れた途端に苦戦することがあります。
だからこそ、ニュートンは別のやり方で測るべきだと思います。
まず「どれくらいのトランザクションを処理できるのか？」と聞くべきではありません。

暗号のガバナンス図は、すぐに信じないほうがいいと学んだ。
最初はいつもバランスが取れて見える。トークン・ハウス。デベロッパー・ハウス。コミュニティ・ハウス。初期フェーズを支えるためのファウンデーション。誰もが役割を持つ。誰もが声を持つ。
でも、本当の試練は決してその図ではない。
本当の試練は、人々が意見を食い違わせるときにやってくる。
トークン保有者は素早いアップグレードを望むのに、開発者はそれを危険だと思っている場合、どうなる？
コミュニティがプライバシー、エージェントの権限、または危険な自動化について不安を抱えているのに、投票がすでに進んでいるとしたらどうなるの？

私は十分に多くの暗号資産のマーケットプレイスの展開を見てきたので、そのパターンを知っています。
最初は、すべてが開かれていて有望に感じます。誰でも出品できる。誰でも作れる。誰でも稼げる。数字が動き始め、ダッシュボードは活発に見え、そして人々はそれを成長だと言います。
すると、ガラクタが現れます。
コピーキャット商品。手間のかからないラッパー。偽の需要。水増しされた利用量。同じもののわずかに名前を変えただけの版。報酬システムのおかげでスパムが儲かるようになったから存在するだけのプロジェクト。
それが私が見ているニュートンのモデル・マーケットプレイスに関するリスクです。

私は、仮想通貨のプロジェクトがAIに寄せすぎ始めた瞬間に、慎重にならざるを得ない地点に到達した。
AIにクリプトの居場所がないわけではない。おそらくある。だが私は、この市場が実用的なアイデアを空っぽのナラティブに変えてしまうのを何度も見てきた。あるサイクルではDeFi、次はゲーム、さらにメタバース、そしてモジュラー、次はリステーキング。そして今は、誰もが自分たちは自律型ファイナンスの未来を作っているのだと聞こえるように言いたがっている。
だから最初にニュートン・プロトコルを見たとき、私はいつも持つのと同じ反応をした。
別のAIエージェントの物語。自動化がすべてを変えると語る別のプロトコル。市場がすでに信じたいと思っている物語の中に、別のトークンが座っている。

「より賢いエージェント」という言葉に期待するのをやめました。
暗号は、古いリスクを新しい言葉で装う方法を持っています。最初に「契約を信じろ」と言われました。次に「オラクル」です。そして次は「ブリッジ」。いまは、DeFiを横断して読み取り、取引し、リバランスし、承認し、実行できるエージェントに焦点が移っています。
それは役に立つこともあります。
しかし、それは単純な問題も生みます。モデルがセキュリティ層ではないということです。
通常のチャットボットが何か間違えるなら、時間を浪費するだけかもしれません。オンチェーンのエージェントが間違えるなら、トランザクションに署名したり、悪い支出先を承認したり、間違ったプールに入ったり、誤ったチェーンへブリッジしたり、ユーザーが本当に望んでいない形でお金を動かしたりできてしまいます。