This often happens when your bot's RPC call times out, but the transaction actually made it to some validators and is in an 'in-flight' state. Since Sui requires a quorum of validators to finalize, your client doesn't get a confirmation. When your bot tries to submit another transaction (or even retry the same one), it uses a stale sequence number or conflicts with the pending transaction. The 'wallet locked' state is a safety mechanism to prevent double-spending while a transaction for that address is actively being processed or is in an ambiguous state. It resets at epoch boundaries as a final cleanup. To fix this, your bot needs robust transaction status monitoring. After any submission, especially on a timeout, actively poll the chain for the transaction's digest or the sender's current sequence number. Never assume a timeout means failure. Always fetch the latest sequence number from the chain before crafting a new transaction to avoid conflicts, and implement smart retry logic with exponential backoff if a transaction truly fails or remains unconfirmed.

Ah, the 'Failed to sign by quorum' issue after RPC timeouts – super frustrating! What's likely happening is your bot sends a transaction, but the RPC times out before your client gets a definitive 'yes' or 'no.' The network, however, probably did receive that transaction and assigned it a sequence number. When your bot tries to send the next transaction, it's using what it thinks is the next sequence number, but the network is expecting a different one (because the first one was already 'used' or is pending). This mismatch effectively 'locks' the wallet because any new transaction with the 'wrong' sequence number gets rejected. The lock releases at epoch change because the network eventually prunes unfinalized transactions, resetting the state. To fix this: 1. Robust Retry/Query Logic: After an RPC timeout, don't immediately re-send the same transaction. Instead, query the network to find out the actual latest committed sequence number for your wallet. 2. Explicit Sequence Number Management: Your bot needs to be super careful about tracking the next expected sequence number. Always fetch it fresh before signing a new transaction, especially after a potential failure. 3. Use WaitForLocalExecution: When submitting transactions via sui_executeTransactionBlock, use WaitForLocalExecution for the request_type. This waits for the transaction to be fully executed and state updated, giving you more reliable confirmation. 4. Dummy Transaction (Last Resort): If you're really stuck, you can sometimes unblock by sending a small, zero-value self-transfer with the problematic sequence number to clear it and advance to the next.

This issue occurs when two concurrent transactions are attempted simultaneously, leading to the objects being locked until the end of the current epoch. Unfortunately, you'll need to wait for the epoch to end and then try again.