I. Outlook

1. Macro-Level Summary and Future Forecast

This week, global macro markets presented a pattern of rebounding inflation, relatively strong economic resilience, and pressure on risk assets. US September CPI rose 3.7% year-over-year and 0.6% month-over-month; PPI surged 1.3% month-over-month, and retail sales grew 0.8% month-over-month, reflecting that rising energy prices have pushed inflation pressures higher again while consumer demand remains resilient. Geopolitical tensions in the Middle East drove up international oil prices, further strengthening market concerns about stagflation risks. The US tech sector pulled back notably, with the Nasdaq falling about 4.48% for the week, the S&P 500 down 1.95%, while the Dow rose 0.67%, as capital rotated from highly valued tech stocks into energy and defensive sectors. Despite the inflation overshoot, the US 10-year Treasury yield still fell back to about 5.09%, indicating that the market is also worried about the economic growth outlook. 

Next week, global markets are expected to continue trading around inflation stickiness, the Fed's rate path, and geopolitical risks. Stronger US inflation and consumption data mean the Fed lacks room for easing in the near term, but pressure on economic growth and financial markets may also limit the extent of further rate hikes. Next week, focus should be on Fed officials' remarks, US state employment data on October 20, University of Michigan consumer sentiment data on October 23, and changes in international oil prices and US Treasury yields. US equities are expected to remain highly volatile, with growth tech sectors facing valuation adjustment pressure; if oil prices continue to rise, inflation expectations may climb further, suppressing global risk appetite. Conversely, if energy prices fall and rate expectations stabilize, the market may see a phase of repair.

2. Crypto Industry Market Changes and Warnings

This week, the crypto market overall continued its pullback, with the core contradiction still being high rate expectations and capital outflows: BTC briefly broke below $82,000 and tested the around $80,000 area, ETH fell significantly more than BTC, total market capitalization dropped about 2%–3% during the week, while BTC dominance rose to about 59.5%, indicating further capital concentration into BTC and weak risk appetite for altcoins. US spot ETF flows continued to weigh on the market, with BTC spot ETFs seeing cumulative net outflows of about $228 million and ETH spot ETFs net outflows of about $320 million from October 12–16; the early-week decline also triggered large-scale long liquidations, with 24-hour market-wide liquidations briefly exceeding $770 million on October 12. Overall, this week's sharp decline was not caused by a single negative factor, but by the combination of expectations of further Fed rate hikes, elevated US Treasury yields, sustained ETF outflows, and deleveraging, with ETH and most altcoins clearly weaker than BTC.

Next week, the market is expected to remain range-bound with a weak bias, waiting for macro and capital flows to reconfirm direction, with the around $80,000 area for BTC becoming an important bull-bear dividing line; if long-end US Treasury yields fall and BTC spot ETFs return to sustained net inflows, BTC has the conditions to rebound first after the earlier leverage washout, but before these two signals appear, the basis for a sustained rally remains insufficient. Structurally, the defensive pattern of "BTC stronger than ETH, major coins stronger than small- and mid-cap altcoins" is expected to continue, and altseason currently lacks a clear capital foundation; particular attention should be paid to changes in rate expectations as the October 27–28 Fed meeting approaches. Therefore, next week is more likely to see repeated contention around the $80,000 level and a gradual choice of direction, rather than a direct start of a one-sided trend. 

3. Industry and Sector Hotspots

This week's industry hotspots were mainly concentrated in RWA, stablecoins/payments, DeFi, prediction markets + privacy, AI×Crypto, and cross-chain security: RWA continued its institutionalization trend, with Multiliquid completing an $8 million funding round, Fission completing a $10 million Series A, and Spout Finance securing $2 million in strategic financing and exploring borrowing USDC against tokenized US stocks, while on-chain RWA AUM has reached about $34.6 billion; in stablecoins and payments, Western Union's Solana stablecoin USDPT launched on Bitso in Mexico, USDC was classified as the EU's first "significant e-money token," but total stablecoin market capitalization contracted slightly during the week. 

