On October 28, 2026, blockchain data provider Allium said it had found unauthorized access to some of its systems on October 25. It brought its core app, Explorer and Explorer APIs back online, revoked existing API keys, and kept backfilling delayed datasets. The incident shows something every automated trader should plan for: when a data source comes back online, its data is not necessarily fresh or complete yet. This crypto data feed checklist splits recovery into separate states, so you can tell whether your strategies actually evaluated every candle they were meant to.
This article uses Allium’s own updates and news reporting as context. Gimmer is not affiliated with Allium, and this article does not claim any connection between Allium and Gimmer or any of Allium’s customers. Allium has not said how the access happened or whether customer data was taken, and nothing here suggests otherwise. Nothing here is a trading signal or a statement about any company or asset.
What happened
In its security update, dated October 28 and signed by CEO Ethan Chan, Allium says it identified a security incident on October 25 involving unauthorized access to certain systems. It restricted access, notified affected customers directly and hired an independent cybersecurity firm. The post says the core platform is back online, says “some features remain temporarily unavailable as recovery continues,” and promises a summary of findings once the investigation ends.
Allium’s status page logs the recovery step by step, with times in US Eastern time. An Explorer outage opened at 19:31 on October 25, and the app was taken offline as a precaution on October 26. A separate datashare incident opened at 18:09 on October 26. It warned that delivery was delayed in all regions and that customers “may see stale data or errors” when querying. Delivery resumed at 18:00 on October 27, with a note that some tables could show small gaps around the restart. At 09:00 on October 28, the Explorer and API were back, but existing API keys were being revoked and users had to set new passwords. By 15:47 that day, raw and enriched tables for 18 chains had passed freshness and completeness checks on two warehouse platforms. Backfill was still running for other chains and for one platform’s records. crypto.news reported that the AI Assistant and MCP service were still unavailable. It also stressed that Allium has not confirmed which customers were affected.
The status timeline shows recovery as several states, not one switch:
- Online: the service answers requests again.
- Authenticated: your client can still get in, which it cannot if the key it uses was revoked.
- Delivering: new records are arriving again.
- Fresh: the newest record is as recent as the schedule says it should be.
- Complete: the gap from the outage has been backfilled and checked.
A dashboard can show “operational” once the first state is true, while the other four are still open.
Common mistakes after a data source recovers
Traders who run automation on third-party data make the same assumptions again and again:
- Uptime counts as freshness: a service that answers requests can still be serving yesterday’s records. Allium’s own wording warned about stale data while delivery was delayed.
- Revoked keys fail quietly: a script, notebook or dashboard that used an old key may show errors or empty results, and nobody reads them. Until someone does, it looks like a quiet market.
- Gaps around the restart go unread: records from the outage window get backfilled later. Any decision, report or backtest made before the backfill used a dataset with a hole in it.
- “No trade” is read as “working”: a strategy that holds on every candle looks the same as one that stopped evaluating, unless you check when each candle was actually evaluated.
A five-state crypto data feed checklist
Fill in one row for every data source your strategies or research depend on, whether that is an exchange feed, a data vendor or an internal pipeline. Write down what state the source has reached, and the evidence that shows it.
| State | Question to answer | Evidence to keep |
|---|---|---|
| 1. Online | Does the source respond, and when did its status page say it recovered? | The status-page entry and its timestamp and time zone. |
| 2. Authenticated | Were any credentials revoked or rotated, and has every client that uses them been updated? | A list of clients and the date each one switched to the new credential, with no secret values written down. |
| 3. Delivering | When did new records start arriving again? | The time of the first new record after the outage. |
| 4. Fresh and complete | Is the newest record on schedule, and has the outage window been backfilled and verified? | The newest record time compared with the expected interval, and the provider’s backfill notice. |
| 5. Evaluated | Did each of your strategies evaluate every expected closed candle during and after the outage window? | A list of expected candle times against the times your runtime actually evaluated, with any gaps marked. |
A row where the source is online but the newest record is late, or where expected candle times have no matching evaluation, is the one to look at first.
Run the checklist with Gimmer’s simulation and runtime monitoring
Gimmer’s Simulation and live guide opens with a line that is the core of this checklist: “Keep every expected candle evaluation observable.” It covers the last row of the table, the one that matters most to an automated strategy.
Read Runtime activity against the candle schedule
The guide’s “Understand the live feed” section explains that Runtime activity shows the newest events first and loads older history as you scroll, and that each event keeps its closed-candle time. Its key sentence: “A healthy feed advances with the strategy interval even when the final action is hold.” For the Evaluated row, list the closed candles you expected over the outage window and match each one to an event. A hold is evidence the strategy ran. A missing event is the gap to explain.
Use the stall table before drawing conclusions
The “Detect and recover a stalled strategy” section has a table of signals, including “Other strategies tick, one does not,” “All strategies stop,” “Activity advances but orders fail” and “Feed looks old.” For that last one, the guide says to “compare the displayed candle time with the configured interval and timezone before concluding it is stalled.” That is the same check as the Fresh row, done inside the workspace. Status pages often use local time and candles often close in UTC, so write the time zone next to every timestamp you record.
Treat catch-up after a restart as something to check
The guide says that after a restart Gimmer “should reconcile the last processed candle and catch up missing closed candles.” The word is “should”, so treat it as a claim to check, not a guarantee. After a restart, confirm in Runtime activity that the missed candles appear once each and in order. If you see duplicate events or positions, the guide says not to retry blindly, and to keep identifiers and timestamps so you can reconcile.
Stay in simulation until every row is closed
The guide’s first section is “Choose simulation first”. Live execution comes only after a representative backtest, a healthy simulation and accepting the real-money trading terms in the app. If a data source you rely on is still backfilling, that is a reason to stay in simulation until the gap is closed. Related reading: why “back online” is not one state covers network-level recovery, the candle data quality checklist shows how gaps distort backtests, and the stale balance-data article explains what delayed records do to rebalancing.
A short example: one outage window, five states
Consider a synthetic trader who runs two strategies in simulation on one-hour candles, and also uses a third-party on-chain dataset for research.
- They read the October 28 status updates and note the facts and their time zone. They change nothing in either strategy because of the headline alone.
- For the Authenticated row, they find that a research notebook stopped returning rows after a key was revoked. They create a new key with the provider, store it outside the notebook, and record the date of the switch.
- For the Fresh and complete row, they write down the newest record time and the provider’s backfill notice. They leave any analysis that touches the outage window marked unverified.
- In Gimmer they open Runtime activity for each strategy and list the expected hourly closes for the window. One strategy shows a hold on every hour. The other is missing two evaluations from a night the laptop slept. That gap has nothing to do with the provider, and they note it.
- They keep both strategies in simulation, fix the sleep setting, and check that the next expected closed candle appears on schedule before thinking about live execution.
The result is a dated record of what was verified and what was not. The example is not a recommendation about any data source, asset, interval or strategy.
What this data feed checklist cannot do
- It cannot tell you whether a provider’s backfilled data is correct, only whether the provider says it was checked and whether your own spot checks agree.
- It cannot reveal the cause of a security incident or whether any data was exposed. Wait for the provider’s own findings.
- Runtime activity shows the final decision for each candle. It does not prove the market data behind that decision was right, or that an order will fill.
- A complete evaluation history does not make a strategy profitable or safe, and catching up after a restart is expected behavior, not a guarantee.
- Rotating a credential protects you going forward. It does not undo anything that happened while the old one was valid.
Trading digital assets involves substantial risk. Backtests and simulations do not guarantee future results, and no checklist, monitoring feed or risk control guarantees that data is fresh or that an order will execute.
Frequently asked questions
Does the Allium incident involve Gimmer?
This article claims no connection between Allium and Gimmer. The checklist applies to any data source your automation or research depends on, whatever tools you use.
My strategy made no trades during the outage. Is that a problem?
Not by itself. No trade can be normal. The check that matters is whether every expected closed candle was evaluated. A hold on schedule is healthy, and a missing evaluation needs attention.
Should I rerun backtests that cover the outage window?
If the data behind a backtest was pulled before the provider finished backfilling, rerun it once the provider says the window is complete. Compare the two results, and treat both as models, not forecasts.
Check freshness before you trust the feed
Allium’s investigation is still going, and its full findings are not out yet. The lesson for automation does not depend on how it ends: a service that is back online is a start, fresh and complete data is evidence, and every expected candle evaluation should be something you can see.
Next step: open Gimmer’s Simulation and live guide, read Runtime activity against your strategy interval, and fill in the five-state table for every data source your strategies depend on.
— The Gimmer Team