Skip to main content

3 posts tagged with "User Experience"

UX design and usability

View all tags

Chain Abstraction and Intent‑Centric Architecture in Cross-Chain UX

· 44 min read
Dora Noda
Software Engineer

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 / ProtocolApproach to Chain AbstractionIntent-Centric MechanismKey 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.

Frictionless On‑Ramp with zkLogin

· 6 min read
Dora Noda
Software Engineer

How to drop wallet friction, keep users flowing, and forecast the upside

What if your Web3 app had the same seamless sign-up flow as a modern Web2 service? That's the core promise of zkLogin on the Sui blockchain. It functions like OAuth for Sui, letting users sign in with familiar accounts from Google, Apple, X, and more. A zero-knowledge proof then securely links that Web2 identity to an on-chain Sui address—no wallet pop-ups, no seed phrases, no user churn.

The impact is real and immediate. With hundreds of thousands of zkLogin accounts already live, case studies report massive gains in user conversion, jumping from a dismal 17% to a healthy 42% after removing traditional wallet barriers. Let's break down how it works and what it can do for your project.


Why Wallets Kill First‑Time Conversion

You've built a groundbreaking dApp, but your user acquisition funnel is leaking. The culprit is almost always the same: the "Connect Wallet" button. Standard Web3 onboarding is a maze of extension installations, seed phrase warnings, and crypto-jargon quizzes.

It’s a massive barrier for newcomers. UX researchers observed a staggering 87% drop-off the moment a wallet prompt appeared. In a telling experiment, simply re-routing that prompt to a later stage in the checkout process flipped the completion rate to 94%. Even for crypto-curious users, the primary fear is, “I might lose my funds if I click the wrong button.” Removing that single, intimidating step is the key to unlocking exponential growth.


How zkLogin Works (in Plain English)

zkLogin elegantly sidesteps the wallet problem by using technologies every internet user already trusts. The magic happens behind the scenes in a few quick steps:

  1. Ephemeral Key Pair: When a user wants to sign in, a temporary, single-session key pair is generated locally in their browser. Think of it as a temporary passkey, valid only for this session.
  2. OAuth Dance: The user signs in with their Google, Apple, or other social account. Your app cleverly embeds a unique value (nonce) into this login request.
  3. ZKP Service: After a successful login, a ZKP (Zero-Knowledge Proof) service generates a cryptographic proof. This proof confirms, "This OAuth token authorizes the owner of the temporary passkey," without ever revealing the user's personal identity on-chain.
  4. Derive Address: The user's JWT (JSON Web Token) from the OAuth provider is combined with a unique salt to deterministically generate their permanent Sui address. The salt is kept private, either client-side or in a secure backend.
  5. Submit Transaction: Your app signs transactions with the temporary key and attaches the ZK proof. Sui validators verify the proof on-chain, confirming the transaction's legitimacy without the user ever needing a traditional wallet.

Step‑by‑Step Integration Guide

Ready to implement this? Here’s a quick guide using the TypeScript SDK. The principles are identical for Rust or Python.

1. Install SDK

The @mysten/sui package includes all the zklogin helpers you'll need.

pnpm add @mysten/sui

2. Generate Keys & Nonce

First, create an ephemeral keypair and a nonce tied to the current epoch on the Sui network.

const keypair = new Ed25519Keypair();
const { epoch } = await suiClient.getLatestSuiSystemState();
const nonce = generateNonce(keypair.getPublicKey(), Number(epoch) + 2, generateRandomness());

3. Redirect to OAuth

Construct the appropriate OAuth login URL for the provider you're using (e.g., Google, Facebook, Apple) and redirect the user.

4. Decode JWT & Fetch User Salt

After the user logs in and is redirected back, grab the id_token from the URL. Use it to fetch the user-specific salt from your backend, then derive their Sui address.

const jwt = new URLSearchParams(window.location.search).get('id_token')!;
const salt = await fetch('/api/salt?jwt=' + jwt).then(r => r.text());
const address = jwtToAddress(jwt, salt);

5. Request ZK Proof

Send the JWT to a prover service to get the ZK proof. For development, you can use Mysten’s public prover. In production, you should host your own or use a service like Enoki.

