Blockchain Abstraction: The Next Frontier

Key takeaways

• Wallet and authentication abstraction, account and transaction abstraction, and chain abstraction have reduced the steps users once had to handle themselves to use blockchain. Banks and Web2 platforms can connect these capabilities to existing accounts and services, offering digital asset features within familiar user journeys.
• The complexity that abstraction removes from the screen becomes the operational responsibility of platforms and infrastructure providers. Systems for managing account recovery, transaction approvals, fee payments, and settlement status are prerequisites for offering blockchain capabilities as everyday services.
• Ramp has integrated wallets and payments into existing finance workflows. TON Wallet in Telegram has simplified incoming transfers from other chains through chain abstraction, while Naver Pay has used wallet and authentication abstraction to connect asset ownership with community access. The value of abstraction is becoming concrete within the workflows and user journeys of existing platforms.
• Connecting wallet and payment infrastructure to the customer bases of existing platforms is accelerating the integration of Web2 and Web3. Practical applications could expand to overseas vendor payments and creator payouts, tickets and memberships used across partner services, and automated purchases delegated within defined permissions and budgets.
• This article examines how abstraction reduces friction in the user experience, focusing on Privy, ERC-4337, Across, and Circle's CCTP. It then analyzes adoption by Ramp, Telegram, and Naver Pay, and explores the possibilities that emerge when these wallet architectures are integrated into Web2 services.

EastPoint is the first private conference to bring together institutional leaders, regulators, and Web3 pioneers to shape the future of Korea's digital asset and AI economy.

Even a product with exceptional technology can fail to gain market acceptance if it overlooks user experience (UX), before it has a chance to demonstrate its value. The maturity of a technology depends on how intuitively users experience that value, beyond what performance metrics alone can show.

The same applies when digital platforms adopt blockchain. What users notice first is how smoothly the entire process connects: buying digital assets, using on-ramps and off-ramps, exchanging assets, and continuing their economic activity. Technical advantages such as consensus algorithms are less immediately tangible.

Just a few years ago, blockchain services fell short in this respect. To use a decentralized application (dApp), users first had to install a wallet app or browser extension and back up a recovery phrase. Once inside, they needed native gas tokens for each transaction and had to sign repeatedly. If their assets were on another chain, they had to work out and manage the entire route, including bridge selection, gas on each chain, and network switching. Recovery after a failure was also their responsibility.

Banks and Web2 platforms with hundreds of millions of customers could hardly add blockchain to their services in this form. For years, blockchain remained a subject of technical evaluation and struggled to become a practical option for adoption.

Much of this friction has now been addressed through (1) wallet and authentication abstraction, (2) account and transaction abstraction, and (3) chain abstraction. A social login can create a wallet. Gas sponsorship removes the need to obtain gas tokens separately, and batching allows multiple calls to execute together. Users sign for the outcome they want, and solvers and relayers construct the route without requiring them to choose a chain.

These changes have expanded the possibilities for banks and platforms to connect blockchain capabilities to existing services. Customers can log in with familiar accounts and make payments on the same screen, while wallet and transaction execution infrastructure handles asset custody and movement behind the scenes. This article examines how the three forms of abstraction work and how they are being adopted in practice, then discusses the services that could emerge as Web2 and Web3 come together.

1. Wallet and authentication abstraction: Privy moves wallet creation behind login

Early dApps were built on the assumption that users already had an external wallet such as MetaMask. Anyone without one had to install a browser extension or mobile app, generate a new key, and store a recovery phrase separately. Only after connecting the wallet to the site and signing a login request could they see the product.

Users had to move between the app and an external wallet to authenticate, store keys, and sign transactions. They took on key management before trying the service and had to learn how blockchain infrastructure worked before experiencing its value. For newcomers to Web3, this was a clear barrier to entry.

Source: Privy

