AccountInUse

The runtime could not lock all accounts needed by this transaction because another transaction in the same block is already using one of them.

Common causes

1. Contention on a hot account. High-traffic programs like AMM pools or order books cause many transactions to compete for the same writable account in the same slot.
2. Duplicate account in instructions. Passing the same account as writable in multiple instructions within a single transaction can trigger this during parallel scheduling.
3. Burst of transactions. Sending many transactions that touch the same account in rapid succession.

How to fix

1. Retry with backoff. The lock conflict is transient — resend the transaction with a fresh blockhash.
2. Use different accounts. If your program supports it, spread state across multiple accounts to reduce contention.
3. Add priority fees. Higher-priority transactions are scheduled first, reducing the chance of lock conflicts.

How to prevent

• Architect programs to use per-user accounts rather than a single global state account.
• When interacting with popular DeFi protocols, add a compute unit price to improve scheduling priority.
• Avoid sending duplicate transactions to the same account in the same slot window.

FAQ

Is AccountInUse the same as a transaction failure? Not exactly. The transaction is not executed — it is rejected before execution because the scheduler could not acquire the account locks.

Does this happen more on mainnet than devnet? Yes. Mainnet has far more traffic, so account lock contention is much more common, especially on popular DeFi program accounts.

Updated: 2026-10-21