Aadi33

When people talk about DeFi vaults, the assumption is usually that the strategy is what matters the most.
Better yields. Better rebalancing. Better execution. Better risk adjusted returns.
Everything else feels like supporting infrastructure.
I used to think the same way. It took me a minute to understand why @NewtonProtocol approaches vaults from a completely different direction.
The interesting part isn't the strategy itself. It's the authorization step that happens before the strategy can execute.
A vault can define policies across compliance, identity, security, and risk, whether that's sanctioned addresses, user eligibility, oracle health, leverage limits 0r approved counterparties. Those rules already exist in many institutional workflows, but they're often enforced through internal processes or checked after decisions have already been made.
Newton treats those rules differently.
Every requested transaction is evaluated against active policies before settlement, and the network returns a signed pass or fail policy attestation. If the transaction satisfies the defined rules, it proceeds. If it doesn't, settlement never happens.
That sounds like a subtle implementation detail, but I think it changes what a vault actually represents.
A vault stops being just a strategy for allocating capital. It becomes a strategy operating inside enforceable boundaries. The important question is no longer whether a manager intended to follow the rules or whether someone notices a violation afterward. The important question becomes whether the requested transaction can satisfy the policy before any assets move.
The more I thought about it, the more it reminded me of card authorization networks. The important decision hAppens before money moves, not after someone investigates a problem. Newton Mainnet Beta seems to be exploring what that same authorization model could look like for onchain finance.
That's the mechanism that stood out to me.
The project isn't trying to build another monitoring dashboard. It's experimenting with the idea that policy enforcement itself should become part of transaction execution, rather than something layered on afterward.
The part I'm still unsure about is how this evolves once institutions bring their actual policies onchain.
Simple rules are easy to imagine. Maximum leverage. Approved protocols. Counterparty restrictions. Oracle health checks.
Real organizations rarely operate with rules that clean. Policies change over time, exceptions appear and different compliance, security, identity and risk requirements often overlap in ways that are difficult to express as deterministic logic.
If institutional capital continues moving onchain, I wonder whether the biggest challenge will still be building better vault strategies.
Or whether the real advantage will belong to the protocols that can turn increasingly complex policies into something machines can verify before settlement.
@NewtonProtocol $NEWT #Newt
$BTC $SXT #BinanceTurns9 #MicronFallsNearly14%InAMonth

多くの人は、ブロックチェーンのセキュリティはトランザクションをより効果的に監視することだと思い込んでいます。何かがうまくいかなかったら、調べて、資金の流れを追い、結果として何が起きたのかを突き止めるのです。
その前提はもっともです。なぜなら、ほとんどのブロックチェーン・セキュリティツールは、まさにそのやり方で作られているからです。彼らは観察し、分析し、報告します。考えれば考えるほど、クレジットカード決済の仕組みに似ていると感じました。重要な判断は、決済が通った後に行われるのではありません。通る前に行われるのです。
Newtonメインネット・ベータについて読んでいるとき、なぜこのプロジェクトがこの点を別の方法でアプローチしているのか理解するのに少し時間がかかりました。面白いのはトランザクションを監視することではありません。そもそも決済を許可すべきかどうかを判断することです。

署名はそれ自体で十分な証拠だった時代もありましたが、ニュートンの実際の設計の多くはそれを前提としていません。そして、その前提が最もはっきり表れているのがマルチシグのポリシーです。
多くの人はマルチシグを、十分な署名が集まっていればよい、つまり「2/3」「3/5」など閾値に達したら、その時点で取引が通るものだと考えがちです。これが、マルチシグの承認がどのように機能するかについて多くの人が持っている、基本的に全てのメンタルモデルです。
しかし、この件に対するニュートンの Rego 拡張は少し違うことを行います。単に署名数を数えて「完了」とするのではありません。各署名から実際の署名者アドレスを復元し、それを承認済みの署名者リストと照合してから、閾値に向けたカウントを行います。つまり本当の問いは「十分な人数が署名したのか」ではなく、「十分な承認済みの人が署名したのか」です。見た目は似ていますが、意味のある点でチェック内容が異なります。

