OneBalance
OneBalance
  • Chain Abstraction Toolkit
    • Introduction
    • Using OneBalance SCA
      • Getting started with OneBalance and Privy
        • Step 1: Setting up Privy
        • Step 2: Setting configurations
        • Step 3: Initializing and Depositing onto the OneBalance Smart Account
        • Step 4: Displaying Chain-Aggregated Balances
        • Step 5: Fetch a quote for transaction execution
        • Step 6: Signing transactions with Privy
        • Step 7: Executing transactions
        • Step 8: Getting execution status
      • Contract calls guide
        • Usage code samples
  • OneBalance vision
    • What is OneBalance
      • Mission of OneBalance
      • Use Cases
      • Credible Accounts and Credible Stack
      • Fellowship of OneBalance
      • Glossary
    • Why resource locks?
      • Technical Details
        • Resource lock
        • Permissions
        • Credible accounts
        • Credible Commitment Machine (CCM)
        • FAQ
          • How does this relate to account abstraction and 4337?
          • Where does the OneBalance account live?
          • Are OneBalance accounts non-custodial?
      • Credible Stack Deep Dive
        • Apps
        • SDK providers
        • Wallets / WaaS
        • Solver Networks
        • Oracle Providers
        • Data Providers
  • Other
    • OneBalance Demo App
      • Roadmap
      • Privacy Policy
      • Terms and Conditions
    • OneBalance Brand assets
Powered by GitBook
On this page
  • Overview and Value Proposition
  • Use Cases
  • Key Features and Capabilities
  • Account
  • Transaction Types
  • Exact Input and Exact Output Modes
  • Execution Optimization
  • Gas Abstraction
  • Fees
  • Supported Chains
  • Tokens
  • Chain abstracted balance
  • Resource Lock
  1. Chain Abstraction Toolkit

Introduction

With any questions please text us in Discord or X, or use this form to contact us. You can find API swagger documentation here, including public API key for tests.

Overview and Value Proposition

Using the Toolkit, applications can deliver a Web2-like non-custodial experience within the Web3 ecosystem. Developers benefit from a streamlined, Web2-like development process, as the Toolkit abstracts away the complexities inherent to Web3. This enables developers to focus primarily on application development and user acquisition strategies rather than intricate Web3-specific concepts.

Applications built with the Toolkit can achieve:

  • Social login, passkey signing, single-click or zero-click transaction execution (when used with Wallet-as-a-Service solutions)

  • Gas abstraction, eliminating the need for users to understand gas mechanics

  • Chain abstraction, allowing users to seamlessly spend balances aggregated across multiple chains as if transactions occurred on a single chain

  • Transactions executed at the speed of the destination chain via Resource Locks

  • Stablecoin abstraction and token-versioning abstraction for users who just want a "USD" balance to spend from or don't make a difference between ETH and wETH.

Take a look at app.onebalance.io as a reference for the chain abstracted UX possible with OneBalance.

Use Cases

The Toolkit is ideal for applications prioritizing exceptional Web3 user experiences, particularly those whose users manage assets across multiple chains. Typical use cases include:

  • Token swapping across multiple chains, including meme-coins etc.

  • Lending, borrowing, and yield optimization products enabling one-click interactions

  • Perpetual trading platforms requiring seamless interaction with multiple-chain contracts and protocols

  • Wallets emphasizing superior user experience

  • NFT purchases across multiple chains

Key Features and Capabilities

Account

The Toolkit is compatible with embedded account providers such as Turnkey and Privy.

A consistent principle across all accounts is the signer key, used for signing on the user side, residing within a Wallet-as-a-Service, with application doing signing requests to it given user authentication. This approach facilitates social login and single-click or zero-click signing experiences.

Currently supported account types:

  • EVM Chains: Kernel 3.1 account with custom ECDSA validator (allows on-chain fund extraction without third-party dependencies)

  • EVM Chains: Kernel 3.1 account with default ECDSA validator (most widely adopted; simplest option for enhancing UX)

  • EVM Chains: 7702 EOA delegating to Kernel 4337 with default ECDSA validator (best for post-Pectra EVM world; available only on chains supporting the 7702 upgrade)

  • Solana: EOA (25'Q2)

  • Bitcoin: EOA (25'Q3)

Let us know via Discord or X if you want other accounts to be integrated, or use this form to contact us.

Transaction Types

All transaction types enable spending from aggregated balances, providing a consistent multi-chain user experience equivalent to same-chain interactions. This streamlined process involves:

  1. Application submits high-level intent to the API

  2. Toolkit returns a quote, detailing expected outcomes and associated costs, along with transactions payload for optimal execution

  3. Application signs and submits transactions for execution back to the API

Supported transaction types include:

  1. Transfer: send funds to any chain regardless of which chains user assets are distributed on.

  2. Swap: same but for swaps.

  3. Calldata execution: Protocol interactions (e.g., staking, sending orders etc.)

  4. Bridging: Explicit cross-chain asset management

Exact Input and Exact Output Modes

Toolkit supports transactions specifying exact spending amounts (exact input) for transfers, swaps and bridging, as well as transactions specifying exact amounts to be received (exact output) for calldata executions and transfers.

Execution Optimization

When assets span multiple chains or reside on the execution chain, the Toolkit automatically optimizes execution paths. Applications only need to specify their intent, and the Toolkit ensures optimal routing and execution.

Gas Abstraction

Toolkit applications achieve default gas abstraction for all user transactions. The current mechanism involves applications subsidizing transactions through paymaster providers such as Pimlico, subsequently recovering gas costs through user transaction fees, generating revenue streams for the application.

Fees

From inception, applications can define flexible user fees per transaction, configurable by chain and transaction type. Fees collected from users are intended to:

  • Offset application-subsidized gas fees

  • Generate robust and flexible revenue streams

Supported Chains

Currently supported chains include:

  • Ethereum Mainnet, Arbitrum, Base, Optimism, Polygon, BNB, Blast, Linea, Avalanche

  • Additional EVM chains planned

  • Solana support in Q2, Bitcoin support in Q3

For additional chain support, please contact us via Discord or X, or use this form.

Tokens

To utilize tokens across chains in an abstracted manner, applications define tokens considered interchangeable across multiple chains. Applications can either configure their token mappings or use existing configurations.

Toolkit operations support both chain-abstracted tokens and chain-specific tokens. As such, the bridging operation is swapping one chain-specific token to another.

As a separate use-case, applications can aggregate various stablecoins into a unified USD balance, automatically abstracting different stablecoin versions if needed.

Chain abstracted balance

For chain-abstracted tokens Toolkit provides the aggregated balances via a separate endpoint. If Resource Lock is enabled, these balances will be delivered with respect to the spent but not yet settled (locked) assets.

Resource Lock

The Resource Lock concept, introduced by OneBalance in early 2024, has significantly enhanced multi-chain transaction efficiency. It enables cross-chain executions at the speed of the destination chain, delivering a seamless user experience comparable to same-chain transactions.

Applications enable Resource Lock via the Toolkit. Once enabled, all user transactions are co-signed by OneBalance, preventing double-spending during asynchronous multi-chain executions.

For the account with custom ESDCA validator, the Resource Lock is enforced on-chain via validating the co-signing on the smart contract level. For all other accounts, it happens off-chain inside the WaaS policy engine, meaning it is compatible with all the chains (and not only EVMs), doesn't require on-chain transaction to enable/disable and doesn't require coordination across chains on the its state.

Resource lock is optional in using the Toolkit, and can always be plugged in and plugged out.

NextUsing OneBalance SCA

Last updated 2 hours ago