40 posts tagged with "web3"

Launching a protocol or scaling an on-chain product is no longer just a technical exercise. Regulators are scrutinizing everything from token launches to wallet privacy, while users expect consumer-grade protections. To keep shipping with confidence, every founding team needs a structured way to translate dense legal memos into product decisions. Drawing from 50 of the most common questions web3 lawyers hear, this playbook breaks the conversation into builder-ready moves.

1. Formation & Governance: Separate the Devco, the Foundation, and the Community​

• Pick the right wrapper. Standard C-corps or LLCs still handle payroll, IP, and investor diligence best. If you plan to steward a protocol or grant program, a separate non-profit or foundation keeps incentives clean and governance transparent.
• Paper every relationship. Use IP assignments, confidentiality agreements, and vesting schedules with clear cliffs, lockups, and bad-actor clawbacks. Document board approvals and keep token cap tables as tight as your equity ledgers.
• Draw bright lines between entities. A development company can build under license, but budget, treasury policy, and decision rights should sit with a foundation or DAO that has its own charter and constitution. Where a DAO needs legal personality, wrap it in an LLC or equivalent.

2. Tokens & Securities: Design for Utility, Document the Rationale​

• Assume regulators look past labels. “Governance” or “utility” tags only matter if users actually interact with a live network, buy for consumption, and are not pitched profit upside. Lockups can reduce speculation but should be justified as stability or anti-sybil safeguards.
• Differentiate access from investment. Access tokens should read like product passes—pricing, docs, and marketing must reinforce entitlement to services, not future profits. Stablecoins trigger their own payments or e-money regimes depending on reserves and redemption rights.
• Treat staking and yields like financial products. Any promise of APRs, pooling, or reliance on the team’s efforts raises securities risk. Keep marketing plain, share risk factors, and map a compliant SAFT-to-mainnet plan if you raise with future tokens.
• Remember NFTs can be securities. Fractionalized ownership, revenue shares, or profit language tips them into investment territory. Lean, consumptive NFTs with explicit licenses are safer.

3. Fundraising & Sales: Market the Network, Not the Moonshot​

• Disclose like a grown-up. Purpose, functionality, vesting, allocations, transfer limits, dependencies, and use of proceeds belong in every sale memo. Keep marketing copy aligned with those docs—no “guaranteed yield” tweets.
• Respect jurisdictional lines. If you cannot comply with U.S. or other high-friction regimes, layer geofencing with eligibility checks, contractual restrictions, and post-sale monitoring. KYC/AML is standard for sales and increasingly for airdrops.
• Manage promotion risk. Influencer campaigns need clear sponsorship disclosures and compliant scripts. Exchange listings or market-making deals demand written agreements, conflict checks, and honest communications to venues.

4. AML, Tax, and IP: Build Controls Into the Product​

• Know your regulatory role. Non-custodial software faces lighter AML obligations, but once you touch fiat ramps, custody, or intermediated exchange, money-transmitter or VASP rules apply. Prepare sanctions screening, escalation paths, and travel-rule readiness where relevant.
• Treat tokens like cash for accounting. Token inflows are typically income at fair market value; sales later trigger gains or losses. Compensation grants often create taxable income at vesting—use written grants, track basis, and prepare for volatility.
• Respect IP boundaries. Pair NFTs and on-chain content with explicit licenses, honor third-party open-source terms, and register trademarks. If you are training AI models, confirm dataset rights and scrub sensitive data.

5. Privacy & Data: Limit Collection, Plan for Deletion​

• Assume wallet addresses are personal data. Combine them with IPs, device IDs, or emails and you have personal identifiable information. Collect only what you need, store off-chain when possible, and hash or tokenize identifiers.
• Engineer for erasure. Immutable ledgers do not excuse you from privacy laws—keep PII off-chain, remove references when users request deletion, and sever links that could re-identify hashed data.
• Be transparent about telemetry. Cookie banners, analytics disclosures, and opt-outs are table stakes. Document an incident response plan that covers severity levels, notification timelines, and contact points.

6. Operations & Risk: Audit Early, Communicate Often​

• Audit and disclose. Independent smart-contract audits, formal verification where warranted, and an ongoing bug bounty signal maturity. Publish reports and explain residual risks plainly.
• Set clear Terms of Service. Spell out custody status, eligibility, prohibited uses, dispute resolution, and how you handle forks. Align ToS, privacy policy, and in-product behavior.
• Plan for forks, insurance, and cross-border growth. Reserve rights to choose supported chains, snapshot dates, and migration paths. Explore cyber, crime, D&O, and tech E&O coverage. When operating globally, localize terms, vet export controls, and use EOR/PEO partners to avoid misclassification.
• Prepare for disputes. Decide in advance whether arbitration or class-action waivers fit your user base. Log law-enforcement requests, verify legal process, and explain technical limits like the absence of key custody.

7. The Builder’s Action Checklist​

• Map your operational role: software vendor, custodian, broker-like service, or payments intermediary.
• Keep marketing factual and functionality-focused; avoid language that implies speculative returns.
• Minimize custody and personal data collection; document any unavoidable touchpoints.
• Maintain living docs for token allocation, governance design, audit status, and risk decisions.
• Budget for legal counsel, compliance tooling, audits, bug bounties, and tax expertise from day one.

8. Turning Legal Advice Into Product Velocity​

Regulation will not slow down for builders. What changes outcomes is embedding legal considerations into backlog grooming, treasury management, and user communications. Make counsel part of sprint reviews, rehearse incident response, and iterate on disclosures the same way you iterate on UX. Do that, and the 50 FAQs above stop being a blocker and start becoming a competitive moat for your protocol.

Most apps still anchor identity to usernames, passwords, and centralized databases. That model is fragile (breaches), leaky (data resale), and clunky (endless KYC repeats). The new stack emerging around decentralized identifiers (DIDs), verifiable credentials (VCs), and attestations points to a different future: users carry cryptographic proof of facts about themselves and reveal only what’s needed—no more, no less.

This post distills the landscape and offers a practical blueprint you can ship with today.

---

The Shift: From Accounts to Credentials​

The core of this new identity stack is built on two foundational W3C standards that fundamentally change how we handle user data.

• Decentralized Identifiers (DIDs): These are user-controlled identifiers that don’t require a central registry like a domain name system. Think of a DID as a permanent, self-owned address for identity. A DID resolves to a signed “DID document” containing public keys and service endpoints, allowing for secure, decentralized authentication. The v1.0 standard became an official W3C Recommendation on July 19, 2022, marking a major milestone for the ecosystem.
• Verifiable Credentials (VCs): This is a tamper-evident, digital format for expressing claims, like "age is over 18," "holds a diploma from University X," or "has passed a KYC check." The VC Data Model 2.0 became a W3C Recommendation on May 15, 2025, locking in a modern foundation for how these credentials are issued and verified.

What changes for developers? The shift is profound. Instead of storing sensitive personally identifiable information (PII) in your database, you verify cryptographic proofs supplied by the user’s wallet. You can request only the specific piece of information you need (e.g., residency in a specific country) without seeing the underlying document, thanks to powerful primitives like selective disclosure.

---

Where It Meets the Logins You Already Use​

This new world doesn't require abandoning familiar login experiences. Instead, it complements them.

• Passkeys / WebAuthn: This is your go-to for phishing-resistant authentication. Passkeys are FIDO credentials bound to a device or biometric (like Face ID or a fingerprint), and they are now widely supported across all major browsers and operating systems. They offer a seamless, passwordless login experience for your app or wallet.
• Sign-In with Ethereum (SIWE / EIP-4361): This standard lets a user prove control of a blockchain address and link it to an application session. It works via a simple, signed, nonce-based message, creating a clean bridge between traditional Web2 sessions and Web3 control.

The best practice is to use them together: implement passkeys for mainstream, everyday sign-in and offer SIWE for wallet-linked flows where a user needs to authorize a crypto-native action.

---

The Rails for Issuing and Checking Credentials​

For credentials to be useful, we need standardized ways to issue them to users and for users to present them to apps. The OpenID Foundation provides the two key protocols for this.

• Issuance: OpenID for Verifiable Credential Issuance (OID4VCI) defines an OAuth-protected API for getting credentials from issuers (like a government agency or a KYC provider) into a user's digital wallet. It’s designed to be flexible, supporting multiple credential formats.
• Presentation: OpenID for Verifiable Presentations (OID4VP) standardizes how your application makes a "proof request" and how a user's wallet responds to it. This can happen over classic OAuth redirects or through modern browser APIs.

When building, you’ll encounter a few key credential formats designed for different ecosystems and use cases:

• W3C VC with Data Integrity Suites (JSON-LD): Often paired with BBS+ cryptography to enable powerful selective disclosure.
• VC-JOSE-COSE and SD-JWT VC (IETF): These formats are built for JWT and CBOR-based ecosystems, also featuring strong selective disclosure capabilities.

Fortunately, interoperability is improving rapidly. Profiles like OpenID4VC High Assurance are helping to narrow the technical options, making cross-vendor integrations much saner for developers.

---

DID Methods: Picking the Right Address Scheme​

A DID is just an identifier; a "DID method" specifies how it's anchored to a root of trust. You’ll want to support a couple of common ones.

• did:web: This method backs a DID with a domain you control. It’s incredibly easy to deploy and is a fantastic choice for enterprises, issuers, and organizations who want to leverage their existing web infrastructure as a trust anchor.
• did:pkh: This method derives a DID directly from a blockchain address (e.g., an Ethereum address). This is highly useful when your user base already has crypto wallets and you want to link their identity to on-chain assets.

Rule of thumb: Support at least two methods—did:web for organizations and did:pkh for individual users. Use a standard DID resolver library to handle the lookup, and consult official registries to evaluate the security, persistence, and governance of any new method you consider adding.

---

Useful Building Blocks You Can Plug In​

Beyond the core standards, several tools can enhance your identity stack.

• ENS (Ethereum Name Service): Provides human-readable names (yourname.eth) that can map to blockchain addresses and DIDs. This is an invaluable tool for improving user experience, reducing errors, and providing a simple profile layer.
• Attestations: These are flexible, verifiable "facts about anything" that can be recorded on-chain or off-chain. The Ethereum Attestation Service (EAS), for example, provides a robust substrate for building reputation and trust graphs without ever storing PII on a public ledger.

---

Compliance Tailwinds You Should Track​

Regulation is often seen as a hurdle, but in this space, it’s a massive accelerator. The EU Digital Identity Framework (eIDAS 2.0), officially adopted as Regulation EU 2024/1183 on May 20, 2024, is the most significant development. It mandates that all EU Member States offer citizens a free EU Digital Identity Wallet (EUDI). With implementing regulations published on May 7, 2025, this is a powerful signal for the adoption of wallet-based credentials across both public and private services in Europe.

Even if you don't operate in the EU, expect the EUDI Wallet and its underlying protocols to shape user expectations and drive wallet adoption globally.

---

Design Patterns That Work in Production (2025)​

• Passwordless First, Wallets Optional: Default to passkeys for sign-in. It's secure, simple, and familiar. Only introduce SIWE when users need to perform a crypto-linked action like minting an NFT or receiving a payout.
• Ask for Proofs, Not Documents: Replace clunky document uploads with a crisp VC proof request using OID4VP. Instead of asking for a driver's license, ask for a proof of "age over 18" or "country of residence is X." Accept credentials that support selective disclosure, like those using BBS+ or SD-JWT.
• Keep PII Off Your Servers: When a user proves something, record an attestation or a short-lived verification result, not the raw credential itself. On-chain attestations are a powerful way to create an auditable record—"User Y passed KYC with Issuer Z on date D"—without storing any personal data.
• Let Orgs Be Issuers with did:web: Businesses, universities, and other organizations already control their domains. Let them sign credentials as issuers using did:web, allowing them to manage their cryptographic keys under their existing web governance models.
• Use ENS for Names, Not Identity: Treat ENS as a user-friendly handle and profile pointer. It's great for UX, but keep the authoritative identity claims within credentials and attestations.

---

A Starter Architecture​

Here’s a blueprint for a modern, credential-based identity system:

• Authentication
  • Default Login: Passkeys (FIDO/WebAuthn).
  • Crypto-Linked Sessions: Sign-In with Ethereum (SIWE) for wallet-based actions.
• Credentials
  • Issuance: Integrate with OID4VCI endpoints from your chosen issuers (e.g., a KYC provider, a university).
  • Presentation: Trigger OID4VP proof requests from your web or native app. Be prepared to accept both W3C VCs (with BBS+) and SD-JWT VCs.
• Resolution & Trust
  • DID Resolver: Use a library that supports at least did:web and did:pkh. Maintain an allowlist of trusted issuer DIDs to prevent spoofing.
• Attestations & Reputation
  • Durable Records: When you need an auditable signal of a verification, mint an attestation containing a hash, the issuer's DID, and a timestamp, rather than storing the claim itself.
• Storage & Privacy
  • Minimalism: Drastically minimize the PII you store server-side. Encrypt everything at rest and set strict time-to-live (TTL) policies. Prefer ephemeral proofs and lean heavily on zero-knowledge or selective disclosure.

---

UX Lessons Learned​