多くの人は一般に、AIエージェントがよく作り込まれていれば、より多くの自律性を与えることは、主に信頼の問題として捉えられると考えています。十分にテストし、きちんと動くのを観察していけば、そのうち、人が毎ステップを確認しなくても、自分ひとりで行動させることに安心感を覚えるようになります。これはだいたい、どんな自動化システムに対しても信頼が拡張されていく流れで、実績が増えれば自律性も増える、というものです。
AIエージェント問題に対するニュートン的な枠組みは、信頼からはあまり始まらないんですよね。そして、実際に始めるならそこから始めるほうが有用だと思います。出発点は、構造的な不一致です。

人は一般に、プロトコルがライブ後にどれだけ実際に変えられるのかについて、2つの陣営のどちらかに分かれがちです。つまり、基本的には不変であり、コードは法であって、いったんデプロイされたものは永遠にそのままだと考えるか、逆に、どこかのチームが管理者キーを持っていて、望むときにこっそり何でも変更できると考えるかです。どちらの前提も、たいていはあまり疑問にされません。どちらかを選んで先に進む、という感じになりがちです。
ニュートンの実際の答えは、その2つの間にあり、どちらの陣営の想定よりも具体的です。プロトコルのアップグレードは、時間ロックされたアップグレードを行ういわゆる「トランスペアレント・プロキシ・パターン」を通じて実施されます。変更は即座に行われるわけでもなく、静かに済むわけでもありませんが、システムが永遠に凍結されたままというわけでもありません。アップグレードが提案されてから実際に有効になるまでの「窓」があり、その期間中は可視化され、ライブに切り替わる前に異議を唱えることもできます。

Paying for infrastructure used to be simple. Most platforms charge for access. You choose a plan, pay a monthly subscription and the service is there whenever you need it. Whether you make one request or ten thousand,.. the bill usually doesn't change very much. That's become the default way people think about infrastructure. You're paying for availability, not for every individual action happening behind the scenes.
That assumption doesn't really apply to Newton.
Its policy engine isn't priced around access. It's priced around execution. Every policy evaluation is measured by the work it actually performs, from WASM instruction count and external data provider calls to the bandwidth consumed while reaching a decision. Fees are then settled daily through an 0nchain payment vault before being distributed between the operators and the protocol. The cost isn't attached to having the Infrastructure available. It's attached to what the infrastructure actually did.
That soundslike a small accounting detail. It isn't. The difference is that Newton treats every policy evaluation as its own unit of work. Two authorizations may both approve a transaction, but they don't necessarily consume the same resources to reach that decision. One policy may query a single provider and return a straightforward answer, while another may evaluate multiple Rego rules, request data from several providers and verify spending limits, jurisdictions, and other conditions before producing exactly the same outcome.
The result might looks an identical. The work required to get there isn't. That's the idea the pricing model is built around. You're not paying because a policy exists. You're paying because of what that policy actually had to do.
Once I started thinking about it that way, the different use cases described throughout the whitepaper looked very different. An autonomous AI agent might trigger thousands of policy evaluations every day. Each authorization could be relatively lightweight, checking spending limits, verifying the destination or enforcing velocity rules before allowing another transaction. A stablecoin issuer might only evaluate a handful of transactions during the same period, yet every one of those evaluations could involve sanctions screening, jurisdiction checks, source of funds verification, and several policy modules working together before approval.
Both are using the same infrastructure and both are paying through the same pricing model. The difference isn't the application itself. The difference is the amount of computation required every time a policy runs. That's what execution based pricing actually measures.
Of course, there's a tradeoff.
Charging for computation instead of access makes pricing much more reflective of the work being performed, but it also makes costs less predictable. Teams now have another operational expense tO consider alongside gas fees. The final cost depends not only on how often policies are executed, but also on how efficiently those policies were written and how many external resources they rely on during evaluation.
That raises another question. If policy modules become reusable across applications, then policy authors won't just be defining authorization logic. They'll also be influencing the execution costs paid by every application that adopts their work. An inefficient policy doesn't simply become Harder to maintain. It quietly becomes more expensive for everyone who relies on it Even if the outcome is identical to a better optimized alternative.
The Newton Protocol's docs explains how execution fees are calculated and distributed, but it doesn't really answer whether developers will eventually compare policy modules by execution cost before choosing one. Trust and security will always matter, but so does efficiency when every authorization carries its own measurable cost.
Gas efficiency eventually became one of the defining characteristics of well designed smart contracts. I'm curious whether policy efficiency follows the same path or whether execution costs remain something most developers only notice after they've already chosen the policy they're going to build around.
@NewtonProtocol $NEWT #Newt
$LAB $TAG
#Labs #USJoblessClaimsFallTo215K