Privy directly addresses this barrier. It introduced embedded wallets in February 2023 and formally launched its platform in February 2024. At launch, it described the product as "the easiest way to onboard all users to Web3, whether or not they already have a wallet." Its purpose was to lower the onboarding barrier.

The approach centers on simple authentication through email one-time passwords (OTPs), social logins, passkeys, or external wallets. Privy links multiple login methods to a single user object and connects wallets on different chains to that object. It keeps login credentials strictly separate from private keys. App-specific access tokens and time-limited authorization keys issued after authentication authorize wallet operations. Giving these components separate roles and lifetimes improves security.

In practice, a single setting enables this onboarding flow. If an app enables createOnLogin, Privy automatically creates a wallet for users who complete its login modal and do not already have one. Users receive a wallet as they log in, without installing an extension or backing up a recovery phrase. All they see is a familiar login step, while wallet creation and key management happen behind the interface. In Privy's TEE configuration, a trusted execution environment handles the creation and storage of the private key behind that interface.

Privy supports both TEE and on-device implementations. This section focuses on a configuration with a trusted execution environment enabled. The private key is generated inside an AWS Nitro Enclave, isolated from external access and networks. Privy then splits the key into two shares using Shamir's Secret Sharing, rather than storing it intact.

Shamir's Secret Sharing is a cryptographic technique that divides a secret into multiple shares. The original can be reconstructed only when a specified minimum number of shares are combined. Fewer shares reveal no information about the original secret.

The two shares have different roles. The enclave share is encrypted so that it can be decrypted only inside the TEE. The auth share enters the signing process only when there is a valid login request. This is a 2-of-2 arrangement, so neither share can reconstruct the private key on its own.

When a signature is needed, the two shares are briefly combined in isolated memory. The Privy API checks the authentication information in the transaction request, then passes the encrypted auth share and the request to the TEE. The TEE verifies the authorization signature and relevant policies, combines the shares, signs, and immediately destroys the reconstructed key. Isolated from the network, the TEE returns only the signature. The caller or API broadcasts the transaction. In this signing flow, the private key is therefore reconstructed temporarily inside the TEE and discarded immediately after use.

This arrangement does not automatically provide complete self-custody. Actual control of a wallet depends on its owner, additional signers, and quorum settings; splitting the key alone does not determine control. In consumer wallets based on the client SDK, the user is the default owner and can export the key. Assigning a service authorization key as the owner gives the service control of the wallet. Because email or social accounts provide access to the wallet, compromised login credentials can also expose it. Passkeys or multifactor authentication (MFA) are therefore recommended for apps that handle high-value assets.

The benefit to users is clear. They can log in on a new device and access the same wallet, then use the service through a familiar Web2 flow without having to think about the wallet. Onboarding that once took minutes and caused users to drop off is effectively compressed into a single login.

Many dApps, including Hyperliquid and Fomo, use Privy's embedded wallets for onboarding. Privy grew rapidly to more than 75 million accounts by June 2025 and was acquired by global payments company Stripe the following month, in July. It continues to be adopted as a major onboarding solution across Web3 products.

2. Account and transaction abstraction: execution policies take over transaction assembly

Consider swapping USDC for ether (ETH) in an app. With a conventional externally owned account (EOA), two transactions were required if the token allowance was missing or insufficient. Users first signed an approval transaction that allowed the swap contract to spend their USDC. They then waited for it to be included in a block before signing the swap transaction itself. Two pop-ups appeared, and users also needed ETH in the wallet to pay gas fees.

An interruption made the problem worse. If the approval succeeded but the swap failed, no exchange took place, yet the swap contract retained permission to move the user's USDC up to the approved limit. In an app with frequent transactions, users who approved only the amount needed each time had to repeat the process. The procedure itself became more frustrating than the action they were trying to complete.

ERC-4337 account abstraction addresses this by letting users submit an instruction sheet in place of sending transactions directly. Previously, users had to construct and sign each transaction, then send them in the correct order. They can now specify the desired execution in an instruction sheet and submit it. The execution infrastructure handles the rest.