• Start Invisible: For most users, the best wallet is the one they don’t have to think about. Use passkeys to handle sign-in seamlessly and only surface wallet interactions contextually when they are absolutely necessary.
• Progressive Disclosure: Don't ask for everything at once. Request the smallest possible proof that unblocks the user's immediate goal. With selective disclosure, you don't need their full document to verify one fact.
• Key Recovery Matters: A credential bound to a single device key is a liability. Plan for re-issuance and cross-device portability from day one. This is a key reason modern profiles are adopting formats like SD-JWT VC and claims-based holder binding.
• Human-Readable Handles Help: An ENS name is far less intimidating than a long hexadecimal address. It reduces user error and adds a layer of recognizable context, even if the true authority lives in the underlying credentials.

---

What to Ship Next Quarter: A Pragmatic Roadmap​

• Weeks 1–2:
  • Add passkeys for your primary sign-in flow.
  • Gate all crypto-native actions behind a SIWE check.
• Weeks 3–6:
  • Pilot a simple age or region gate using an OID4VP request.
  • Accept VC 2.0 credentials with selective disclosure (BBS+ or SD-JWT VC).
  • Start creating attestations for "verification passed" events instead of logging PII.
• Weeks 7–10:
  • Onboard a partner issuer (e.g., your KYC provider) using did:web and implement a DID allowlist.
  • Offer ENS name linking in user profiles to improve address UX.
• Weeks 11–12:
  • Threat-model your presentation and revocation flows. Add telemetry for common failure modes (expired credential, untrusted issuer).
  • Publish a clear privacy posture explaining exactly what you ask for, why, how long you retain it, and how users can audit it.

---

What’s Changing Fast (Keep an Eye on This)​

• EU EUDI Wallet Rollouts: The implementation and conformance testing of these wallets will massively shape capabilities and verification UX across the globe.
• OpenID4VC Profiles: Interoperability between issuers, wallets, and verifiers is constantly improving thanks to new profiles and test suites.
• Selective Disclosure Cryptosuites: Libraries and developer guidance for both BBS+ and SD-JWT VC are rapidly maturing, making them easier to implement.

---

Principles to Build By​

• Prove, Don’t Store: Default to verifying claims over storing raw PII.
• Interoperate by Default: Support multiple credential formats and DID methods from day one to future-proof your stack.
• Minimize & Disclose: Ask for the smallest possible claim. Be transparent with users about what you are checking and why.
• Make Recovery Boring: Plan for device loss and issuer rotation. Avoid brittle key-binding that strands users.

If you’re building fintech, social, or creator platforms, credential-first identity isn’t a future bet anymore—it’s the shortest path to lower risk, smoother onboarding, and global interoperability.

Public blockchains give every participant a synchronized, auditable ledger—but they also expose every piece of data by default. Seal, now live on Sui Mainnet as of September 3, 2025, addresses this by pairing on-chain policy logic with decentralized key management so that Web3 builders can decide exactly who gets to decrypt which payloads.

TL;DR​

• What it is: Seal is a secrets-management network that lets Sui smart contracts enforce decryption policies on-chain while clients encrypt data with identity-based encryption (IBE) and rely on threshold key servers for key derivation.
• Why it matters: Instead of custom backends or opaque off-chain scripts, privacy and access control become first-class Move primitives. Builders can store ciphertexts anywhere—Walrus is the natural companion—but still gate who can read.
• Who benefits: Teams shipping token-gated media, time-locked reveals, private messaging, or policy-aware AI agents can plug into Seal’s SDK and focus on product logic, not bespoke crypto plumbing.

Policy Logic Lives in Move​

Seal packages come with seal_approve* Move functions that define who can request keys for a given identity string and under which conditions. Policies can mix NFT ownership, allowlists, time locks, or custom role systems. When a user or agent asks to decrypt, key servers evaluate these policies via Sui full-node state and only approve if the chain agrees.

Because the access rules are part of your on-chain package, they are transparent, auditable, and versionable alongside the rest of your smart contract code. Governance updates can be rolled out like any other Move upgrade, with community review and on-chain history.

Threshold Cryptography Handles the Keys​

Seal encrypts data to application-defined identities. A committee of independent key servers—chosen by the developer—shares the IBE master secret. When a policy check passes, each server derives a key share for the requested identity. Once a quorum of t servers responds, the client combines the shares into a usable decryption key.

You get to set the trade-off between liveness and confidentiality by picking committee members (Ruby Nodes, NodeInfra, Overclock, Studio Mirai, H2O Nodes, Triton One, or Mysten’s Enoki service) and selecting the threshold. Need stronger availability? Choose a larger committee with a lower threshold. Want higher privacy assurances? Tighten the quorum and lean on permissioned providers.

Developer Experience: SDKs and Session Keys​

Seal ships a TypeScript SDK (npm i @mysten/seal) that handles encrypt/decrypt flows, identity formatting, and batching. It also issues session keys so wallets are not constantly spammed with prompts when an app needs repeated access. For advanced workflows, Move contracts can request on-chain decryption via specialized modes, allowing logic like escrow reveals or MEV-resistant auctions to run directly in smart contract code.

Because Seal is storage-agnostic, teams can pair it with Walrus for verifiable blob storage, with IPFS, or even with centralized stores when that fits operational realities. The encryption boundary—and its policy enforcement—travels with the data regardless of where the ciphertext lives.

Designing with Seal: Best Practices​

• Model availability risk: Thresholds such as 2-of-3 or 3-of-5 map directly to uptime guarantees. Production deployments should mix providers, monitor telemetry, and negotiate SLAs before entrusting critical workflows.
• Be mindful of state variance: Policy evaluation depends on full nodes performing dry_run calls. Avoid rules that hinge on rapidly changing counters or intra-checkpoint ordering to prevent inconsistent approvals across servers.
• Plan for key hygiene: Derived keys live on the client. Instrument logging, rotate session keys, and consider envelope encryption—use Seal to protect a symmetric key that encrypts the larger payload—to limit blast radius if a device is compromised.
• Architect for rotation: A ciphertext’s committee is fixed at encryption time. Build upgrade paths that re-encrypt data through new committees when you need to swap providers or adjust trust assumptions.

What Comes Next​

Seal’s roadmap points toward validator-operated MPC servers, DRM-style client tooling, and post-quantum KEM options. For builders exploring AI agents, premium content, or regulated data flows, today’s release already provides a clear blueprint: encode your policy in Move, compose a diverse key committee, and deliver encrypted experiences that respect user privacy without leaving Sui’s trust boundary.

If you are considering Seal for your next launch, start by prototyping a simple NFT-gated policy with a 2-of-3 open committee, then iterate toward the provider mix and operational controls that match your app’s risk profile.

TL;DR​

Cross-chain abstraction turns a maze of chains, bridges, and wallets into a single, coherent platform experience for both developers and end users. The ecosystem has quietly matured: intent standards, account abstraction, native stablecoin mobility, and network-level initiatives like the OP Superchain and Polygon's AggLayer make a "many chains, one experience" future realistic in 2025. For enterprises, the win is pragmatic: simpler integrations, enforceable risk controls, deterministic operations, and compliance-ready auditability—without betting the farm on any single chain.

---

The Problem Enterprises Actually Have (and Why Bridges Alone Didn’t Fix It)​

Most enterprise teams don’t want to “pick a chain.” They want outcomes: settle a payment, issue an asset, clear a trade, or update a record—reliably, auditably, and at a predictable cost. The trouble is that production Web3 today is irredeemably multichain. Hundreds of rollups, appchains, and L2s have launched over the past 18 months alone, each with its own fees, finality times, tooling, and trust assumptions.

Traditional cross-chain approaches solved transport—moving tokens or messages from A to B—but not the experience. Teams are still forced to manage wallets per network, provision gas per chain, pick a bridge per route, and shoulder security differences they can’t easily quantify. That friction is the real adoption tax.

Cross-chain abstraction removes that tax by hiding chain selection and transport behind declarative APIs, intent-driven user experiences, and unified identity and gas. In other words, users and applications express what they want; the platform determines how and where it happens, safely. Chain abstraction makes blockchain technology invisible to end users while preserving its core benefits.

Why 2025 is Different: The Building Blocks Finally Clicked​

The vision of a seamless multi-chain world isn't new, but the foundational technology is finally ready for production. Several key components have matured and converged, making robust chain abstraction possible.

• Network-Level Unification: Projects are now building frameworks to make separate chains feel like a single, unified network. The OP Superchain aims to standardize OP-Stack L2s with shared tooling and communication layers. Polygon's AggLayer aggregates many ZK-secured chains with "pessimistic proofs" for chain-level accounting, preventing one chain’s issues from contaminating others. Meanwhile, IBC v2 is expanding standardized interoperability beyond the Cosmos ecosystem, pushing toward "IBC everywhere."

• Mature Interop Rails: The middleware for cross-chain communication is now battle-tested and widely available. Chainlink CCIP offers enterprise-grade token and data transfer across a growing number of chains. LayerZero v2 provides omnichain messaging and standardized OFT tokens with a unified supply. Axelar delivers General Message Passing (GMP) for complex contract calls across ecosystems, connecting EVM and Cosmos chains. Platforms like Hyperlane enable permissionless deployments, allowing new chains to join the network without gatekeepers, while Wormhole offers a generalized messaging layer used across more than 40 chains.

• Intent & Account Abstraction: The user experience has been transformed by two critical standards. ERC-7683 standardizes cross-chain intents, allowing apps to declare goals and let a shared solver network execute them efficiently across chains. Concurrently, EIP-4337 smart accounts, combined with Paymasters, enable gas abstraction. This allows an application to sponsor transaction fees or let users pay in stablecoins, which is essential for any flow that might touch multiple networks.

• Native Stablecoin Mobility: Circle’s Cross-Chain Transfer Protocol (CCTP) moves native USDC across chains via a secure burn-and-mint process, reducing wrapped-asset risk and unifying liquidity. The latest version, CCTP v2, further cuts latency and simplifies developer workflows, making stablecoin settlement a seamless part of the abstracted experience.

What “Cross-Chain Abstraction” Looks Like in an Enterprise Stack​

Think of it as a layered capability you can add to existing systems. The goal is to have a single endpoint to express an intent and a single policy plane to govern how it executes across any number of chains.

1. Unified Identity & Policy: At the top layer are smart accounts (EIP-4337) with role-based access controls, social recovery, and modern custody options like passkeys or MPC. This is governed by a central policy engine that defines who can do what, where, using allow- and deny-lists for specific chains, assets, and bridges.

2. Gas & Fee Abstraction: Paymasters remove the "I need native gas on chain X" headache. Users or services can pay fees in stablecoins, or the application can sponsor them entirely, subject to predefined policies and budgets.

3. Intent-Driven Execution: Users express outcomes, not transactions. For example, "swap USDC for wETH and deliver it to our supplier's wallet on chain Y before 5 p.m." The ERC-7683 standard defines the format for these orders, allowing shared solver networks to compete to execute them safely and cheaply.

4. Programmable Settlement & Messaging: Under the hood, the system uses a consistent API to select the right rail for each route. It might use CCIP for a token transfer where enterprise support is key, Axelar GMP for a cross-ecosystem contract call, or IBC where native light-client security fits the risk model.

5. Observability & Compliance by Default: The entire workflow is traceable, from the initial intent to the final settlement. This produces clear audit trails and allows data to be exported to existing SIEMs. Risk frameworks can be programmed to enforce allowlists or trigger emergency brakes, for instance, by pausing routes if a bridge’s security posture degrades.

A Reference Architecture​

From the top down, a chain-abstracted system is composed of clear layers:

• Experience Layer: Application surfaces that collect user intents and completely hide chain details, paired with SSO-style smart account wallet flows.
• Control Plane: A policy engine for managing permissions, quotas, and budgets. This plane integrates with KMS/HSM systems and maintains allowlists for chains, assets, and bridges. It also ingests risk feeds to circuit-break vulnerable routes automatically.
• Execution Layer: An intent router that selects the best interop rail (CCIP, LayerZero, Axelar, etc.) based on policy, price, and latency requirements. A Paymaster handles fees, drawing from a treasury of pooled gas and stablecoin budgets.
• Settlement & State: Canonical on-chain contracts for core functions like custody and issuance. A unified indexer tracks cross-chain events and proofs, exporting data to a warehouse or SIEM for analysis and compliance.

Build vs. Buy: How to Evaluate Providers of Chain Abstraction​

When selecting a partner to provide chain abstraction capabilities, enterprises should ask several key questions:

• Security & Trust Model: What are the underlying verification assumptions? Does the system rely on oracles, guardian sets, light clients, or validator networks? What can be slashed or vetoed?
• Coverage & Neutrality: Which chains and assets are supported today? How quickly can new ones be added? Is the process permissionless or gated by the provider?
• Standards Alignment: Does the platform support key standards like ERC-7683, EIP-4337, OFT, IBC, and CCIP?
• Operations: What are the provider’s SLAs? How transparent are they about incidents? Do they offer replayable proofs, deterministic retries, and structured audit logs?
• Governance & Portability: Can you switch interop rails per route without rewriting your application? Vendor-neutral abstractions are critical for long-term flexibility.
• Compliance: What controls are available for data retention and residency? What is their SOC2/ISO posture? Can you bring your own KMS/HSM?

A Pragmatic 90-Day Enterprise Rollout​

