​
Available Configurations for EVM (details below)

ConfigurationValidatorVersionDeploymentResource Lock Options
BasicECDSAValidatorKernel 3.1ERC-4337Can be enabled
EIP-7702ECDSAValidatorKernel 3.3EIP-7702Can be enabled
Role-BasedRoleBasedValidatorKernel 3.1EIP-4337Always enabled
Screenshot2025 05 29at12 32 52 Pn
OneBalance supports a modular architecture designed to accommodate various account types. We are happy to support other account versions on demand or advise which one works best for your application.

​
Choosing the Right Configuration

When selecting an account model for your integration, consider your specific requirements for compatibility, performance, and access control.
ConfigurationProsCons
Basic- Most adopted 4337-type account
- Simplest in use and UI/UX
- Easy to integrate, if already in use within the application		- Contract upgrades, if required, are cumbersome
Role-Based- Secure in emergency cases related to WaaS/TEE- Consumes slightly more gas
EIP-7702- More gas efficient
- Easier future contract upgrades
- Can act as both EOA and Smart Account		- Recently introduced by the Ethereum account standard, not yet widely battle-proven
- Not yet supported on all EVMs

​
Getting Started with Account Models

Follow the Getting Started guide, which uses Role-Based configuration.

​
Signer Compatibility

The OneBalance Toolkit is designed to work with various signer providers:
SignerAccountStandard Path (no RL)Enabling Resource Lock
turnkeyBasic🟢 Available🟢 Available
EIP-7702🟢 Available🟢 Available
Role-BasedRL can’t be disabled🟢 Available
solanaEarly Q3Early Q3
privyBasic🟢 Available🟢 Available
EIP-7702🟢 AvailableIn design
Role-BasedRL can’t be disabled🟢 Available
solanaEarly Q3In design
Other signersOther accountsOn demand, case by caseOn demand, case by case

​
Account Components Explanation

The OneBalance account system consists of several key components that can be combined in different ways:

Validators

Authentication, Access Control, PermissionsValidator is a module of smart account

Account Versions

Optimized for various deployment methodsSmart Contract Implementation

Deployment type

How accounts are initialized
Directly affects user deposit (account) address

Resource Lock

Allows fast path cross-chain executionRequires gatekeeping at the account/signing level

​
Supported Validator Types

Validators are responsible for authenticating transactions and managing account access:

ECDSAValidator (Default)

Uses standard Elliptic Curve Digital Signature Algorithm for authentication, compatible with most existing wallet infrastructures.

RoleBasedValidator

Allows to have a user_admin role (think user cold wallet) next to the signer role to rotate keys and execute trustless rage quit in emergency case.

​
Supported Smart Account Versions

Kernel 3.1

Compatible with: Both ECDSAValidator and RoleBasedValidatorThe versatile version that supports multiple validator types and is widely compatible across different configurations.

Kernel 3.3

Optimized for: EIP-7702 deployments with ECDSAValidatorA specialized version designed to take advantage of the latest EIP-7702 standard for improved gas efficiency.
These account versions are based on an open-source smart contract account implementation.

​
Deployment Methods

EIP-4337 (Account Abstraction)

The established standard for smart contract accounts across EVM chains. User address in the UI is the Smart Account address, the signer existance is hidden.

EIP-7702

A newer, optimized approach for account abstraction with potential gas savings. User addres in the UI is the EOA address with imlementation being referenced as a universal smart contract.

​
Resource Lock options for Account

Resource Lock disabled

Execution happens only traditional way requiring sequential cross-chain transactions. Transactions can be sent both with OneBalance API and standrard JSON-RPC.

Resource Lock enabled

Enhanced execution using Resource Locks for near-instant cross-chain transactions. Once enabled, transactions can be sent only through OneBalance API.
To learn more about how Resource Locks enable Fast Path execution and improve transaction speed
and reliability, see our detailed Resource Locks documentation.

​
Multi-Account Support

With the introduction of Solana support, OneBalance now supports operations across multiple blockchain accounts through new API endpoints. This enables cross-chain operations between EVM and non-EVM chains.

​
Account Array Structure

The v3 endpoints use an accounts array instead of a single account object: 
{
  "from": {
    "accounts": [
      {
        "type": "role-based",
        "sessionAddress": "0x...",
        "adminAddress": "0x...",
        "accountAddress": "0x..."
      },
      {
        "type": "solana",
        "accountAddress": "J5CCzBULFax899tcirb6wMbenQUd8whbaetG7EfSick5"
      }
    ],
    "asset": { "assetId": "ob:usdc" },
    "amount": "1000000"
  }
}

​
Solana Account Type

Solana accounts use a simplified structure with just the account address: 
{
  "type": "solana",
  "accountAddress": "J5CCzBULFax899tcirb6wMbenQUd8whbaetG7EfSick5"
}
Solana accounts are EOA-style addresses (base58 encoded) and don’t require session/admin addresses like EVM smart accounts.

​
Account Compatibility Rules

The accounts array supports specific combinations based on blockchain compatibility:
First Account TypeSecond Account TypeValid?Use Case
role-basedsolana✅Cross-chain operations
kernel-v3.1-ecdsasolana✅Cross-chain operations
kernel-v3.3-ecdsasolana✅Cross-chain operations
solana-✅Solana-only operations
role-basedkernel-v3.1-ecdsa❌Both are EVM accounts
role-basedkernel-v3.3-ecdsa❌Both are EVM accounts
solanasolana❌Duplicate chain type
You cannot combine multiple accounts of the same chain type (e.g., two EVM accounts or two Solana accounts) in a single request.

​
When to Use Multi-Account

Use multiple accounts when:
  • Performing cross-chain swaps (Solana ↔ EVM)
  • Using aggregated balances from multiple chains
  • Transferring assets between different blockchain ecosystems
Use single account when:
  • Operating within a single blockchain (EVM-only or Solana-only)
  • All required assets are on the same chain

​
Backwards Compatibility

v1 endpoints continue to work for EVM-only operations using the single account format. v3 endpoints are required for any Solana integration or multi-chain operations.

​
Resources

Ethereum Improvement Proposals Community Resources