More precisely, the user's action becomes a UserOperation, an instruction sheet containing the sender, execution details, fee conditions, and signature. The main change is that a smart account with batch execution support can combine approval and swap in a single UserOperation. The delivery system for these instructions has clearly separated roles:

• Bundler: A collection service that simulates multiple UserOperations, filters out requests that fail validation, and submits the rest in a bundle.
• EntryPoint: An onchain checkpoint through which all UserOperations pass.
• Smart account: An account whose signature acceptance conditions can be defined in code.
• Paymaster: An optional party that pays fees on the user's behalf.

The approach adds an efficient execution infrastructure while preserving Ethereum's underlying consensus rules. Once the user approves, the app creates a UserOperation and the bundler groups it with others for submission to the EntryPoint. The EntryPoint validates the signature through the smart account and checks whether fees can be paid. If a paymaster is used, its policy is also checked before the EntryPoint calls the smart account to execute the approval and swap together. Three capabilities support the improved experience users get from a single click.

The first is fee, or gas, abstraction. With a paymaster, an app can cover the full fee or pay ETH on the user's behalf and later collect reimbursement in USDC. Suppose a user needs to pay 100 USDC on a platform. On Ethereum, the user would ordinarily need a small amount of ETH for gas. With fee abstraction, the platform can pay the gas in ETH first and recover the cost from the user in USDC, or cover the expense itself.

The second is transaction batching. EIP-5792 allows an app to send multiple calls, such as approval and swap, to a wallet in one request. If a wallet supports atomic execution and is asked to use it, a failure in any call reverts the entire batch. This prevents an incomplete state in which only the spending approval remains. Users can complete the process with one confirmation instead of two pop-ups.

The third is limited delegation through session keys. A session key resembles a debit card issued with a spending limit. A user might authorize "only these functions in this contract, up to 100 USDC, until the end of this month." After that one approval, a game client or automated agent can submit transactions without further pop-ups. The account's validation code enforces the limits, so requests outside the permitted conditions are automatically rejected by the smart contract. Enforcement does not depend on the app's goodwill. ERC-7715, a standard for requesting execution permissions from wallets, is still a draft, but the approach is already attracting attention in other ecosystems, such as agentic commerce, where automated execution is essential.

This convenience comes with costs and responsibilities. Sponsored fees are paid from the budget of the app or a third party, and paymasters can reject requests under their policies. An overly broad or compromised session key can put assets at risk up to its configured limits. As users gain convenience, platforms take on substantial operational responsibilities, including sponsorship budgets, permission scopes, session revocation, and control over account code upgrades.

The user experience changes substantially. Obtaining gas tokens, approving consecutive transactions, and signing repeatedly give way to an experience resembling a simple payment button in a Web2 app. However smoothly a smart account handles execution on one chain, though, it cannot automatically bring assets scattered across other chains to the destination. Chain abstraction addresses this remaining problem.

3. Chain abstraction: solvers and settlement layers take over network selection

Chain abstraction addresses the barriers between chains, the final obstacle in this progression toward better blockchain UX.

Suppose an app runs on Base, but the user's USDC is on Arbitrum. In the past, this created a substantial task. The user had to identify the chain holding the assets, obtain its gas token, approve token spending by a bridge contract, wait for the transfer to complete, switch networks, and obtain gas for the destination chain. Only then were the assets ready to use on Base. Even a single token swap required bridge selection, gas on two chains, repeated signatures, and exposure to failure, simply because the networks differed.

Chain abstraction transfers responsibility for assembling the route to the execution layer, while the underlying process remains. Users sign outcome conditions such as the asset to receive, maximum amount to pay, minimum amount to receive, recipient address, and expiry time. A solver or relayer receives this intent and uses its own capital to deliver the result on the destination chain. It is reimbursed for the principal and paid its fee only after the destination payment has been verified.