• Days 0–15: Baseline & Policy: Inventory all chains, assets, bridges, and wallets currently in use. Define an initial allowlist and establish circuit-break rules based on a clear risk framework.
• Days 16–45: Prototype: Convert a single user journey, such as a cross-chain payout, to use an intent-based flow with account abstraction and a paymaster. Measure the impact on user drop-off, latency, and support load.
• Days 46–75: Expand Rails: Add a second interoperability rail to the system and route transactions dynamically based on policy. Integrate CCTP for native USDC mobility if stablecoins are part of the workflow.
• Days 76–90: Harden: Wire the platform’s observability data to your SIEM, run chaos tests on route failures, and document all operating procedures, including emergency pause protocols.

Common Pitfalls (and How to Avoid Them)​

• Routing by "Gas Price Only": Latency, finality, and security assumptions matter as much as fees. Price alone is not a complete risk model.
• Ignoring Gas: If your experience touches multiple chains, gas abstraction isn't optional—it's table stakes for a usable product.
• Treating Bridges as Interchangeable: They aren’t. Their security assumptions differ significantly. Codify allowlists and implement circuit breakers to manage this risk.
• Wrapped-Asset Sprawl: Whenever possible, prefer native asset mobility (like USDC via CCTP) to minimize liquidity fragmentation and reduce counterparty risk.

The Enterprise Upside​

When chain abstraction is done well, blockchain stops being a collection of idiosyncratic networks and becomes an execution fabric your teams can program against. It offers policies, SLAs, and audit trails that match the standards you already operate under. Thanks to mature intent standards, account abstraction, robust interop rails, and native stablecoin transport, you can finally deliver Web3 outcomes without forcing users—or your own developers—to care about which chain did the work.

The concept of transitioning from today's dominant "Magnificent 7" tech giants to a new generation of digital asset leaders represents one of the most significant investment theses in modern finance. While the specific "MAG7 to DAG7" terminology does not appear in publicly available materials, Alex Tapscott—Managing Director of Ninepoint Partners' Digital Asset Group and blockchain thought leader—has extensively articulated a vision for how Web3 technologies will force "leaders of the old paradigm to make way for the Web3 champions of tomorrow." This transition from centralized platform monopolies to decentralized protocol economies defines the next era of market dominance.

Understanding the MAG7 era and its limitations​

The Magnificent 7 consists of Apple, Microsoft, Google/Alphabet, Amazon, Meta, Nvidia, and Tesla—tech behemoths that collectively represent over $10 trillion in market capitalization and have dominated equity markets for the past decade. These companies epitomize the Web2 era's "read-write web," where users generate content but platforms extract value.

Tapscott identifies fundamental problems with this model that create opportunity for disruption. Web2 giants became "gatekeepers, enacting barriers and imposing tolls on everything we do," transforming users into products through surveillance capitalism. 45% of financial intermediaries suffer economic crime annually compared to 37% economy-wide, while regulatory costs continue climbing and billions remain excluded from the financial system. The MAG7 captured value through centralization, network effects that locked in users, and business models based on data extraction rather than value distribution.

What tomorrow's champions look like according to Tapscott​

Tapscott's investment framework centers on the transition from Web2's "read-write" model to Web3's "read-write-own" paradigm. This isn't merely technological evolution—it represents a fundamental restructuring of how value accrues in digital ecosystems. As he stated when launching Ninepoint's Web3 Innovators Fund in May 2023: "There will be winners and losers as leaders of the old paradigm are forced to make way for the Web3 champions of tomorrow."

The defining characteristic of future champions is ownership distribution rather than ownership concentration. "Web3 turns internet users into internet owners—they can earn ownership stakes in products and services by holding tokens," Tapscott explains. This extends Silicon Valley's practice of sharing equity with employees globally to anyone using Web3 applications. The next generation of dominant companies will paradoxically capture more value by giving ownership to users, creating network effects through aligned incentives rather than platform lock-in.

The four pillars of next-generation dominance​

Tapscott identifies four core principles that define tomorrow's champions, each representing a direct inversion of Web2's extractive model:

Ownership: Digital assets serve as containers for value, enabling property rights in the digital realm. Early Compound and Uniswap users received governance tokens for participation, transforming users into stakeholders. Future leaders will enable users to monetize their contributions rather than platforms monetizing user data.

Commerce: A new economic layer enabling peer-to-peer value transfer without intermediaries. DeFi protocols disintermediate traditional finance while tokenization brings real-world assets on-chain. Winners will remove middlemen and reduce friction rather than inserting themselves as essential intermediaries.

Identity: Self-sovereign identity returns data control to individuals, breaking free from platform lock-in. Privacy-preserving authentication replaces surveillance-based models. Champions will solve identity problems without centralized control.

Governance: Decentralized autonomous organizations distribute decision-making power through token-based voting, aligning stakeholder interests. Future winners won't maximize shareholder value at user expense—they'll align all stakeholder incentives through tokenomics.

Tapscott's investment framework for identifying champions​

The nine digital asset categories​

Tapscott's taxonomy from "Digital Asset Revolution" provides a comprehensive map of where value will accrue:

Cryptocurrencies like Bitcoin serve as digital gold and base settlement layers. Bitcoin's $1+ trillion market cap and "unrivalled" role as "mother of all cryptocurrencies" makes it foundational infrastructure.

Protocol tokens (Ethereum, Solana, Cosmos, Avalanche) represent the "fat protocols" that capture value from application layers. Tapscott emphasizes these as primary infrastructure investments, noting Ethereum's role powering DeFi and NFTs while alternatives like Solana offer "perfect crypto project" scalability.

Governance tokens (Uniswap, Aave, Compound, Yearn Finance) enable community ownership of protocols. Uniswap, which Tapscott calls "one of the best" DAOs, frequently exceeds Coinbase's volume while distributing governance to users—demonstrating the power of decentralized coordination.

Stablecoins represent potentially the most significant near-term disruption. With $130+ billion in USDT and growing markets for USDC and PYUSD, stablecoins transform payment infrastructure. Tapscott views them as SWIFT replacements enabling financial inclusion globally—particularly critical in crisis economies experiencing hyperinflation.

NFTs and gaming assets enable creator economics and digital ownership. Beyond speculation, creators earned $1.8+ billion in royalties on Ethereum while 300+ projects generated $1 million+ each—demonstrating real utility in directly connecting creators with consumers.

Securities tokens, natural asset tokens (carbon credits), exchange tokens, and CBDCs round out the taxonomy, each representing digitization of traditional value storage.

The three-category investment approach​

Tapscott structures portfolio construction around three complementary exposure types through Ninepoint's strategy:

Platform exposure: Direct investment in smart contract platforms and protocols—the foundational infrastructure layer. This includes Bitcoin, Ethereum, Solana, Cosmos, and Avalanche, which serve as the rails enabling all other applications.

Pure-play Web3 businesses: Companies staking their entire existence on blockchain technology. Examples include Circle (USDC stablecoin issuer planning public offering), Animoca Brands (building infrastructure for 700+ million users), and DeFi protocols like Uniswap and Aave.

Beneficiaries and adopters: Traditional enterprises integrating Web3 to transform their business models. PayPal's PYUSD stablecoin launch represents "a big leap forward" that "probably won't be the last," while companies like Nike and Microsoft lead enterprise adoption. These bridge TradFi and DeFi, bringing institutional legitimacy.

Specific companies and sectors Tapscott highlights​

Layer 1 protocols as foundational bets​

CMCC Global's early investments reveal Tapscott's conviction in infrastructure dominance. Solana at $0.20 and Cosmos at $0.10 represent concentrated bets on specific technological approaches—Solana's blazing speed and minimal fees versus Cosmos's "internet of blockchains" enabling interoperability through IBC protocol.

Ethereum remains foundational as the dominant smart contract platform with unmatched developer ecosystems and network effects. Avalanche joins the portfolio for its tokenized real-world asset focus. The multi-chain thesis recognizes that smart contract platforms must interoperate seamlessly for DeFi and Web3 to reach full potential, rejecting winner-take-all dynamics.

DeFi as accelerant to financial revolution​

"If Bitcoin was the spark for the financial services revolution, then DeFi and digital assets are the accelerant," Tapscott explains. He identifies nine functions DeFi will transform: storing value, moving value, lending value, funding and investing, exchanging value, insuring value, analyzing value, accounting/auditing, and identity authentication.

Uniswap exemplifies the power of decentralized coordination, frequently exceeding centralized exchange volumes while distributing governance to token holders. Its $11 billion market cap demonstrates value capture by protocols that eliminate intermediaries.

Aave and Compound pioneered decentralized lending with flash loans and algorithmic interest rates, removing banks from capital allocation. Yearn Finance aggregates yield across protocols, demonstrating how DeFi protocols compose like Lego blocks.

Osmosis in the Cosmos ecosystem innovated superfluid staking and reached $15+ billion TVL, showing non-EVM chains' viability. The total DeFi ecosystem's $75+ billion TVL and growing demonstrates this isn't speculation—it's infrastructure replacing traditional finance.

Consumer applications and mass adoption wave​

Animoca Brands represents CMCC Global's largest investment to date—a $42 million commitment across multiple rounds signaling conviction that consumer-facing applications drive the next wave. With 450+ portfolio companies and 700+ million addressable users, Animoca's ecosystem (The Sandbox, Axie Infinity, Mocaverse) creates infrastructure for Web3 gaming and digital ownership.

Gaming serves as Web3's killer application because ownership mechanics naturally align with gameplay. Players earning income through play-to-earn models, true asset ownership enabling cross-game interoperability, and creator economies where developers capture value directly—these represent genuine utility beyond financial speculation.

Payment infrastructure transformation​

Circle's USDC stablecoin with $20 billion supply represents "essential infrastructure" as an "innovative financial technology firm" planning public offering. PayPal's PYUSD launch marked traditional finance's embrace of blockchain rails, with Tapscott noting this represents probably not "the last company" to adopt crypto payments.

Stablecoins projected to reach $200 billion markets solve real problems: cross-border payments without SWIFT delays, dollar access for unbanked populations, and programmable money enabling smart contract automation. Venezuela's LocalBitcoins volume surge during hyperinflation demonstrates why "bitcoin matters"—providing financial access when traditional systems fail.

Comparing MAG7 dominance with Web3 champion characteristics​

The fundamental difference between eras lies in value capture mechanisms and stakeholder alignment:

Web2 (MAG7) characteristics: Centralized platforms treating users as products, winner-take-all economics through network effects and lock-in, gatekeepers controlling access and extracting rents, platforms capturing all value while contributors receive fixed compensation, surveillance capitalism monetizing user data.

Web3 (tomorrow's champions) characteristics: Decentralized protocols where users become owners through token holdings, multi-polar ecosystems with interoperable protocols, permissionless innovation without gatekeepers, community value capture through token appreciation, ownership economy where contributors participate in upside.

The shift represents moving from companies that maximize shareholder value at user expense to protocols that align all stakeholder incentives. Tomorrow's dominant "companies" will look less like companies and more like protocols with governance tokens—they won't be companies in the traditional sense but rather decentralized networks with distributed ownership.

As Tapscott articulates: "Over the next decade, this digital asset class will expand exponentially, engulfing traditional financial instruments like stocks, bonds, land titles and fiat currency." The tokenization of everything means ownership stakes in protocols could eclipse traditional equities in importance.

Methodologies and frameworks for evaluation​

Technological differentiation as primary filter​

Tapscott emphasizes that "value will be captured through finding early stage investment opportunities with technological differentiation" rather than market timing or narrative-driven investing. This requires rigorous technical assessment: evaluating codebases and architecture, consensus mechanisms and security models, tokenomics design and incentive alignment, interoperability capabilities and composability.

The focus on infrastructure over applications in early stages reflects conviction that foundational protocols accrue disproportionate value. "Fat protocols" capture value from all applications built atop them, unlike Web2 where applications captured value while protocols remained commodities.

Network effects and developer ecosystems​

Leading indicators for future dominance include developer activity (commits, documentation quality, hackathon participation), active addresses and transaction volumes, total value locked in DeFi protocols, governance participation rates, and cross-chain integrations.

Developer ecosystems particularly matter because they create compounding advantages. Ethereum's massive developer base creates network effects making it increasingly difficult to displace despite technical limitations, while emerging platforms compete through superior technology or specific use case optimization.

Bear market building philosophy​

"Bear markets provide the opportunity for the industry to focus on building," Tapscott emphasizes. "Crypto winters are always the best time to drill down on these core concepts, do the work and build for the future." The last bear market brought NFTs, DeFi protocols, stablecoins, and play-to-earn gaming—innovations that defined the next bull cycle.

Investment strategy centers on multi-year holding periods focused on protocol development milestones rather than short-term volatility. "The most successful people in crypto are those who can keep calm and carry on," ignoring daily price gyrations to focus on fundamentals.

Portfolio construction emphasizes concentration—15-20 core positions with high conviction rather than broad diversification. Early-stage focus means accepting illiquidity in exchange for asymmetric upside, with CMCC Global's $0.20 Solana and $0.10 Cosmos investments demonstrating this approach's power.

Differentiating hype from real opportunity​

Tapscott employs rigorous frameworks to separate genuine innovation from speculation:

Problems blockchain solves: Does the protocol address real pain points (fraud, fees, delays, exclusion) rather than solutions seeking problems? Does it reduce friction and costs measurably? Does it expand access to underserved markets?

Adoption metrics over speculation: Focus on usage rather than price—transaction volumes, active wallets, developer commits, enterprise partnerships, regulatory clarity progress. "Look beyond the daily market gyrations, and you'll see that innovators are laying the foundations for a new Internet and financial services industry."

Historical context method: Comparing blockchain to early internet (1993) suggests technologies in infrastructure phase appear overhyped short-term but transformative long-term. "A decade from now, you'll wonder how society ever functioned without it, even though most of us barely know what it is today."

Regulatory navigation and institutional bridges​

Future champions will work with regulators rather than against them, building compliance into architecture from inception. Tapscott's approach through regulated entities (Ninepoint Partners, CMCC Global's Hong Kong SFC licenses) reflects lessons from NextBlock Global's regulatory challenges.

