On October 26, 2026, Nasdaq-listed Datavault AI filed a Form 8-K saying it has been unable to complete a bitcoin withdrawal it requested in June 2026 from a wallet maintained at the Biconomy exchange, and that several of its past financial statements should no longer be relied upon. The shares fell about 50% on October 27. Whatever the final explanation turns out to be, the filing shows a gap every automated trader should keep in view: a balance a venue shows you is not the same thing as capital you can move. This crypto withdrawal checklist separates those states, so your records and your strategies rely only on balances you have actually checked.
This article uses a public filing and news reporting as context. Gimmer is not affiliated with Datavault AI, Scilex or Biconomy, does not integrate any of them, and nothing here alleges wrongdoing by any party; the filing does not give a reason for the delay. Nothing here is a trading signal or a statement about any exchange, company or asset.
What happened
According to Datavault AI’s Form 8-K, filed under Item 4.02 (Non-Reliance on Previously Issued Financial Statements) and signed on October 26, the story starts with a September 2025 agreement in which Scilex Holding Company would buy $150 million of Datavault shares and warrants, paid in bitcoin. The filing says Scilex credited 1,309.04 BTC to Datavault’s wallet at Biconomy through off-chain transfers, and that between September 26, 2025 and January 30, 2026 Datavault sold 491.431 BTC back to Scilex for about $40.5 million in cash. In June 2026 the company asked to withdraw bitcoin from that wallet to an external account. As of the filing, it says it has been unable to complete the withdrawal.
On October 20, management and the audit committee decided the bitcoin should not have been recorded as a crypto asset at all. It is to be treated as an amount owed by Scilex instead. The preliminary corrections reduce reported total assets by $8.1 million as of September 30, 2025, $92.2 million as of December 31, 2025, $57.1 million as of March 31, 2026 and $49.0 million as of June 30, 2026. The company warns it may find more errors. It also says it had counted the bitcoin balances as a source of liquidity when assessing whether it could keep operating, and that this assessment is being revisited. CoinDesk reported that the shares closed at $0.067 on Tuesday, October 27, down 49.55%. It added that Biconomy had not responded to a request for comment.
The filing is about more than one balance. It shows four records that people often treat as one:
- Credited: a balance shown inside a venue’s own ledger. In this case it got there through off-chain transfers.
- Withdrawable: a balance you have actually moved to an address you control, with an on-chain transaction to prove it.
- Recorded: what your own books, spreadsheets or application state say you hold.
- Relied upon: the balance your plans, liquidity assumptions or automated position sizing treat as available.
Datavault’s restatement happened because the second state never confirmed the first, while the third and fourth had already been built on it.
Common mistakes with exchange balances
Traders who run automation on centralized venues tend to make the same assumptions:
- A number on screen is treated as custody: a credited balance is an entry in someone else’s database. Until a withdrawal completes, it is a claim on the venue, not an asset in your wallet.
- Off-chain credits are never tested: internal transfers and deposits between accounts on the same platform settle instantly in the venue’s ledger, so nobody checks whether the funds could leave.
- Local state outlives reality: an application, backup or spreadsheet keeps showing yesterday’s balance and positions long after the venue’s state has changed.
- Sizing rules count everything: percentage-based position sizing and portfolio targets read the full venue balance. If part of that balance is stuck, every order is sized against capital you cannot use.
A five-state crypto withdrawal checklist
Fill in one row per venue where you hold funds or run a strategy. The point is to write down which state each balance has reached, and the proof that it got there.
| State | Question to answer | Evidence to keep |
|---|---|---|
| 1. Credited | What does the venue show, and how did the balance arrive: on-chain deposit, internal transfer or trade? | A dated statement or export from the venue, with the deposit or transfer IDs. |
| 2. Withdrawable | Have you recently completed a small withdrawal to an address you control, and how long did it take? | The on-chain transaction ID, the amount, the fee and the request and arrival times. |
| 3. Recorded | Does your local record agree with the venue, and when was it last updated? | A labelled backup or export with its date, plus the venue statement it was checked against. |
| 4. Reconciled | Do positions, pending orders, balances and connected accounts match between your records and the venue? | A short list of differences found and how each was resolved. |
| 5. Relied upon | Which part of the balance do your strategies size against, and does it leave out anything unverified? | The sizing settings and the reserve you hold back, with the date you last reviewed them. |
A row where the credited balance is large, the last withdrawal test is old or missing, and strategies size against the full amount is the row to look at first.
Use Gimmer’s backup and recovery guide to keep records honest
Gimmer’s Backup and recovery guide is written for moving or restoring a workspace, but its core sentence applies directly here: “a local backup can restore Gimmer state, but an exchange or wallet remains an external source of truth.” Four of its steps map onto the checklist.
Stop changing state, then export a labelled record
The guide’s first steps are “Stop changing state,” which means pausing configuration edits and checking for live strategies or open positions, and “Use the backup or export action in the current app.” It then asks you to store two copies, one encrypted offline, and to label each with the date and app version, keeping passwords and secrets out of the filename. That labelled backup is the evidence for the Recorded row: a dated snapshot of what your workspace believed at a known moment.
Reconcile against the venue, not against yourself
The guide says to compare local positions, pending orders, balances, allowances and connected accounts with the exchange or wallet before restarting any strategy. That is the Reconciled row. Do the comparison on the venue’s own website or statement, not inside any application. A withdrawal test is a separate step you do yourself at the exchange. Gimmer’s exchange connection guide says “Never enable withdrawals for Gimmer,” so moving funds is never something you delegate to the app.
Do not blindly resume automation
The guide’s callout is titled “Do not blindly resume automation.” It warns that restored local state can be older than the exchange, and that a strategy could act on a wrong position or balance. The same risk applies when the venue’s balance itself is in doubt. Its restore steps end with “Reconcile external accounts, then resume in simulation before live execution,” which keeps the Relied upon row conservative until the facts are settled.
Back up again when risk changes
The guide lists when to back up again, including “After changing wallet or exchange connections” and after materially changing important strategies. If you reduce exposure at a venue, move funds or reconnect an account, take a fresh labelled backup so your records match the new state. Related reading: the exchange shutdown checklist covers offboarding a venue in order, the stale balance-data article shows how outdated balances distort rebalancing, and the API key permission checklist explains why a trading key should never be able to withdraw.
A short example: one venue, five states
Consider a synthetic trader who keeps 0.80 BTC at one exchange and runs a small spot strategy against it in simulation, with plans to go live.
- They read the October 26 filing and note the facts it states, including that no reason for the delay was given. They change nothing in the strategy because of the headline alone.
- For the Credited row, they download a dated statement. It shows that 0.30 BTC arrived as an internal transfer from another account on the same platform, and 0.50 BTC as on-chain deposits.
- For the Withdrawable row, they withdraw 0.01 BTC to a wallet they control, directly on the exchange website. They record the transaction ID and the arrival time, and the withdrawal completes.
- In Gimmer they pause edits, use the backup action, label the file with the date and app version, and compare positions, pending orders and balances with the exchange statement. They find one cancelled order that local history still showed as pending, and note it.
- For the Relied upon row, they lower the strategy’s fixed position size so that sizing does not depend on the internally transferred portion, and keep running in simulation until the next expected candle evaluation appears in runtime activity.
The result is a written record of what is verified and what is not. It is not a guarantee about the venue. The example is not a recommendation about any exchange, asset, position size or strategy.
What this withdrawal checklist cannot do
- A successful small withdrawal shows the path worked at that moment. It does not prove a larger amount can leave, or that the venue will stay solvent or open.
- It cannot reveal how a venue holds customer assets, or whether a credited balance is fully backed.
- Gimmer cannot withdraw funds, and its guides tell you never to give it withdrawal permission. Every withdrawal test happens at the exchange, under your control.
- A backup records what the workspace believed. It is not an independent source of truth, and restoring one does not change anything at the venue.
- Reconciliation finds differences; it cannot recover funds.
Trading digital assets involves substantial risk. Backtests and simulations do not guarantee future results, and no checklist, backup or risk control guarantees that funds held at a third party can be withdrawn.
Frequently asked questions
Does the Datavault AI filing involve Gimmer?
No. Gimmer has no connection to Datavault AI, Scilex or Biconomy. The checklist applies to any venue where you hold a balance, whatever tools you use.
How often should I test a withdrawal?
There is no universal schedule. Many operators test after a material deposit, after a venue changes its terms, and before relying on a balance for live trading. Date each test so the evidence does not go stale.
Can I restore an old Gimmer backup and keep trading?
Not without reconciling first. The guide says restored state can be older than the exchange, so compare positions, pending orders and balances with the venue, then resume in simulation before any live execution.
Verify the balance before you rely on it
The Datavault AI case is still developing, and the filing leaves the cause of the delay open. The lesson for automation does not depend on how it ends: a credited balance is a claim, a completed withdrawal is evidence, and your records should only reflect what you have checked.
Next step: open Gimmer’s Backup and recovery guide, take a labelled backup, and fill in the five-state table for every venue that holds funds your strategies size against.
— The Gimmer Team