Just as ERC-4337 has become a common specification for account abstraction, ERC-7683, proposed by Uniswap Labs and Across, seeks to standardize the format of cross-chain intents.

Across is a representative implementation of this intent-based model. A user deposits assets into the source chain's vault, or SpokePool. A relayer detects the deposit and promptly pays the user on the destination chain using its own funds. The user can receive assets within minutes without waiting for a comparatively slow canonical Layer 1 or Layer 2 bridge to complete the transfer.

Subsequent settlement takes place asynchronously in the backend. The relayer is reimbursed after verification and a challenge period, so rapid payment and final settlement are separate. If payment does not occur before the deadline, the assets are returned to the designated refund address through the settlement process. Cross-chain swaps in the Uniswap interface also run on Across.

For stablecoins, Circle's Cross-Chain Transfer Protocol (CCTP) provides an official route directly from the issuer. USDC is burned on the source chain, and an attestation from Circle allows the same amount to be minted on the destination chain. The issuer guarantees the aggregate supply without wrapped tokens or separate liquidity pools, making the protocol suitable as basic infrastructure for banks and platforms that require consistency. It is limited to supported assets and chains, and standard transfers must wait for source-chain finality. CCTP V2 substantially shortens the wait through Fast Transfer, which obtains Circle's attestation and mints USDC on the destination chain before finality.

These improvements in convenience also move risk. Across depends on relayer liquidity and involves a waiting period for refunds, while CCTP depends on Circle's attestation infrastructure. ERC-7683 standardizes the language of orders without guaranteeing shared escrow or liquidity. A platform that hides these complex routes must therefore manage quote expiry, track whether destination payment has occurred, monitor final settlement, and trace refunds.

4. Adoption expands: blockchain enters existing platform workflows

Advances in the three forms of abstraction discussed above have considerably expanded the options available to companies adopting blockchain. Companies can now source the core capabilities for wallet creation, key management, asset conversion, and transfers from external infrastructure providers and readily integrate them into existing accounts and services. As a result, they have substantially improved the user experience (UX) by incorporating these capabilities into existing products without requiring customers to use a separate blockchain service.

When examining adoption, it is therefore necessary to look at which wallet a platform uses and which components it builds itself or sources externally. Ramp connected Stripe's infrastructure to payments and accounting. The wallet service within Telegram expanded its funding options through MoonPay, while Naver Pay introduced Magic's wallet capabilities into tickets and communities. Each case expanded how assets could be used within an existing service while retaining its customers and services.

4.1. Ramp and Stripe: connecting stablecoins to payment approvals and accounting

Consider a corporate finance team paying a vendor. The person responsible must check the invoice amount and recipient, obtain internal approval, make the payment, and record the result in the books. Even if stablecoins reduce transfer times, the payment process as a whole is unlikely to become easier if the team still has to manage a separate wallet and reenter transfer records. This is why stablecoin payments need to connect to existing accounting systems.

To address this, corporate finance platform Ramp announced two features with Stripe in July 2026. One is a bill payment feature that uses dollars in an external bank account to pay vendors in stablecoins. The other is an account that allows companies to hold and use stablecoins. Companies can choose to use stablecoins for payments without holding them in advance, or hold a balance themselves when needed.

For payments funded from a bank account, Bridge converts dollars into stablecoins and delivers them to the recipient's wallet. Accounts that hold stablecoins use Privy's enterprise wallet infrastructure, and Ramp displays fiat and stablecoin balances together in dollar terms. Although the funds are held and moved in different ways, finance teams manage balances and payment records on the same screen.

Privy worked with Ramp's development team to build corporate custodial wallets, Solana support, transaction approval policies, and APIs for balances and transfers. It also added balance change notifications (webhooks) and metadata for reconciliation so that asset movements could be immediately recorded and verified in the company's books.

Under this division of responsibilities, Ramp handles the customer-facing payment interface, approval process, and accounting integrations. Privy provides wallet and permission management in the backend. Ramp connected the results processed by external infrastructure to its existing financial processes, without developing wallet and transfer capabilities for each blockchain itself.