Professional investor focus and proper custody solutions (insured Bitcoin funds, State Street administration) bring institutional credibility. The convergence of TradFi and DeFi requires champions who can operate in both worlds—protocols sophisticated enough for institutions yet accessible for retail users.

Enterprise adoption indicators Tapscott highlights include 42+ major financial institutions exploring blockchain, consortiums like Goldman Sachs and JPMorgan's blockchain initiatives, tokenized treasury adoption, and Bitcoin ETF launches bringing regulated exposure.

The path forward: sectors defining tomorrow​

Tapscott identifies several mega-trends that will produce the next generation of trillion-dollar protocols:

Tokenization infrastructure enabling digitization of real estate, equities, commodities, carbon credits, and intellectual property. "This digital asset class will expand exponentially, engulfing traditional financial instruments" as friction disappears from capital formation and trading.

DeFi 2.0 combining best aspects of centralized finance (speed, user experience) with decentralization (self-custody, transparency). Examples like Rails building hybrid exchanges on Kraken's Ink L2 show this convergence accelerating.

Bitcoin as productive asset through innovations like Babylon protocol enabling staking, using BTC as DeFi collateral, and institutional treasury strategies. This evolution from pure store of value to yield-generating asset expands Bitcoin's utility.

Web3 identity and privacy through zero-knowledge proofs enabling verification without revelation, self-sovereign identity returning data control to individuals, and decentralized reputation systems replacing platform-dependent profiles.

Real-world asset tokenization represents perhaps the largest opportunity, with projections of $10+ trillion RWA markets by 2030. Protocols like OpenTrade building institutional-grade infrastructure demonstrate early infrastructure emerging.

The nine-function DeFi transformation​

Tapscott's framework for analyzing DeFi's disruption potential spans all financial services functions, with specific protocol examples demonstrating viability:

Storing value through non-custodial wallets (MakerDAO model) versus bank deposits. Moving value via cross-border stablecoins versus SWIFT networks. Lending value peer-to-peer (Aave, Compound) versus bank intermediation. Funding and investing through DeFi aggregators (Yearn, Rariable) disrupting robo-advisors. Exchanging value on DEXs (Uniswap, Osmosis) versus centralized exchanges.

Insuring value through decentralized insurance protocols versus traditional carriers. Analyzing value via on-chain analytics providing unprecedented transparency. Accounting/auditing through transparent ledgers providing real-time verification. Identity authentication through self-sovereign solutions versus centralized databases.

Each function represents trillion-dollar markets in traditional finance ripe for decentralized alternatives that eliminate intermediaries, reduce costs, increase transparency, and expand global access.

Key takeaways: identifying and investing in tomorrow's champions​

While Alex Tapscott has not publicly articulated a specific "DAG7" framework, his comprehensive investment thesis provides clear criteria for identifying next-generation market leaders:

Infrastructure dominance: Tomorrow's champions will be Layer 1 protocols and critical middleware enabling the Internet of Value—companies like Solana, Cosmos, and Ethereum building foundational rails.

Ownership economics: Winners will distribute value to stakeholders through tokens rather than extracting rents, creating aligned incentives between platforms and users that Web2 giants never achieved.

Real utility beyond speculation: Focus on protocols solving genuine problems with measurable metrics—transaction volumes, developer activity, TVL, active users—rather than narrative-driven speculation.

Interoperability and composability: Multi-chain future requires protocols that communicate seamlessly, with winners enabling cross-ecosystem value transfer and application composability.

Regulatory sophistication: Champions will navigate complex global regulatory environments through proactive engagement, building compliance into architecture while maintaining decentralization principles.

Patient capital with conviction: Early-stage infrastructure investments require multi-year time horizons and willingness to endure volatility for asymmetric returns, with concentration in highest-conviction opportunities.

The transition from MAG7 to tomorrow's champions represents more than sector rotation—it marks a fundamental restructuring of value capture in digital economies. Where centralized platforms once dominated through network effects and data extraction, decentralized protocols will accrue value by distributing ownership and aligning incentives. As Tapscott concludes: "The blockchain will create winners and losers. While opportunities abound, the risks of disruption and dislocation must not be ignored." The question isn't whether this transition occurs, but which protocols emerge as the defining infrastructure of the ownership economy.

Alchemy is a dominant force in the Web3 infrastructure space, serving as the entry point for thousands of developers and major projects like OpenSea. By analyzing public user feedback from platforms like G2, Reddit, and GitHub, we can gain a clear picture of what developers value, where they struggle, and what the future of Web3 development experience could look like. This isn't just about one provider; it's a reflection of the entire ecosystem's maturing needs.

What Users Consistently Like​

Across review sites and forums, users consistently praise Alchemy for several key strengths that have cemented its market position.

• Effortless "On-ramp" & Ease of Use: Beginners and small teams celebrate how quickly they can get started. G2 reviews frequently highlight it as a "great platform to build Web3," praising its easy configuration and comprehensive documentation. It successfully abstracts away the complexity of running a node.
• Centralized Dashboard & Tooling: Developers value having a single "command center" for observability. The ability to monitor request logs, view analytics, set up alerts, and rotate API keys in one dashboard is a significant user experience win.
• Intelligent SDK Defaults: The Alchemy SDK handles request retries and exponential backoff by default. This small but crucial feature saves developers from writing boilerplate logic and lowers the friction of building resilient applications.
• Reputation for Strong Support: In the often-complex world of blockchain development, responsive support is a major differentiator. Aggregate review sites like TrustRadius frequently cite Alchemy's helpful support team as a key benefit.
• Social Proof and Trust: By showcasing case studies with giants like OpenSea and securing strong partner endorsements, Alchemy provides reassurance to teams who are choosing a managed RPC provider.

The Main Pain Points​

Despite the positives, developers run into recurring challenges, especially as their applications begin to scale. These pain points reveal critical opportunities for improvement.

• The "Invisible Wall" of Throughput Limits: The most common frustration is hitting 429 Too Many Requests errors. Developers encounter these when forking mainnet for testing, deploying in bursts, or serving a handful of simultaneous users. This creates confusion, especially on paid tiers, as users feel throttled during critical spikes. The impact is broken CI/CD pipelines and flaky tests, forcing developers to manually implement sleep commands or backoff logic.
• Perception of Low Concurrency: On forums like Reddit, a common anecdote is that lower-tier plans can only handle a few concurrent users before rate limiting kicks in. Whether this is strictly accurate or workload-dependent, the perception drives teams to consider more complex multi-provider setups or upgrade sooner than expected.
• Timeouts on Heavy Queries: Intensive JSON-RPC calls, particularly eth_getLogs, can lead to timeouts or 500 errors. This not only disrupts the client-side experience but can crash local development tools like Foundry and Anvil, leading to lost productivity.
• SDK and Provider Confusion: Newcomers often face a learning curve regarding the scope of a node provider. For instance, questions on Stack Overflow show confusion when eth_sendTransaction fails, not realizing that providers like Alchemy don't hold private keys. Opaque errors from misconfigured API keys or URLs also present a hurdle for those new to the ecosystem.
• Data Privacy and Centralization Concerns: A vocal subset of developers expresses a preference for self-hosted or privacy-focused RPCs. They cite concerns about large, centralized providers logging IP addresses and potentially censoring transactions, highlighting that trust and transparency are paramount.
• Product Breadth and Roadmap: Comparative reviews on G2 sometimes suggest that competitors are expanding faster into new ecosystems or that Alchemy is "busy focused on a couple chains." This can create an expectation mismatch for teams building on non-EVM chains.

Where Developer Expectations Break​

These pain points often surface at predictable moments in the development lifecycle:

1. Prototype to Testnet: A project that works perfectly on a developer's machine suddenly fails in a CI/CD environment when tests run in parallel, hitting throughput limits.
2. Local Forking: Developers using Hardhat or Foundry to fork mainnet for realistic testing are often the first to report 429 errors and timeouts from mass data queries.
3. NFT/Data APIs at Scale: Minting events or loading data for large NFT collections can easily overwhelm default rate limits, forcing developers to search for best practices on caching and batching.

Uncovering the Core "Jobs-to-be-Done"​

Distilling this feedback reveals three fundamental needs of Web3 developers:

• "Give me a single pane of glass to observe and debug." This job is well-served by Alchemy's dashboard.
• "Make my bursty workloads predictable and manageable." Developers accept limits but need smoother handling of spikes, better defaults, and code-level scaffolds that work out-of-the-box.
• "Help me stay unblocked during incidents." When things go wrong, developers need clear status updates, actionable post-mortems, and easy-to-implement failover patterns.

Actionable Opportunities for a Better DX​

Based on this analysis, any infrastructure provider could enhance its offering by tackling these opportunities:

• Proactive "Throughput Coach": An in-dashboard or CLI tool that simulates a planned workload, predicts when CU/s (Compute Units per second) limits might be hit, and auto-generates correctly configured retry/backoff snippets for popular libraries like ethers.js, viem, Hardhat, and Foundry.
• Golden-Path Templates: Provide ready-made, production-grade templates for common pain points, such as a Hardhat network config for forking mainnet with conservative concurrency, or sample code for efficiently batching eth_getLogs calls with pagination.
• Adaptive Burst Capacity: Offer "burst credits" or an elastic capacity model on paid tiers to better handle short-term spikes in traffic. This would directly address the feeling of being unnecessarily constrained.
• Official Multi-Provider Failover Guides: Acknowledge that resilient dApps use multiple RPCs. Providing opinionated recipes and sample code for failing over to a backup provider would build trust and align with real-world best practices.
• Radical Transparency: Directly address privacy and censorship concerns with clear, accessible documentation on data retention policies, what is logged, and any filtering that occurs.
• Actionable Incident Reports: Go beyond a simple status page. When an incident occurs (like the EU region latency on Aug 5-6, 2025), pair it with a short Root Cause Analysis (RCA) and concrete advice, such as "what you can do now to mitigate."

Conclusion: A Roadmap for Web3 Infrastructure​

The user feedback on Alchemy provides a valuable roadmap for the entire Web3 infrastructure space. While the platform excels at simplifying the onboarding experience, the challenges users face with scaling, predictability, and transparency point to the next frontier of developer experience.

As the industry matures, the winning platforms will be those that not only provide reliable access but also empower developers with the tools and guidance to build resilient, scalable, and trustworthy applications from day one.

QuickNode stands as a pillar in the Web3 infrastructure landscape, praised for its speed and extensive multi-chain support. To understand what makes it a go-to choice for so many developers—and where the experience can be improved—we synthesized a wide range of public user feedback from platforms like G2, Reddit, Product Hunt, and Trustpilot.

This analysis reveals a clear story: while developers love the core product, the user journey is not without its hurdles, particularly when it comes to cost.

---

The Highs: What Users Love About QuickNode​

Across the board, users celebrate QuickNode for delivering a premium, frictionless developer experience built on three core strengths.

🚀 Blazing-Fast Performance & Rock-Solid Reliability​

This is QuickNode's most lauded feature. Users consistently describe the service as "blazing fast" and "the most performant and reliable RPC provider out there." Low-latency responses, often under 100ms, and a claimed 99.99% uptime give developers the confidence to build and scale responsive dApps.

As one enterprise client from Nansen noted, QuickNode provides “robust, low-latency, high-performance nodes” capable of handling billions of requests. This performance isn't just a number; it's a critical feature that ensures a smooth end-user experience.

✅ Effortless Onboarding & Intuitive UI​

Developers are often "up and running within minutes." The platform is frequently praised for its clean dashboard and intuitive workflows that abstract away the complexities of running a node.

One developer on Reddit called the interface a "no-brainer," while a full-stack dev highlighted that “signing up and provisioning a node takes minutes without any complex DevOps work.” This ease of use makes QuickNode an invaluable tool for rapid prototyping and testing.

🤝 Top-Tier Customer Support & Documentation​

Exceptional support and documentation are consistent themes. The support team is described as “quick to respond and genuinely helpful,” a crucial asset when troubleshooting time-sensitive issues.

The API documentation receives universal praise for being clear, thorough, and beginner-friendly, with one user calling the tutorials "well-crafted." This investment in developer resources significantly lowers the barrier to entry and reduces integration friction.

---

The Hurdles: Where Users Face Challenges​

Despite the stellar performance and user experience, two key areas of friction emerge from user feedback, primarily centered around cost and feature limitations.

💸 The Pricing Predicament​

Pricing is, by far, the most common and emotionally charged point of criticism. The feedback reveals a tale of two user bases:

• For Enterprises, the cost is often seen as a fair trade for premium performance and reliability.
• For Startups and Indie Developers, the model can be prohibitive.

The core issues are:

1. Steep Jumps Between Tiers: Users note a “significant jump from the $49 ‘Build’ plan to the $249 ‘Accelerate’ plan,” wishing for an intermediate tier that better supports growing projects.
2. Punitive Overage Fees: This is the most significant pain point. QuickNode’s policy of automatically charging for another full block of requests after exceeding a quota—with no option to cap usage—is a source of major frustration. One user described how an "inadvertent excess of just 1 million requests can incur an additional $50." This unpredictability led a long-time customer on Trustpilot to call the service “the biggest scam…stay away” after accumulating high fees.

As one G2 reviewer summarized perfectly, “the pricing structure could be more startup-friendly.”

🧩 Niche Feature Gaps​

While QuickNode's feature set is robust, advanced users have pointed out a few gaps. Common requests include:

• Broader Protocol Support: Users have expressed a desire for chains like Bitcoin and newer L2s like Starknet.
• More Powerful Tooling: Some developers contrasted QuickNode with competitors, noting it had "missing features like more powerful webhook support."
• Modern Authentication: A long-term user wished for OAuth support for better API key management in enterprise environments.

These gaps don't detract from the core offering for most users, but they highlight areas where competitors may have an edge for specific use cases.

---

Key Takeaways for the Web3 Infra Space​

The feedback on QuickNode offers valuable lessons for any company building tools for developers.

• Performance is Table Stakes: Speed and reliability are the foundation. Without them, nothing else matters. QuickNode sets a high bar here.
• Developer Experience is the Differentiator: A clean UI, fast onboarding, excellent docs, and responsive support build a loyal following and create a product that developers genuinely enjoy using.
• Pricing Predictability Builds Trust: This is the most critical lesson. Ambiguous or punitive pricing models, especially those with uncapped overages, create anxiety and destroy trust. A developer who gets a surprise bill is unlikely to remain a long-term, happy customer. Predictable, transparent, and startup-friendly pricing is a massive competitive advantage.

Conclusion​

QuickNode has rightfully earned its reputation as a top-tier infrastructure provider. It delivers on its promise of high performance, exceptional reliability, and a stellar developer experience. However, its pricing model creates significant friction, particularly for the startups and independent developers who are the lifeblood of Web3 innovation.

This user feedback serves as a powerful reminder that building a successful platform isn't just about technical excellence; it's about aligning your business model with the needs and trust of your users. The infrastructure provider that can match QuickNode's performance while offering a more transparent and predictable pricing structure will be incredibly well-positioned for the future.

Here's a consolidated summary of the report on Web3 Developer Experience (DevEx) innovations.

Executive Summary​

The Web3 developer experience has significantly advanced in 2024-2025, driven by innovations in programming languages, toolchains, and deployment infrastructure. Developers are reporting higher productivity and satisfaction due to faster tools, safer languages, and streamlined workflows. This summary consolidates findings on five key toolchains (Solidity, Move, Sway, Foundry, and Cairo 1.0) and two major trends: “one-click” rollup deployment and smart contract hot-reloading.

---

Comparison of Web3 Developer Toolchains​

Each toolchain offers distinct advantages, catering to different ecosystems and development philosophies.

• Solidity (EVM): Remains the most dominant language due to its massive ecosystem, extensive libraries (e.g., OpenZeppelin), and mature frameworks like Hardhat and Foundry. While it lacks native features like macros, its widespread adoption and strong community support make it the default choice for Ethereum and most EVM-compatible L2s.
• Move (Aptos/Sui): Prioritizes safety and formal verification. Its resource-based model and the Move Prover tool help prevent common bugs like reentrancy by design. This makes it ideal for high-security financial applications, though its ecosystem is smaller and centered on the Aptos and Sui blockchains.
• Sway (FuelVM): Designed for maximum developer productivity by allowing developers to write contracts, scripts, and tests in a single Rust-like language. It leverages the high-throughput, UTXO-based architecture of the Fuel Virtual Machine, making it a powerful choice for performance-intensive applications on the Fuel network.
• Foundry (EVM Toolkit): A transformative toolkit for Solidity that has revolutionized EVM development. It offers extremely fast compilation and testing, allowing developers to write tests directly in Solidity. Features like fuzz testing, mainnet forking, and "cheatcodes" have made it the primary choice for over half of Ethereum developers.
• Cairo 1.0 (Starknet): Represents a major DevEx improvement for the Starknet ecosystem. The transition to a high-level, Rust-inspired syntax and modern tooling (like the Scarb package manager and Starknet Foundry) has made developing for ZK-rollups significantly faster and more intuitive. While some tools like debuggers are still maturing, developer satisfaction has soared.

---

Key DevEx Innovations​

Two major trends are changing how developers build and deploy decentralized applications.

"One-Click" Rollup Deployment​

Launching a custom blockchain (L2/appchain) has become radically simpler.

• Foundation: Frameworks like Optimism’s OP Stack provide a modular, open-source blueprint for building rollups.
• Platforms: Services like Caldera and Conduit have created Rollup-as-a-Service (RaaS) platforms. They offer web dashboards that allow developers to deploy a customized mainnet or testnet rollup in minutes, with minimal blockchain engineering expertise.
• Impact: This enables rapid experimentation, lowers the barrier to creating app-specific chains, and simplifies DevOps, allowing teams to focus on their application instead of infrastructure.

Hot-Reloading for Smart Contracts​

This innovation brings the instant feedback loop of modern web development to the blockchain space.

• Concept: Tools like Scaffold-ETH 2 automate the development cycle. When a developer saves a change to a smart contract, the tool automatically recompiles, redeploys to a local network, and updates the front-end to reflect the new logic.
• Impact: Hot-reloading eliminates repetitive manual steps and dramatically shortens the iteration loop. This makes the development process more engaging, lowers the learning curve for new developers, and encourages frequent testing, leading to higher-quality code.

Conclusion​

The Web3 development landscape is maturing at a rapid pace. The convergence of safer languages, faster tooling like Foundry, and simplified infrastructure deployment via RaaS platforms is closing the gap between blockchain and traditional software development. These DevEx improvements are as critical as protocol-level innovations, as they empower developers to build more complex and secure applications faster. This, in turn, fuels the growth and adoption of the entire blockchain ecosystem.

Sources:

• Solidity Developer Survey 2024 – Soliditylang (2025)
• Moncayo Labs on Aptos Move vs Solidity (2024)
• Aptos Move Prover intro – Monethic (2025)
• Fuel Labs – Fuel & Sway Documentation (2024); Fuel Book (2024)
• Spearmanrigoberto – Foundry vs Hardhat (2023)
• Medium (Rosario Borgesi) – Building Dapps with Scaffold-ETH 2 (2024)
• Starknet/Cairo developer survey – Cairo-lang.org (2024)
• Starknet Dev Updates – Starknet.io (2024–2025)
• Solidity forum – Macro preprocessor discussion (2023)
• Optimism OP Stack overview – CoinDesk (2025)
• Caldera rollup platform overview – Medium (2024)
• Conduit platform recap – Conduit Blog (2025)
• Blockchain DevEx literature review – arXiv (2025)

Introduction​

The rapid growth of Layer-1 and Layer-2 blockchains has fragmented the Web3 user experience. Users today juggle multiple wallets, networks, and token bridges just to accomplish complex tasks that span chains. Chain abstraction and intent-centric architecture have emerged as key paradigms to simplify this landscape. By abstracting away chain-specific details and allowing users to act on intents (desired outcomes) rather than crafting explicit per-chain transactions, these approaches promise a unified, seamless cross-chain experience. This report delves into the core principles of chain abstraction, the design of intent-focused execution models, real-world implementations (such as Wormhole and Etherspot), technical underpinnings (relayers, smart wallets, etc.), and the UX benefits for developers and end-users. We also summarize insights from EthCC 2025 – where chain abstraction and intents were hot topics – and provide a comparative table of different protocol approaches.

Principles of Chain Abstraction​

Chain abstraction refers to any technology or framework that presents multiple blockchains to users and developers as if they were a single unified environment. The motivation is to eliminate the friction caused by chain heterogeneity. In practice, chain abstraction means:

• Unified Interfaces: Instead of managing separate wallets and RPC endpoints for each blockchain, users interact through one interface that hides network details. Developers can build dApps without deploying separate contracts on every chain or writing custom bridge logic for each network.
• No Manual Bridging: Moving assets or data between chains happens behind the scenes. Users do not manually execute lock/mint bridge transactions or swap for bridge tokens; the abstraction layer handles it automatically. For example, a user could provide liquidity on a protocol regardless of which chain the liquidity resides on, and the system will route funds appropriately.
• Gas Fee Abstraction: Users no longer need to hold each chain’s native token to pay for gas on that chain. The abstraction layer can sponsor gas fees or allow gas to be paid in an asset of the user’s choice. This lowers the barrier for entry since one does not have to acquire ETH, MATIC, SOL, etc. separately.
• Network Agnostic Logic: The application logic becomes chain-agnostic. Smart contracts or off-chain services coordinate to execute user actions on whatever chain(s) necessary, without requiring the user to manually switch networks or sign multiple transactions. In essence, the user’s experience is of one “meta-chain” or a blockchain-agnostic application layer.

The core idea is to let users focus on what they want to achieve, not which chain or how to achieve it. A familiar analogy is web applications abstracting away server location – just as a user doesn’t need to know which server or database their request touches, a Web3 user shouldn’t need to know which chain or bridge is used for an action. By routing transactions through a unified layer, chain abstraction reduces the fragmentation of today’s multi-chain ecosystem.

Motivation: The push for chain abstraction stems from pain points in current cross-chain workflows. Managing separate wallets per chain and performing multi-step cross-chain operations (swap on Chain A, bridge to Chain B, swap again on Chain B, etc.) is tedious and error-prone. Fragmented liquidity and incompatible wallets also limit dApp growth across ecosystems. Chain abstraction tackles these by cohesively bridging ecosystems. Importantly, it treats Ethereum and its many L2s and sidechains as part of one user experience. EthCC 2025 emphasized that this is critical for mainstream adoption – speakers argued that a truly user-centric Web3 future “must abstract away blockchains”, making the multi-chain world feel as easy as a single network.

Intent-Centric Architecture: From Transactions to Intents​

Traditional blockchain interactions are transaction-centric: a user explicitly crafts and signs a transaction that executes specific operations (calls a contract function, transfers a token, etc.) on a chosen chain. In a multi-chain context, accomplishing a complex goal might require many such transactions across different networks, each manually initiated by the user in the correct sequence. Intent-centric architecture flips this model. Instead of micromanaging transactions, the user declares an intent – a high-level goal or desired outcome – and lets an automated system figure out the transactions needed to fulfill it.

Under an intent-based design, a user might say: “Swap 100 USDC on Base for 100 USDT on Arbitrum”. This intent encapsulates the what (swap one asset for another on a target chain) without prescribing the how. A specialized agent (often called a solver) then takes on the job of completing it. The solver will determine how to best execute the swap across chains – for example, it might bridge the USDC from Base to Arbitrum using a fast bridge and then perform a swap to USDT, or use a direct cross-chain swap protocol – whatever yields the best result. The user signs one authorization, and the solver handles the complex sequence on the backend, including finding the optimal route, submitting the necessary transactions on each chain, and even fronting any required gas fees or taking on interim risk.

How Intents Empower Flexible Execution: By giving the system freedom to decide how to fulfill a request, intent-centric design enables much smarter and more flexible execution layers than fixed user transactions. Some advantages:

• Optimal Routing: Solvers can optimize for cost, speed, or reliability. For instance, multiple solvers might compete to fulfill a user’s intent, and an on-chain auction can select the one offering the best price (e.g. best exchange rate or lowest fees). This competition drives down costs for the user. Wormhole’s Mayan Swift protocol is an example that embeds an on-chain English auction on Solana for each intent, shifting competition from a “first-come” race to a price-based bidding for better user outcomes. The solver that can execute the swap most profitably for the user wins the bid and carries out the plan, ensuring the user gets the most value. This kind of dynamic price discovery is not possible when a user pre-specifies a single path in a regular transaction.
• Resilience and Flexibility: If one bridge or DEX is unavailable or suboptimal at the moment, a solver can choose an alternative path. The intent remains the same, but the execution layer can adapt to network conditions. Intents thus allow programmable execution strategies – e.g. splitting an order or retrying via another route – all invisible to the end-user who only cares that their goal is achieved.
• Atomic Multi-Chain Actions: Intents can encompass what would traditionally be multiple transactions on different chains. Execution frameworks strive to make the entire sequence feel atomic or at least failure-managed. For example, the solver might only consider the intent fulfilled when all sub-transactions (bridge, swap, etc.) are confirmed, and roll back or compensate if anything fails. This ensures the user’s high-level action is either completed in full or not at all, improving reliability.
• Offloading Complexity: Intents dramatically simplify the user’s role. The user doesn’t need to understand which bridges or exchanges to use, how to split liquidity, or how to schedule operations – all that is offloaded to the infrastructure. As one report puts it, “users focus on the what, not the how”. A direct benefit is user experience: interacting with blockchain applications becomes more like using a Web2 app (where a user simply requests a result, and the service handles the process).

