How the Newton Authorization Layer Works
When we talk about a blockchain transaction, we usually picture the moment of settlement: money moving from one wallet to another. But settling a transaction between two parties is really just one part of it. There’s a lot that happens behind the scenes before a transaction can go through.
In traditional finance, entire teams sit in the loop to check things like compliance, fraud, and security before anything clears. Crypto has largely lacked that layer, pushing it offchain, where enforcement is spotty and hard to verify. And if we want blockchain to reach mainstream adoption, settlement can’t be the only piece we get right. Everything that decides whether a transaction should happen in the first place has to come onchain with it — at scale, and safely.
That missing layer is the problem Newton was built to solve.
Why a dedicated authorization layer
Today, if you wanted to verifiably enforce that kind of logic onchain without Newton, you would have to encode it directly in your smart contract and wire in the relevant data providers yourself. And contracts are not built for this. Running logic is slow and expensive. Changes require redeployments. And the whole approach opens up new attack surface.
It helps to think about traditional blockchains, like the EVM ecosystem, as general computing infrastructure. They are built to do almost anything. Newton is designed from the ground up to do policies and authorization. That focus is what makes the rest of the stack possible.
Policies are written in Rego
Policies on Newton are written in Rego, and there are two big reasons for that choice.
First, Rego is an industry standard that reaches well beyond blockchain. It is the same language IT teams already use for compliance and policy enforcement inside traditional enterprises, which means there is a mature ecosystem of tooling and documentation around it.
Second, it is far more flexible and easier to work with than expressing the same rules in a smart contract language like Solidity. With Rego you can write very expressive policies that enforce all sorts of conditions on a transaction, and Newton is built from the ground up to leverage that.
The policy attestation flow, step by step
Newton is designed to be a protocol of neutral operators that enforce these policies. An operator is an independent participant that runs the policy checks and signs off on the result. Here is how a single transaction moves through the stack.
1. Intent. A user wants to make a transaction on a destination chain. That could be sending funds from wallet A to wallet B, or making a curation decision inside a vault. Newton supports Ethereum and Base today, with more chains on the way.
2. Evaluation. Each operator receives a proposal: the transaction, plus the policy it should be evaluated against. The policy can include logic for calling third party data providers, so each operator pulls in the relevant onchain or offchain data at the moment of evaluation. Newton works with offchain data providers such as Chainalysis, RedStone, vaults.fyi, Webacy. A policy might look at historical APY trends for a vault, an offchain risk score from a vendor, or market volatility over the last 24 hours. Those offchain signals give a comprehensive picture of which transactions are safe and which ones carry more risk. And if the out-of-the-box providers don’t cover what you need, you can bring your own: the connector that calls your data source is compiled to a small WebAssembly (WASM) module that every operator runs in a sandbox, so almost any onchain or offchain source can be plugged in.
3. Consensus. Newton is designed so that no single operator decides the outcome. Once Newton is out of Beta, many operators evaluate the same proposal independently, and the network only issues an authorization once a required number of them agree — so you never have to trust any one of them. What keeps them honest is money: every operator backs its work with a financial stake (Newton runs on EigenLayer, where operators put up restaked ETH). If an operator signs off on the wrong answer, any independent party can challenge it during a dispute window and prove the error with a zero-knowledge fraud proof; a caught operator loses part of its stake, a penalty called slashing. Acting dishonestly costs far more than it could ever gain.
4. Attestation. Once enough operators agree the policy is satisfied, their individual approvals are combined into one compact proof: a joint cryptographic signature that means “a supermajority of the network checked this and reached the same answer.” It certifies that for this specific intent, against this specific policy, the transaction is allowed to proceed. The simplest way to picture it: Newton produces an attestation that works like a green light or a red light on whether a policy has been satisfied.
5. Enforcement. That proof is enforced back in the smart contract where the original intent wants to execute. When the intent is proposed on the destination chain, the proof travels with it and is verified against the Newton library. A small snippet of code in your smart contract validates the proof and acts as the final gate for whether the transaction goes through. The green light or red light Newton communicates is what actually enables, or blocks, settlement onchain.
Verifiability and Privacy
The piece that really makes this model shine is the Newton Explorer. It is a public record of every single task, where a task is a proposed intent or transaction together with the policy it was checked against. Anyone can go in and see what has been evaluated and why.
That transparency matters. This is not an opaque, offchain policy engine that asks you to take its word for it. By using TEEs (trusted execution environments), the system preserves the privacy of the underlying data even while evaluating it inside a policy. The result: anyone can independently verify that a policy was enforced correctly, while the private details behind it stay private. You get verifiability and privacy in one engine.
This design is especially powerful for compliance. As regulation tightens around AML and KYC across the US and internationally, many approaches try to filter out bad actors at the browser or web tool layer. Newton enforces those rules onchain, inside the smart contract, without revealing identity data. As a developer, that lets you state confidently that you are complying with the regulations, and back it up with an audit trail in the Newton Explorer that communicates your posture clearly and transparently.
Getting started
The easiest entry point is the VaultKit developed by Magic Labs, an SDK that makes it straightforward to integrate these policies directly into your smart contract. Newton has already partnered with a range of data providers on a ready made set of policies called the policy stack. You can open the Newton dashboard, mix and match the components your system needs, and tweak them as you see fit.
Beyond the core settlement technology and the logic of moving money, it is that final layer of trustlessness, privacy, and verifiability that will carry blockchain technology over the line and into real adoption by institutions and the masses.