const proof = await fetch('/api/prove', {
method:'POST',
body: JSON.stringify({ jwt, ... })
}).then(r => r.json());

6. Sign & Send

Now, build your transaction, set the sender to the user's zkLogin address, and execute it. The SDK handles attaching the zkLoginInputs (the proof) automatically. ✨

const tx = new TransactionBlock();
tx.moveCall({ target:'0x2::example::touch_grass' }); // Any Move call
tx.setSender(address);
tx.setGasBudget(5_000_000);

await suiClient.signAndExecuteTransactionBlock({
transactionBlock: tx,
zkLoginInputs: proof // The magic happens here
});

7. Persist Session

For a smoother user experience, encrypt and store the keypair and salt in IndexedDB or local storage. Remember to rotate them every few epochs for enhanced security.


KPI Projection Template

The difference zkLogin makes isn't just qualitative; it's quantifiable. Compare a typical onboarding funnel with a zkLogin-powered one:

Funnel StageTypical with Wallet PopupWith zkLoginDelta
Landing → Sign-in100 %100 %
Sign-in → Wallet Ready15 % (install, seed phrase)55 % (social login)+40 pp
Wallet Ready → First Tx~23 %~90 %+67 pp
Overall Tx Conversion~3 %≈ 25‑40 %~8‑13×

👉 What this means: For a campaign driving 10,000 unique visitors, that's the difference between 300 first-day on-chain actions and over 2,500.


Best Practices & Gotchas

To create an even more seamless experience, keep these pro-tips in mind:

  • Use Sponsored Transactions: Pay for your users' first few transaction fees. This removes all friction and delivers an incredible "aha" moment.
  • Handle Salts Carefully: Changing a user's salt will generate a new address. Only do this if you control a reliable recovery path for them.
  • Expose the Sui Address: After signup, show users their on-chain address. This empowers advanced users to import it into a traditional wallet later if they choose.
  • Prevent Refresh Loops: Cache the JWT and ephemeral keypair until they expire to avoid asking the user to log in repeatedly.
  • Monitor Prover Latency: Keep an eye on the proof-generation round-trip time. If it exceeds 2 seconds, consider hosting a regional prover to keep things snappy.

Where BlockEden.xyz Adds Value

While zkLogin perfects the user-facing flow, scaling it introduces new backend challenges. That's where BlockEden.xyz comes in.

  • API Layer: Our high-throughput, geo-routed RPC nodes ensure your zkLogin transactions are processed with minimal latency, regardless of user location.
  • Observability: Get out-of-the-box dashboards to track key metrics like proof latency, success/fail ratios, and your conversion funnel's health.
  • Compliance: For apps that bridge into fiat, our optional KYC module provides a compliant on-ramp directly from the user's verified identity.

Ready to Ship?

The era of clunky, intimidating wallet flows is over. Spin up a zkLogin sandbox, plug in BlockEden’s full-node endpoint, and watch your sign-up graph bend upward—while your users never even have to hear the word “wallet.” 😉

User Pain Points with RiseWorks: A Comprehensive Analysis

· 21 min read
Dora Noda
Software Engineer

RiseWorks is a global payroll platform enabling companies to hire and pay international contractors in fiat or crypto. User feedback reveals a range of pain points across different user types – HR professionals, freelancers/contractors (including funded traders), startups, and businesses – touching on onboarding, pricing, support, features, integrations, ease of use, and performance. Below is a detailed report of recurring issues (with direct user quotes) and how sentiments have evolved over time.

Onboarding Experience

RiseWorks touts automated onboarding and compliance checks (KYC/AML) to streamline bringing on contractors. HR teams appreciate not having to manually handle contractor paperwork, and the platform claims a 94% approval rate with a 17-second median ID verification time. This suggests most users get verified almost instantly, which is a positive for quick onboarding.

However, some freelancers find the identity verification (KYC) process tedious. New contractors must provide extensive details (e.g. personal info, tax ID, proof of address) as part of registration. A few users encountered KYC issues (one even created a YouTube guide on fixing RiseWorks KYC rejections), indicating that when the automated process fails, it can be confusing to resolve. In general, though, there haven’t been widespread complaints about the sign-up itself – most frustration arises later during payouts. Overall, onboarding is thorough but typical for a compliance-focused payroll system: it front-loads some effort to ensure legal and tax requirements are met, which some users accept as necessary, while others feel could be smoother.

