Glossary
Last updated
Last updated
See .
The address or public key associated with the signature of an incoming request to the or threshold contract. This is the party trying to transact on behalf of the user account, and it may be the or a party authorized by a .
A type which checks parameters of transactions, such as , contract address, action/function name, message type, and parameters. Only matching transactions are allowed; otherwise, the action is blocked, unless the caller is . Policies are stored in user-state contract and logic executed by the gatekeeper-message contract, where relevant policies are called Authorizations. EVM targets currently only support and contract address filtering.
The internal name for any kind of which depends on message inspection, such as , , , and policies. Action-limited session keys can be created by using expiration in conjunction with such policies.
A type which checks parameters of transactions, such as , contract address, action/function name, message type, and parameters. A matching transaction is blocked. Policies are stored in user-state contract and logic executed by the gatekeeper-message contract, where relevant policies are called Authorizations. EVM targets currently only support and contract address filtering.
The unique identifier for a or . The code base and documentation uses "home chain ID" and "target chain ID" to avoid confusion.
Externally Owned Account. A traditional blockchain account, where a private key produces signatures which can be verified to belong to the corresponding public key, and thus directly controls addresses and assets. An Obi account is not an EOA, but it can control any number of EOAs on any number of chains.
A design principle for distributed applications which uses specialized distributed networks for specific purposes in the stack – such as using one chain for settlement, consensus, execution, and data availability.
Obi's place in the modular space. Unlike most other modular solutions, Obi accounts can be used seamlessly without the blockchain or application developers needing to even have knowledge of it.
A Japanese word for certain types of belts. In addition, bi is the Mandarin word for "coin."
The service and account which covers fees for user transactions on EVM chains.
A type which checks parameters of transactions, such as , contract address, action/function name, message type, and parameters. A delay can then be enforced if the parameters match a delay policy. Policies are stored in user-state contract and logic executed by the gatekeeper-message contract, where relevant policies are called Authorizations. EVM targets currently only support and contract address filtering.
A special contract which handles on EVM chains. Note that in the Rust contract code – including code – "entry point" also refers to the various home account contract messages: instantiate, execute, migrate, sudo and query.
A pre-authorized route across multiple chains. Due to the limitations of multi-chain messaging protocols, in most instances, a non-custodial is used to complete subsequent steps of a fast travel transaction. However, the worker is only authorized to proceed with the Fast Travel route approved by the user – a will refuse to sign any other transactions.
An authorized by a , such as a spendlimit account, an beneficiary, or a . Used to distinguish authorized accounts from and their smart accounts (whether or ). A is architecturally identical, but is intended to be easily triggered and bound to , not directly controlled by another person or device.
Obi's MPC signature finalization runs on a query, which passes no gas cost on to the user, returns instantly without waiting for block time, and costs the node 1/80th of the resources of a typical transaction. Gas is still paid by the user or their sponsor on the , whether directly or via fee abstraction (feegrant or ERC-4337 paymaster).
The user's account on the .
A user's home chain is where their smart account lives – where are stored and enforced. In current implementations, this is also where the threshold (MPC) contract lives, and can sign for various . In the future, multiple signers will be available. The home chain ID is currently secret-4. It will be obi-1 upon Obi network activation, with secret-4 as a backup.
Intent-bound cannot have their modified. This is doubly ensured by the address keypair combining the intent with its entropy – meaning that if a signature is created for a different intent (such as a different asset, receiver, or slippage setting), the signature will not even match and no execution can proceed.
A special kind of (allowance) which has a "dormancy period" (cooldown in contract code). Inheritanced beneficiaries cannot act unless the account has been dormant for this amount of time. Governed by the gatekeeper-spendlimit contract.
In the context of distributed applications, an intent is a (trans)action where the user expresses their desire – such as obtaining a specific asset – without needing to execute the various complex details needed to reach that objective. For example, the user may say "I wish to convert this ETH on Arbitrum to a wstETH/ETH LP on a Cosmos chain," instead of separately signing the 10-12 transactions usually required to perform such an action. Obi can restrict intent solvers, whether AI or otherwise, so that they cannot violate customizable .
The user; the address or public key (preferably a ) which is the ultimate owner of the user . The owner is the only signing party authorized to take admin actions such as updating the account, updating the owner, and adding .
Enabling a "one-click login experience" that can still protect the user from destructive or accidental actions, a sessionkey is a temporary authorization to transact until the expiration time is reached. A sessionkey can destroy itself or can be destroyed by the owner at any time. The sessionkey can be limited by any other kinds of limitations, such as , message restrictions, contract address restrictions, and more. The "sessionkey policy" is an abstraction itself; it is expressed in code by attaching an expiration to some other kind of . An admin-level sessionkey is simply an unrestricted (actor matching only) with an expiration attached.
A special smart contract which can finalize signatures for transactions, regardless of their , if and only if they are allowed to be signed by some , r they are signed by the full of the user account. The finalization is the final round of threshold MPC signing. A threshold signer has access – in a secure, isolated Intel SGX hardware environment – to a single share of a user's private key.
A smart contract account. Transactions are only approved if they match the held in smart contract code/state, which may be simple ("Is the actor the ?") or complex ("Is the actor an active , and does this transaction spend funds less than or equal to the session key's remaining ?"). The Smart Account does not itself finalize transaction signatures – prior to finalizing, the asks the relevant smart account if the given message may be signed for the given .
An allowance, permitting an to spend a user account's funds. The usual term "allowance" is generally avoided here to distinguish from token contract allowances, which are handled by token contracts instead of account contracts. A spendlimit can be used for a budget or subscription. On some chains, spendlimits can be unified, meaning that assets with known price sources can be converted to the spendlimit asset when verifying transactions. For example, ETH could be spent by an with a USDC unified spendlimit. Spendlimits are governed by the gatekeeper-spendlimit contract, and entries include params for spendlimit details and beneficiary_params for inheritance details. A single /address can have both.
The destination "actor" for a transaction – the account associated with the transaction on the . Assets and addresses on various target chains (Ethereum, Arbitrum, Polygon, Bitcoin, Cosmos, Osmosis, etc.) can be controlled by the user's smart account on their home chain, thanks to threshold signer contracts. From the perspective of the target chain, a transaction is a simple, standard transaction – whether an EOA or SCA transaction – and there is no need for the chain to be aware that an Obi Account's transaction policies were checked in order to finalize the transaction signature.
The destination chain for a transaction. One can control addresses/accounts on any number of target chains.
A permission; a rule which allows a certain actor (public key/address) to complete transactions under certain conditions, or which prohibits/delays an actor or actors from completing transactions under certain conditions. Transaction policy types currently available include /// list, , , , and policies – which can be used as allowance/budget or subscription policies.
A transaction policy type which checks parameters of transactions, such as , contract address, action/function name, message type, and parameters. Blockchain actions can be triggered – whether directly or by appending to messages. Policies are stored in user-state contracts and logic executed by the gatekeeper-message contract, where relevant policies are called . EVM targets currently only support and contract address filtering.
A target user account which is not an EOA but an ERC4337 contract account on an EVM chain. This may also apply to analogous accounts on Cosmos chains and Solana in the future. This is different from the user's core smart account, which is a . UAC or SCA (smart contract account) is used, as this is an industry standard term, but we clarify " contract" as much as possible. These contracts are deployed implicitly or on demand to . The address is known ahead of time, and is the same across all target EVM chains. can be signed by the user's target private key and executed on target chains.
The user's entry point. This is the address where the user's home assets, if any, are kept.
An ERC4337-compliant wrapped transaction. This is a normal Ethereum transaction packed and signed in such a way that a bundler/paymaster can submit the transaction and cover fees for the user. The user operation is by the user's private key. This target private key has a deterministic association with the user's ultimate ERC4337 target account address, but it does not have a direct cryptographic association. In other words, if you imported this private key into a traditional wallet, the resulting public key and address would be different from the user's ERC4337 address.
often apply to other individuals, but they can also be used to implicitly create -bound addresses. Assets and other properties belonging to these addresses can only pursue the allowed intent. This allows non-custodial pre-authorized activity, such as , stop losses, and actions, without needing special smart contract pools or custodial solutions.