In essence, an intent-centric architecture elevates the level of abstraction from low-level transactions to high-level objectives. Ethereum’s community is so keen on this model that the Ethereum Foundation has introduced the Open Intents Framework (OIF), an open standard and reference architecture for building cross-chain intent systems. The OIF defines standard interfaces (like the ERC-7683 intent format) for how intents are created, communicated, and settled across chains, so that many different solutions (bridges, relayers, auction mechanisms) can plug in modularly. This encourages a whole ecosystem of solvers and settlement protocols that can interoperate. The rise of intents is grounded in the need to make Ethereum and its rollups feel “like a single chain” from a UX perspective – fast and frictionless enough that moving across L2s or sidechains happens in seconds without user headache. Early standards like ERC-7683 (for standardized intent format and lifecycle) have even garnered support from leaders like Vitalik Buterin, underscoring the momentum behind intent-centric designs.

Key Benefits Recap: To summarize, intent-centric architectures bring several key benefits : (1) Simplified UX – users state what they want and the system figures out the rest; (2) Cross-Chain Fluidity – operations that span multiple networks are handled seamlessly, effectively treating many chains as one; (3) Developer Scalability – dApp developers can reach users and liquidity across many chains without reinventing the wheel for each, because the intent layer provides standardized hooks into cross-chain execution. By decoupling what needs to be done from how/where it gets done, intents act as the bridge between user-friendly innovation and the complex interoperability behind the scenes.

Technical Building Blocks of Cross-Chain Abstraction​

Implementing chain abstraction and intent-based execution requires a stack of technical mechanisms working in concert. Key components include:

• Cross-Chain Messaging Relayers: At the core of any multi-chain system is a messaging layer that can reliably carry data and value between blockchains. Protocols like Wormhole, Hyperlane, Axelar, LayerZero, and others provide this capability by relaying messages (often with proofs or validator attestations) from a source chain to one or more destination chains. These messages might carry commands like “execute this intent” or “mint this asset” on the target chain. A robust relayer network is crucial for unified transaction routing – it serves as the “postal service” between chains. For example, Wormhole’s network of 19 Guardian nodes observes events on connected chains and signs a VAA (verifiable action approval) that can be submitted to any other chain to prove an event happened. This decouples the action from any single chain, enabling chain-agnostic behavior. Modern relayers focus on being chain-agnostic (supporting many chain types) and decentralized for security. Wormhole, for instance, extends beyond EVM-based chains to support Solana, Cosmos chains, etc., making it a versatile choice for cross-chain communication. The messaging layer often also handles ordering, retries, and finality guarantees for cross-chain transactions.

• Smart Contract Wallets (Account Abstraction): Account abstraction (e.g. Ethereum’s ERC-4337) replaces externally owned accounts with smart contract accounts that can be programmed with custom validation logic and multi-step transaction capabilities. This is a foundation for chain abstraction because a smart wallet can serve as the user’s single meta-account controlling assets on all chains. Projects like Etherspot use smart contract wallets to enable features like transaction batching and session keys across chains. A user’s intent might be packaged as a single user operation (in 4337 terms) which the wallet contract then expands into multiple sub-transactions on different networks. Smart wallets can also integrate paymasters (sponsors) to pay gas fees on the user’s behalf, enabling true gas abstraction (the user might pay in a stablecoin or not at all). Security mechanisms like session keys (temporary keys with limited permissions) allow users to approve intents that involve multiple actions without multiple prompts, while limiting risk. In short, account abstraction provides the programmable execution container that can interpret a high-level intent and orchestrate the necessary steps as a series of transactions (often via the relayers).

• Intent Orchestration and Solvers: Above the messaging and wallet layer lives the intent solver network – the brains that figure out how to fulfill intents. In some architectures, this logic is on-chain (e.g. an on-chain auction contract that matches intent orders with solvers, as in Wormhole’s Solana auction for Mayan Swift). In others, it’s off-chain agents monitoring an intent mempool or order book (for example, the Open Intents Framework provides a reference TypeScript solver that listens for new intent events and then submits transactions to fulfill them). Solvers typically must handle: finding liquidity routes (across DEXes, bridges), price discovery (ensuring the user gets a fair rate), and sometimes covering interim costs (like posting collateral or taking on finality risk – delivering funds to the user before the cross-chain transfer is fully finalized, thereby speeding up UX at some risk to the solver). A well-designed intent-centric system often involves competition among solvers to ensure the user’s intent is executed optimally. Solvers may be economically incentivized (e.g. they earn a fee or arbitrage profit for fulfilling the intent). Mechanisms like solvers’ auctions or batching can be used to maximize efficiency. For example, if multiple users have similar intents, a solver might batch them to minimize bridge fees per user.

• Unified Liquidity and Token Abstraction: Moving assets across chains introduces the classic problem of fragmented liquidity and wrapped tokens. Chain abstraction layers often abstract tokens themselves – aiming to give the user the experience of a single asset that can be used on many chains. One approach is omnichain tokens (where a token can exist natively on multiple chains under one total supply, instead of many incompatible wrapped versions). Wormhole introduced Native Token Transfers (NTT) as an evolution of traditional lock-and-mint bridges: instead of infinite “bridged” IOU tokens, the NTT framework treats tokens deployed across chains as one asset with shared mint/burn controls. In practice, bridging an asset under NTT means burning on the source and minting on the destination, maintaining a single circulating supply. This kind of liquidity unification is crucial so that chain abstraction can “teleport” assets without confusing the user with multiple token representations. Other projects use liquidity networks or pools (e.g. Connext or Axelar) where liquidity providers supply capital on each chain to swap assets in and out, so users can effectively trade one asset for its equivalent on another chain in one step. The Securitize SCOPE fund example is illustrative: an institutional fund token was made multichain such that investors can subscribe or redeem on Ethereum or Optimism, and behind the scenes Wormhole’s protocol moves the token and even converts it into yield-bearing forms, removing the need for manual bridges or multiple wallets for the users.

• Programmable Execution Layers: Finally, certain on-chain innovations empower more complex cross-chain workflows. Atomic multi-call support and transaction scheduling help coordinate multi-step intents. For instance, the Sui blockchain’s Programmable Transaction Blocks (PTBs) allow bundling multiple actions (like swaps, transfers, calls) into one atomic transaction. This can simplify cross-chain intent fulfillment on Sui by ensuring all steps either happen or none do, with one user signature. In Ethereum, proposals like EIP-7702 (smart contract code for EOAs) extend capabilities of user accounts to support things like sponsored gas and multi-step logic even at the base layer. Moreover, specialized execution environments or cross-chain routers can be employed – e.g. some systems route all intents through a particular L2 or hub which coordinates the cross-chain actions (the user might just interact with that hub). Examples include projects like Push Protocol’s L1 (Push Chain) which is being designed as a dedicated settlement layer for chain-agnostic operations, featuring universal smart contracts and sub-second finality to expedite cross-chain interactions. While not universally adopted, these approaches illustrate the spectrum of techniques used to realize chain abstraction: from purely off-chain orchestration to deploying new on-chain infrastructure purpose-built for cross-chain intent execution.

In summary, chain abstraction is achieved by layering these components: a routing layer (relayers messaging across chains), an account layer (smart wallets that can initiate actions on any chain), and an execution layer (solvers, liquidity and contracts that carry out the intents). Each piece is necessary to ensure that from a user’s perspective, interacting with a dApp across multiple blockchains is as smooth as using a single-chain application.

Case Study 1: Wormhole – Intent-Based, Chain-Agnostic Routing​

Wormhole is a leading cross-chain interoperability protocol that has evolved from a token bridge into a comprehensive message-passing network with intent-based functionality. Its approach to chain abstraction is to provide a uniform message routing layer connecting 20+ chains (including EVM chains and non-EVM chains like Solana), and on top of that, build chain-agnostic application protocols. Key elements of Wormhole’s architecture include:

• Generic Message Layer: At its core, Wormhole is a generic publish/subscribe bridge. Validators (Guardians) observe events on each connected chain and sign a VAA (verifiable action) that can be submitted on any other chain to reproduce the event or call a target contract. This generic design means developers can send arbitrary instructions or data cross-chain, not just token transfers. Wormhole ensures messages are delivered and verified consistently, abstracting away whether the source was Ethereum, Solana, or another chain.

• Chain-Agnostic Token Transfers: Wormhole’s original Token Bridge (Portal) used a lock-and-mint approach. Recently, Wormhole introduced Native Token Transfers (NTT), an improved framework for multichain tokens. With NTT, assets can be issued natively on each chain (avoiding fragmented wrapped tokens), while Wormhole handles the accounting of burns and mints across chains to keep supply in sync. For users, this feels like a token “teleports” across chains – they deposit on one chain and withdraw the same asset on another, with Wormhole managing the mint/burn bookkeeping. This is a form of token abstraction that hides the complexity of different token standards and addresses on each chain.

• Intent-Based xApp Protocols: Recognizing that bridging tokens is only one piece of cross-chain UX, Wormhole has developed higher-level protocols to fulfill user intents like swaps or transfers with gas fee management. In 2023–2024, Wormhole collaborated with the cross-chain DEX aggregator Mayan to launch two intent-focused protocols, often called xApps (cross-chain apps) in the Wormhole ecosystem: Mayan Swift and Mayan MCTP (Multichain Transfer Protocol).

  • Mayan Swift is described as a “flexible cross-chain intent protocol” that essentially lets a user request a token swap from Chain A to Chain B. The user signs a single transaction on the source chain locking their funds and specifying their desired outcome (e.g. “I want at least X amount of token Y on destination chain by time T”). This intent (the order) is then picked up by solvers. Uniquely, Wormhole Swift uses an on-chain auction on Solana to conduct competitive price discovery for the intent. Solvers monitor a special Solana contract; when a new intent order is created, they bid by committing how much of the output token they can deliver. Over a short auction period (e.g. 3 seconds), bids compete up the price. The highest bidder (who offers the most favorable rate to the user) wins and is granted the right to fulfill the swap. Wormhole then carries a message to the destination chain authorizing that solver to deliver the tokens to the user, and another message back to release the user’s locked funds to the solver as payment. This design ensures the user’s intent is fulfilled at the best possible price in a decentralized way, while the user only had to interact with their source chain. It also decouples the cross-chain swap into two steps (lock funds, then fulfill on dest) to minimize risk. The intent-centric design here shows how abstraction enables smart execution: rather than a user picking a particular bridge or DEX, the system finds the optimal path and price automatically.

  • Mayan MCTP focuses on cross-chain asset transfers with gas and fee management. It leverages Circle’s CCTP (Cross-Chain Transfer Protocol) – which allows native USDC to be burned on one chain and minted on another – as the base for value transfer, and uses Wormhole messaging for coordination. In an MCTP transfer, a user’s intent might be simply “move my USDC from Chain A to Chain B (and optionally swap to another token on B)”. The source-chain contract accepts the tokens and a desired destination, then initiates a burn via CCTP and simultaneously publishes a Wormhole message carrying metadata like the user’s destination address, desired token on destination, and even a gas drop (an amount of the bridged funds to convert to native gas on the destination). On the destination chain, once Circle mints the USDC, a Wormhole relayer ensures the intent metadata is delivered and verified. The protocol can then automatically e.g. swap a portion of USDC to the native token to pay for gas, and deliver the rest to the user’s wallet (or to a specified contract). This provides a one-step, gas-included bridge: the user doesn’t have to go acquire gas on the new chain or perform a separate swap for gas. It’s all encoded in the intent and handled by the network. MCTP thus demonstrates how chain abstraction can handle fee abstraction and reliable transfers in one flow. Wormhole’s role is to securely transmit the intent and proof that funds were moved (via CCTP) so that the user’s request is fulfilled end-to-end.

Illustration of Wormhole’s intent-centric swap architecture (Mayan Swift). In this design, the user locks assets on the source chain and defines an outcome (intent). Solvers bid in an on-chain auction for the right to fulfill that intent. The winning solver uses Wormhole messages to coordinate unlocking funds and delivering the outcome on the destination chain, all while ensuring the user receives the best price for their swap.

• Unified UX and One-Click Flows: Wormhole-based applications are increasingly offering one-click cross-chain actions. For example, Wormhole Connect is a frontend SDK that dApps and wallets integrate to let users bridge assets with a single click – behind the scenes it calls Wormhole token bridging and (optionally) relayers that deposit gas on the target chain. In the Securitize SCOPE fund use-case, an investor on Optimism can purchase fund tokens that originally live on Ethereum, without manually bridging anything; Wormhole’s liquidity layer automatically moves the tokens across and even converts them into a yield-bearing form, so the user just sees a unified investment product. Such examples highlight the chain abstraction ethos: the user performs a high-level action (invest in fund, swap X for Y) and the platform handles cross-chain mechanics silently. Wormhole’s standard message relaying and automatic gas delivery (via services like Wormhole’s Automatic Relayer or Axelar’s Gas Service integrated in some flows) mean the user often signs just one transaction on their origin chain and receives the result on the destination chain with no further intervention. From the developer perspective, Wormhole provides a uniform interface to call contracts across chains, so building cross-chain logic is simpler.

