Tron Industry Weekly Report: Stagflation May Cause BTC to Test $80,000 Support Again, Detailed Explanation of Building Chain Abstract Web3 Experience Infrastructure Newton

I. Outlook

1. Summary of Macroeconomic Trends and Future Predictions

This week, the global macro market showed a pattern of inflation rebound, strong economic resilience, and pressure on risk assets. The U.S. CPI in September rose by 3.7% year-on-year and 0.6% month-on-month; the PPI increased significantly by 1.3% month-on-month, and retail sales grew by 0.8% month-on-month, reflecting that rising energy prices have rekindled inflationary pressures while consumer demand remains resilient. Geopolitical tensions in the Middle East have driven up international oil prices, further intensifying market concerns about stagflation risks. The U.S. tech sector saw a notable pullback, with the Nasdaq index dropping about 4.48% for the week, the S&P 500 falling by 1.95%, while the Dow Jones increased by 0.67%, indicating a rotation of funds from overvalued tech stocks to energy and defensive sectors. Despite inflation exceeding expectations, the yield on the U.S. 10-year Treasury bond fell back to around 5.09%, showing that the market is also worried about the economic growth outlook.

Next week, the global market is expected to continue to grapple with sticky inflation, the Federal Reserve's interest rate path, and geopolitical risks. Strong U.S. inflation and consumption data suggest that the Federal Reserve lacks room for easing in the short term, but economic growth and financial market pressures may also limit the extent of further rate hikes. Key points to watch next week include statements from Federal Reserve officials, employment data from U.S. states on October 20, consumer confidence data from the University of Michigan on October 23, as well as changes in international oil prices and U.S. Treasury yields. U.S. stocks are expected to maintain high volatility, with the tech growth sector facing valuation adjustment pressures; if oil prices continue to rise, inflation expectations may further increase, suppressing global risk appetite. Conversely, if energy prices retreat and interest rate expectations stabilize, the market may see a phase of recovery.

2. Market Changes and Warnings in the Cryptocurrency Industry

This week, the cryptocurrency market continued its overall pullback, with the core contradiction still being high interest rate expectations and capital outflows: BTC briefly fell below $82,000 and tested the $80,000 area, while ETH's decline was significantly greater than that of BTC. The total market capitalization dropped by about 2% to 3% over the week, with BTC's market share rising to about 59.5%, indicating a further concentration of funds towards BTC and a weak risk appetite for altcoins. The pressure from U.S. spot ETF funds continued, with a cumulative net outflow of about $228 million for BTC spot ETFs from October 12 to 16, and a net outflow of about $320 million for ETH spot ETFs; the early-week decline also triggered large-scale long liquidations, with over $770 million in total market liquidations on October 12 within 24 hours. Overall, this week's sharp decline was not solely due to a single negative factor but was jointly suppressed by the Federal Reserve's further rate hike expectations, high U.S. Treasury yields, continuous ETF outflows, and deleveraging, with ETH and most altcoins significantly weaker than BTC.

Next week, the market is expected to remain in a weak oscillation, waiting for macro and capital conditions to reconfirm direction, with the $80,000 area for BTC becoming an important boundary between bulls and bears; if long-term U.S. Treasury yields fall and BTC spot ETFs return to sustained net inflows, there may be conditions for BTC to rebound first after the previous leverage washout, but until these two signals appear, the foundation for a sustained surge remains insufficient. Structurally, it is expected to continue showing a defensive pattern of "BTC stronger than ETH, mainstream coins stronger than small and mid-cap altcoins," with the altcoin season temporarily lacking a clear capital basis; particular attention should be paid to changes in interest rate expectations as the Federal Reserve meeting on October 27-28 approaches. Therefore, next week is more likely to involve repeated games around the $80,000 area, gradually choosing a direction rather than directly initiating a one-sided trend.

3. Industry and Sector Hotspots

This week, industry hotspots mainly focused on RWA, stablecoins/payments, DeFi, prediction markets + privacy, AI × Crypto, and cross-chain security: RWA continued its institutional trend, with Multiliquid completing $8 million in financing, Fission completing $10 million in Series A, and Spout Finance obtaining $2 million in strategic financing while exploring borrowing USDC collateralized by tokenized U.S. stocks; the on-chain RWA AUM is approximately $34.6 billion; in the stablecoin and payment sector, Western Union's Solana stablecoin USDPT launched on Bitso in Mexico, and USDC was listed as the EU's first "significant electronic money token," but the total market capitalization of stablecoins slightly contracted over the week.

