You may also like:
Intro
Since the inception of Ethereum (”ETH”), its popularity has soared, inspiring the creation of thousands of dApps, and millions of users onboarding to experience a decentralized world. However, due to its scalability restraints and high network fees, hundreds of alternative Layer 1 Blockchain solutions have arisen, providing faster throughput and cheaper transaction fees.
To tackle some of the constraints on ETH mainnet, several prolific projects have created Layer 2 networks to build on top of ETH and help it scale. This is also part of the second step in Ethereum’s roadmap - The Surge.
But what is the result? An overall worse user experience.
Instead of a simplistic user-centric approach of allowing them to choose which dApp they would like to use, users must also consider:
- Which chain they would like to operate on
- The liquidity available on each chain
- The balances they hold on different networks
- Time constraints moving between networks
- Gas fees to pay on each chain
- Type of gas token to be used as payment (Eg SOL on Solana, ETH on Ethereum)
It is clear that in order for the Web3 space to grow and become an alternative to traditional finance, we must pivot from a cross-chain approach to a chain-agnostic one. A user should not have to worry about any of the concerns listed above and be able to use Web3 in a way similar to the way they interact with applications in the Web2 world.
Introducing OneBalance, the brand new account model that allows for all participants to interact across all DLT solutions, whilst also unifying:
- Token balances across multiple chains
- Identities
- Liquidity
About OneBalance
OneBalance is a new chain abstracted credible account model that will allow a user to hold a singular balance across all chains and interact with any other dApp, on any other chain; quickly, **conveniently and reliably.
This was previously impossible with Externally Owned Accounts (”EOA”), ie your wallet in Metamask.
Why? EOA’s bundle the authentication and permissions issuance within their respective execution environment (ie the messages you sign to allow a dApp to use your funds to execute a transaction). Furthermore, due to the different signing schemes on different chains (ie one method to sign a txs on Solana being different to signing a txs on Ethereum), a singular EOA cannot be used across multiple chains. This has ultimately left users stranded, needing to utilize different EOAs (wallets) for different chains.
With OneBalance, we introduce programmable keys and credible off-chain resource locks that permanently unbundle the roles of the EOA.
As we pivot from a chain-centric view of Web3 and focus on an account centric view, we unlock the ability for tremendous innovations to be created in this ecosystem.
A OneBalance account allows:
- Combining tokens balances from every chain
- Reliably swapping and sending tokens to and from any chains
- Fast fulfillment through pre-confirmations with delayed settlement (ie buying a token on Solana with funds on Avalanche will be processed quickly through pre-confirmations)
A OneBalance account enables:
- Non-custodial Binance
- Decentralized Fireblocks
- Aggregation of all liquidity, on-chain and off-chain
- Using any credible token as the gas-token payment on any chain
Example 1
- Situation: A user has $10 of USDC on Solana
- Job to be done: Buy an NFT on Base.
Without OneBalance the user journey would be:
With OneBalance it would be simplified to the following:
Example 2:
- Situation: A user has $100 USDC spread across 3 networks (Injective, Solana, Avalanche)
- Job to be done: Buy a NFT on Base
Without OneBalance the user journey would be:
With OneBalance it would be simplified to the following:
Web3 today: EOA Account Model
The current Web3 ecosystem is based on an outdated account model that is used within all dApps and wallets. Present EOAs have a [public-private key pair] (link) that is accessed through the JSON-RPC API to manage all aspects of the user state.
EOAs play three crucial roles:
- Authentication: the user is who they say they are because they have the private key associated with the public key
- On-chain identity: the user stores their state (e.g. balance) at the address associated with their public key
- Permissions: the user issues permissions to execute transactions, which are picked up by the chain
But they have limitations:
- No way to authenticate with SSO (ie using your Google account to approve a transaction. similar to using your Facebook account to login to Spotify or other apps).
- Users can’t flexibly delegate granular control of their state (e.g., allowing a DEX to sign transactions automatically for 3 hours as the user will be trading frequently and doesn’t want to be approved every time).
- The key pair is tied and limited to their respective signing ecosystem (ie you cannot sign a message on Arbitrum, and execute a transaction on Tron).
Most importantly, EOAs aren’t able to provide the following capabilities:
- Allowing solvers to act as third party executors without risk of griefing. For example, if a user signals the intent to swap ETH-USDC, a solver should be able to instantly fill this intent without the risk of the user cancelling the txs or double spending.
- Programmatically issuing permissions to operate on user state while user is offline. For example, allowing the wallet to execute a limit order to buy BTC whilst you slept.
- Efficiently enforcing execution atomicity in an asynchronous environment. This means that current EOAs cannot revert the TXs if it is not fully executed (eg if a user wants to swap 100 USDC on ETH for SOL on Solana, scenarios exist where only part of the full txs is executed. They cannot provide guarantee’s for use user to have the full txs executed or nothing).
The OneBalance Account model will ensure the following characteristics:
- Let users or apps use any authentication mechanism. This could range from traditional methods of signing txs, to using user biometrics.
- Let users programmatically issue permissions to modify their state, even when offline. This is especially needed within Web3 gaming to allow users to sign a singular txs, and then have an uninterrupted gaming session. Another scenario could can be seen with traders wanting to set TWAP orders within DeFi
- Solvers can credibly rely on commitments made by users to provide cross chain execution. For example, if the user has the intent to swap wBTC (on ETH) for INJ (on Injective), the second the user signs the txs, the solver can take it as guaranteed without the fear of being griefed.
- Users can move seamlessly between a spectrum of different levels of custody, enabling progressive self-custody. For example, Telegram bots widely store the user keys but provide a great UX by managing tx execution for the user. On the other side of the spectrum lie multisigs, which is non-custodial, but the flexibility and UX are poor. OneBalance will allow the user to choose how self custodial they would like to be.
Web3 tomorrow: OneBalance Account Model
Each OneBalance account can be thought of as its own rollup. The account wraps individual user state (ie their balances) from all chains and replicates it in a virtual environment. This virtual environment allows users to transact within it by first “locking” the authorised funds to be transacted, before executing the transactions using cross-chain execution proofs.
Crucially, a OneBalance account can have an arbitrary number of sub accounts across any number of chains and can manage arbitrary state, therefore it is backwards compatible with all apps and assets including ERC20s, NFTs, DAOs, multisigs, defi protocols, and deposits or points campaigns.
A OneBalance account is governed by an extensible manifest file which provides an adaptable architecture that can reliably compose and evolve with all parts of the chain abstraction ecosystem. For example, a user has 100 USDC spread across 10 chains ($10 per chain) and wants to spend $500. Onebalance is adaptable to allow either the application or the user to decide.
With OneBalance accounts, you can seamlessly build apps that leverage cross-rollup pre-confirmation transactions to provide near instant finality and costless execution. No longer will you have to wait for delays in bridging, complications in UX, or issues with native token gas fees.
Technical details
Resource Lock Sequencer
A resource lock puts a portion of the user's balance from any chain into an escrow that specifies fulfillment conditions and expiry.
For example, the following resource lock could be a cross-chain Request For Quote (RFQ) that debits 70 USDC on Base but on the condition on 0.5 SOL being credited to the user account on Solana. The Ethereum block number is an arbitrary amount of time in the future. If those conditions are not met by that block number, then the 70 USDC will be returned to the user on Ethereum.
resource_lock: {
lock: 70 USDC on Ethereum,
condition: 0.5 SOL on Solana,
expiry: Ethereum block 19782324
}
Locks are necessary to prevent Solver from being griefed by the user through double spending or equivocating their request during execution.
A lock is analogous to depositing funds in a smart contract, or issuing an ERC20 approval, but without spending gas or waiting for on-chain finality since it is done within the account itself.
The lock expiry needs to be of long enough duration to give solvers the chance to execute the requested state transition on the destination chain and provide a proof of fulfillment to the OneBalance Fulfillment Engine.
Crucially, this introduces separation between fulfillment time and settlement time. Allowing users to buy SOL with ETH at the speed of Solana without being constrained by the speed of Ethereum. This fulfillment speed can be extended to any Web3 transaction such as minting an NFT, sniping a new memecoin, and other use cases yet unthought of.
Note that this does not eliminate the need for bridges as they remain necessary for settlement - it simply removes them from the critical path of fulfillment.
Permissions Engine
The Permissions Engine executes programs which issue permissions for apps to request state transitions through issuing resource locks on behalf of users.
.png)
Permission policies could could be stateful or stateless. For example:
- Scoped session keys: allow an app like a telegram bot to take arbitrary actions on subsets of a users token balances
- Circuit breaker: sell all open positions if there is no account activity or market volatility above a predefined threshold
- Limit order: post an order if a pair reaches a certain price on a DEX
- MFA: post a transaction if two valid authentication methods are provided
There exists four architectures of permission engine architectures which affords for secure provisioning and enforcement of locks: Trusted Execution Environments (TEEs), Multi-Party Computation / chain signatures (MPC), Smart Contract Accounts (SCAs), and in protocol virtual machine changes.
These technologies are all being refined as we speak. The ideal architecture today versus a year from now versus 5 years form now is going to evolve. Therefore the thing that matters today is to build a composable and adaptable architecture that can fit with all the parts of the ecosystem.
Roadmap
OneBalance v1:
- add support for transactions and swaps of any token on any chain
- add support for session keys for trusted applications
- add support for user rage quit through exit hatch
OneBalance v2:
- add support for stateless policies
- add support for arbitrary transactions
- add support for authentication modules
OneBalance v3:
- add support for arbitrary intents
- add support for stateful policies
OneBalance v4:
- add liveness guarantees through account replication