Pricing and Fees

RiseWorks uses a dual pricing model: either a flat $50 per contractor per month or a 3% fee on payment volume, with an Employer-of-Record option (~$399 per employee) for full-time international hires. For freelancers (contractors), the platform itself is free to sign up – they can send invoices and receive payments without subscribing. Startups and businesses choose between paying per contractor vs. a percentage of payouts depending on which is more cost-effective for their team size and payout amounts.

Pain points around pricing have not been the center of user complaints (operational issues overshadow cost concerns). However, some companies note that 3% of large payouts can become hefty, while $50/month for each contractor might be steep if you have many small engagements. As a point of comparison, Rise’s own marketing claims its fees are lower than competitors like Deel. One independent review also highlighted that Rise offers crypto payouts with minimal fees (only ~$2.50 on-chain fees, or free on layer-2 networks), which can be appealing for cost-conscious crypto-native businesses.

In summary, pricing feedback is mixed: startups and HR managers appreciate the transparency of a flat fee or percentage choice, but they must calculate which model is affordable for them. So far, no major outcry on “hidden fees” or unfair pricing has appeared in user reviews. The main caution is for businesses to weigh the flat vs. percent model – e.g. a $10,000 contractor payment would incur $300 fee under the 3% plan, which might prompt choosing the flat monthly rate instead. Proper guidance on selecting plans could improve satisfaction here.

Customer Support

Customer support is one of the most significant pain points echoed by users across the board. RiseWorks advertises 24/7 multilingual support and multiple contact channels (in-app chat, email, even a Google form). In practice, however, user feedback paints a very different picture.

Freelancers and traders have reported extremely poor response times. One user lamented that **“they have no customer support. You’ll get 1 automated message and no replies after that. I don’t even know how to get my funds back lol.”*. Others similarly describe support as virtually non-existent. For example, a funded forex trader who tried RiseWorks for a payout warned: “Don’t try it… I withdrew with them and [am] failing to get my cash, support is very poor, they don’t respond at all despite having received my cash. I have 2 days now still trying to withdraw but I wish I hadn’t selected this crap of service.” This kind of feedback – no response to urgent withdrawal issues – is alarming for users expecting help.

HR professionals and business owners also find this troubling. If their contractors can’t get assistance or funds, it reflects poorly on the company. Some HR users note that while their account managers set up the service, ongoing support is hard to reach when issues arise. This has been a recurring theme: “terrible CS” (customer service) is mentioned alongside negative Trustpilot reviews. In social media forums and groups, users shared Trustpilot links and warned others to “beware of Rise” due to support and payout problems.

It’s worth noting that RiseWorks appears aware of support shortcomings and has provided more contact methods (the Google form, etc.). But as of the past year, the predominant user sentiment is frustration with support responsiveness. Quick, helpful support is critical in payroll (especially when money is in limbo), so this is a key area where RiseWorks is currently failing its users. Both freelancers and companies are demanding more reliable, real-time support to address payment issues.

Features and Functionality

RiseWorks is a feature-rich platform, especially appealing to crypto and Web3 companies. Users appreciate some of its unique capabilities, but also point out a few missing or immature features given the company’s relative youth (founded 2019).

Notable features praised by users (mostly businesses and crypto-savvy freelancers) include:

  • Hybrid payouts (fiat & crypto): Rise supports 90+ local currencies and 100+ cryptocurrencies, allowing companies and contractors to mix and match payout methods. This flexibility is a standout feature – for example, a contractor can choose to receive part of their pay in local currency and part in USDC. For Web3-native workers, this is a big plus.
  • Compliance automation: The platform handles drafting compliant contracts, tax form generation, and local law compliance for international contractors. HR professionals value this “all-in-one” aspect, as it reduces legal risk. One external review noted Rise “navigates international tax laws and regulations” to keep things compliant for every contractor.
  • Crypto finance extras: Freelancers on Rise can access built-in features like high-yield DeFi accounts for their earnings (as mentioned on Rise’s site) and secure storage via Rise’s smart contract wallet. These novel features aren’t common in traditional payroll software.