NEAR also launched SOL yield products through the Gauntlet strategy's Kamino Vault; prediction markets continue to develop towards privacy, with StarkWare launching OffMarket to provide a privacy channel for Polymarket trading; in the AI × Crypto sector, the DATA Network, which transformed from the original Story Protocol, received a $30 million strategic investment from the Sui Foundation, with AI data rights confirmation, payments, and Agent infrastructure continuing to heat up; in security and cross-chain aspects, Autheo suffered a loss of about $1.7 million due to the exploitation of Hyperlane's trusted Relayer keys, and THEO plummeted over 90%, once again exposing the single-point trust risk of cross-chain bridges.

II. Market Hotspot Sectors and Potential Projects of the Week

1. Overview of Potential Projects

1.1. Detailed Explanation of Total Financing of $86 million, led by Paypal, 1k(x), Northzone, with participation from institutions such as Cherubic and Volt—building a chain-abstract Web3 experience infrastructure for the general public, Newton (Magic Labs)

Introduction

Newton Protocol is a decentralized on-chain transaction authorization strategy engine built on EigenLayer AVS (Active Validation Service). It can directly execute transaction rules in smart contracts, including consumption limit restrictions, sanctions list screening, fraud protection, and compliance rule management.

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

Protocol Element Analysis

Newton Protocol is a policy engine for on-chain transaction authorization, built on EigenLayer's Active Validation Service (AVS). This page introduces how its core components work together. During the reading of the integration guide, you can return here for reference.

1. How Newton Works

Users write rules (policy) to define when transactions should be allowed to execute. When a user submits a transaction (Intent), Newton's decentralized Operator network evaluates the transaction based on the user's set 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 the conditions that an Intent must meet to be approved. Policies are stored on IPFS (referenced by CID) and can be reused by multiple PolicyClients.

Policies can reference two types of data sources:

• data.params: Configuration parameters set by the PolicyClient owner, such as:

• Spend Limits

• Allowlists

• data.wasm: Data obtained at runtime by the PolicyData WASM Oracle, such as:

• 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 in the SDK.

Task

A Task is the unit that evaluates the combination of Intent and corresponding Policy.

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

• Each Task is judged as:

• Compliant

• Non-compliant

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

Attestation

An Attestation is a cryptographic proof (BLS aggregate signature) used to prove that a Newton Operator has evaluated a certain Policy and made an approval or rejection result for the Intent.

Attestation includes:

• taskId (Task ID)

• policyId (Policy ID)

• evaluation result

• expiration block

For details on the generation mechanism of Attestation, see Consensus & Security.

PolicyClient

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

Developers can integrate Newton into their contracts by inheriting NewtonPolicyClient and calling:

• _validateAttestation()

• _validateAttestationDirect()

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

PolicyData

PolicyData Oracle is a WASM component used to obtain or calculate external data during the policy evaluation process.

Its output will be provided as data.wasm for use by Rego Policy.

Application examples include:

• Obtaining token prices;

• Querying sanctions lists;

• Verifying KYC status.

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

Operator

An Operator is an EigenLayer node registered to Newton AVS.

Operator Responsibilities:

• Independently assess Tasks;

• Execute strategy validation;

• After reaching the consensus threshold (Quorum), aggregate multiple BLS signatures into a unified consensus proof.

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

Gateway

The Gateway is an interface service based on JSON-RPC 2.0, used to receive tasks and coordinate Operator execution assessments.

All SDK and CLI interactions are completed through the Gateway.

Overview of Protocol Technical Architecture

The 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 develop and upgrade independently while maintaining high security for the overall system.

1. Policy Layer

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

|-----------------------------|----------------------------------| | Component | Function | | Policy Registry | On-chain registration of all deployed policies, referenced by CID (Content Identifier) | | Policy Library | Provides reusable policy templates, such as spending limits, sanction checks, KYC verification, etc. | | PolicyData Oracles | WASM-based components that obtain external data during policy evaluation |

The process for developers to publish policies:

1. Write Rego policies and WASM Oracles;

2. Upload them to IPFS via newton-cli;