NEAR also launched a SOL yield product through the Kamino Vault under the Gauntlet strategy; prediction markets continued to move toward privacy, with StarkWare launching OffMarket to provide a privacy channel for Polymarket trading; in AI×Crypto, DATA Network, transformed from the original Story Protocol, received a $30 million strategic investment from Sui Foundation, and AI data rights confirmation, payments, and Agent infrastructure continued to heat up; in security and cross-chain, Autheo suffered about $1.7 million in losses due to the exploitation of Hyperlane's trusted Relayer key, and THEO plunged more than 90%, once again exposing the single-point trust risk of cross-chain bridges. 

II. Market Hot Sectors and Projects with Potential This Week

1. Overview of Projects with Potential

1.1. In-depth: $86 million total funding led by Paypal, 1k(x), and Northzone, with participation from Cherubic, Volt, and other institutions — building Newton (Magic Labs), a chain abstraction Web3 experience infrastructure for mass users

Introduction

Newton Protocol is a decentralized on-chain transaction authorization policy engine built on EigenLayer AVS (Actively Validated Service). It can directly enforce transaction rules in smart contracts, including spending limit restrictions, sanctions list screening, fraud protection, and compliance rule management.

Newton Protocol is a policy engine for defining, validating, and enforcing rules, allowing developers to encode various rules (such as spending limits, sanctions screening, anti-fraud mechanisms, etc.) directly into smart contracts and ensure these rules are strictly enforced through on-chain verification mechanisms.

Protocol Element Analysis

Newton Protocol is a policy engine for on-chain transaction authorization, built on EigenLayer Actively Validated Service (AVS). This page introduces how its core components work together. You can return here for reference while reading the integration guide.

1. How Newton Works

Users write rules (Policies) that define when a transaction should be allowed to execute. When a user submits a transaction (Intent), Newton's decentralized Operator network evaluates the transaction against the user-defined policy and returns a cryptographic proof (Attestation), which is verified by the smart contract before executing the transaction.

2. Key Concepts

Policy

A Policy is a Rego program that defines which conditions an Intent must satisfy to be approved. Policies are stored on IPFS (referenced by CID) and can be reused by multiple PolicyClients.

A Policy can reference two types of data sources:

• data.params: configuration parameters set by the PolicyClient owner, for example:
• Spend Limits
• Allowlists
• data.wasm: data fetched at runtime by the PolicyData WASM Oracle, for example:
• Token prices
• KYC status

Intent

An Intent is a proposed transaction request submitted to the policy evaluation system for validation.

It contains standard EVM transaction fields, and users need to construct the corresponding Intent when calling simulateTask or submitEvaluationRequest via the SDK.

Task

A Task is the unit that combines an Intent with the corresponding Policy for evaluation.

In Newton, a Task is the most basic evaluation unit:

• Each Task is judged as:
• Compliant
• Non-compliant

Users can query Task status via the RPC API or Newton Explorer.

Attestation

An Attestation is a cryptographic proof (BLS aggregate signature) used to prove that Newton Operators have evaluated a Policy and made an approval or rejection decision on the Intent.

An Attestation contains:

• taskId
• policyId
• evaluation result
• expiration block

For details on how Attestations are generated, see Consensus & Security.

PolicyClient

A PolicyClient is a smart contract used to verify an Attestation before executing a transaction.

Developers can integrate Newton into their own contracts by inheriting NewtonPolicyClient and calling in function modifiers:

• _validateAttestation()
• _validateAttestationDirect()

to complete transaction authorization verification. For specific implementation, refer to Smart Contract Integration.

PolicyData

The PolicyData Oracle is a WASM component used to fetch or compute external data during policy evaluation.

Its output is provided as data.wasm to the Rego Policy.

Application examples include:

• Fetching token prices;
• Querying sanctions lists;
• Verifying KYC status.

Developers can create their own data Oracles through the Writing Data Oracles guide.