Despite these strengths, users have identified some functionality pain points:

  • Lack of certain integrations or features standard in mature platforms: Because RiseWorks is “newer to the payroll industry (5 years old)”, some advanced features are still catching up. For instance, recruiters note that Rise doesn’t yet have robust reporting/analytics on spend or automatic general ledger integrations. A startup comparing options found that while Rise covers the basics, it lacked some bells and whistles (like time-tracking or invoice generation for clients) that they had to handle separately.
  • Mobile app availability: A few contractors wished for a dedicated mobile app. Currently, RiseWorks is accessed via web; the interface is responsive, but an app for on-the-go access (to check payment status or upload documents) would enhance usability. Competing services often have mobile apps, so this is a minor gripe from the freelancer side.
  • New feature stability: As Rise adds features (for example, they recently introduced direct EUR/GBP bank payouts with conversion), some early adopters experienced bugs. One user mentioned initial hiccups setting up a “RiseID” (a Web3 identity feature) – the concept is promising, but the setup failed for them until support (eventually) resolved it. This suggests that cutting-edge features sometimes need more polish.

In summary, RiseWorks’ feature set is powerful but still evolving. Tech-forward users love the crypto integration and compliance automation, while some traditional users miss features they’re accustomed to in older, more established payroll systems. The core functionality is solid (global payments in multiple currencies), yet the platform would benefit from continuing to refine new features and perhaps adding more business-oriented tools (reports, integrations) as it matures.

Integrations

Integration capabilities are a mixed bag and depend on the user’s context:

  • For Web3 and crypto users, RiseWorks shines by integrating with popular blockchain tools. It connects to widely used crypto wallets and chains, offering flexibility in funding and withdrawing. For example, it supports direct integration with Ethereum and Polygon networks, and wallets like MetaMask and Gnosis Safe. This means companies can fund payroll from a crypto treasury or contractors can withdraw to their personal crypto wallet seamlessly. One user pointed out they chose Rise specifically so they could pay a team in stablecoins without manual transfers – a big convenience over piecing together exchanges and bank wires.
  • For traditional businesses/HR systems, however, RiseWorks’ integrations are limited. It does not yet natively integrate with common HR or accounting software (such as Workday, QuickBooks, or ERP systems). An HR manager noted that data from Rise (e.g. payment records, contractor details) had to be exported and input into their accounting system manually. The platform does provide an API for custom integrations, but this requires technical effort. In contrast, some competitors offer plug-and-play integrations with popular software, so this is an area of improvement.

Another integration pain point mentioned by users in certain countries is with local banks and payment networks. RiseWorks ultimately relies on partner banks or services to deliver local currency. In one case, an Indian freelancer’s bank (Axis Bank) rejected the incoming transfer after 18 hours, possibly due to the intermediary or crypto-related origin, causing payout delays. This suggests integration with local banking systems can be hit-or-miss depending on region. Users in places with strict bank policies may need alternative payout methods (or for Rise to partner with different processors).

To summarize integration feedback: Great for crypto connectivity, lacking for traditional software ecosystems. Startups and freelancers in the crypto space laud how well RiseWorks plugs into blockchain workflows. Meanwhile, HR teams at traditional firms view the lack of out-of-the-box integration with their existing tools as a friction point, requiring workarounds. As Rise expands, adding integrations (or even simple CSV import/exports) for major payroll/accounting systems could alleviate this pain for business users.

Ease of Use and Interface

On the whole, users find the RiseWorks interface modern and relatively intuitive, but certain processes can be confusing especially when issues arise. The onboarding guide for funded traders (from a partner prop firm) shows the platform steps clearly – e.g. the dashboard to “easily submit invoices” for your earnings and withdraw in your chosen currency. Contractors have reported that basic tasks like creating an invoice or adding a withdrawal method are straightforward through the guided workflow. The design is clean and tailored to both non-crypto users (who can simply choose a bank transfer) and crypto users (who connect a wallet).

