NewtonProtocol

How Newton Protocol authorizes a transaction:

- Intent: A user proposes a transaction
- Evaluation: Operators gather the required data
- Consensus: The network agrees on the outcome
- Attestation: A cryptographic proof is issued
- Enforcement: The contract settles/blocks the transaction

Oracle and risk data providers supply the inputs policies need to evaluate transactions

Newton Protocol is provider-agnostic, so market, credit, vault, and other external data can feed into its policies and have the resulting conditions enforced before value moves

This is the workflow behind Newton Protocol's authorization layer:

- Request: User initiates, dApp submits
- Evaluate: Operators evaluate the policy
- Decision: Allow or Deny
- Attestation: BLS-signed approval
- Enforce: Contract verifies before execution

Policy Composability

The ability to combine multiple rules and data sources into a single authorization policy.

Newton policies can combine sanctions data, KYC credentials, market data, jurisdiction checks, and other inputs to determine whether a transaction is authorized.

The authorization layer for assets on the move

Newton

Privacy-preserving authorization

Newton uses selective disclosure so users can prove specific attributes without exposing the underlying identity data

Counterparty risk is the risk associated with who is on the other side of a transaction.

Integrations such as Arkham can provide entity identities, wallet roles, and risk tags used by Newton policies when evaluating transactions.

A rule is enforceable when a transaction cannot execute unless the rule is satisfied

- policy defines the rule
- data + evaluation determine the outcome
- proof makes the outcome verifiable
- enforcement makes it binding

This flow makes rules enforceable

Settlement without authorization is incomplete

Data oracles provide external data to Newton’s policy engine for evaluation.

Integrations such as Redstone can provide asset prices and other financial data used by Newton policies when evaluating transactions.

Want to add an authorization layer to your stack?

Newton lets you define the policy, connect it to your smart contract, and execute transactions with verified attestations

Build from scratch or start with an existing policy

Newton operates as the authorization layer between transaction intent and onchain execution.

The analogy to card payment networks is precise:

Newton enforces policy at the point of execution.

Operators evaluate an intent and produce an attestation, which the smart contract verifies before the transaction can execute.

Newton Architecture Layers

Policy: a Rego program on IPFS setting a transaction's conditions

Compute & Consensus: operators evaluate the transaction, signatures aggregate into one proof

Verification & Execution: a contract validates the proof, then executes or blocks the transaction

How Newton Works
You write policies defining when transactions are allowed.

Then it moves through 5 steps:

Intent
Evaluation
Consensus
Attestation
Enforcement

Operators evaluate policy, agree on the result, produce a cryptographic proof, and the SC verifies it pre-settlement.

we are building the onchain authorization layer so nobody has to sit and watch a screen all weekend

Crypto Regulation Timeline

2013 FinCEN: Exchanges become money transmitters
2014 Mt. Gox puts custody in focus
2019 FATF extends the Travel Rule
2023 EU adopts MiCA
2025 GENIUS Act signed
2026 MiCA fully applies

Global real estate has barely made it onchain

- Total market: $393T
- Tokenized real estate: $202.6M

That's 0.00005% of the market

Every property comes with its own ownership, compliance, and transfer rules

Making those rules executable is what unlocks tokenization at scale

Evolution of DeFi Vaults
2020 Yearn automates yield
2022 ERC-4626 standardizes vaults
2024 Morpho externalizes risk to curators
2024 ERC-7540 async vaults unlock RWAs
2025 Stream Finance collapse freezes $160M
2026 Vault TVL passes $74B
2026 Newton launches VaultKit