What Is ZAN Sui Data Service?

ZAN Sui Data Service is a professional data service platform for the Sui blockchain, offering both GraphQL API access to the full Sui historical dataset and real-time gRPC subscriptions to meet various data querying and real-time monitoring needs. These services help developers build more competitive and responsive applications within the Sui ecosystem. ZAN Sui Data Service goes beyond simply exposing on-chain data to developers. It provides structured, on-demand data services that enable developers to focus more on implementing business logic.

Why Choose ZAN Sui Data Service?

GraphQL API Benefits

Compared to traditional REST or multi-endpoint aggregation, reduce request count by 40%–70% and improve end-to-end data loading by 30%–60% on average.

• Faster Loading: 30%–60% average speedup. Fetch only the fields you need and return related data in a single response — less serial calling and duplication, faster list / detail first paint.
• Fewer Requests: 40%–70% fewer API calls. Move from “stitching multiple endpoints” to “one query for all required fields,” especially effective for asset pages, transaction details, and activity feeds.
• Easier Migration: Replace core endpoints in 1–3 days (typical). Keep frontend data structures stable while consolidating multiple endpoints into a unified schema — less integration and maintenance overhead.
• Controlled Cost: Query complexity visibility, more stable in production. Observe query cost / latency and apply guardrails (e.g., limits / throttling) to prevent expensive queries from impacting overall performance.

Real-time gRPC Subscription Benefits

Reduce latency from seconds to 200–500 ms-class updates; in high-frequency scenarios, server request volume can typically drop by 50%.

• Lower Latency: 200–500 ms-class update experience. Ideal for price alerts, transaction status, asset changes, and notifications — where users are waiting for updates.
• More Efficient: 50% fewer high-frequency polling requests. Switch from “poll every 2–5 seconds” to “push on change,” significantly reducing QPS and bandwidth overhead.
• More Reliable Increments: Resumable consumption via checkpoints. Catch up from checkpoints after disconnects to reduce missed updates — great for indexing and real-time pipelines.
• Faster Rollout: Gradual replacement of existing polling logic. Start by subscribing to the most critical event / object changes, while keeping the rest on JSON-RPC — lower migration risk.

In short, by choosing ZAN Sui Data Service, developers can efficiently build higher-performance, faster-responding applications within the Sui ecosystem, while focusing more on implementing business logic.

What Use Scenarios Is ZAN Sui Data Service Suitable For?

• DeFi Application: Real-time monitoring of liquidity pool changes and transaction events.
• NFT Market: Tracking NFT’s minting, transfer and sale events.
• Game Application: Monitoring game-related assets and state changes in real-time.
• Wallet Service: Building high-performance blockchain wallets and asset management tools.
• Data Analysis: Deep analysis of chain data to build business intelligence platforms.
• Monitoring and Alarm: Real-time monitoring of key indicators to respond to abnormal situations.

ZAN Sui Data Service delivers the highest performance in the Asia-Pacific region with millisecond-level latency, supporting full access to and retrieval of all Sui on-chain data. Priced at only one-fifth of comparable products on the market, ZAN Sui Data Service provides a sustainably scalable data foundation for businesses that demand query efficiency, real-time responsiveness, and stability.

Experience ZAN Sui Data Service Now

ZAN Sui Data Service is now live on our official website. Developers can click the link below to start building right away.

Professional Sui blockchain data service platform

About ZAN

As a technology brand of Ant Digital Technologies for Web3 products and services, ZAN provides rich and reliable services for business innovations and a development platform for Web3 endeavors.

The ZAN product family includes ZAN Node Service, ZAN ZK Acceleration, ZAN Smart Contract Review, and ZAN Identity, with more products in the pipeline.

Contact Us

Website | Twitter | Discord | Telegram

🔥 Why Do You Need the Polygon High-Speed Node?

On Polygon, the high-throughput chain processing hundreds of transactions per second, latency directly impacts profits — and speed is a real competitive edge. But the reality is harsh:

• 🕒 High Latency: Public RPC endpoints often route across regions, pushing round-trip times past 100 ms. While your transaction is still in transit, the opportunity is already gone.
• 🔄 Inconsistent Node State: The node you’re connected to may be 2–3 blocks behind, causing your submitted transaction to be rejected outright.
• 🚧 Single-Path Broadcasting: Your transaction is sent to only one node — if that node is congested or offline, it can vanish without a trace.

🚀 Polygon Ultra-Fast Transaction Acceleration Engine: A Three-Part System That Redefines Speed

🌐 Network Layer: Millisecond-Level Direct Connectivity to “Erase” Physical Distance

• Proximity Validator Deployment: Node services and Polygon core validators are deployed in the same region, such as Singapore or Tokyo, or even within the same availability zone.
• Co-Location Deployment: Through VPC Peering and Direct Connect, enable intranet-grade, low-latency connectivity across tenants and VPCs, completely bypassing public internet jitter.
• RTT consistently held at 2–5 ms — 20–50× faster than typical public internet connections.

🧠 Scheduling Layer: “Connect Fast” and “Connect Right”

We don’t blindly connect to any node — we continuously and dynamically assess node health across the entire network:

• ✅ Real-time Monitoring: Block height, sync lag, mempool depth, and API response time.
• ✅ Smart Scoring: Only nodes with the latest block, an active mempool, and response times under 10 ms are selected.
• ✅ Automatic Failover: If a node becomes unhealthy, traffic is rerouted within milliseconds — so transactions never stall.

“Latest and most active” means your transactions are always at the very front of the block-production queue.

⚡ Transaction Layer: From “Passive Waiting” to “Active Priority Capture”

• Mempool Visibility: Direct node connections let us see transactions 100–500 ms earlier than the public mempool.
• Multi-Path Broadcast: Each transaction is simultaneously sent to several directly connected validators, entering the consensus network through multiple channels.
• Priority Entry: Increase the gas price to bypass public mempool congestion and enter high-throughput nodes’ pending-inclusion queues directly.

✅ Result: the average confirmation time is 2.1 seconds, and transaction-sniping success rate is up 300%!

☁️ Inter-tenant Cloud Networking: An Enterprise-Grade Reliable Foundation

• Seamless Multi-VPC Networking: Secure connectivity across accounts and business units;
• 99.99% SLA: Underpinned by BGP and intelligent routing to automatically bypass link failures;
• Elastic Scaling: Automatically scales bandwidth during traffic spikes to keep transaction paths congestion-free.

🔗 End-to-End Data Flow: A 4-Step Ultra-Fast Loop

1. Connectivity Setup → Use dedicated private lines to directly connect to multiple trusted Polygon nodes;
2. Health Checks & Routing → Score nodes in real time and lock in the top 3 block-producing nodes;
3. Transaction Submission → Simult.aneously broadcast to multiple nodes and gain priority entry into the mempool;
4. Accelerated Inclusion → 2-second confirmations on average, far above the industry norm!

🎯 Use Cases

🔥 DeFi Arbitrage / MEV Capture: Winning comes down to milliseconds

🖼️ NFT Mint Sniping: Say goodbye to failed mints from “gas wars”

💱 Market Maker Quoting: Ensure orders are included on-chain as soon as possible

🌉 Cross-Chain Bridge Interaction: Reduce cross-chain latency and waiting costs

💎 Summary

On Polygon’s fast lane, standard RPC is a bicycle — we deliver an F1 car.
Powered by our global cloud infrastructure, an intelligent routing engine, and multi-path transaction broadcasting, every transaction stays in the fast lane.

🚀 Trusted by dozens of leading DeFi and NFT projects, accelerating 10,000+ transactions per day on average.

👉 Want your transactions to land faster? Connect directly and experience high speed on Polygon!

📧 Email us to learn more about ZAN Polygon High-Speed Node: service@zan.top

🔗 Experience ZAN Node Service now: https://zan.top/home/node-service?chInfo=ch_tw

About ZAN

As a technology brand of Ant Digital Technologies for Web3 products and services, ZAN provides rich and reliable services for business innovations and a development platform for Web3 endeavors.

The ZAN product family includes ZAN Node Service, ZAN ZK Acceleration, ZAN Smart Contract Review, and ZAN Identity, with more products in the pipeline.

Contact Us

Website | Twitter | Discord | Telegram

Powering the Future: Ultra-Fast Node Synergy, ZK Compute Leap, and Full-Dimensional Contract Defense

In 2025, ZAN upgraded three core “superpowers” to the Web3 world:

• Node Service: Stably supporting over 2 billion daily requests, with millisecond-level latency, providing industrial-grade infrastructure guarantees for high-frequency trading, real-time data, and large-scale applications, and building a solid operational foundation.
• ZK Acceleration: With a disruptive acceleration ratio of 159X (vs 16-core CPU) and 3X (vs industry standard), driving an end-to-end ZKP performance leap through hardware-software co-optimization, efficiently empowering zkVM / proving systems, and setting a new benchmark for Web3 infrastructure.
• Smart Contract Review: Integrating 50+ top-tier conference research achievements and 20+ patented technologies, providing zero-incident protection across the full lifecycle from development to deployment to upgrade for 100+ critical projects, and forging a security foundation for Web3’s high-growth tracks.

Through these three capabilities, ZAN has continuously empowered hundreds of thousands of developers worldwide to build the future efficiently and securely. ZAN has achieved leadership in the Asia-Pacific in 2025 while serving users worldwide, becoming the preferred Web3 infrastructure partner for massive numbers of project teams to drive business growth.

Node Services Fully Upgraded and Evolved: Ultra-Fast, Secure, Cross-Chain Collaboration

• The new-generation high-concurrency, low-latency architecture was officially live — request latency was reduced by 50%, and resource utilization improved by up to 2x.
• Partnered with leading public chain Solana to expand footprint across the Asia-Pacific region — focusing on core areas such as high-performance RPC services, Validator hosting, and transaction acceleration, together driving Web3 innovation across the Asia-Pacific region! Solana developer community has grown to over 50K, spanning countries including Singapore, Japan, South Korea, Malaysia, the United States, and Germany worldwide. Solana trading experience enhanced again — launching an integrated Solana trading boost + MEV protection solution, combined with low-latency communication protocols such as gRPC / ShredStream, ensuring users’ trading is one step faster and worry-free in security, with daily accelerated transactions surpassing 10K. >> https://zan.top/home/solana

Collaboration Details：https://x.com/zan_team/status/1922524828738978113

• The multi-chain Validator collaboration ecosystem expanded strongly — reaching deep Validator collaborations with leading public chains such as Aptos and Avail to jointly build a decentralized, highly available underlying trust network.

• The ecosystem footprint continued to expand：
• Deep coverage of emerging high-performance public chains such as Jovay, Pharos, Hyperliquid, Monad, Gravity Alpha, Near, and X Layer, continuously advancing the implementation of the core ecosystem.
• Services covered multiple leading exchanges, million-user wallets, enterprise-grade data security platforms, and other clients and scenarios, enhancing on-chain infrastructure capabilities with security, stability, and low latency as the goals.
• Co-built with multiple leading projects across various tracks to reach technical strategic partnerships, promoting cross-ecosystem interoperability and capability reuse, and exploring new paradigms and standards for on-chain technology.

ZAN connected chains, applications, and users, driving efficient collaboration in a multi-chain world.

ZK Acceleration Reshaped the Performance Boundaries of ZKPs, with Hardware-Software Co-Optimization Driving End-to-End Ultra-Fast Evolution

• Formed the GPU-accelerated architecture based on three proving systems — Halo2, Stwo, and Plonky3 — efficiently supporting diverse applications including zkVMs, achieving over 20x performance improvement.
• Supported two leading zkVM projects integrating with EthProofs.
• Collaborated with StarkWare to open-source the GPU acceleration solution for Stwo + Stwo-Cairo, achieving up to 37x speedup and making significant impact in the community.

https://x.com/zan_team/status/1953047534043271488

• Jointly launched Zetta, the world’s first zkVM accelerator architecture, with Succinct — delivering 20x performance compared to a 64-core CPU on the U55c FPGA accelerator card, laying a technical foundation for future zk acceleration infrastructure.

Image Source：https://x.com/SuccinctLabs/status/1948415077457240203

• Became a leading proof service provider on the Succinct Network, having completed 255K proofs to date. >> https://blog.succinct.xyz/network/zan/

Smart Contract Full Lifecycle Defense Framework

• A Proactive Defense Network Engineered by Professional Security Experts

Powered by 50+ research papers from top-tier international security conferences and 20+ patented technologies, delivering:

✓ 21-day SLA for continuous vulnerability remediation

✓ End-to-end security coverage across the entire development lifecycle (Development → Testing → Deployment → Upgrade)

• Battle-Tested in High-Growth Sectors

Safeguarding the deployment of 100+ projects with deep expertise across:

✓ Infrastructure Layer: L2 Rollups, Cross-Chain Bridges, etc

✓ Application Layer: DEXs, DEX Aggregators, GameFi, NFT Protocols, Prediction Markets, etc

✓ Asset Layer: Wallet Security Architecture, Token Issuance Systems, etc

Providing a zero-incident security foundation for diverse blockchain scenarios.

Meanwhile, SmartCogent and the x402 Facilitator respectively launched in June and November, combining cutting-edge AI with on-chain protocol understanding to deliver an “out-of-the-box” intelligent interaction hub that automated complex operations with one click and unleashed limitless innovation potential for Web3.

Ecosystem Co-Prosperity: Global Collaboration Reshaped the Future of Web3

Every ecosystem resonance is a cornerstone in building the future of Web3. ZAN sincerely thanks every partner for your trust and support, and warmly invites builders worldwide to join us on the journey to 2026, driven by our belief in technology to unlock limitless possibilities!

ZAN 2026: A New Global Benchmark for Infrastructure

In 2026, ZAN will officially launch global expansion, advancing from an Asia-Pacific leader toward becoming a global Top 3 blockchain infrastructure provider.

Comprehensive Upgrade of the Intelligent Experience

Farewell to the traditional tool console, comprehensively evolving into an “AI-Driven Console” — intelligent Q&A, intelligent troubleshooting, and intelligent recommendations will become core capabilities; key experience systems such as the pricing system, billing and metering, documentation, and troubleshooting workflows will be transformed, and the enterprise-grade private deployment solution will be officially launched, providing top-tier customers with secure and compliant Dedicated Node services.

Ultimate Performance Breakthrough

In partnership with Alibaba Cloud, ZAN will build a high-speed node solution to achieve millisecond-level latency; Solana Trading Boost will be fully commercialized, and a full-chain transaction service matrix covering BSC / Solana / Base / Sui will take shape, making every on-chain transaction faster, more stable, and lower-cost.

AI × Web3 Frontier Exploration

Focusing on the innovative integration of intelligent technologies and blockchain, defining the next-generation infrastructure paradigm through frontier breakthroughs.

From functionality to intelligence, from regional to global, from participation to definition — ZAN is reshaping the benchmark for blockchain infrastructure.

The ZAN Ark has set sail — powered by innovation and steered by trust. We sincerely invite developers worldwide to join us in building a new frontier for Web3!

About ZAN

As a technology brand of Ant Digital Technologies for Web3 products and services, ZAN provides rich and reliable services for business innovations and a development platform for Web3 endeavors.

The ZAN product family includes ZAN Node Service, ZAN ZK Acceleration, ZAN Smart Contract Review, and ZAN Identity, with more products in the pipeline.

Contact Us

Website | Twitter | Discord | Telegram

Introduction: Systemic Upgrades as the Ultimate Test for Web3 Infrastructure