In summary, Wormhole’s approach to chain abstraction is to provide the infrastructure (decentralized relayers + standardized contracts on each chain) that others can build upon to create chain-agnostic experiences. By supporting a wide variety of chains and offering higher-level protocols (like the intent auction and gas-managed transfer), Wormhole enables applications to treat the blockchain ecosystem as a connected whole. Users benefit by no longer needing to worry about what chain they’re on or how to bridge – whether it’s moving liquidity or doing a multi-chain swap, Wormhole’s intent-centric xApps aim to make it as easy as a single-chain interaction. Wormhole’s co-founder Robinson Burkey noted that this kind of infrastructure has reached “institutional-scale maturity”, allowing even regulated asset issuers to operate seamlessly across networks and abstract away chain-specific constraints for their users.

Case Study 2: Etherspot – Account Abstraction Meets Intents​

Etherspot approaches the cross-chain UX problem from the perspective of wallets and developer tooling. It provides an Account Abstraction SDK and an intent protocol stack that developers can integrate to give their users a unified multi-chain experience. In effect, Etherspot combines smart contract wallets with chain abstraction logic so that a user’s single smart account can operate across many networks with minimal friction. Key features of Etherspot’s architecture include:

• Modular Smart Wallet (Account Abstraction): Every user of Etherspot gets a smart contract wallet (ERC-4337 style) that can be deployed on multiple chains. Etherspot contributed to standards like ERC-7579 (minimal modular smart accounts interface) to ensure these wallets are interoperable and upgradeable. The wallet contract acts as the user’s agent and can be customized with modules. For example, one module might enable a unified balance view – the wallet can report the aggregate of a user’s funds across all chains. Another module might enable session keys, so the user can approve a series of actions with one signature. Because the wallet is present on each chain, it can directly initiate transactions locally when needed (with Etherspot’s backend bundlers and relayers orchestrating the cross-chain coordination).

• Transaction Bundler and Paymasters: Etherspot runs a bundler service (called Skandha) that collects user operations from the smart wallets, and a paymaster service (Arka) that can sponsor gas fees. When a user triggers an intent through Etherspot, they effectively sign a message to their wallet contract. The Etherspot infrastructure (the bundler) then translates that into actual transactions on the relevant chains. Crucially, it can bundle multiple actions – e.g. a DEX swap on one chain and a bridge transfer to another chain – into one meta-transaction that the user’s wallet contract will execute step by step. The paymaster means the user might not need to pay any L1 gas; instead, the dApp or a third party could cover it, or the fee could be taken in another token. This realizes gas abstraction in practice (a big usability win). In fact, Etherspot highlights that with upcoming Ethereum features like EIP-7702, even Externally Owned Accounts could gain gasless capabilities similar to contract wallets – but Etherspot’s smart accounts already allow gasless intents via paymasters today.

• Intent API and Solvers (Pulse): On top of the account layer, Etherspot provides a high-level Intent API known as Etherspot Pulse. Pulse is Etherspot’s chain abstraction engine that developers can use to enable cross-chain intents in their dApps. In a demo of Etherspot Pulse in late 2024, they showed how a user could perform a token swap from Ethereum to an asset on Base, using a simple React app interface with one click. Under the hood, Pulse handled the multi-chain transaction securely and efficiently. The key features of Pulse include Unified Balances (the user sees all assets as one portfolio regardless of chain), Session Key Security (limited privileges for certain actions to avoid constant approvals), Intent-Based Swaps, and Solver Integration. In other words, the developer just calls an intent like swap(tokenA on Chain1 -> tokenB on Chain2 for user) through the Etherspot SDK, and Pulse figures out how to do it – whether by routing through a liquidity network like Socket or calling a cross-chain DEX. Etherspot has integrated with various bridges and DEX aggregators to find optimal routes (it is likely using some of the Open Intents Framework concepts as well, given Etherspot’s involvement in the Ethereum intents community).

• Education and Standards: Etherspot has been a vocal proponent of chain abstraction standards. It has released educational content explaining intents and how “users declare their desired outcome, while solvers handle the backend process”, emphasizing simplified UX and cross-chain fluidity. They enumerate benefits like users not needing to worry about bridging or gas, and dApps gaining scalability by easily accessing multiple chains. Etherspot is also actively collaborating with ecosystem projects: for example, it references the Ethereum Foundation’s Open Intents Framework and explores integrating new cross-chain messaging standards (ERC-7786, 7787, etc.) as they emerge. By aligning with common standards, Etherspot ensures its intent format or wallet interface can work in tandem with other solutions (like Hyperlane, Connext, Axelar, etc.) chosen by the developer.

• Use Cases and Developer UX: For developers, using Etherspot means they can add cross-chain features without reinventing the wheel. A DeFi dApp can let a user deposit funds on whatever chain they have assets on, and Etherspot will abstract the chain differences. A gaming app could let users sign one transaction to claim an NFT on an L2 and have it automatically bridged to Ethereum if needed for trading. Etherspot’s SDK essentially offers chain-agnostic function calls – developers call high-level methods (like a unified transfer() or swap()) and the SDK handles locating user funds, moving them if needed, and updating state across chains. This significantly reduces development time for multi-chain support (the team claims up to 90% reduction in development time when using their chain abstraction platform). Another aspect is RPC Playground and debugging tools Etherspot built for AA flows, which make it easier to test complex user operations that may involve multiple networks. All of this is geared towards making integration of chain abstraction as straightforward as integrating a payments API in Web2.

From the end-user perspective, an Etherspot-powered application can offer a much smoother onboarding and daily experience. New users can sign in with social login or email (if the dApp uses Etherspot’s social account module) and get a smart account automatically – no need to manage seed phrases for each chain. They can receive tokens from any chain to their one address (the smart wallet’s address is the same on all supported chains) and see them in one list. If they want to perform an action (swap, lend, etc.) on a chain where they don’t have the asset or gas, the intent protocol will automatically route their funds and actions to make it happen. For example, a user holding USDC on Polygon who wants to participate in an Ethereum DeFi pool could simply click “Invest in Pool” – the app (via Etherspot) will swap the USDC to the required asset, bridge it to Ethereum, deposit into the pool contract, and even handle gas fees by taking a tiny portion of the USDC, all in one flow. The user is never confronted with “please switch to X network” or “you need ETH for gas” errors – those are handled behind the scenes. This one-click experience is exactly what chain abstraction strives for.

Etherspot’s CEO, Michael Messele, spoke at EthCC 2025 about “advanced chain abstraction” and highlighted that making Web3 truly blockchain-agnostic can empower both users and developers by enhancing interoperability, scalability, and UX. Etherspot’s own contributions, like the Pulse demo of single-intent cross-chain swaps, show that the technology is already here to drastically simplify cross-chain interactions. As Etherspot positions it, intents are the bridge between the innovative possibilities of a multi-chain ecosystem and the usability that end-users expect. With solutions like theirs, dApps can deliver “frictionless” experiences where chain differences disappear into the background, accelerating mainstream adoption of Web3.

User & Developer Experience Improvements​

Both chain abstraction and intent-centric architectures are ultimately in service of a better user experience (UX) and developer experience (DX) in a multi-chain world. Some of the notable improvements include:

• Seamless Onboarding: New users can be onboarded without worrying about what blockchain they’re on. For instance, a user could be given a single smart account that works everywhere, possibly created with a social login. They can receive any token or NFT to this account from any chain without confusion. No longer must a newcomer learn about switching networks in MetaMask or safeguarding multiple seed phrases. This lowers the barrier to entry significantly, as using a dApp feels closer to a Web2 app signup. Projects implementing account abstraction often allow email or OAuth-based wallet creation, with the resulting smart account being chain-agnostic.

• One-Click Cross-Chain Actions: Perhaps the most visible UX gain is condensing what used to be multi-step, multi-app workflows into one or two clicks. For example, a cross-chain token swap previously might require: swapping Token A for a bridgeable asset on Chain 1, going to a bridge UI to send it to Chain 2, then swapping to Token B on Chain 2 – and managing gas fees on both chains. With intent-centric systems, the user simply requests “Swap A on Chain1 to B on Chain2” and confirms once. All intermediate steps (including acquiring gas on Chain2 if needed) are automated. This not only saves time but also reduces the chances of user error (using the wrong bridge, sending to wrong address, etc.). It’s akin to the convenience of booking a multi-leg flight through one travel site versus manually purchasing each leg separately.

• No Native Gas Anxiety: Users don’t need to constantly swap for small amounts of ETH, MATIC, AVAX, etc. just to pay for transactions. Gas fee abstraction means either the dApp covers the gas (and maybe charges a fee in the transacted token or via a subscription model), or the system converts a bit of the user’s asset automatically to pay fees. This has a huge psychological impact – it removes a class of confusing prompt (no more “insufficient gas” errors) and lets users focus on the actions they care about. Several EthCC 2025 talks noted gas abstraction as a priority, e.g. Ethereum’s EIP-7702 will even allow EOA accounts to have gas sponsored in the future. In practice today, many intent protocols drop a small amount of the output asset as gas on the destination chain for the user, or utilize paymasters connected to user operations. The result: a user can, say, move USDC from Arbitrum to Polygon without ever touching ETH on either side, and still have their Polygon wallet able to make transactions immediately on arrival.

• Unified Asset Management: For end-users, having a unified view of assets and activities across chains is a major quality-of-life improvement. Chain abstraction can present a combined portfolio – so your 1 ETH on mainnet and 2 ETH worth of bridged stETH on Optimism might both just show as “ETH balance”. If you have USD stablecoins on five different chains, a chain-agnostic wallet could show your total USD value and allow spending from it without you manually bridging. This feels more like a traditional bank app that shows a single balance (even if funds are spread across accounts behind the scenes). Users can set preferences like “use cheapest network by default” or “maximize yield” and the system might automatically allocate transactions to the appropriate chain. Meanwhile, all their transaction history could be seen in one timeline regardless of chain. Such coherence is important for broader adoption – it hides blockchain complexity under familiar metaphors.

• Enhanced Developer Productivity: From the developer’s side, chain abstraction platforms mean no more writing chain-specific code for each integration. Instead of integrating five different bridges and six exchanges to ensure coverage of assets and networks, a developer can integrate one intent protocol API that abstracts those. This not only saves development effort but also reduces maintenance – as new chains or bridges come along, the abstraction layer’s maintainers handle integration, and the dApp just benefits from it. The weekly digest from Etherspot highlighted that solutions like Okto’s chain abstraction platform claim to cut multi-chain dApp development time by up to 90% by providing out-of-the-box support for major chains and features like liquidity optimization. In essence, developers can focus on application logic (e.g. a lending product, a game) rather than the intricacies of cross-chain transfers or gas management. This opens the door for more Web2 developers to step into Web3, as they can use higher-level SDKs instead of needing deep blockchain expertise for each chain.

• New Composable Experiences: With intents and chain abstraction, developers can create experiences that were previously too complex to attempt. For example, cross-chain yield farming strategies can be automated: a user could click “maximize yield on my assets” and an intent protocol could move assets between chains to the best yield farms, even doing this continuously as rates change. Games can have assets and quests that span multiple chains without requiring players to manually bridge items – the game’s backend (using an intent framework) handles item teleportation or state sync. Even governance can benefit: a DAO could allow a user to vote once and have that vote applied on all relevant chains’ governance contracts via cross-chain messages. The overall effect is composability: just as DeFi on a single chain allowed Lego-like composition of protocols, cross-chain intent layers allow protocols on different chains to compose. A user intent might trigger actions on multiple dApps across chains (e.g. unwrap an NFT on one chain and sell it on a marketplace on another), which creates richer workflows than siloed single-chain operations.

• Safety Nets and Reliability: An often under-appreciated UX aspect is error handling. In early cross-chain interactions, if something went wrong (stuck funds in a bridge, a transaction failing after you sent funds, etc.), users faced a nightmare of troubleshooting across multiple platforms. Intent frameworks can build in retry logic, insurance, or user protection mechanisms. For example, a solver might take on finality risk – delivering the user’s funds on the destination immediately (within seconds) and waiting for the slower source chain finality themselves. This means the user isn’t stuck waiting minutes or hours for confirmation. If an intent fails partially, the system can rollback or refund automatically. Because the entire flow is orchestrated with known steps, there’s more scope to make the user whole if something breaks. Some protocols are exploring escrow and insurance for cross-chain operations as part of the intent execution, which would be impossible if the user was manually jumping through hoops – they’d bear that risk alone. In short, abstraction can make the overall experience not just smoother but also more secure and trustworthy for the average user.

All these improvements point to a single trend: reducing the cognitive load on users and abstracting away blockchain plumbing into the background. When done right, users may not even realize which chains they are using – they just access features and services. Developers, on the other hand, get to build apps that tap liquidity and user bases across many networks from a single codebase. It’s a shift of complexity from the edges (user apps) to the middle (infrastructure protocols), which is a natural progression as technology matures. EthCC 2025’s tone echoed this sentiment, with “seamless, composable infrastructure” cited as a paramount goal for the Ethereum community.

Insights from EthCC 2025​

The EthCC 2025 conference (held in July 2025 in Cannes) underscored how central chain abstraction and intent-based design have become in the Ethereum ecosystem. A dedicated block of sessions focused on unifying user experiences across networks. Key takeaways from the event include:

• Community Alignment on Abstraction: Multiple talks by industry leaders echoed the same message – simplifying the multi-chain experience is critical for the next wave of Web3 adoption. Michael Messele (Etherspot) spoke about moving “towards a blockchain-agnostic future”, Alex Bash (Zerion wallet) discussed “unifying Ethereum’s UX with abstraction and intents”, and others introduced concrete standards like ERC-7811 for stablecoin chain abstraction. The very title of one talk, “There’s No Web3 Future Without Chain Abstraction”, encapsulated the community sentiment. In other words, there is broad agreement that without solving cross-chain usability, Web3 will not reach its full potential. This represents a shift from previous years where scaling L1 or L2 was the main focus – now that many L2s are live, connecting them for users is the new frontier.

• Ethereum’s Role as a Hub: EthCC panels highlighted that Ethereum is positioning itself not just as one chain among many, but as the foundation of a multi-chain ecosystem. Ethereum’s security and its 4337 account abstraction on mainnet can serve as the common base that underlies activity on various L2s and sidechains. Rather than competing with its rollups, Ethereum (and by extension Ethereum’s community) is investing in protocols that make the whole network of chains feel unified. This is exemplified by the Ethereum Foundation’s support for projects like the Open Intents Framework, which spans many chains and rollups. The vibe at EthCC was that Ethereum’s maturity is shown in embracing an “ecosystem of ecosystems”, where user-centric design (regardless of chain) is paramount.

• Stablecoins & Real-World Assets as Catalysts: An interesting theme was the intersection of chain abstraction with stablecoins and RWAs (Real-World Assets). Stablecoins were repeatedly noted as a “grounding force” in DeFi, and several talks (e.g. on ERC-7811 stablecoin chain abstraction) looked at making stablecoin usage chain-agnostic. The idea is that an average user shouldn’t need to care on which chain their USDC or DAI resides – it should hold the same value and be usable anywhere seamlessly. We saw this with Securitize’s fund using Wormhole to go multichain, effectively abstracting an institutional product across chains. EthCC discussions suggested that solving cross-chain UX for stablecoins and RWAs is a big step toward broader blockchain-based finance, since these assets demand smooth user experiences for adoption by institutions and mainstream users.

• Developer Excitement and Tooling: Workshops and side events (like Multichain Day) introduced developers to the new tooling available. Hackathon projects and demos showcased how intent APIs and chain abstraction SDKs (from various teams) could be used to whip up cross-chain dApps in days. There was a palpable excitement that the “Holy Grail” of Web3 UX – using multiple networks without realizing it – is within reach. The Open Intents Framework team did a beginner’s workshop explaining how to build an intent-enabled app, likely using their reference solver and contracts. Developers who had struggled with bridging and multi-chain deployment in the past were keen on these solutions, as evidenced by the Q&A sessions (as reported informally on social media during the conference).

• Announcements and Collaboration: EthCC 2025 also served as a stage for announcing collaborations between projects in this space. For example, a partnership between a wallet provider and an intent protocol or between a bridge project and an account abstraction project were hinted at. One concrete announcement was Wormhole integrating with the Stacks ecosystem (bringing Bitcoin liquidity into cross-chain flows) which wasn’t directly chain abstraction for Ethereum, but exemplified the expanding connectivity across traditionally separate crypto ecosystems. The presence of projects like Zerion (wallet), Safe (smart accounts), Connext, Socket, Axelar, etc., all discussing interoperability, signaled that many pieces of the puzzle are coming together.

Overall, EthCC 2025 painted a picture of a community coalescing around user-centric cross-chain innovation. The phrase “composable infrastructure” was used to describe the goal: all these L1s, L2s, and protocols should form a cohesive fabric that applications can build on without needing to stitch things together ad-hoc. The conference made it clear that chain abstraction and intents are not just buzzwords but active areas of development attracting serious talent and investment. Ethereum’s leadership in this—through funding, setting standards, and providing a robust base layer—was reaffirmed at the event.

Comparison of Approaches to Chain Abstraction and Intents​

The table below compares several prominent protocols and frameworks that tackle cross-chain user/developer experience, highlighting their approach and key features:

Project / Protocol	Approach to Chain Abstraction	Intent-Centric Mechanism	Key Features & Outcomes
Wormhole (Interop Protocol)	Chain-agnostic message-passing layer connecting 25+ chains (EVM & non-EVM) via Guardian validator network. Abstracts token transfers with Native Token Transfer (NTT) standard (unified supply across chains) and generic cross-chain contract calls.	Intent Fulfillment via xApps: Provides higher-level protocols on top of messaging (e.g. Mayan Swift for cross-chain swaps, Mayan MCTP for transfers with gas). Intents are encoded as orders on source chain; solved by off-chain or on-chain agents (auctions on Solana) with Wormhole relaying proofs between chains.	• Universal Interoperability: One integration gives access to many chains. • Best-Price Execution: Solvers compete in auctions to maximize user output (reduces costs). • Gas & Fee Abstraction: Relayers handle delivering funds and gas on target chain, enabling one-click user flows. • Heterogeneous Support: Works across very different chain environments (Ethereum, Solana, Cosmos etc.), making it versatile for developers.
Etherspot (AA + ChA SDK)	Account abstraction platform offering smart contract wallets on multiple chains with unified SDK. Abstracts chains by providing a single API to interact with all user’s accounts and balances across networks. Developers integrate its SDK to get multi-chain functionality out-of-the-box.	Intent Protocol (“Pulse”): Collects user-stated goals (e.g. swap X to Y cross-chain) via a high-level API. The backend uses the user’s smart wallet to execute necessary steps: bundling transactions, choosing bridges/swaps (with integrated solver logic or external aggregators), and sponsoring gas via paymasters.	• Smart Wallet Unification: One user account controls assets on all chains, enabling features like aggregated balance and one-click multi-chain actions. • Developer-Friendly: Pre-built modules (4337 bundler, paymaster) and React TransactionKit, cutting multi-chain dApp dev time significantly. • Gasless & Social Login: Supports gas sponsorship and alternative login (improving UX for mainstream users). • Single-Intent Swaps Demo: Showcased cross-chain swap in one user op, illustrating how users focus on “what” and let Etherspot handle “how”.
Open Intents Framework (Ethereum Foundation & collaborators)	Open standard (ERC-7683) and reference architecture for building intent-based cross-chain applications. Provides a base set of contracts (e.g. a Base7683 intent registry on each chain) that can plug into any bridging/messaging layer. Aims to abstract chains by standardizing how intents are expressed and resolved, independent of any single provider.	Pluggable Solvers & Settlement: OIF doesn’t enforce one solver network; it allows multiple settlement mechanisms (Hyperlane, LayerZero, Connext’s xcall, etc.) to be used interchangeably. Intents are submitted to a contract that solvers monitor; a reference solver implementation is provided (TypeScript bot) that developers can run or modify. Across Protocol’s live intent contracts on mainnet serve as one realization of ERC-7683.	• Ecosystem Collaboration: Built by dozens of teams to be a public good, encouraging shared infrastructure (solvers can service intents from any project). • Modularity: Developers can choose trust model – e.g. use optimistic verification, a specific bridge, or multi-sig – without changing the intent format. • Standardization: With common interfaces, wallets and UIs (like Superbridge) can support intents from any OIF-based protocol, reducing integration effort. • Community Support: Vitalik and others endorse the effort, and early adopters (Eco, Uniswap’s Compact, etc.) are building on it.
Axelar + Squid (Cross-Chain Network & SDK)	Cosmos-based interoperability network (Axelar) with a decentralized validator set that passes messages and tokens between chains. Abstracts the chain hop by offering a unified cross-chain API (Squid SDK) which developers use to initiate transfers or contract calls across EVM chains, Cosmos chains, etc., through Axelar’s network. Squid focuses on providing easy cross-chain liquidity (swaps) via one interface.	“One-Step” Cross-Chain Ops: Squid interprets intents like “swap TokenA on ChainX to TokenB on ChainY” and automatically splits it into on-chain steps: a swap on ChainX (using a DEX aggregator), a transfer via Axelar’s bridge, and a swap on ChainY. Axelar’s General Message Passing delivers any arbitrary intent data across. Axelar also offers a Gas Service – developers can have users pay gas in the source token and it ensures the destination transaction is paid, achieving gas abstraction for the user.	• Developer Simplicity: One SDK call handles multi-chain swaps; no need to manually integrate DEX + bridge + DEX logic. • Fast Finality: Axelar ensures finality with its own consensus (seconds) so cross-chain actions complete quickly (often faster than optimistic bridges). • Composable with dApps: Many dApps (e.g. decentralized exchanges, yield aggregators) integrate Squid to offer cross-chain features, effectively outsourcing the complexity. • Security Model: Relies on Axelar’s proof-of-stake security; users trust Axelar validators to safely bridge assets (a different model from optimistic or light-client bridges).
Connext (xCall & Amarok)	Liquidity-network bridge that uses an optimistic assurance model (watchers challenge fraud) for security. Abstracts chains by providing an xcall interface – developers treat cross-chain function calls like normal function calls, and Connext routes the call through routers that provide liquidity and execute the call on the destination. The goal is to make calling a contract on another chain as simple as calling a local one.	Function Call Intents: Connext’s xcall takes an intent like “invoke function F on Contract C on Chain B with data X and send result back” – effectively a cross-chain RPC. Under the hood, liquidity providers lock bond on Chain A and mint representative assets on Chain B (or use native assets if available) to carry out any value transfer. The intent (including any return handling) is fulfilled after a configurable delay (to allow fraud challenges). There isn’t a solver competition; instead any available router can execute, but Connext ensures the cheapest path by using a network of routers.	• Trust-Minimized: No external validator set – security comes from on-chain verification plus bonded routers. Users don’t cede custody to a multi-sig. • Native Execution: Can trigger arbitrary logic on the destination chain (more general than swap-focused intents). This suits cross-chain dApp composability (e.g. initiate an action in a remote protocol). • Router Liquidity Model: Instant liquidity for transfers (like a traditional bridge) without waiting for finality, since routers front liquidity and later reconcile. • Integration in Wallets/Bridges: Often used under the hood by wallets for simple bridging due to its simplicity and security posture. Less aimed at end-user UX platforms and more at protocol devs who want custom cross-chain calls.

(Table legend: AA = Account Abstraction, ChA = Chain Abstraction, AMB = arbitrary messaging bridge)

Each of the above approaches addresses the cross-chain UX challenge from a slightly different angle – some focus on the user’s wallet/account, others on the network messaging, and others on the developer API layer – but all share the goal of making blockchain interactions chain-agnostic and intent-driven. Notably, these solutions are not mutually exclusive; in fact, they often complement each other. For example, an application could use Etherspot’s smart wallet + paymasters, with the Open Intents standard to format the user’s intent, and then use Axelar or Connext under the hood as the execution layer to actually bridge and perform actions. The emerging trend is composability among chain abstraction tools themselves, ultimately building toward an Internet of Blockchains where users navigate freely.

Conclusion​

Blockchain technology is undergoing a paradigm shift from siloed networks and manual operations to a unified, intent-driven experience. Chain abstraction and intent-centric architecture are at the heart of this transformation. By abstracting away the complexities of multiple chains, they enable a user-centric Web3 in which people interact with decentralized applications without needing to understand which chain they’re using, how to bridge assets, or how to acquire gas on each network. The infrastructure – relayers, smart accounts, solvers, and bridges – collaboratively handle those details, much like the Internet’s underlying protocols route packets without users knowing the route.

The benefits in user experience are already tangible: smoother onboarding, one-click cross-chain swaps, and truly seamless dApp interactions across ecosystems. Developers, too, are empowered by higher-level SDKs and standards that dramatically simplify building for a multi-chain world. As seen at EthCC 2025, there is a strong community consensus that these developments are not only exciting enhancements but fundamental requirements for the next phase of Web3 growth. Projects like Wormhole and Etherspot demonstrate that it’s possible to retain decentralization and trustlessness while offering Web2-like ease of use.

Looking ahead, we can expect further convergence of these approaches. Standards such as ERC-7683 intents and ERC-4337 account abstraction will likely become widely adopted, ensuring compatibility across platforms. More bridges and networks will integrate with open intent frameworks, increasing liquidity and options for solvers to fulfill user intents. Eventually, the term “cross-chain” might fade away, as interactions won’t be thought of in terms of distinct chains at all – much like users of the web don’t think about which data center their request hit. Instead, users will simply invoke services and manage assets in a unified blockchain ecosystem.

In conclusion, chain abstraction and intent-centric design are turning the multi-chain dream into reality: delivering the benefits of diverse blockchain innovation without the fragmentation. By centering designs on user intents and abstracting the rest, the industry is taking a major step toward making decentralized applications as intuitive and powerful as the centralized services of today, fulfilling the promise of Web3 for a broader audience. The infrastructure is still evolving, but its trajectory is clear – a seamless, intent-driven Web3 experience is on the horizon, and it will redefine how we perceive and interact with blockchains.

Sources: The information in this report was gathered from a range of up-to-date resources, including protocol documentation, developer blog posts, and talks from EthCC 2025. Key references include Wormhole’s official docs on their cross-chain intent protocols, Etherspot’s technical blog series on account and chain abstraction, and the Ethereum Foundation’s Open Intents Framework release notes, among others, as cited throughout the text. Each citation is denoted in the format 【source†lines】 to pinpoint the original source material supporting the statements made.