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

Ich habe genug Krypto-Marktplätze gesehen, um zu wissen, wie das normalerweise ausgeht.
Am Anfang klingt alles fair. Jeder kann etwas veröffentlichen. Nutzer können bewerten, was funktioniert. Gute Entwickler bekommen Aufmerksamkeit, und die besten Strategien steigen langsam nach oben.
Dann findet jemand einen Abkürzungsweg.
Eine Strategie beginnt gut zu laufen, also wird sie kopiert. Ein paar Einstellungen werden geändert, ein neuer Name wird hinzugefügt, und die Fork taucht unter einer frischen Wallet auf. Dann kommen die Bewertungen von verknüpften Konten, Bots oder Leuten, die praktisch kein echtes Geld aufs Spiel setzen.

Ich möchte nicht, dass von Newtons Keystore-Rollup eine weitere „Fast-Chain“-Geschichte wird.
Krypto hat davon bereits genug.
Jedes Mal, wenn ein neues Rollup auftaucht, stellen die Leute dieselben Fragen. Wie viele Transaktionen kann es bewältigen? Wie günstig sind die Gebühren? Wie viel TVL kann es anziehen? Wie viele Apps werden auf ihm starten?
Diese Fragen ergeben für ein normales L2 Sinn.
Aber ich glaube nicht, dass Newton auf diese Weise beurteilt werden sollte.
Wenn das Keystore-Rollup ausgeliefert wird, besteht seine wichtigste Aufgabe nicht darin, endlose DeFi-Aktivität zu beherbergen. Es soll den Berechtigungsstatus verwalten.

Ich glaube nicht, dass die interessanteste Frage rund um Newton einfach nur die ist, ob TEEs gut oder schlecht sind.
Diese Debatte ist zu einfach.
Crypto-Leute lieben klare Argumente. Die eine Seite sagt: Hardware-Vertrauen ist eine Schwäche. Die andere Seite sagt: TEEs sind praktisch und nützlich. Dann wiederholen alle immer wieder dieselben Punkte, bis sich das Gespräch größer anfühlt als das eigentliche Problem.
Bei Newton denke ich, ist die bessere Frage eine ruhigere:
Wo versteckt sich das Vertrauen eigentlich?
Daran komme ich immer wieder zurück.
Newton versucht nicht nur, KI-Agenten irgendwohin zu bringen, wo sie ausführen können. Jedenfalls sieht es anhand dessen, wie sich der Stack abzeichnet, eher so aus, als wolle Newton sich vor der Ausführung hinsetzen und entscheiden, ob eine Aktion überhaupt erlaubt sein sollte.

Ich habe diese Krypto-Vergleichsdiagramme nie gemocht.
Sie lassen alles viel einfacher aussehen, als es wirklich ist.
Ein Projekt trägt die Bezeichnung „AI agents“. Ein anderes heißt „inference“. Wieder ein anderes „compute“. Dann gibt es „marketplace“. Und dann fangen die Leute an zu streiten darüber, welches gewinnt – so, als würden alle versuchen, dasselbe Problem zu lösen.
Ich glaube nicht, dass sie es sind.
Darum finde ich Newton schwierig, auf die übliche Weise zu vergleichen.
Die Frage ist nicht, ob es besser ist als Giza, Allora, Ritual oder Olas.
Die bessere Frage lautet vielmehr: