OneBalance
OneBalance
  • Welcome to OneBalance
  • OneBalance Toolkit
    • Introduction
    • Get Started with OneBalance SCA
      • Setup OneBalance Toolkit with Privy
        • Step 1: Setting up Privy
        • Step 2: Setting configurations
        • Step 3: Initializing and Depositing onto the OneBalance Smart Account
        • Step 4: Displaying Chain-Aggregated Balances
        • Step 5: Fetch a quote for transaction execution
        • Step 6: Signing transactions with Privy
        • Step 7: Executing transactions
        • Step 8: Getting execution status
      • Contract calls guide
        • Usage code samples
  • OneBalance vision
    • Our vision
      • Mission of OneBalance
      • Use Cases
      • Credible Accounts and Credible Stack
      • Fellowship of OneBalance
      • Glossary
    • Why resource locks?
      • Technical Details
        • Resource lock
        • Permissions
        • Credible accounts
        • Credible Commitment Machine (CCM)
        • FAQ
          • How does this relate to account abstraction and 4337?
          • Where does the OneBalance account live?
          • Are OneBalance accounts non-custodial?
      • Credible Stack Deep Dive
        • Apps
        • SDK providers
        • Wallets / WaaS
        • Solver Networks
        • Oracle Providers
        • Data Providers
  • Other
    • OneBalance Demo App
      • Roadmap
      • Privacy Policy
      • Terms and Conditions
    • OneBalance Brand Assets
Powered by GitBook
On this page
  1. OneBalance vision
  2. Why resource locks?
  3. Technical Details

Resource lock

A resource lock is a credible commitment made by a user to escrow some state conditional on particular conditions fulfilled, or an expiry time.

An example could be a cross-chain request to purchase an NFT on Solana using USDC deposited in the OneBalance account from Ethereum.

resource_lock: {
	lock: 1500 USDC,
	fulfill: DeGods #12345,
	expiry: Solana block 245547084
}

Resource locks are necessary to prevent solvers from being griefed by a user through double spending or equivocating their request during execution.

Since the user makes a commitment not to overwrite their request within a time window, it removes the uncertainty solvers typically incur between a transaction being signed and the finalized chain state.

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 provide solvers the chance to execute the requested state transition on the destination chain and submit a proof of fulfillment to the fulfillment engine.

Crucially, this introduces a separation between fulfillment time and settlement time. Since the account provides local assurance of the lock, solvers can bring a requested state transition on a destination chain without waiting for finality on the origin chain.

This allows 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 execution of any state transition such as sniping an NFT, sending money to your grandmother, or anything else users do on blockchains.

PreviousTechnical DetailsNextPermissions

Last updated 1 month ago