However, ease of use drops when something goes wrong. The user experience for exception cases (like a KYC verification failure, a withdrawal stuck in processing, or needing to contact support) is frustrating. Because support lagged, users ended up seeking help on forums or trying to troubleshoot on their own – which speaks to a lack of in-app guidance for resolving issues. For instance, a user whose payout was in limbo couldn’t find status details or next steps in the UI, leading them to post “How do I even get my money?” on Reddit out of confusion. This indicates the platform might not surface clear error messages or actionable info when payments are delayed (an area to improve UX).

From an HR perspective, the admin interface for onboarding and managing contractors is decent, but could be more feature-rich for ease of use. HR users would like to see, for example, a single view of all contractor statuses (KYC pending, payment in process, etc.) and maybe a bulk action tool. Currently, the platform’s focus is on individual contractor workflows, which is simple but at scale can become a bit click-heavy for HR teams managing dozens of contractors.

In summary, RiseWorks is easy to use for standard operations, but its user-friendliness falters in edge cases. New users generally have little trouble navigating the system for intended tasks. The interface is comparable to other modern SaaS products and even first-time freelancers can figure out how to get set up and invoice their client through Rise. On the flip side, when users encounter an unusual scenario (like a delay or a need to update submitted info), the platform offers limited guidance – causing confusion and reliance on external support. Smoother handling of those scenarios and more proactive communication in-app would greatly enhance the overall user experience.

Performance and Reliability

Performance, in terms of payment processing speed and reliability, has been the most critical issue for many users. The platform’s technical performance (site uptime, page loading) hasn’t drawn complaints – the website and app generally load fine. It’s the operational performance of getting money from point A to B that shows problems.

Payout Delays: Numerous users have reported that bank withdrawals take far longer than expected. In several cases, contractors waited weeks for funds that were supposed to arrive in days. One trader shared that “my payout has been stuck in withdrawal phase with them for 2 weeks now”. Another user similarly posted about a withdrawal pending for days without updates. Such delays leave freelancers in limbo, unsure if or when they will receive their earnings. This is a severe reliability concern – on a payroll platform, timely payment is fundamental. Some affected users even voiced fears that they had been scammed when money didn’t show up on time. While RiseWorks eventually did fulfill many of these payouts, the lack of communication during the delay exacerbated the frustration.

Crypto vs. Bank Transfer Performance: Interestingly, feedback indicates that crypto payouts are much faster and smoother than traditional bank transfers on RiseWorks. Contractors who opted to withdraw in cryptocurrency (like USDC) often received their funds quickly – sometimes within minutes if on a crypto wallet. A customer feedback analysis noted “quick crypto withdrawals” as a positive theme, contrasted with “delayed bank transfers” for fiat. This suggests that Rise’s crypto infrastructure is robust, but its banking partnerships or processes may be a bottleneck. For users, this created a divide: tech-savvy freelancers learned to prefer crypto to avoid delays, whereas those needing local currency had to endure waiting periods.

System Stability: Aside from payment timing, there were a few instances of system glitches. In mid-2024, a handful of users encountered errors like being unable to initiate a withdrawal or the platform showing a “processing” status indefinitely. These might have been one-off bugs or related to the KYC/documents not being fully approved behind the scenes. There isn’t evidence of widespread outages, but even isolated cases of hung transactions erode trust. RiseWorks does have a status page, yet some users weren’t aware of it or it didn’t reflect their specific issue.

Trust and Perceived Reliability: Early on, RiseWorks struggled with user trust. In mid-2024 when it was relatively new to many, it had an average Trustpilot rating around 3.3 out of 5 (an “Average” score) with very few reviews. Comments about missing money and poor support led some to label it untrustworthy. One third-party scam monitoring site even flagged riseworks.io with a “very low trust score”, cautioning it might be risky. This shows how performance issues (like payout failures) directly impacted its reputation.