人々は一般に、監査証跡を「リプレイ（再生）ボタン」のようなものだと考えます。規制当局、監査人、あるいは捜査担当者が何が起きたのかを理解したいとき、記録を開き、基となる情報を調べ、最初から最後まで意思決定を再構成します。監査証跡は、単にある行為が行われたという証拠であるだけではありません。それは多くの場合、証拠そのものが存在する場所でもあります。
その前提はもっともです。なぜなら、これまでのほとんどの監査システムはそういう仕組みで動いてきたからです。銀行は取引記録を保持します。企業は書類をアーカイブします。コンプライアンス部門は、あらゆる判断の背後にある情報を保持します。誰かが「なぜその行為が承認されたのか、あるいは拒否されたのか」と尋ねたとき、期待されるのは、データ自体を取得して調べられることです。

For years blockchain infrastructure has been measured by the same standards. Higher throughput, lower fees, and faster settlement became the benchmarks every new network tried to outperform. The assumption was simple: if transactions could be executed more efficiently, the infrastructure problem would eventually solve itself.
That way of Thinking made sense when blockchains were primarily responsible for one thing: execution. Once a valid signature was provided and the network is reached consensus, its job was done. Whether the transaction complied with regulations, satisfied internal policies or met institutional requirements was someone else's responsibility.
But that assumption doesn't explain where Onchain finance is heading.
The next generation of participants isn't asking whether a transaction can be executed. They're asking whether it should be to executed. Stablecoin issuers need compliance checks before settlement. Institutions need investor eligibility before assets move. AI agents need predefined spending limits before they can act autonomously. None of those questions are answered by another thousand transactions per second.
Execution answers whether a transaction can happen. Authorization answers whether it should happen. That's the part Newton Protocol is actually built around.
Instead of competing with existing blockchains, Newton introduces a decentralized authorization layer that sits between transaction intent and settlement. Applications define programmable policies, the network evaluates them.. and smart contracts verify a cryptographic attestation before execution. The blockchain still settles the transaction. Newton focuses on proving that the required conditions have been satisfied before settlement ever begins.
That changes an assumption blockchain infrastructure has largely accepted without questioning.
For years ownership and authorization have effectively been treated as the same thing. If a wallet controls an asset and produces a valid signature, execution follows. Newton separates those ideas by arguing that ownership alone isn't always enough. Authorization becomes a programmable decision based on identity, compliance, risk controls, or application specific policies that are evaluated before settlement rather than after it.
Of course, that approach comes with tradeoffs.
One of blockchain's defining characteristics has always been reducing intermediaries between users and settlement. Adding an authorization layer introduces another checkpoint before execution, and some will argue that this creates unnecessary complexity for systems built around permissionless access. Others will see it differently. As regulated assets, institutions, and autonomous AI agEnts become part of Onchain finance, programmable Authorization may become another piece of essential infrastructure rather than unnecessary friction. Newton doesn't remove that debate. It proposes a decentralized alternative to the centralized approval systems that already exist today.
I keep wondering whether we'll eventually stop comparing blockchain networks by how quickly they settle transactions and start comparing them by how intelligently they decide which transactions deserve to settle in the first place. If that happens, faster execution may n0 longer define the next generation of blockchain infrastructure. Authorization might.
@NewtonProtocol $NEWT #Newt
#blockchain $BTC #lab $LAB

