Account Models
Understanding OneBalance account models and their capabilities.
Available Configurations for EVM (details below)
| Configuration | Validator | Version | Deployment | Resource Lock Options |
|---|---|---|---|---|
| Basic | ECDSAValidator | Kernel 3.1 | ERC-4337 | Can be enabled |
| EIP-7702 | ECDSAValidator | Kernel 3.3 | EIP-7702 | Can be enabled |
| Role-Based | RoleBasedValidator | Kernel 3.1 | EIP-4337 | Always enabled |
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.
| Configuration | Pros | Cons |
|---|---|---|
| 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:
| Signer | Account | Standard Path (no RL) | Enabling Resource Lock |
|---|---|---|---|
turnkey | Basic | 🟢 Available | 🟢 Available |
EIP-7702 | 🟢 Available | 🟢 Available | |
Role-Based | RL can’t be disabled | 🟢 Available | |
solana | Early Q3 | Early Q3 | |
privy | Basic | 🟢 Available | 🟢 Available |
EIP-7702 | 🟢 Available | In design | |
Role-Based | RL can’t be disabled | 🟢 Available | |
solana | Early Q3 | In design | |
| Other signers | Other accounts | On demand, case by case | On 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, Permissions
Validator is a module of smart account
Account Versions
Optimized for various deployment methods
Smart Contract Implementation
Deployment type
How accounts are initialized
Directly affects user deposit (account) address
Resource Lock
Allows fast path cross-chain execution
Requires 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 RoleBasedValidator
The versatile version that supports multiple validator types and is widely compatible across different configurations.
Kernel 3.3
Optimized for: EIP-7702 deployments with ECDSAValidator
A 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.
Resources
Ethereum Improvement Proposals
Community Resources