3. Deploy PolicyData and Policy contracts on-chain.

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

• Thresholds

• Allowlists

• Expiration

1. Compute & Consensus Layer

The Compute Layer is responsible for executing off-chain policy evaluations 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 execute policy evaluations | | 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 obtain PolicyData (run 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 the signatures and generates a consensus proof after reaching Quorum.

6. 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 | Validates BLS aggregated signatures based on 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 validated by Newton's policy and with valid Attestation can continue to execute.

4. Data Flow

The complete policy evaluation process is as follows:

1. Submit Intent: The caller sends the Intent and PolicyClient address to the Gateway.

2. Create Task: The Gateway creates a Task, binding the Intent to the corresponding Policy.

3. Fetch Data: The Operator executes the PolicyData WASM Oracle to obtain external data required for policy evaluation.

4. Policy Evaluated: The Operator uses the Intent, Oracle data, and parameters to run the Rego Policy, assessing whether the transaction complies with the rules.

5. Signatures Produced: Each Operator signs the evaluation result using 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 the verification passes, the protected transaction continues to execute.

Privacy Layer

The privacy architecture of the Newton Protocol is based on HPKE encryption, Secure Envelopes, and Confidential Policy Evaluation, providing on-chain transaction capabilities that support privacy protection for institutional and enterprise scenarios while ensuring compliance verifiability.

The privacy layer of Newton allows end users to submit encrypted sensitive data, such as:

• Personally Identifiable Information (PII)

• Credentials

• Financial Records

Operators will jointly decrypt the required data through Threshold Decryption during the policy evaluation process, while this sensitive information will never appear on-chain.

Many policy execution scenarios require access to sensitive data, such as:

• Identity proof documents;

• API keys;

• Compliance records;

• Private business parameters.

The privacy layer of Newton provides the following capabilities:

End-to-End Encryption

Using HPKE (Hybrid Public Key Encryption) to perform end-to-end encryption on sensitive input data, with the underlying mechanisms including:

• X25519 key exchange;

• ChaCha20-Poly1305 encryption algorithm.

Ensuring that sensitive data remains secure during transmission and processing.

Threshold Decryption

Operators jointly complete data decryption through a t-of-n key share mechanism.

Features:

• No single Operator holds the complete decryption key;

• Data can only be restored when the required number of Operators collaborate;

• Reduces the risk of single-point leakage.

Zero On-chain Exposure

On-chain only records:

• Hash

• Commitment

And does not store any plaintext sensitive data, ensuring that user privacy is not exposed in the public blockchain environment.

Dual-Signature Authorization

Before Operators perform decryption operations, they need to obtain signatures from:

• The End User;

• The dApp.

Only after both parties confirm will the Operator execute the sensitive data decryption, preventing unauthorized data access by design.

How it works

This integration process is divided into three steps:

1. Client encrypts sensitive data
   The client uses the system's Threshold Public Key to encrypt sensitive data (obtained through newt_getPrivacyPublicKey).

2. Upload encrypted data package
   The encrypted data envelope is uploaded to the Gateway, and a corresponding Reference ID is obtained.

3. Create task and execute evaluation
   A Task containing the Reference ID is created. During the policy evaluation process, the Operator decrypts the required data using the Threshold Decryption mechanism.

HPKE Encryption

Newton uses the HPKE standard (RFC 9180) and adopts the following cipher suites:

|---------------|---------------------------| | Component | Algorithm | | KEM | DHKEM (X25519, HKDF-SHA256) | | KDF | HKDF-SHA256 | | AEAD | ChaCha20-Poly1305 | | Signing | Ed25519 |

The Base Mode of HPKE encrypts data to the system's Threshold X25519 Public Key.

This public key is generated through interactive Distributed Key Generation (DKG) among the Operator set, with no single Operator holding the complete private key.

Sender authentication is completed separately by signing the serialized encrypted envelope using Ed25519.

Threshold Decryption

Newton distributes the HPKE private key among multiple Operators through interactive DKG (FROST DKG / Pedersen VSS) mechanisms.

During the task evaluation process:

1. Each Operator calculates a Partial Decryption Share using its own DKG key share.

2. Operators exchange decryption shares through encrypted NATS messages.

3. Each Operator reconstructs the plaintext data locally using a t-of-n share mechanism.

4. The reconstructed plaintext data is used for policy evaluation and BLS signature generation.

The threshold key pair is cryptographically independent of the Operator's ECDSA key and BLS key.

Therefore:

• Even if a signing key is leaked, it will not lead to the leakage of decryption shares;

• An attacker cannot gain the ability to decrypt sensitive data through the Operator's signing key.

The combined public key will be stored on-chain and can be obtained through a single contract call:

getThresholdPublicKey() or through newt_getPrivacyPublicKey

RPC method. The DKG key generation process is only executed when the Operator set changes and will not run repeatedly in each Task.

Consensus & Security

The consensus mechanism, BLS signature aggregation, and economic security model of the Newton Protocol. Through the EigenLayer restaking mechanism, it provides cryptographic and economic security guarantees for policy evaluation in on-chain compliance and risk management.

The Newton Protocol uses BLS signature aggregation and EigenLayer restaked ETH to provide cryptographic and economic security guarantees for the policy evaluation process.

Two-Phase Consensus

Newton adopts a two-phase consensus mechanism to address data discrepancies arising when Operators independently obtain real-time sensitive data (e.g., price data from external APIs).

Since the data obtained by different Operators may have slight deviations, Newton ensures that all Operators can ultimately sign the same message, even if the initially received data values are slightly different.

• Prepare Phase

The Gateway sends data retrieval requests to Operator nodes through newt_fetchPolicyData. Each Operator independently retrieves external data and returns an unsigned data response.

• Consensus Computation

The Gateway aggregates all data returned by Operators and calculates the median as the consensus data while verifying whether the data meets the tolerance range (default tolerance is 10%).

• Commit Phase

The Gateway broadcasts the confirmed standard consensus data through newt_evaluateAndSign. Operators perform policy evaluation using fully consistent data and sign the evaluation results with BLS keys.

• Aggregation Phase

The Gateway collects the BLS signatures returned by Operators, and when the number of signatures reaches the consensus threshold, multiple signatures are aggregated to generate the final Aggregate Proof.

Multichain Support

The Newton Protocol supports cross-chain policy verification, enabling compliance and transaction authorization rules to be executed across Ethereum, Layer2, and other target chains.

The Newton Protocol supports policy evaluation across multiple blockchains. AVS Operators run on the Ethereum source chain, while the PolicyClient contract can be deployed on target chains such as Base and Base Sepolia.

1. Source Chain and Destination Chain

|------------------------|-------------------------------------|------------------------------------| | Chain Type | Function | Example | | Source Chain | The chain where Newton AVS Operator is registered and BLS key management occurs | Ethereum Mainnet, Ethereum Sepolia | | Destination Chain | The chain where the PolicyClient contract is deployed and transactions are executed | Base, Base Sepolia, Ethereum Sepolia |

The source chain provides core security infrastructure, including:

• Operator registration;

• Staking management;

• Slashing mechanism.

The destination chain consumes attestations through lightweight verifier contracts and completes verification using cached Operator states.

2. How It Works

Execution Process

1. Task Submitted

The caller submits a task to the Gateway and sets the target chain's chain_id in the Intent.

2. Operators Evaluate

Operators perform policy evaluation using the Newton AVS infrastructure on the source chain.

3. BN254 Certificate Produced

The BLS aggregated signature is encoded as a BN254 Certificate for verification on the target chain.

4. Attestation Verified on Destination

The PolicyClient on the destination chain verifies the proof using BN254CertificateVerifier. Once verified, the destination chain can proceed with the corresponding transaction.

Tron Comments

The advantage of Newton (Magic Labs) lies in its construction of a decentralized on-chain transaction authorization strategy engine based on EigenLayer AVS. Through Policy, Operator network, Attestation proof, and smart contract verification mechanisms, it upgrades traditional static signature authorization to a programmable and verifiable transaction permission control system. It supports consumption limit restrictions, KYC/AML, sanction screening, anti-fraud rules, and AI Agent transaction management, and combines HPKE encryption, threshold decryption, BLS aggregate signatures, and cross-chain verification capabilities to provide on-chain execution infrastructure that balances privacy, security, and compliance for institutions and enterprises.

Its disadvantage is that the system architecture involves multiple complex components such as Rego policies, WASM Oracles, AVS Operators, cross-chain proofs, and privacy computing, resulting in a high development and integration threshold. At the same time, the protocol's value heavily relies on the adoption by enterprises, DeFi applications, and the AI Agent ecosystem, and it still needs to validate stability, operational costs, and adaptability in different regulatory environments in large-scale commercial scenarios.

II. Industry Data Analysis

1. Overall Market Performance

1.1. Spot BTC vs ETH Price Trends

BTC

ETH

III. Macroeconomic Data Review and Key Data Release Points for Next Week

This week's macro conclusion:

The biggest change is not a sudden weakening of the economy, but a significant increase in the "re-inflation" risk in the United States. The September CPI rose to 3.7% year-on-year, and the PPI increased by 1.3% month-on-month, while import prices surged, indicating that price pressures are increasing on the consumption side, production side, and input side. Therefore, the macro trading logic leans more towards reassessing the Federal Reserve's easing space—if subsequent employment and PMI remain resilient, the combination of "growth still okay + inflation relatively high" will continue to limit the pace of interest rate cuts.

Key data points for next week:

In the United States, the data density next week is actually lower than this week, focusing on initial jobless claims + October PMI;

If the U.S. PMI remains strong, employment does not deteriorate significantly, and inflation remains high, the macro environment will further lean towards "higher rates for longer," which is the macro logic that needs to be focused on in trading U.S. stocks, gold, the dollar, and the crypto market next week.

IV. Regulatory Policies

I. United States: CFTC Advances Crypto Asset Trading and Market Regulation Rules

October 13, 2026 | U.S. Commodity Futures Trading Commission (CFTC)

The U.S. Federal Register published on October 13 the CFTC's proposed rulemaking advance notice regarding "Regulation Crypto Asset Transactions" and "Regulation Crypto Asset Markets." The document addresses crypto asset trading and markets under Section 2(c)(2)(D) of the Commodity Exchange Act, aiming to solicit public opinions to lay the foundation for developing regulatory rules that better align with the characteristics of the crypto asset market.

Policy significance: U.S. crypto asset regulation continues to advance through the specific rule-making process of regulatory agencies, focusing on clarifying the regulatory requirements for crypto asset trading activities and related markets. However, this document is part of the preliminary opinion solicitation process and does not represent that the new rules have been formally passed or come into effect.

II. Singapore: Stablecoin Regulatory Legislation Consultation Ends This Week

October 16, 2026 | Monetary Authority of Singapore (MAS)

The Monetary Authority of Singapore previously released a consultation document on September 1 regarding amendments to the Payment Services Act, aiming to implement a regulatory framework for single currency stablecoins (MAS-SCS), with October 16 set as the deadline for public opinion submissions. This consultation covers stablecoin reserves and value stabilization mechanisms, capital requirements, redemption at face value, information disclosure, as well as arrangements for cross-jurisdictional joint issuance and recognition of foreign stablecoins. MAS also proposed measures to prohibit regulated stablecoins from paying interest, requiring issuers to conduct stress tests and develop recovery and orderly exit plans.

Policy significance: This week marks the transition of Singapore's stablecoin regulatory framework into the policy evaluation phase following the end of the consultation. Eligible stablecoins are expected to gain a clearer regulatory identity and serve cross-border settlement and tokenized financial markets. However, it is important to emphasize that October 16 is the deadline for collecting opinions, not the date when the new rules officially come into effect.

III. International Regulatory Organization: FSB Releases Global Stablecoin Cross-Border Risk Monitoring Document

October 12, 2026 | Financial Stability Board (FSB)

On October 12, the FSB officially released "Global Stablecoin Arrangements: Cross-border Vulnerabilities and Financial Stability Monitoring," summarizing the potential cross-border financial stability risks posed by global stablecoin arrangements for the G20. The document focuses on the organizational structure of global stablecoins, the transmission paths of risks between different institutions and jurisdictions, and the limitations of data indicators and sources that regulators can use to monitor stablecoin activities.

Policy significance: As the scale of cross-border circulation and use of stablecoins expands, individual national regulatory agencies may find it difficult to independently identify all risks. The FSB's document emphasizes the importance of cross-border regulatory coordination and data monitoring, providing a reference for countries to improve stablecoin risk regulation in the future. However, this document is a result of international regulatory research and policy coordination and is not a binding law that directly takes effect in member countries.