ゼロ知識証明（ZK proof）というのは、通常は誰かがとても特定の用途のために、非常に具体的な回路を作ったことを意味します。残高がある数より上であることを証明する。投票が正しく集計されたことを証明する。用途が1つに限られた仕事で、その仕事のために作り込まれた専用回路が1つある。別のものを証明したいなら、基本的に最初からやり直し、別の回路を作ることになります。
Newtonの「紛争システム」はそんなふうには動かないはずで、理解するのに少し時間がかかりました。誰かが書くポリシーごとに新しい回路を作るのではなく、Regoのポリシーエンジンそのもの、つまりコンプライアンスルールを実行する実際のインタプリタを丸ごと取り込み、それを汎用のzkvmにコンパイルしたのです。つまり、Regoで書かれたどんなポリシーでも（制裁チェック、速度制限、複数ステップの適格性ルールなど）、自動的に証明可能になります。ポリシーごとに新しい回路作業は不要です。証明可能にされたのは個々のルールではなく、エンジンそのものです。

人々はウォレットの秘密鍵を、セキュリティモデル全体そのものみたいに扱います。鍵を失えば、すべてを失う。安全に保てば大丈夫――それが、ほとんどの人が疑うことなく抱いている、基本的に全体像です。
でも、実際に最近どうやって資金が抜き取られるのかを見てみると、それが本当ではないことが分かります。鍵を当てられたり、ブルートフォースされたりすることは、ほとんどありません。問題は、最初から許可されるべきではなかった“署名されたトランザクション”が通ってしまうことです。秘密鍵が盗まれたわけですらない半分のケースでは、信頼してはいけない何かによって使われただけです。誰も注意深く読まなかった承認があり、パッと見では問題なさそうに見えるコントラクト同士のやり取りがあり、それが原因になります。

誰も実際には見ていないのに、みんながそれでも信じる“1つの数値”
バル ト（金庫）のリスクポリシーでは、取引を通す前に、例えばオラクルの健全性を確認する必要がある。単純そうだ。価格を取得して、チェックを実行する……通るか、失敗か。だがニュートンは、そこからただ一か所の情報を引っ張ってくるだけではない。
すべてのオペレーターが、それぞれの接続を通じて、それぞれの経路で、その価格を独立して取得する。つまり、誰もが盲目的に信じる“単一のフィード”が存在しないようにする、という発想だ。これは設計上の選択として理にかなっている。
問題は、みんなが別々に取得している場合、全員がまったく同じ数値に着地するとは限らないことだ。あるオペレーターは1.001を得て、別のオペレーターは0.998を得る。わずかな差ではあるが、それでも違う。そして、アテステーション（証明）が実際に機能するには全員が同じ結果にサインオフしなければならない。だから、その差を一つの数値に変換する必要がある。ニュートンの答えは、返ってきたものの中央値を取って、それをポリシーが基準とする数値にすることだ。

暗号はすべての取引を検証します。しかし、では誰がその判断を検証するのでしょうか？
長い間、暗号のいちばん難しい部分はすでに解決されていると思っていました。
取引は署名され、ブロードキャストされ、ネットワークによって検証され、オンチェーンに記録されます。ブロックチェーンがそれを受け入れるなら、すべて問題ないはずですよね？
考えれば考えるほど、ブロックチェーンが答えるのはただ1つの問いだけだと気づきました：
"この取引は有効ですか？"
それよりももっと重要かもしれない別の問いを、決して聞かないのです：
"この取引はそもそも行われるべきですか？"