According to Ramp's July 2026 announcement, more than 1,000 companies were making payments in stablecoins, and more than 70% of the value of those stablecoin payments moved outside banking hours. Stablecoins are becoming a useful tool for overcoming the time constraints of existing payment processes without adding a separate wallet management burden for finance teams. Through wallet abstraction, Ramp delegated key management to Privy and connected Bridge's asset conversion and transfer capabilities to integrate stablecoin payments into existing approval and accounting workflows.

To recap, Ramp used wallet abstraction to delegate key management to Privy and connected Bridge's asset conversion and transfer capabilities to integrate stablecoin payments into existing approval and accounting workflows.

4.2. Telegram and MoonPay: adding external funding routes to a wallet inside a messenger

Efforts to place Web3 wallets inside messaging apps continue. As the integration of Kakao Pay into KakaoTalk illustrates, placing a wallet inside a messenger where users spend considerable time can substantially increase usage. But a wallet has limited utility if users cannot easily convert between fiat currency and digital assets to deposit or withdraw funds.

For example, if users must buy assets on a separate exchange and manually swap tokens from another chain before bringing them into the wallet, the only improvement is a shorter wallet setup process. The benefit would be limited. Adding asset capabilities to an everyday platform therefore requires connecting both the wallet entry point and the routes through which funds enter.

Wallet in Telegram illustrates this challenge. The service offers separate custodial and self-custodial wallets. In the former, the operator manages the keys; in the latter, users control their own assets.

MoonPay's infrastructure provides funding routes for this wallet. In July 2025, MoonPay announced that it would support asset purchases in TON Wallet through cards, Apple Pay, Google Pay, and other methods, as well as withdrawals to supported bank cards. The wallet service connected external on-ramps and off-ramps to the user flow within the messenger, without building every deposit and withdrawal route for each payment method itself.

In February 2026, the service introduced MoonPay Deposits so that users could also bring in assets held on other chains. Users select the token to deposit and the source network, and a deposit address is generated. When they send assets to that address from an external wallet or exchange, MoonPay detects the deposit and handles the conversion, cross-chain transfer, and final delivery of the assets. Users choose and send the asset they wish to swap, while the infrastructure selects the intermediate bridge and constructs the conversion route.

TON Connect connects individual mini apps within Telegram to wallets. Mini apps use this standard to request wallet connections and transaction approvals, and users give final approval in the wallet app. Telegram provides the customer interface, the wallet service manages asset access permissions, MoonPay handles incoming funds, and mini apps provide the actual uses for those assets.

Telegram does not directly hold all user assets in custody, and users of self-custodial wallets remain responsible for managing their private keys and recovery methods. Even so, the significance of this case is that it connects the full user journey, from bringing in external assets to using them in a service, within a single flow. Through chain abstraction provided by MoonPay, TON Wallet in Telegram delegates swap and bridge route selection to the infrastructure so that users can bring assets from other chains into their wallet within the messenger.

To recap, TON Wallet in Telegram uses chain abstraction through MoonPay to delegate swap and bridge route selection to the infrastructure, allowing users to bring assets from other chains into their wallet within the messenger.

4.3. Naver Pay and Magic: connecting asset ownership to community access

Consider a community open only to people who hold a ticket to a performance. What users want is a space to interact with others who attended the same event, rather than token ownership for its own sake. Here, the wallet stores assets and verifies eligibility to use a service.

In August 2024, Naver Pay launched the beta version of a non-custodial wallet created with a Naver account and a dedicated password. According to its official help center, the wallet uses a solution from Magic Labs to generate wallet addresses and private keys. This connects an external provider's wallet creation capabilities to the process of signing in with an existing Naver account and setting a dedicated password.

