How OneBalance Works
Learn how OneBalance Toolkit integrates with your application
High-Level Overview of Toolkit Integration
Routing Overview
In most cases, when using the Toolkit, applications specify a high-level intent, which is then translated into the actual payload on the Toolkit side and provided to the client ready for signing. Routing in a chain-abstracted intent includes:
- Which chains are optimal to spend from, given the user’s balance is distributed across chains
- Whether bridging is required to perform an intent, or if it can be executed on the same chain
- What is the minimal bridging amount required to perform an intent
- Which solver/bundler provides the best execution price
- Whether a paymaster is needed or if the user pays for gas from their own account
Note that some optimizations from the list are work in progress and will be delivered soon.
The application does not need to worry about any of these - they are optimized on the Toolkit side. Read more on how transactions work in this section.
Account Overview
The OneBalance Toolkit is compatible with embedded signer providers such as Turnkey and Privy, as well as with applications that have direct access to signer keys (such as Web3 wallets and centralized exchanges).
The Toolkit utilizes accounts that are compatible with gas abstraction on all chains, so users never have to worry about paying gas. Read more on particular account options in this section.
Resource Lock & Fast Path
The Resource Lock concept, introduced by OneBalance in early 2024, has significantly enhanced multichain transaction efficiency.
More specifically, it allows asynchronous execution of a multichain intent, separating intent fulfillment from settlement, which makes multichain transactions feel like same-chain transactions for the user.
Applications enable Resource Locks via the Toolkit. Once enabled, all user transactions are co-signed (sequenced) by OneBalance, preventing double-spending during asynchronous multichain executions.
Monetization
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
Fees are settled with every user transaction as a transfer to the application wallet. Read more on how to configure fees in this section.