小さなDeFiアプリが、適切なコンプライアンスを最初から組み込んだ状態でローンチしたいと考えています。制裁対象のスクリーニング、KYCチェック、そして誰も奇妙な金額を奇妙な速度で動かさないようにするためのいくつかの速度制限です。通常は、この分野を知っている人を雇って、ロジックを書き、テストし、そして数か月後に厄介な取りこぼしが原因でトラブルにならないことを祈ることになります。小規模チームの多くはそれを省略するか、最低限だけやって運を天に任せます。
それが、ニュートンのポリシーマーケットプレイスが解決しようとしている問題の本質です。同じ制裁チェックを、あらゆるアプリがそれぞれ独自に作り込むのではなく、誰かがRegoで一度だけ書いて公開し、他のアプリはそれをそのまま差し込めばよいのです。ポリシー作成者がモジュールを作り、アプリ側は必要なものを選び、自分たちのケースに合わせてパラメータを設定します。コンプライアンスを、毎回ゼロから作り上げる「もの」ではなく「組み合わせて作る」ものにするのです。

An admin key gets compromised, or an oracle gets fed a bad price, and a vault's risk limits, the ones sitting somewhere in a spreadsheet or a risk team's Slack channel, don't catch anything because they were never actually enforced onchain in the first place. They were just written down somewhere. The outflow starts. someone notices a few hours later, posts about it, and then the Postmortem thread shows up walking through exactly how the limits should have to caught this. By that point the funds are three bridges away.
I've watched this exact sequence happen enough times that it stopped feeling like an edge case and started feeling like the default. Rules exist. They just don't live anywhere the chain actually checks before settlement.
That's the gap Newton Mainnet Beta is built to close. It works the way card authorization already works, where Visa checks a transaction against fraud rules and Spend limits before the bank settles it , except Newton does this for onchain transactions instead. It checks against an active policy before settlement and returns a signed pass or fAil attestation onchain. Not a report on what happened. A record of what got enforced before the transaction went through.
The vault example is the one that makes this concrete for me. Billions are sitting in curated DeFi vaults right now and growing fast, but the actual risk limits Governing them live offchain in fragmented processes nobody outside the team can verify. Newtons approach is to make those rules enforceable directly, across four domains, compliance checks like OFAC and sanctions screening, identity and eligibility verification, real time security threat blocking, and risk factors like counterparty exposure, leverage, and oracle health. The policies aren't being built in isolation either, Chainalysis and Hexagate, Vaults.fyi, and RedStone with Credora are involved on the policy side, with security backing from Eigen Labs, Succinct, Rhinestone, and Octane.
What I actually wanted to know is whether enforcing checks earlier removes the risk or just relocates it. Spent some time thinking about it and I think it's the second one. Not a criticism, just how systems like this tend to work once you look closely. The policy becomes the new thing you have to trust. Who wrote it. How current the data feeding it is. Whether the operators evaluating it are seeing what they claim to be seeing.
That last part is the one I keep coming back to. The pitch is that the chain never touches your underlying data, only proofs and attestations get recorded. But the version running right now still has operators looking at plaintext while they evaluate. Fully private evaluation, the kind where nobody touches the raw data at any point, is still something being built toward, not something live yet. So the claim and the current state aren't fully lined up. Worth knowing instead of assuming.
Magic Labs is the team building this, the same group behind embedded wallets with over 57 million wallets and 200,000 plus developers already on their infra, including the wallet layer behind Polymarket. Newton starts with vaults but the stated direction is RWAs, stablecoins, and AI agents next, anchored by what they're calling an Internet of Policies marketplace. $NEWT is the token running through all of it.
Going to be watching how this plays out once Mainnet Beta sees real volume. Whether that privacy gap closes, aNd how long it Actually takes.
@NewtonProtocol $NEWT #Newt
#newton #defi