Each milestone Ethereum network upgrade (https://ethereum.org/zh/roadmap/)—from “The Merge” and the “Dencun” upgrade to the latest Fusaka upgrade on December 4, 2025 — has been a comprehensive “stress test” for Web3 infrastructure providers. As the core hub connecting developers, applications, and blockchain networks, RPC node providers are the key players in this hard-fought upgrade battle.

The core goal of the Fusaka upgrade is to reshape Ethereum’s data availability architecture by introducing breakthrough technologies such as PeerDAS (EIP-7594), clearing the way for large-scale expansion of Layer 2 (L2) networks. For professional RPC infrastructure providers like ZAN Cloud, this is by no means a simple software version iteration, but a triple test of forward-looking monitoring capabilities, phased deployment capabilities, and cross-ecosystem collaboration capabilities.

As the “infrastructure guardian” of the Web3 ecosystem, ZAN Cloud understands that the stability and timeliness of RPC services are the lifeline for developer innovation and application deployment. This article will provide an in-depth breakdown of ZAN Cloud’s end-to-end response plan, revealing how we leverage technical strength to safeguard the Fusaka upgrade, ensuring node services remain stable and reliable at all times, and building a solid foundational support for Web3 developers worldwide.

Forward-Looking Monitoring — Capturing Upgrade Signals End-to-End to Achieve “Foresight”

The success of a large-scale network upgrade begins with millisecond-level responsiveness to technical developments. ZAN Cloud has built a multi-layered, automated monitoring and alerting system to ensure that every upgrade signal — from code commits to community consensus — is captured with precision.

1. GitHub Tracking: Full-Lifecycle Monitoring of Multi-Client Release Versions

Ethereum’s core clients (execution clients: Geth, Reth; consensus clients: Lighthouse, etc.) are the primary carriers for upgrade implementation. Real-time control of their version dynamics is the first step in handling an upgrade. ZAN Cloud’s engineering team has set up a customized automated monitoring toolchain to enable full-process technical tracking:

• Real-time release alerts: Continuously monitor the official GitHub repositories of major clients. Once a Pre-release test version or a Latest stable release tag is detected, the system immediately triggers multi-level internal alerts and automatically pulls the release package to perform preliminary code-level compatibility analysis.

2. Community Engagement: Cross-Validating Across Multiple Channels to Ensure Accurate Information

The technical details and timelines of blockchain upgrades are often born out of public discussions within the community. ZAN Cloud is not only a receiver of technical information, but also a deeply engaged participant in Ethereum’s core community:

• Full follow-through on core meetings: The engineering team regularly tracks meeting notes and public discussions from the Ethereum Dev community, gaining first-hand access to the latest decisions on upgrade proposals, phased timelines, and potential technical risks, ensuring our understanding of the upgrade path stays aligned with core developers.
• Cross-validation from multiple information sources: By subscribing to official updates from the Ethereum Foundation Blog and joining core developer Discord groups, among other channels, we cross-verify upgrade details to eliminate misjudgments that could arise from relying on a single source, ensuring our upgrade preparation stays on the right track.

3. Internal Health Monitoring: Dual Validation of Versions and Interfaces

Alongside external monitoring, ZAN Cloud leverages its internal automated operations platform to build a health and compatibility monitoring system for node clusters:

• Real-time visualization of version distribution: By integrating Prometheus and Grafana to build monitoring dashboards, we display in real time the client types and version distribution ratios of nodes across the entire network, ensuring that during the upgrade process, node version iteration progress is clearly visible and under control.
• Proactive interface compatibility testing: For new features introduced in the Fusaka upgrade, we prepare comprehensive test cases in advance covering all scenarios, and conduct continuous stress testing and compatibility validation of the JSON-RPC interfaces of new client versions, ensuring that after the upgrade, existing Web3 applications will not be affected in their normal calls.

Phased Deployment — From Testnets to Mainnet, Advancing Step by Step to Reduce Risk

In the face of a systemic upgrade like Fusaka, ZAN Cloud strictly follows the deployment principles of “test first, then mainnet; small traffic, then full rollout; canary release with rollback,” minimizing upgrade risks and ensuring service continuity.

1. Early Battle Preparation: Meeting the Performance Challenges of “Super Nodes”

While the PeerDAS mechanism in the Fusaka upgrade enhances L2 data availability, it also places higher demands on the storage and bandwidth performance of RPC nodes — RPC providers must take on the role of “Super Nodes,” storing and processing the full set of Ethereum Layer 1 (L1) data. To this end, ZAN Cloud planned ahead and made thorough preparations:

• Forward-looking expansion of hardware resources: Based on estimations of PeerDAS data traffic, we planned and deployed high-spec storage servers and high-bandwidth network resources in advance, ensuring nodes can handle the post-upgrade surge in data volume with ease.
• Deep tuning of node configurations: The engineering team performed in-depth optimization of node runtime parameters based on the characteristics of the new client versions. By adjusting memory allocation, data caching strategies, and more, we ensure low latency and high throughput for RPC requests under high-load scenarios.

2. Phased Implementation: Testnets First, Smooth Transition to Mainnet

The core of upgrade deployment is “progressive implementation.” ZAN Cloud has formulated a clear phased execution plan:

1. Testnets first for validation: Before the upgrade windows open on Ethereum testnets such as Sepolia and Hoodi, we complete node version upgrades in advance and work with developers through multiple rounds of testing to verify node support for new features, while also collecting feedback to optimize node configurations.
2. Mainnet canary deployment: During the mainnet upgrade window, we adopt a gradual upgrade approach — first switching a small proportion of user traffic to the new-version nodes and continuously monitoring their operating status; once all metrics remain stable, we then gradually increase the traffic share until a full cutover is completed.
3. Emergency rollback mechanism: Before the full cutover, we establish a comprehensive rollback plan. If unforeseen technical failures occur in the new version, we can switch all traffic back to the old-version nodes within seconds, achieving “zero-perception” fault recovery and minimizing the impact on users’ business to the greatest extent possible.

Ecosystem Collaboration — Coordinated Support for Layer 2 Networks to Achieve End-to-End Compatibility

An upgrade to Ethereum L1 will inevitably trigger chain reactions across L2 networks. As an RPC provider covering mainstream L2 networks, ZAN Cloud has always regarded coordinated L1–L2 upgrades as core work, ensuring seamless connectivity across the entire ecosystem.

1. Deep Collaboration with L2 Teams to Synchronize Adaptation Progress

ZAN Cloud has established a regular communication mechanism with mainstream L2 teams such as Jovay, Arbitrum, Optimism, and Base:

• Track in real time each L2 network’s adaptation plan for the Fusaka upgrade and its version release progress, obtaining L2 node upgrade requirements and technical parameters in advance.
• For the customized needs of L2 networks, adjust RPC node configuration strategies to ensure compatibility between L1 and L2 node versions, avoiding data transmission interruptions caused by version mismatches.

2. Focusing on Blob Data Flows to Ensure Core L2 Functionality

After the Fusaka upgrade, L2 transaction data will be submitted to L1 via a brand-new Blob mechanism, which is critical to the normal operation of L2 networks. ZAN Cloud focuses on the following work:

• Conduct dedicated tests on the Blob data processing capabilities of upgraded L1 nodes to verify whether nodes can correctly receive, store, and query Blob data.
• For the core needs of L2 sequencers and provers, optimize the efficiency of Blob data retrieval via RPC interfaces to ensure that L2 transaction finalization and data availability are not affected.

3. Coordinated Upgrades for Multi-Chain Services to Achieve Full Ecosystem Coverage

Leveraging its multi-chain RPC service architecture, ZAN Cloud extends its Fusaka upgrade response plan across the entire ecosystem:

• Treat the upgrades of L1 and each L2 network as a coordinated project, and develop a unified upgrade timeline to ensure that nodes across all relevant networks complete iterations within compatible time windows.
• After the upgrade is completed, perform end-to-end testing of the full RPC service pipeline, covering all scenarios such as transaction queries and contract calls from L1 to L2, ensuring a consistent service experience for users in a multi-chain environment.

Conclusion: ZAN Cloud — Your Trusted Web3 Infrastructure Partner

The Ethereum Fusaka upgrade is a major challenge of the technical strength and service capabilities of Web3 infrastructure providers. As an industry-leading RPC node provider, ZAN Cloud has always taken “forward-looking planning, phased implementation, and full-ecosystem collaboration” as its core principles, calmly responding to every systemic challenge.

From GitHub code tracking to assessing community consensus, from testnet validation to progressive upgrade deployment, and from L1 node upgrades to L2 ecosystem coordination, ZAN Cloud ensures 99.9% high availability of node services with a standardized, automated, and refined end-to-end solution.

Looking ahead, ZAN Cloud will continue to deepen its focus on the Web3 infrastructure domain, keep pace with upgrades across Ethereum and the broader multi-chain ecosystem, and safeguard global developers and application teams with professional technical capabilities and reliable service quality. Choosing ZAN Cloud means choosing stable, efficient, future-ready Web3 infrastructure assurance.

This article was written by Edison from the ZAN Team.

About ZAN

As a technology brand of Ant Digital Technologies for Web3 products and services, ZAN provides rich and reliable services for business innovations and a development platform for Web3 endeavors.

The ZAN product family includes ZAN Node Service, ZAN ZK Acceleration, ZAN Smart Contract Review, and ZAN Identity, with more products in the pipeline.

Contact Us

Website | Twitter | Discord | Telegram

As an important gateway to the blockchain ecosystem, wallets in recent years in the Web3 industry seem to no longer be the main narrative of Web3. This phenomenon stems both from the market’s focus shifting to the AI track and from the lack of breakthrough innovative products in the wallet sector. For most users, wallets are regarded as infrastructure-like existence: when interacting with the Ethereum ecosystem they use MetaMask, and when interacting with the Solana ecosystem they choose Phantom. This tacit understanding has become an industry norm, but it seems to be only that.

However, upon closer observation, it becomes apparent that mainstream wallets in the past few years in fact carry out a large number of innovations and upgrades. For example, MetaMask implements login via third-party social accounts such as Google and Apple, and expands support to non-EVM ecosystem chains such as Bitcoin and Solana; Phantom evolves from a Solana-native wallet into a multichain wallet, supporting the Ethereum mainnet and multiple L2s, as well as public chains such as Bitcoin and Sui…

In addition, security issues always remain at the core of wallet product iteration. The frequent incidents of private-key theft change users’ psychological expectations of self-custody security, pushing wallet products to seek a new balance between security and usability. People increasingly find that full self-custody may be highly idealized, especially for wallets that interact frequently with DApps. As a result, from complex seed-phrase management to streamlined social logins, and from single-chain support to full-chain interoperability, the ongoing evolution of wallet products is reshaping the way users interact with blockchains.

MetaMask: Social Login and Multichain Expansion

First is MetaMask (https://metamask.io/). As an iconic wallet of the Ethereum ecosystem, its changes to some extent can be regarded as a wind vane for the wallet sector. Its social login feature represents a breakthrough in the traditional wallet experience. Based on the TOPRF (Threshold Oblivious Pseudorandom Function) cryptographic primitive, MetaMask implements identity verification via a Google or Apple account while preserving the core characteristics of a non-custodial wallet. This technical approach splits the private key into multiple encrypted shards and stores them in a distributed manner; only through dual verification — social authentication and an independent security password set by the user — can the complete private key be reconstructed.

At the architectural level, MetaMask first achieves support for non-EVM ecosystems through the Snaps extension system. As pluggable modules, Snaps allow developers to create customized support for different blockchains, transforming MetaMask from a purely Ethereum wallet into a true multichain gateway. This architectural design both preserves core security and leaves room for future expansion. Unfortunately, since its launch, Snaps remains somewhat lukewarm. And this year, MetaMask goes further by offering native multichain support, currently taking the lead in natively supporting Solana and Bitcoin SegWit addresses.

Phantom: A Versatile Wallet Originating from Solana

Phantom (https://phantom.com/) wallet’s development trajectory reflects the rapid growth of the Solana ecosystem. Initially as a Solana-native wallet, Phantom quickly gains market recognition thanks to its smooth user experience and deep support for NFTs. In 2023, Phantom officially supports the Ethereum mainnet, marking its strategic shift toward a multichain wallet.

Just like Solana’s rapid development, Phantom also adds new features very quickly. It is now possible to buy perpetual contracts directly within the wallet and trade directly on prediction markets. This seems to be a trend across the entire internet industry: service providers always want users to stay longer inside their own apps.

In terms of user experience, Phantom’s social login adopts a distinctive PIN mechanism. After completing authentication via a Google or Apple account, users need to set a PIN as a local verification credential. This design strikes a balance between security and usability — the PIN is easier to remember than a traditional seed phrase while providing an additional security layer. Through its Phantom Connect technology, Phantom provides developers with an authentication SDK, allowing applications to automatically create embedded wallets for users while remaining compatible with existing Phantom wallet users. The cross-device sync feature allows users to access their wallets seamlessly across different devices, further improving convenience.

TipLink: Links That Are Money

TipLink (https://tiplink.io/) is a major innovation in the Web3 interaction paradigm. According to its official documentation, TipLink’s core concept is “Links that are money”. Its workflow is extremely simple: users connect a crypto wallet to create a TipLink and deposit funds, generate a unique URL or QR code to share with the recipient, and the recipient can claim and use these funds even if they do not have a crypto wallet.

This design completely removes the onboarding barrier of traditional wallets. Recipients do not need to understand concepts such as private keys, seed phrases, or gas fees; they only need to click the link to complete claiming the funds. TipLink’s innovative value lies in redefining the concept of a “wallet” — it is no longer a tool that users must actively create and manage, but an asset container that can be passively received and used. This model is particularly suitable for high-frequency, lightweight use cases such as small payments, tipping, and gifts, providing new possibilities for the mass adoption of Web3.

New Wallets

Although the wallet sector is already quite entrenched, new players are still joining.

The TopNod (https://topnod.com/) wallet further segments the Web3 wallet market. According to its official website, it is a decentralized self-custodial wallet focused on real-world assets (RWAs), and TopNod’s core positioning is to connect Web3 with traditional financial markets. It supports the tokenization of mainstream financial assets such as gold, U.S. Treasuries, and U.S. stocks, providing users with the ability to view, store, and transfer cross-chain RWA tokens.

In terms of security, TopNod adopts enterprise-grade standards, including multiple protection mechanisms such as AES-256 encryption, TEE (Trusted Execution Environment) protection, encrypted access-code sharding, and secure memory confinement. Traditional finance–grade security principles and compliance standards give it a unique advantage in RWA policy-making and cooperation with financial institutions.

Summary

Wallets may no longer be the hottest narrative focus in Web3, but their importance as infrastructure never diminishes. As AI and blockchain technologies further converge, wallet products continue to innovate in areas such as identity management, asset automation, and cross-chain interoperability. As the industry’s focus shifts among different tracks, wallets, as the bridge connecting users to the blockchain world, continue to evolve and lay the foundation for the next wave of mass adoption.

This article was written by the ZAN Team.

About ZAN

As a technology brand of Ant Digital Technologies for Web3 products and services, ZAN provides rich and reliable services for business innovations and a development platform for Web3 endeavors.

The ZAN product family includes ZAN Node Service, ZAN PowerZebra (zk acceleration), ZAN Identity (Know your customers and clients), ZAN Smart Contract Review, with more products in the pipeline.

Contact Us

Website | Twitter | Discord | Telegram

ERC8004 is a protocol specification on Ethereum that defines a set of standards enabling agents to establish trust relationships on the blockchain, integrating the A2A (Agent-to-Agent) narrative with Web3. In this article, let’s take a look at the logic behind this grand Web3 + AI narrative.

The protocol is available at https://eips.ethereum.org/EIPS/eip-8004, created in August this year and currently under review. This article will explain what problem this protocol aims to solve, break down its standards in plain language, and finally explore some of the potential implications of this protocol. The full read takes about 15 minutes — feel free to bookmark it!

The Problem the Protocol Solves

First, let’s take a look at what problem this protocol is trying to solve:

In simple terms, it addresses the trust issue in A2A (Agent-to-Agent) interactions. For example, I have an AI assistant named Xiao A — it’s an agent — and I ask it to order me a reliable meal delivery. However, my agent isn’t good at this task (after all, interfacing with delivery riders and restaurants is a huge undertaking, and a small AI assistant doesn’t support that). So what can I do?

That’s when I can ask other agents for help.

So here’s the question: how can my agent find another reliable agent to help? Isn’t there a lack of a trust intermediary? In fact, humans face the same issue — we use platforms like Taobao for transactions, and Taobao acts as a centralized trust intermediary. But centralized trust intermediaries have their limitations, which become even more pronounced in the age of agents. For agents to operate efficiently, they shouldn’t have to rely on humans or centralized institutions for every task — otherwise, humans will end up holding AI back. Even if we use centralized institutions for verification, we’d still need those that either work with AI or operate in a decentralized manner to truly unlock AI’s potential.

Therefore, if there could be a decentralized, trustworthy data source to help me find reliable agents, work efficiency would improve significantly. This is where the ERC8004 protocol comes in.

Hmm, does this sound reasonable? Next, let’s take a look at how ERC8004 is designed based on this logic.

An Analysis of the Protocol’s Specific Design

This section provides an analysis of the protocol’s specific technical design. However, we won’t dive into overly detailed contract interfaces and parameters from the specification itself; instead, we’ll aim to make it as understandable as possible for everyone. For the finer details, readers can refer to the official protocol standard documentation. Based on the protocol’s content, we’ll explain in plain terms how this protocol attempts to solve the problem we outlined above.

Technically speaking, ERC8004 essentially defines interface specifications for three types of contracts:

• Identity Registry: Built on ERC721 (Non-Fungible Tokens, or NFTs), used to register agents — each agent is essentially an NFT, and through this NFT, one can retrieve the agent’s relevant information.
• Reputation Registry.
• Validation Registry.

In simple terms, you can think of these three types of contracts as three kinds of institutions operating on the blockchain.

• Institution One: Agents come here to open an account, just like you’d open a restaurant.
• Institution Two: I’m responsible for collecting ratings for these agents, similar to Dianping and Gaode Street View.
• Institution Three: I’m a third-party investigation agency in charge of verification — like a quality inspection bureau or health department.

🌐 A Concrete Workflow

Let’s use the food delivery example: suppose you want your AI assistant “Xiao A” to order you a meal delivery that doesn’t use gutter oil:

1. Finding a collaborator: “Xiao A” first queries the Identity Registry to find a well-rated food delivery agent “Xiao B” and checks its historical reviews.
2. Establishing initial trust: Next, “Xiao A” checks the Reputation Registry to see how other collaborators have rated “Xiao B” and decides whether to hire it.
3. Execution and Validation: If this meal is critically important, “Xiao A” or you can additionally hire an independent validator “Xiao C” from the Validation Registry. “Xiao C” will verify whether “Xiao B”’s report is accurate and meets the requirements, and publicly disclose the verification result.
4. Settlement and Feedback: You pay “Xiao A” via the x402 protocol (a receipt mechanism that connects on-chain payments with off-chain activities — see our previous article on x402 for more details). “Xiao A” then pays “Xiao B” and “Xiao C.” Finally, you leave positive reviews for the services provided by “Xiao A” and “Xiao B,” and all these payments and actions will either reinforce or affect their respective reputations in the registries.

In summary, ERC-8004 establishes a decentralized and trustworthy collaboration environment for AI assistants through the interplay and coordination of these three contracts, enabling them to freely and securely exchange services and value just as humans do in the marketplace.

Identity Registry

This contract is essentially an NFT contract, including transfer and other functionalities inherent to the ERC721 standard, but it redefines and extends the NFT’s metadata file:

You can see that you originally provided the Agent’s name, image, description, and corresponding endpoint address.

Additionally, it also specifies the registration method register and related events (the ERC721 standard itself does not define a mint method, so this method is considered part of ERC8004).

Reputation Registry

This contract, when initially deployed, requires the NFT contract to be passed in via the constructor, meaning it is uniquely associated with one Identity Registry.

Defines several methods:

• giveFeedback: Allows scoring an NFT in the Identity Registry on a scale of 0–100. (agentId corresponds to the NFT’s TokenID.) Calling this method requires a parameter feedbackAuth, which is a signature signed by the agent when accepting the task.
• revokeFeedback.
• appendResponse: Allows adding supplementary information (with format requirements), such as an off-chain address along with a hash value for verification.
• There are also a series of read methods for retrieving relevant rating information.

The format requirement for supplementary information is:

Validation Registry

Like the Reputation Registry, this registry also requires the contract address of the Identity Registry to be passed in during construction, and it is uniquely associated with one Identity Registry. This contract must be called by the Agent’s Owner (the NFT’s Owner) and provides the following methods:

• validationRequest: Used to request validation.
• validationResponse: Used to respond to validation.

This article will not delve into the specific details further. In essence, ERC-8004 defines three contract standards, enabling us to establish a transparent, decentralized agent evaluation mechanism on-chain, helping agents better find desired collaboration partners and providing a Web3 trust solution for A2A.

Our Practice

Combining the design of ERC-8004, we have built a trustless service on the Pharos and Jovay networks, which assigns agents with “Trusted DIDs” in the web3 world. Additionally, building upon the original foundation, we have extended financial-grade enhanced TEE/ZK verification capabilities, with future support for higher-security verification enhancements tailored to machine-to-machine transactions in financial scenarios.

Future Outlook

It sounds great, but it is also full of challenges — yet challenges are also opportunities. Let’s take a look at what kinds of opportunities the future might hold.

First, although the data is on-chain — transparent and immutable — ensuring that the on-chain data is genuinely truthful and trustworthy remains a problem. Therefore, there may eventually emerge some highly trusted on-chain validators, which in effect represent authoritative institutions behind the scenes. Reliable validators can provide more credible information through various means, such as historical on-chain data. For example, if you use a new account to post fake negative reviews, your credibility would clearly be insufficient.

Following this logic, there are many things that can be built around this protocol:

• You could build a service specifically to provide on-chain support for intelligent agents. For example, I could help you deploy a contract for your agent, and this contract could perform various operations based on this protocol. I could offer such a service through an MCP.
• You could create an on-chain “food street,” where everyone registers their agents with your contract. For example, I open a shop that specializes in fried chicken (AI-powered robot fried chicken, of course!) and register it on this food street. As long as the food street attracts significant traffic, you can charge registration fees — just like ENS (Ethereum Name Service) does today. Haha, in fact, ENS can already be understood as a registry; you’d just need to extend it slightly.
• You could create an on-chain “Black Pearl” (or Michelin-style) restaurant guide, providing ratings and reviews for others — of course, you could charge a small fee for it.

In short, everything that was previously done offline can now be moved on-chain — agents can simply work in the on-chain world from now on.

What do you all think — does it sound credible? At the very least, the author finds it quite interesting.

This article was written by Fisher from the ZAN Team.

About ZAN

As a technology brand of Ant Digital Technologies for Web3 products and services, ZAN provides rich and reliable services for business innovations and a development platform for Web3 endeavors.

The ZAN product family includes ZAN Node Service, ZAN PowerZebra (zk acceleration), ZAN Identity (Know your customers and clients), ZAN Smart Contract Review, with more products in the pipeline.

Contact Us

Website | Twitter | Discord | Telegram

Whether the assets can be recovered depends critically on the type of the receiving address. This article will analyze the different scenarios.

1. Scenario 1: The receiving address is an EOA

An EOA (Externally Owned Account) is what we commonly refer to as a standard wallet address directly controlled by a private key or seed phrase.

Prerequisites for Asset Recovery:

• You transferred the assets to an EOA address.
• You possess the private key or seed phrase for the destination EOA address. (This is typically another one of your own wallet addresses or the address of a friend who is willing to cooperate).
• The destination chain is an EVM-compatible chain.

Recovery Method:

The holder of the private key for the receiving EOA address can simply withdraw the funds on the destination chain.

2. Scenario 2: The receiving address is a contract

This is one of the most devastating scenarios. Unlike EOAs, smart contract addresses are not derived from a private key, so no one possesses a private key to control the contract. Furthermore, if the contract was not written with a rescue function to handle erroneously transferred assets, the funds may be permanently locked within it, irretrievable by anyone.

However, in certain circumstances, there is still a glimmer of hope. Next, we will construct a scenario where ETH gets locked on the Ethereum mainnet and then demonstrate how to rescue the funds.

2.1. Scenario Introduction

In summary, this scenario involves a user who intended to call a contract on the Sepolia testnet, transferring ETH into the contract to mint tokens. However, when initiating the transaction, they were mistakenly connected to the mainnet. This resulted in the ETH being locked in the contract on the mainnet. The specific process for constructing this scenario is as follows:

1. On the Ethereum Sepolia testnet, the project team (an EOA) deployed an implementation contract. Assume the contract’s primary function is for users to deposit ETH to mint corresponding ATokens, with the logic roughly depicted in the mintTokens function. Suppose it is deployed at address A. It is crucial to note that contract A does not contain any function to directly withdraw ETH.

2. On the Ethereum Sepolia testnet, the project team (an EOA) deployed a factory contract. The function of this contract is to deploy a proxy contract that points to an implementation contract using the minimal proxy (Clones) pattern, based on a provided implementation address and salt (as shown in the deployProxyByImplementation function). Assume this factory is deployed at address B. Let's further assume that by calling the deployProxyByImplementation function with the address of implementation contract A passed as _implementation, a proxy contract pointing to A is deployed at address C.

3. The user, intending to mint ATokens on the Sepolia testnet by initiating a call to the proxy contract at address C and transferring in ETH. Normally, proxy contract C would delegate the call to the mintTokens function of implementation contract A to complete the user's operation.

However, the user was mistakenly connected to the Ethereum mainnet when initiating the transaction. As a result, the user transferred ETH directly to address C on the Ethereum mainnet. At this point, no contract was deployed at address C on the mainnet, and no one possesses the private key for this address. The user’s funds were therefore temporarily locked at address C on the mainnet.

2.2. Key Concepts

Before presenting the specific recovery solution, we will first introduce the fundamental concepts required.

2.2.1. CREATE & CREATE2

CREATE and CREATE2 are two common methods for deploying contracts in Solidity.

• CREATE: When a contract is deployed using CREATE, its address is determined by the deployer’s address and that account’s transaction count (nonce). The address is independent of the contract’s content.
• CREATE2: When a contract is deployed using CREATE2, the address calculation no longer depends on the deployer’s nonce. Instead, it is determined by the following four parameters:

2.2.2. Minimal Proxy Contract (Clones)

https://docs.openzeppelin.com/contracts/4.x/api/proxy#clones

A Minimal Proxy Contract, also often called a Clone Contract (Clones), is a pattern whose core idea is to deploy a proxy contract that points to a specified implementation contract at an extremely low Gas cost.

Within a Clones contract, a proxy can be deployed using either CREATE or CREATE2. For instance, deploying a proxy via the cloneDeterministic function utilizes the CREATE2 method.

In the cloneDeterministic function, the bytecode of the created proxy contract is very short, following the format: 0x363d3d373d3d3d363d73<Implementation Address>5af43d82803e903d91602b57fd5bf3. It directly hardcodes the implementation contract's address into the bytecode and uses delegatecall to forward all calls made to the proxy to this implementation contract.

As seen from the cloneDeterministic function, it uses CREATE2 to create the proxy contract. The address of the created proxy depends on the creator's address, the salt, the implementation contract's address, and a fixed string of bytecode. It is independent of the implementation contract's bytecode.

2.3. Rescue Solution

Next, we will explain how to rescue the user’s ETH at mainnet address C. The primary approach is to deploy contract code to address C on the Ethereum mainnet, take control of the address, and extract the ETH. The specific operational steps are as follows:

1. Deploy a factory contract on the mainnet at the same address B as on the testnet. The reason for needing the same factory contract address is that when subsequently deploying the proxy contract via cloneDeterministic, the proxy contract's address calculation is dependent on the factory contract's address. By examining the transaction that deployed the factory contract on the Sepolia testnet, obtain the deployer's (project team's) nonce for that transaction. On the mainnet, advance the project team's (EOA) address nonce to the value it was just before deploying the factory contract. Then, deploy the factory contract on the mainnet. Since both the deployer's address and the nonce are identical to the deployment transaction on the testnet, the factory contract deployed on the mainnet will also have address B.

2. Deploy an implementation contract on the mainnet at the same address A as on the testnet. As mentioned in the #Minimal Proxy Contract (Clones)# section, when deploying a proxy contract using the cloneDeterministic function of a Clones contract, the calculated proxy address depends on the salt and the implementation contract's address, but it is independent of the implementation contract's bytecode. Therefore, we only need to deploy a contract at address A; the specific content of the contract does not affect the calculation of the proxy contract's address. Consequently, we can directly deploy a contract at address A that includes a function to withdraw ETH, with code as shown below.

On the testnet, implementation contract A was deployed by the project team’s address (EOA). Therefore, similarly, the address of implementation contract A depends only on the transaction initiator and its nonce. By observing the transaction that deployed implementation contract A on the testnet, we can find the relevant nonce. We then advance the project team’s address (EOA) nonce on the mainnet to that specific value and deploy implementation contract A.

3. Deploy a proxy contract on the mainnet at the same address C as on the testnet. Observe the transaction that deployed proxy contract C on the testnet to obtain the salt information. Then, call the deployProxyByImplementation function of factory contract B on the mainnet, passing the address of implementation contract A and the salt as parameters. This will deploy the proxy contract at address C on the mainnet.

4. Call the mainnet proxy contract C to withdraw funds. The project team’s address (EOA) calls the withdraw function of proxy contract C, specifying the recipient for the funds. This successfully withdraws the frozen ETH from proxy contract C, which can then be returned to the affected user.

2.4. Conclusion

As this rescue solution demonstrates, the ability to recover funds is contingent upon meeting a highly specific set of conditions simultaneously. For example, the contract deployer’s relevant nonce on the target chain must still be available, and the contract trapping the funds must either already have a withdrawal function or allow for one to be deployed through various means (such as the contract being upgradeable or using a proxy pattern like Clones).

Therefore, it is imperative for everyone to be extremely cautious when transacting and to meticulously double-check every transaction before initiating it. Before interacting with any contract, use ZAN’s AI SCAN vulnerability scanning tool to assess the contract’s security. If an accident does occur and funds become locked, do not panic. Instead, contact a security team promptly to assess whether a rescue is feasible.

This article was written by Cara from the ZAN Team and AntChain OpenLabs.

About ZAN

As a technology brand of Ant Digital Technologies for Web3 products and services, ZAN provides rich and reliable services for business innovations and a development platform for Web3 endeavors.

The ZAN product family includes ZAN Node Service, ZAN PowerZebra (zk acceleration), ZAN Identity (Know your customers and clients), ZAN Smart Contract Review, with more products in the pipeline.

Contact Us

Website | Twitter | Discord | Telegram

Coinbase recently announced a new payment protocol: x402. As x402 was initiated by Coinbase, it naturally supports Base Sepolia by default. It has also added support for the Solana chain, demonstrating that x402 is not bound to any specific blockchain.

To understand the workflow, I created a repository (https://github.com/gin-lsl/x402-solana-demo) containing the complete Server, Client, and Facilitator components. I chose Koa as the base framework to implement a scenario where a client pays with Devnet USDC (a custom token) to access a specific API endpoint provided by the server.

Some explanations

I used the spl-token tool to create the token, visible here:
https://solscan.io/token/9gKBTRXgVTszU31A12oJKKSy6aje8LyoVvNfSimembHo?cluster=devnet

Solana was selected for its developer-friendly environment, offering near-unlimited test tokens for development and testing — no login, social account binding, or mainnet wallet balance required.

Running the Project:

1. Create a .env file with required environment variables.
2. Execute the following commands:

# Run Server (and Facilitator)
pnpm dev

# Run client
pnpm pay:fetch

Code Explanation

The demo consolidates all components for simplicity. Key files:

solana.ts

• Provides a /solana/get-balance endpoint (a "valuable" API requiring payment).
• Acts as the Server, handling business logic (steps 5–8 in the sequence diagram, specifically step 7).
• Allows Web2 developers to integrate Web3 payments without deep blockchain knowledge.

facilitator.ts

• Implements the Facilitator with /supported, /verify, and /settle endpoints for chain support checks, transaction validation, and on-chain settlement.
• Requires a private key to cover transaction fees (steps 9–10 in the diagram).
• Standardized; can use official templates. Adaptation needed for non-Base chains:
• For unsupported chains (e.g., Solana), simulate transactions for verification.
• Uses @solana/kit to send transactions via RPC (sendTransaction) and confirm results (waitForRecentTransactionConfirmation).

x402-middleware.ts

• Koa middleware linking Server and Facilitator.
• Guards paid endpoints, returns HTTP 402, and routes /verify//settle requests.
• Demo simplifications:
• maxAmountRequired set artificially high to avoid client-side validation errors.
• asset uses a custom Devnet token (not x402’s default). On mainnet, this should be official USDC.
• Unlike Express (which overrides Response for an onion model), Koa natively supports the flow: verify → business logic → settle.

payment-client-fetch.ts

• Client role (steps 1–4). Uses x402-fetch helpers to:
• Auto-handle 402 responses.
• Sign transactions with the wallet’s private key.
• Resend requests with the X-PAYMENT header.
• Flow: Direct API call → 402 response → signature generation → retry with signed payload.

Run Commands:

# Run Server
pnpm dev

# Run client
pnpm client

Client logs/output:

> pnpm run --parallel client

server client$ tsx src/payment-client-fetch.ts
server client: [dotenv@17.2.3] injecting env (4) from .env -- tip: 🔄 add secrets lifecycle management: https://dotenvx.com/ops
server client: headers: Headers {
server client:   vary: 'Origin',
server client:   'access-control-allow-origin': '*',
server client:   'content-type': 'application/json; charset=utf-8',
server client:   'content-length': '399',
server client:   date: 'Fri, 31 Oct 2025 16:16:10 GMT',
server client:   connection: 'keep-alive',
server client:   'keep-alive': 'timeout=5'
server client: }
server client: body: {
server client:   "success": true,
server client:   "data": {
server client:     "address": "8dQE449ozUAS2XPyvao6hEpkAtGALo1A1q4TApayFfCo",
server client:     "balance": {
server client:       "lamports": "14095638085",
server client:       "sol": "14.095638085"
server client:     }
server client:   },
server client:   "paymentInfo": {
server client:     "amount": 0.1,
server client:     "currency": "SOL",
server client:     "settled": {
server client:       "success": true,
server client:       "payer": "8jDsKhqYn15fhpMXMFcZJMZVkzDMAVvUgh29y2ws9iJi",
server client:       "transaction": "5GJDV8AugQFJqWJYmgkmUebyYvhcZZNEq3XQ1MunXKamtgFwo7HvdjZFq55FJ77AF1gDXnJ6ogSDx27VWmPeSo5r",
server client:       "network": "solana-devnet"
server client:     }
server client:   }
server client: }
server client: no x-payment-response header, status: 200
server client: Done

Reflections

If earlier Web3 efforts focused on user accessibility (payments, investments), x402 targets Web2 developers by lowering barriers to Web3 payment integration.

While x402/client helpers streamline user payments (e.g., via USDC wallets), the protocol’s greater impact lies in empowering service providers.

Challenges for adoption:

• Enterprises with legacy settlement systems may resist due to integration complexity and regulatory concerns.
• Node RPC providers could leverage x402 to monetize advanced APIs (e.g., transaction acceleration).

Final Note:
x402 is a foundational standard, not a solution. Its value lies in unifying ecosystems around a shared specification. Rational evaluation is crucial — avoid hype traps.

About ZAN

As a technology brand of Ant Digital Technologies for Web3 products and services, ZAN provides rich and reliable services for business innovations and a development platform for Web3 endeavors.

The ZAN product family includes ZAN Node Service, ZAN ZK Acceleration, ZAN Identity (Know your customers and clients), ZAN Smart Contract Review, with more products in the pipeline.

Contact Us

Website | Twitter |Discord | Telegram

Suppose someone has a wallet with 100 BTC (roughly $10 million), but they lost the private key. In theory the bitcoins are still on‑chain — if someone “by chance” generates the exact same private key or address, they could take the funds.

So the question is: can I write a program that frantically generates random addresses, try my luck, and maybe hit a wealthy address?

What is an “address collision”?

Plain explanation

Imagine:

• The world has about 10⁴⁸ lockers (that is, a 1 followed by 48 zeros).
• About 100 million of those lockers contain money.
• You randomly guess a locker number to see if you win.

That’s what a blockchain “address collision” is — randomly generating addresses in hopes of colliding with an address that has a balance.

How are blockchain addresses derived?

Simplified flow:

1. Generate a random number (the private key)
2. Compute the public key from the private key using math
3. Hash the public key to get the address

That’s it — an address is produced.

Try it yourself: 10 lines of code to generate a wallet

Step 1: install the tool

# install ethers.js via npm
npm install ethers

Step 2: write the code

Create a file create-wallet.js：

const { ethers } = require('ethers');

// generate a random wallet
const wallet = ethers.Wallet.createRandom();

console.log('🎉 Congrats! Your new wallet:');
console.log('Address:', wallet.address);
console.log('Private key::', wallet.privateKey);
console.log('\nMnemonic（12 words — remember it!）:');
console.log(wallet.mnemonic.phrase);

Step 3: run it

node create-wallet.js

Sample output:

🎉 Congrats! Your new wallet:
Address: 0x0649472C2c03cFc0841bAd56A51f3c8e7f952F35
Private key: 0x084fdb0de766d3e8e5a164a84bf49f43c170bcacb2944e233e9cfdadd1d48fe7

Mnemonic (12 words — remember it!):
basic zoo front around turkey boy crew hair awake prefer acquire obey

There you go — you’ve generated a wallet address. 🎊

So, can I mass‑generate addresses and try my luck?

Example “address collision” program

You can certainly try! Here’s a loop example.

(First you’ll need to sign up for a ZAN account, enable node services, and get an RPC URL.)

const { ethers } = require('ethers');

console.log('🎰 Starting address collision attempt — good luck!\n');

// connect to Ethereum network (to check balances)
const provider = new ethers.JsonRpcProvider('https://api.zan.top/node/v1/eth/sepolia/YOUR_API_KEY');

let attempts = 0;

async function tryMyLuck() {
  while (true) {
    attempts++;
    
    // generate a random address
    const wallet = ethers.Wallet.createRandom();
    
    // check balance
    try {
      const balance = await provider.getBalance(wallet.address);
      
      if (balance > 0) {
        // 🎉 jackpot!
        console.log('💰💰💰 Jackpot! Found a funded address!');
        console.log('Address:', wallet.address);
        console.log('Balance:', ethers.formatEther(balance), 'ETH');
        console.log('Private key:', wallet.privateKey);
        break;
      } else {
        // still empty...
        if (attempts % 100 === 0) {
          console.log(`Tried ${attempts} times, still going...`);
        }
      }
    } catch (error) {
      console.log('Query error, continuing...');
    }
  }
}

tryMyLuck();

Run result (example)

🎰 Starting address collision attempt — good luck!

Tried 100 times, still going...
Tried 200 times, still going...
Tried 300 times, still going...
Tried 400 times, still going...
Tried 500 times, still going...
...
(You’ll keep seeing this until the heat death of the universe.)

How hard is it? Let’s do the math

Basic data

What does 10^−40 mean?

Let’s make it relatable.

1. Lottery 🎫

Winning the Double‑Color Ball jackpot:        1/17,721,088     (about 1 in 10 million)
Colliding with a blockchain address:    1/10^40          (1 in 10^40)

Difficulty gap:            10^32 times harder

Another analogy: If winning the lottery is like “randomly picking the right person in all of China,” then an address collision is like “randomly picking a specific atom in the entire universe correctly 40 times in a row.”

Gacha game 🎴
Suppose the SSR drop rate is 0.6% (0.006). Address collision is roughly equivalent to pulling 18 SSRs in a row at that rate — essentially impossible.

2. Everyday probabilities 🌍

Why so hard? The math principle

Huge address space

An Ethereum address looks like:

0x742d35Cc6634C0532925a3b844Bc9e7595f0bEb

Without the 0x it’s 40 hexadecimal characters, i.e., 160 bits.

Number of possible combinations:

2^160 = 1,461,501,637,330,902,918,203,684,832,716,283,019,655,932,542,976

If you tried to read it aloud it would come out roughly like: ‘one thousand four hundred and sixty‑one … unfathomable five thousand…’ (this already exceeds the conventional Chinese number‑naming scale).

Real‑world cases

Has anyone ever succeeded? 🤔

From Bitcoin’s birth in 2009 to today:

• Zero successes by random collision — nobody has gained funds by purely random address collision.
• Zero private‑key brute‑force cracks — no one has mathematically brute‑forced a private key.

So how are wallets stolen?

All reported wallet thefts are due to:

Key point: thefts are caused by human error, not mathematics being broken.

Should I still worry about security?

Mathematically: you’re safe ✅

As long as:

• Your private key is truly randomly generated (don’t use weak keys like 1234567890 )
• You don’t leak your private key

Mathematically, no one can crack your wallet.

In practice: watch out for these ⚠️

Although address collisions are essentially impossible, you should still be careful:

❌ What NOT to do

// ❌ Create a wallet from a weak private key
const wallet = new ethers.Wallet('0x0000000000000000000000000000000000000000000000000000000000000001');

// ❌ Screenshot private keys
// ❌ Paste them into cloud notes
// ❌ Send them over WeChat / email
// ❌ Tell anyone your mnemonic
// ❌ Use example mnemonics from tutorials

✅ What TO do:

// ✅ Use the library’s random generator
const wallet = ethers.Wallet.createRandom();

// ✅ Write the mnemonic on paper
// ✅ Store it in a safe or safety deposit box
// ✅ Keep multiple offline backups in different places
// ✅ Use a hardware wallet for large balances

Quick summary

Key takeaways

1. Generating addresses is trivial — a few lines of code generate countless addresses.
2. Address collision is astronomically hard — ~10³² times harder than winning the lottery.
3. Math is secure — from 2009 to now, nobody has succeeded by collision.
4. Humans are the weakest link — all known thefts result from leaked keys or scams, not broken cryptography.

One‑line conclusion

Instead of wasting time trying to collide addresses, go buy a lottery ticket; instead of that, get a job. 😄

For those who really want to try address collisions

If you insist:

const { ethers } = require('ethers');

console.log('Address collision difficulty comparison:');
console.log('');
console.log('Lottery jackpot probability:     1 / 10,000,000');
console.log('Address collision probability:     1 / 10,000,000,000,000,000,000,000,000,000,000,000,000,000');
console.log('');
console.log('Recommendations:');
console.log('1. f you have that compute power, mine instead');
console.log('2. If you have that time, do honest work instead');
console.log('3. If you have that luck, buy a lottery ticket');
console.log('4. If you really want to try, I won’t stop you 🤷');

Appendix: full address‑collision simulator

Want to experience “waiting forever”? Here’s a full version:

const { ethers } = require('ethers');

console.log('🎰 lockchain Address Collision Simulator v1.0\n');
console.log('⚠️ Warning: this program could run until the heat death of the universe\n');

const provider = new ethers.JsonRpcProvider('https://api.zan.top/node/v1/eth/sepolia/YOUR_API_KEY');

let attempts = 0;
let startTime = Date.now();

async function bruteForce() {
  console.log('🚀 Starting address collision attempt...\n');
  
  while (true) {
    attempts++;
    
    // generate a random wallet
    const wallet = ethers.Wallet.createRandom();
    
    // query balance every 1000 attempts (too frequent calls will be rate‑limited)
    if (attempts % 1000 === 0) {
      try {
        const balance = await provider.getBalance(wallet.address);
        
        if (balance > 0n) {
          console.log('💰💰💰 Wow! Jackpot!💰💰💰');
          console.log('Address:', wallet.address);
          console.log('Balance:', ethers.formatEther(balance), 'ETH');
          console.log('Private key:', wallet.privateKey);
          console.log('Mnemonic:', wallet.mnemonic.phrase);
          console.log('\n🎉 Go buy a lottery ticket! Your luck is insane!');
          break;
        }
      } catch (error) {
        // on query failure, continue
      }
      
      // show progress
      const elapsed = (Date.now() - startTime) / 1000;
      const speed = attempts / elapsed;
      const remainingAttempts = 1e40;
      const remainingYears = (remainingAttempts / speed) / (365.25 * 24 * 3600);
      
      console.log(`Attempts: ${attempts.toLocaleString()}`);
      console.log(`Elapsed: ${elapsed.toFixed(1)} s`);
      console.log(`Speed: ${speed.toFixed(0)} attempts/s`);
      console.log(`Estimated remaining: ${remainingYears.toExponential(2)} years`);
      console.log(`Progress: ${(attempts / 1e40 * 100).toExponential(2)}%`);
      console.log('---');
    }
  }
}

bruteForce().catch(console.error);

Final notes

Remember these three rules:

1. Generating addresses is easy — a few lines of code do it.
2. Address collisions are virtually impossible — astronomically less likely than lotteries.
3. Protect your private key — that’s the only real security risk.

⚠️ Important reminder ⚠️

Never use example mnemonics or private keys from online tutorials!

Never tell anyone your private key!

Never tell anyone your private key!

Never tell anyone your private key!

(Important things, said three times.)

This article was written by KenLee from the ZAN Team.

About ZAN

As a technology brand of Ant Digital Technologies for Web3 products and services, ZAN provides rich and reliable services for business innovations and a development platform for Web3 endeavors.

The ZAN product family includes ZAN Node Service, ZAN ZK Acceleration, ZAN Identity (Know your customers and clients), ZAN Smart Contract Review, with more products in the pipeline.

Contact Us

Website | Twitter |Discord | Telegram

After thinking about it, deploying pages on the blockchain may have the following benefits:

1. Decentralization: All changes require the joint consent of everyone, and no single organization has the final say.
2. No certificate required: Because the blockchain itself uses encryption technology, no additional certificate configuration is required.

I have seen the domain name scheme on TON before, and I thought it was just fun and not very practical at the time, after all, the traditional access method is already very stable and commonly used. But now I think it may really be useful, so I plan to study it more carefully.

Creating a website on the blockchain

This article will try to deploy a website in TON and allow users to access this page in the browser. The process is divided into three steps: 1. Purchase a domain name; 2. Prepare the front-end page; 3. Bind the page to the domain name.

The concepts of domain names in the blockchain and in the WEB2 world are actually similar. They are both aliases for a complex and difficult-to-remember address. In the blockchain, they represent the user’s address, and in the WEB2 world, they represent the IP address of the service.

Buy a domain

Taking TON as an example, the official purchase address of domain names is https://dns.ton.org/, and the price is calculated in TON. Just like WEB2, the shorter the characters, the more expensive the domain name, ranging from 1 to 100 TON.

If the domain name is not owned by anyone, you can bid at a low price, and after the bid, a countdown will begin. During the countdown, everyone can bid until the countdown ends. After the domain name is auctioned, the domain name will be stored in the user’s wallet in the form of NFT. Domain name NFT can be traded. The domain name is valid for 1 year and will be reclaimed after expiration.

To sum up, you can purchase a domain name through an auction on the official website, or you can trade it from other users.

Prepare the front-end page

In this step, you need to prepare a front-end page for display. For simplicity, this article only prepares an HTML file and nginx to expose the page. Of course, the project also needs a cloud server to run the front-end page. This step is the same as traditional front-end application deployment.

Bind the page to .ton

After you have a .ton domain name, you can bind your ANDL address on the TON DNS official website. Of course, you can also use the binding tool provided by TON and follow the instructions on the official website to bind your page.

After the binding is completed, you also need to start a listening port on the server to listen for http requests and forward them to udp. You can use the official rldp-http-proxy tool here and start it by entering the following command:

rldp-http-proxy/rldp-http-proxy -p 8080 -c 3333 -C global.config.json

Where 8080 is the TCP port that will listen for incoming HTTP queries on localhost, and 3333 is the UDP port that will be used for all outbound and inbound RLDP and ADNL activity (i.e. connecting to the TON website through the TON network). global.config.json is the file name of the TON global configuration, which can be downloaded here.

Visit .ton domains

Trying to access a website by typing the .ton domain name directly in the browser will not work, because the browser does not know where to resolve the domain name. So some additional operations are required here.

The process of requesting .ton

When requesting a .ton domain name, the corresponding ANDL address will be queried on the chain first. This address can be simply understood as the IP address in WEB2, which will be automatically generated when you deploy the website. This query process can also be compared to the DNS query process.

Then, according to the ANDL address, the request will be forwarded to your corresponding machine, and you can specify the corresponding return page. The overall process is quite similar to WEB2, the main difference is that the query method of address and domain name mapping is different.

Accessing the page through a proxy

The most recommended way is to use the proxy tool Tonutils Reverse Proxy provided by the official website. After downloading and installing it, a port 8080 will be started for proxy, and then you can access the .ton domain name.

You can see the websites that can access .ton domain names.

Usage Summary

At present, the following problems have been encountered:

1. There are requirements for the environment in which the website runs. Your system needs to support glibc version 2.34 or above, so before deploying the page, check whether your machine meets the requirements.
2. The documentation is not very clear. It may be because there is not much demand for TON to run the website, so the documentation is not very complete and you need to explore it yourself. In addition, the Chinese version is not updated in a timely manner and lags behind the English version.
3. The access speed is slow. The access speed lags behind that of traditional websites. Of course, there are many factors involved, and we can only say that there is a lot of room for improvement in the future.
4. Not supported by wallets. The official website provides a simple embedded browser page, which you can choose to access without installing a proxy. However, this website is currently identified as a phishing website by all mainstream wallets o.0.

All in all, the current experience is actually average, and there are still many areas that can be improved in the future, but I think this direction is very good and innovative, and it’s worth a try.

This article was written by YeezoGao from the ZAN Team.

About ZAN

As a technology brand of Ant Digital Technologies for Web3 products and services, ZAN provides rich and reliable services for business innovations and a development platform for Web3 endeavors.

The ZAN product family includes ZAN Node Service, ZAN PowerZebra (zk acceleration), ZAN Identity (Know your customers and clients), ZAN Smart Contract Review, with more products in the pipeline.

Contact Us

Website | Twitter | Discord | Telegram

Zoom image will be displayed