Obi Stack Overview
Overview of the modular component groups of the Obi stack
Last updated
Overview of the modular component groups of the Obi stack
Last updated
The Obi stack has multiple component groups which can be swapped out or upgraded independently, without adversely affecting users.
🧩 a modular accounts blockchain which quietly integrates with all chains, without requiring backend integration work or cross-chain messaging
🔑 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
A typical transaction involves:
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.
🛠️ a robust all-chain permission system, allowing existing use cases such as , , subscriptions, budgets, , cross-chain , and purpose-bound "worker addresses" – in addition to new use cases not yet deployed
The user signs the transaction request with their Multikey threshold (or with a user-authorized account or easy .
The user’s account or the transaction based on the current abstraction rules, the simplest of which is, “Is the sender/signer the account ?”
The Obi finalizes the signature with the network share, an irretrievable share which can only sign if step 2 allowed the transaction.
The user is unaware of most of this process. They sign a transaction – sometimes automatically in the case of easy restricted – and then can see the results on the destination network ().
