> ## Documentation Index
> Fetch the complete documentation index at: https://docs.defiloops.com/llms.txt
> Use this file to discover all available pages before exploring further.

# How live data reaches your card

> The one path every piece of live market data takes: from a source, to stored history, to views, to the cards that read it. What starts it, what stops it and what happens when a source fails.

**In short:** a card that reacts to the market needs a live number. That number comes from the **feed runtime**, the one path all live data takes. A source produces the value. We store every value as history. Views turn history into the series a card reads. The card wakes when the value changes. Every venue and network goes through the same path, so a card can watch one venue and trade on another.

This page covers live data. A card can read 2,625 data feeds. [What we hold](https://docs.defiloops.com/data/streams.md) lists the stored history and where each series starts.

## Where data comes from

Three kinds of source feed the runtime.

| source | what it gives | stamped with |
| - | - | - |
| Venue market data | Candles, mark and index prices and funding from venues such as Hyperliquid and Lighter | the venue's own time |
| The swap router | A price for each token pair on Ethereum, Base and Arbitrum, every time the rate changes | the block number and block time |
| Network reads | Hourly DEX pool volume, lending reserve limits and prices, a lending position, Lighter deposits and withdrawals | the block number and block time |

A venue is only a source. It does not decide where a card trades. A card may trigger on Hyperliquid data and place its order on Binance, because the data path and the trading venue are chosen separately.

> [!NOTE]
>
> Your balances, positions, orders and fills are **not** on this path. They live in your account's own records and come from the venues and the network directly. The runtime carries market data, plus the lending and Lighter account reads listed above.

## History is kept

Every value that enters the runtime is written to stored history with its own time. A venue keeps only a short window of its own data, and that limit loses nothing here, because we hold our own copy.

How far back the history reaches depends on the series:

* **Router prices and pool volume** start on the day we first switched that feed on. They are recorded as they happen, so they cannot be backfilled.
* **Candles from the venues** keep one-minute bars for 3 days. Coarser bars go back further. See [What we hold](https://docs.defiloops.com/data/streams.md) for each start date.

A feed that restarts reads its own history and rebuilds. Nothing starts from an empty page.

## One producer per feed

Each feed has exactly one producer. Every card, view and tool that needs the value reads that one producer's output. Ten cards watching the same price cause one read from the source, not ten.

Feeds also start and stop with demand:

1. A live card announces which feeds it reads.
2. The runtime starts any feed that nobody is producing yet.
3. When the last card that reads a feed stops, the feed runs on for a short grace period, then stops.

A few feeds that everything needs, such as the router's prices, stay on all the time.

## When a source fails

The runtime assumes sources fail, and it fails closed.

* **A crash stays small.** Each feed, view and card runs on its own. If one crashes, only that one restarts, and it rebuilds from stored history. A card that crashes again and again is parked, so it cannot take the rest down.
* **Stale data is marked.** A price older than 15 seconds is stale. When a price is stale, nothing writes a new value, and the old value ages in plain sight. Triggers refuse to act on it.
* **A missing price stops the card.** A card's caps and fills read prices from the stored feeds. If a token has no fresh price, the card is refused. There is no fallback to an older number.
* **Checks fail closed.** Each outside call has a timeout and a circuit breaker. When a source or a database stops answering, the breaker opens and the runtime waits. It does not guess.
* **Prices get a second opinion.** When a card is saved, the router's price for each pair it swaps is compared with an independent reference, and a gap of more than 2% refuses the card. When a swap is signed, the enclave checks its floor against its own price source.

## Triggers act on the latest value

A trigger reads the newest value, not a confirmed one. When a feed changes, the cards that read it wake at once.

A network can rewrite a recent block. When that happens, the runtime corrects its stored history. It never blocks a trade for a reorganisation, and it does not undo a trade that already ran on the earlier value.

## Views

A raw view shows one source: one pool's hourly volume, or one market's closed bars at one minute, one hour, four hours and one day. A combined view joins several sources into one series.

Views are scripts in the same Pine-style language as a [measure](https://docs.defiloops.com/cards/overview.md). They are not hand-built per source. A view runs inside a sandbox with a hard limit on memory and on work per call, so a bad script cannot stall the feed. Cards and measures read views. They do not read sources.

## What is live today

| part | status |
| - | - |
| Router prices, closed bars and derived prices on Ethereum, Base and Arbitrum | live |
| Hourly pool volume for curated USDC pools on Base, with views | live |
| Lending reserve reads on Base and Ethereum, and your lending position on Base | live, only while a card needs them |
| Hyperliquid and Lighter candles and Lighter market data | live |
| Lighter deposit and withdrawal reads on Ethereum | live |
| Feeds that start and stop with card demand | live |
| Price-triggered plans woken by feed changes | live |
| Pine-style views | live |

Price alerts for owners and your own fills as a feed are not available yet.

## Under the hood

For engineers and anyone checking the guarantees. Each guarantee below is a design rule of the runtime.

* **Isolation.** The runtime is a set of independent supervised processes: one per source, feed, view and card. A failure restarts one process. Repeated failures park it.
* **Memory is bounded.** Every process has a heap cap. In-memory series are fixed-size rings. Nothing grows with input, and no names are created from outside data.
* **No unbounded queues.** Prices coalesce to the latest value per key, so a slow reader sees the newest price and never a backlog. Writers have a queue cap. At the cap they shed the oldest entry and count it.
* **Every call has a timeout.** Databases and outside services sit behind circuit breakers that fail closed.
* **Validation at every boundary.** Inbound data is checked against a schema before any process sees it. Refusals are counted.
* **Kill switches and alarms.** Each producer can be switched off on its own, and one global switch stops them all. Parked, shed and refused counts are exported as metrics.
* **One producer by registration.** A feed key has a single owner. A second producer for the same key is refused.
* **Services use mutual authentication.** The runtime, the router and the order service talk over encrypted links where each side proves its identity.
* **Event index trimming.** The index of raw chain events is trimmed after 7 days and never inside twice the reorganisation depth. It is a working index. The feed history is the record.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.