However, by 2025 there are signs of improvement. More users have successfully used the service, and satisfied voices have somewhat balanced out the detractors. According to an aggregate review report, the overall Trustpilot rating for RiseWorks climbed to 4.4/5 as of April 2025. This suggests that many users eventually did get paid and had a decent experience, possibly leaving positive feedback. The increase in rating could mean the company addressed some early bugs and delays, or that users who utilize the crypto payout (which works reliably) gave high scores. Regardless, the presence of happy customers alongside the unhappy ones now indicates mixed experiences – not uniformly bad as the initial feedback might have implied.

In conclusion on reliability: RiseWorks has proven reliable for some (especially via crypto), but inconsistent for others (especially via banks). The platform’s performance has been patchy, which is a major pain point because payroll is all about trust and timing. Freelancers and businesses need to know payments will arrive as promised. Until Rise can ensure bank transfers are as prompt as their crypto payments, this will remain a concern. The trend in recent months is somewhat positive (fewer horror stories, better ratings), but cautious optimism is warranted – users still frequently advise each other to “be careful and have a backup” when using Rise, reflecting lingering concerns about its reliability.

Summary of Recurring Themes and Patterns

Across user types, a few recurring pain points stand out clearly on the RiseWorks platform:

  • Payout Delays and Unreliability: This is the number one issue raised by freelancers (especially funded traders and contractors). Early users in 2023-2024 often experienced significant delays in receiving funds, with some waiting weeks and fearing they might never get paid. This pattern seems to be improving in 2025, but delays (particularly for fiat transfers) are still reported. The contrast between slow bank transfers and fast crypto payouts is a recurring theme – indicating the platform’s traditional payment rails need improvement.
  • Poor Customer Support: Nearly every negative review or forum post cites the lack of responsive support. Users across the spectrum (HR admins and contractors alike) have been frustrated by either no replies or generic, unhelpful responses when they reach out for help. This has been consistent from the platform’s early days up to recent times, though the company claims 24/7 support availability. It’s a critical pain point because it compounds other issues; when a payment is delayed, not getting timely support makes the experience far worse.
  • Trust and Transparency Issues: In the platform’s initial rollout to new communities (like prop trading firms’ users), there was skepticism due to the above issues. RiseWorks had to battle perceptions of being a “scam” or unreliable. Over time, as more users successfully received payments, some trust is being earned back (reflected in improved ratings). Still, trust remains fragile – new users often seek out reviews and ask others if RiseWorks is safe before committing their earnings to it. Businesses considering RiseWorks also evaluate its short track record and sometimes express hesitation to rely on a relatively young company for something as sensitive as payroll.
  • Value Proposition vs. Execution: Users acknowledge that RiseWorks is tackling a valuable problem – global contractor payments with crypto options – and many want it to work. HR professionals and startup founders like the idea of a one-stop solution for international compliance, and freelancers like having more ways to get paid (especially in crypto with low fees). When the platform works as intended, these benefits are realized, and users are pleased. For instance, a few Trustpilot comments (per summary reports) praise how easy it was to withdraw in their local currency, or how convenient it is to not worry about tax forms. The pain point is that the execution hasn’t been consistent. The concept is strong, but the company is still ironing out operational kinks. As one community member aptly put it, “Rise has potential, but they need to sort out their payout system and support if they want people to stick with it.” This encapsulates the sentiment that many early adopters have: cautiously hopeful but currently disappointed in key areas.

Below is a summary table of pain points by category, with highlights of what users have reported:

