exec_funding

exec_funding is one of the shapes the historical store holds. A stored series lives under a kind= path segment, and that segment is the layout contract its producers and its consumers have to agree on: the columns, how the leaf is partitioned, and what venue and symbol mean for this particular kind. All of it is below, rendered from the same table the runtime dispatches on.

One decoded row becomes a crate::funding_log::FundingRow. The codec that owns the schema is FundingCodec; the store writes through append_funding and reads through scan_funding.

Identity

venue = the perp venue; symbol = the venue COIN (BTC, not BTCUSDT), which is why this series never collides with that symbol's public prints

This is the field most often assumed and most often wrong, which is why it is stated per kind rather than once for the store.

Columns

Every Arrow column today's writer emits, in schema order, with the codec flavor that picks its Arrow type and nullability.

Layout

Traps

The ACCOUNT's REALIZED funding — what this account actually paid or received. ⚠ The NAME COLLISION this row used to carry is RESOLVED by decision 0080: the bare word funding sat on this, the SPECIALISED case, while the MARKET funding-RATE history lives in the bar row above under interval=funding. The account plane's prefix now does the work, so exec_fill/exec_order/exec_funding share one and a reader can see which side a kind is on. The market rate was deliberately NOT renamed — interval is part of SeriesId and bar series exist, so that migration is not free. ⚠ The partition key is (venue, coin) and the account is NOT in it; the ACCOUNT COLUMN is what makes two accounts' payments for one coin separable, because hash is the venue TRANSACTION hash and names no account — before that column a main account's -1200 and a test account's -30 read back as -1230, unsubtractable. Whether to ALSO partition per account is left open by 0079 and is now a convenience question. ⚠ hist rm REFUSES this kind by name, as it does every account kind, because it deletes by SERIES and one series holds both accounts. ⚠ The trait default no longer lies: append_funding/scan_funding return DataError::Unsupported rather than Ok(0)/Ok(vec![]), so a store that cannot hold this kind says so instead of reporting a successful write of nothing.

Pinned rather than fixed: the contradiction is recorded with both sides named, so a reader meets it here instead of in production.

Known producers

Idempotency in this store is batch-level and keyed on a commit-key string, never on per-row value dedup. Two producers that collide on one template silently no-op each other's appends, and a producer that changes its template re-admits history it already wrote — both invisible unless the shapes are written side by side.

⚠ That list is observed, not exhaustive, and no gate can make it so: a commit key is an ordinary string argument, so proving the list complete would mean following every call in the workspace. What is gated per listed entry is that the producer exists and spells the template verbatim. Read it as "these producers write this kind", never as "only these do".

Where this comes from

vike_data::store_kind::STORE_KINDS, exported as rosters.json at every release. The store's own gate derives the live kind set from the code — the series directory literals, the compaction dispatch and the write verbs — and fails until a new kind has a row, so this page cannot describe a shape the store does not write.