Operator

An Operator is an EigenLayer node registered to Newton AVS.

Operators are responsible for:

• Independently evaluating Tasks;
• Executing policy validation;
• Aggregating multiple BLS signatures into a single unified consensus proof after reaching the consensus threshold (Quorum).

For details on Quorum and Slashing mechanisms, see Consensus & Security.

Gateway

Gateway is a JSON-RPC 2.0-based interface service used to receive tasks and coordinate Operator evaluation.

All SDK and CLI interactions are completed through the Gateway.

Brief Overview of Protocol Technical Architecture

Newton Protocol is a system composed of a three-layer architecture that separates Policy Definition, Policy Evaluation, and Policy Enforcement.

This modular architecture allows each layer to evolve and upgrade independently while maintaining high security guarantees for the overall system.

1. Policy Layer

The Policy Layer is responsible for defining the rules that exist in the system and how these rules are configured.

Component

Function

Policy Registry

Registers all deployed policies on-chain, referenced by CID (Content Identifier)

Policy Library

Provides reusable policy templates, such as spending limits, sanctions checks, KYC verification, etc.

PolicyData Oracles

WASM-based components that fetch external data during policy evaluation

Process for developers to publish a policy:

1. Write the Rego policy and WASM Oracle;
2. Upload them to IPFS via newton-cli;
3. Deploy the PolicyData and Policy contracts on-chain.

When users configure a policy, they need to deploy a PolicyClient contract and set specific parameters, such as:

• Thresholds
• Allowlists
• Expiration

2. Compute & Consensus Layer

The Compute Layer is responsible for off-chain policy evaluation performed by the Newton AVS Operator network.

Component

Function

Gateway

JSON-RPC interface that receives tasks and distributes them to Operators

Operators

EigenLayer nodes that independently perform policy evaluation

Aggregator

Collects BLS signatures from each Operator and generates a unified consensus proof

When a Task is submitted:

1. The Gateway receives the Intent and identifies the target Policy;
2. Available Operators fetch PolicyData (running the WASM Oracle);
3. Each Operator independently executes the Rego Policy evaluation;
4. Each Operator generates a BLS signature for the evaluation result;
5. The Aggregator collects signatures and generates a consensus proof after reaching Quorum.

3. Verification & Execution Layer

The Verification Layer is responsible for on-chain proof verification and transaction execution.

Component

Function

NewtonProverTaskManager

Core task management module responsible for creating tasks, storing responses, and managing challenge windows

AttestationValidator

Verifies BLS aggregate signatures against the Operator set

PolicyClient

Smart contract deployed by developers that calls verification logic before executing transactions

PolicyClientRegistry

Records registered PolicyClient contracts

This layer ensures that only transactions that have passed Newton policy validation and obtained a valid Attestation can proceed to execution.

4. Data Flow

The complete policy evaluation process is as follows:

1. Submit Intent — The caller sends the Intent and the PolicyClient address to the Gateway.
2. Create Task — The Gateway creates a Task that binds the Intent to the corresponding Policy.
3. Data Fetched — Operators execute the PolicyData WASM Oracle to obtain the external data required for policy evaluation.
4. Policy Evaluated — Operators run the Rego Policy using the Intent, Oracle data, and Params to evaluate whether the transaction complies with the rules.
5. Signatures Produced — Each Operator signs the evaluation result with its own BLS key.
6. Proof Aggregated — The Aggregator collects signatures from multiple Operators and aggregates them into a consensus proof.
7. Proof Returned — The caller receives the corresponding Attestation.
8. On-chain Verification — The PolicyClient verifies the proof through the AttestationValidator.
9. Transaction Executes — If verification passes, the protected transaction proceeds.

Privacy Layer

Newton Protocol's privacy architecture is based on HPKE encryption, Secure Envelopes, and Confidential Policy Evaluation, providing institutional and enterprise scenarios with privacy-preserving on-chain transaction capabilities while ensuring transaction compliance is verifiable.

<