AspectPain Points ReportedSupporting User Feedback
OnboardingSome friction with KYC (ID verification, document upload) process, especially if information isn’t accepted on first try.“Comprehensive Automation… including automated onboarding” (Pros); Some needed external help for KYC issues (e.g. YouTube tutorials – implies process could be clearer).
Pricing & FeesPricing model ($50/contractor or 3% volume) must be chosen carefully; high volume payouts can incur large fees. Contractors sometimes bear fees (e.g. ~0.95% on certain transfers).Rise claims to undercut competitors on fees. Few direct complaints on cost – one reason is other issues took precedence. Startups do note to “mind the 3% if doing large payouts” (community advice).
Customer SupportVery slow or no responses to support queries; lack of live resolution. Users felt abandoned when issues arose.“They have no customer support. [You’ll] get 1 automated message and no replies…”; “Support is very poor, they don’t respond at all…crap service”.
FeaturesMissing some advanced features (time tracking, integrations, detailed reporting). New features (RiseID, etc.) have occasional bugs.“Newer to the payroll industry (5 years old)” – still adding features. Users appreciate crypto payout feature, but note it’s a basic payroll tool lacking extras that older systems have.
IntegrationsLimited integration with external business software; no native sync with HRIS or accounting systems. Some issues interfacing with certain local banks.“Rise integrates with… widely used [blockchain] wallets” (crypto integration is a plus). But traditional integration is manual (CSV exports/API). One user’s local bank refused a Rise transfer, causing delays.
Ease of UseGenerally user-friendly UI, but poor guidance when errors occur. Users unsure what to do when a payout is stuck or KYC needs re-submission.“The Rise dashboard lets you easily submit invoices…withdraw in local currency or supported cryptocurrencies.” (intuitive for normal tasks). Lacks in-app alerts or tips when something goes wrong, leading to user confusion.
PerformancePayout processing is inconsistent – fast for crypto, but slow for fiat. Some payouts stuck for days/weeks. Reliability concerns and anxiety over whether money will arrive.“Delayed bank transfers” and “funds seem to be in limbo”; multiple Reddit threads about waiting weeks. In contrast, “quick crypto withdrawals” reported by others.

Patterns Over Time: Early feedback (late 2022 and 2023) was largely negative, centering on unmet basic expectations (money not arriving, no support). This created a narrative in forums that “RiseWorks is not delivering”. Over 2024 and into 2025, the company appears to have taken steps to address these issues: expanding payment corridors (adding EU/UK local transfers), providing more support channels, and likely resolving many individual cases. Consequently, we see a more mixed set of reviews recently – some users reporting smooth experiences alongside those who still hit snags. The Trustpilot score rising to 4.4/5 by April 2025 (from ~3/5 a year prior) exemplifies this shift. It suggests that a number of users are now satisfied (or at least the happy customers increased), perhaps due to successful crypto payouts or improved processes.

That said, key pain points persist in 2025: delays in certain payouts and subpar support are mentioned in recent discussions, meaning RiseWorks hasn’t fully escaped those problems. The improvement in average ratings could reflect proactive measures, but also possibly efforts to encourage positive reviews. It’s important to note that even with a 4.4 average, the negative experiences were very severe for those who had them, and those narratives continue to circulate in user communities (Reddit, prop trading forums, etc.). New users often explicitly ask if others have had issues, indicating the caution that still surrounds the platform’s reputation.

Conclusion

In conclusion, RiseWorks addresses a real need for global payroll (especially bridging crypto and fiat payments), but user experiences show a gap between promise and reality. HR professionals and businesses love the concept of compliant, automated contractor payments in any currency, yet they worry about reliability when they see freelancers struggling to get paid. Freelancers and funded traders are excited by flexible payout options and low fees, but many have encountered unacceptable delays and silence when they needed help. Over time there are signs of improvement – some users now report positive outcomes – but the recurring themes of payout delays and poor support remain the biggest pain points holding RiseWorks back.

For RiseWorks to fully win over all user types, it will need to significantly improve its customer support responsiveness and ensure timely payments consistently. If those core issues are fixed, much of the historical negativity would likely fade, as the underlying service offering is strong and innovative. Until then, user feedback will likely continue to be mixed: with startups and crypto-native users praising features and cost, and others cautioning about support and speed. As one user summarized on social media, RiseWorks has great potential but must “deliver on the basics” – a sentiment that encapsulates the platform’s current standing in the eyes of its users.

Sources:

  • User discussions on Reddit (r/Forex, r/Daytrading, r/buhaydigital) highlighting payout delays and support issues
  • Trustpilot summary via TradersUnion/Kimola reports (mixed reviews: “delayed bank transfers, lack of customer support, and quick crypto withdrawals”)
  • RiseWorks marketing and documentation (pricing page, integrations, and competitor comparisons)
  • Community posts (Facebook group for prop firm traders) warning about missing bank payouts
  • PipFarm user guide for RiseWorks, outlining onboarding steps and contractor experience
  • Medium review on RiseWorks (Coinmonks) for feature overview and pricing details.