🧩Obi Stack Overview
Overview of the modular component groups of the Obi stack
The Obi stack has multiple component groups which can be swapped out or upgraded independently, without adversely affecting users.
Depending on your experience with various technologies, you may find it helpful to think of Obi's core technology as:
🧩 a modular accounts blockchain which quietly integrates with all chains, without requiring backend integration work or cross-chain messaging
🛠️ a robust all-chain permission system, allowing existing use cases such as spend limits, inheritance, subscriptions, budgets, session keys, gasless MEV-shielded cross-chain intents, and purpose-bound "worker addresses" – in addition to new use cases not yet deployed
🔑 a near-zero-latency gasless MPC helper network – like a Ledger hardware wallet adding to your security, but as a network – where even nodes, downtime, or secure hardware vulnerabilities do not jeopardize user funds or access
🔒 a security network bringing standardization to user accounts across blockchains
😄 an all-chain, seamless, recoverable, hack-resistant user account experience
Transaction Flow
A typical transaction involves:
The user signs the transaction request with their Multikey threshold (or with a user-authorized allowance account or easy session key).
The Obi signer finalizes the signature with the network share, an irretrievable share which can only sign if step 2 allowed the transaction.
This final signed transaction is broadcast directly or via 4337 relay/paymaster.
Step 1 is local to the client application. Under most conditions, steps 2 and 3 are gasless queries. Step 4 fees are covered by the paymaster.
The user is unaware of most of this process. They sign a transaction – sometimes automatically in the case of easy restricted session keys – and then can see the results on the destination network (target chain).
Last updated