Naver Pay also designed how users interact with the wallet beyond its initial entry screen. It labels non-fungible tokens (NFTs) as "art" and transaction hashes as "transaction numbers," and lets users view their holdings within the Naver Pay app. It adopted the wallet's technical capabilities while adapting the customer-facing terminology and user flow to the existing platform.

Wallet Community, launched in March 2026, gave asset ownership a specific use. The wallet holds NFTs in the form of art, tickets, and certificates, while the community's "ticket-verified rooms" admit only users who hold the corresponding ticket or related art. By distinguishing general channels on topics such as Jeju tourism from ticket-verified rooms related to the KLPGA, Naver Pay tied access to some communities to asset ownership.

The roles in this flow are distinct. The Naver account identifies the service user, Magic's wallet technology creates that user's digital asset account, and Naver Pay determines which services can use the assets held in it. Ticket-verified rooms use this ownership information as an entry condition. The platform connects wallet information to its own service rules; the wallet provider does not determine community access rights. Through wallet and authentication abstraction, Naver Pay hides wallet creation behind a Naver login and a dedicated password, then connects the wallet's asset ownership information to eligibility for community participation.

To recap, Naver Pay uses wallet and authentication abstraction to hide wallet creation behind a Naver login and a dedicated password, then connects the wallet's asset ownership information to eligibility for community participation.

5. An Era of Web2 and Web3 Integration

Web3 adoption is more likely to take place within existing Web2 services than through the formation of new platforms. Ramp's finance workflows, Telegram's messenger, and Naver Pay's communities demonstrate how blockchain-based asset and transaction capabilities can connect naturally to the accounts and user journeys of existing platforms. As this integration expands, users can broaden the ways they use assets while remaining within familiar apps and experiences.

To turn this integration into practical services, companies need to connect the wallet and transaction capabilities that address the constraints they want to resolve. They must clearly assign responsibility for account recovery, transaction approvals, fee payments, and settlement status management, and integrate these functions into existing customer support systems. For example, when a payment is delayed, customers should be able to check where their funds are and whether the payment can be retried directly within the platform. This is what allows blockchain capabilities to become part of an everyday service.

Payments and settlement are among the first areas where further expansion can be expected. Just as Ramp has connected stablecoins to finance workflows, the same structure can be applied to platforms that pay merchants or distribute creator earnings. A platform can verify the payment amount and recipient, send the funds in stablecoins, and let recipients check their payment history and balances in an existing dashboard. This preserves a familiar workflow without the constraints of banking hours.

Tickets and memberships are another major area where connections between services can expand. A ticket issued by a concert platform could provide access to a fan community, discounts at partner accommodations, or priority booking for the next event. If participating businesses agree on issuers and eligibility criteria, and each service verifies wallet holdings, a single ticket can establish eligibility across multiple services.

Platforms should focus on designing uses for assets after they are issued. Just as Naver Pay links ticket ownership to community access, assets in a wallet need to lead to tangible benefits that give customers a reason to hold them and use a platform that incorporates Web3. As more partner services join, the value available through a single ticket or membership grows, creating a strong incentive for existing customers to return.

Combining limited delegation with payments can also enable software to purchase the resources it needs within boundaries set by the user. Users can define permitted services and spending limits as policies, then authorize agents to purchase the data or external capabilities required for their tasks. Wallet permission management thus evolves from reducing repeated transaction approvals into payment infrastructure for automated services.

Reusing existing customer bases and infrastructure can accelerate this expansion. Platforms can offer new value to customers they already serve, while wallet and payment infrastructure providers can supply the same underlying technology to multiple platforms. Compared with building wallets and fund transfer routes from scratch, this substantially reduces the development burden and makes it easier to carry applications proven in one service into another.

Web2 and Web3 are already coming together in payments and communities. As these connections expand, blockchain can become core infrastructure for receiving payments, checking benefits, and purchasing services within everyday apps. Abstraction is central to this integration. By lowering barriers to entry and connecting these capabilities to the customer bases of existing platforms, it can accelerate the transition.

Join EastPoint