Every public number and what it actually means: its definition, source, unit, derivation class, and freshness window. This catalog is generated from the metric registry, so it stays aligned with the data surfaces.
106 available public metrics. Only metrics backed by an approved public source and a current public workspace appear in this catalog or its queries.
Showing 106 of 106 available public metrics
Capital & PUT
PUT collateral backingput_collateral_usd
Connected source
The dollar value of the collateral standing behind the perpetual-put obligation — the money that would have to be there if every put were exercised.
Unit
usd (2 dp)
Derivation
observed— read directly from a source
Source
ft.status.put.dashboard.v1
Upstream field
put.collateral_total_usd
Aggregation
last— a stock or running total; never summed across buckets
Freshness
expected every 5 minutes, stale after 1 hour
Entity
chain:{chainId}:ft-put
Chains
whatever chains the payload lists — never a list we maintain
Thresholds
none — see the methodology notes for why one is not set
Counts toward claimable totals
no
Methodology notes
Chain-scoped: the entity carries the chain id from the payload, so a new chain publishes without a registry change. Chains 1 (Ethereum) and 146 (Sonic) were the verified set on 2026-07-13.
No threshold yet. PRODUCT.md §8 defines a critical rule for "backing below obligations", but the obligation side of that comparison is not published by any endpoint we have a contract for — so the rule cannot be evaluated without fabricating the denominator. It stays unset until an obligations figure exists.
Backing history comes from the collateralPutValues daily series (fixture observed 2026-07-13: $51.94M → $51.53M). This is the ONLY value series we publish from the PUT dashboard — see the quarantined FT-denominated series below.
Strategy deploymentput_strategy_deployed_usd
Connected source
How much of the PUT collateral is currently working inside each external yield strategy (Aave, Spark, Lido and so on), in dollars.
Unit
usd (2 dp)
Derivation
observed— read directly from a source
Source
ft.status.put.dashboard.v1
Upstream field
put.strategy_deployed_usd
Aggregation
last— a stock or running total; never summed across buckets
whatever chains the payload lists — never a list we maintain
Thresholds
none — see the methodology notes for why one is not set
Counts toward claimable totals
no
Methodology notes
Strategies are read from collaterals[].vaultInfo.strategies — NOT from a top-level strategies key (the PoC read the wrong path; the production contract fixes it).
Feeds signature visualization A, the capital-flow Sankey (collateral → yield wrapper → strategy). Flow conservation is tested, so capital is never double-counted across the diagram, and only relationships actually present in first-party data are drawn.
No threshold. PRODUCT.md §8 has a critical rule for strategy allocation drift greater than 5 percentage points, but that rule needs the allocation PERCENT (deployedPct), which the current contract does not publish — only the dollar amount. Adding the rule requires a contract version that emits the percentage.
Strategy APYput_strategy_apy
Connected source
The annualised yield each strategy is currently earning on the PUT collateral it holds, as reported by the vault.
whatever chains the payload lists — never a list we maintain
Thresholds
none — see the methodology notes for why one is not set
Counts toward claimable totals
no
Methodology notes
Upstream calls this monthlyYieldAPY: an annualised rate computed from a trailing month. It is a rate of return, not a promise, and rolling it up across a range averages it rather than summing it.
Yield claimed (all time)put_yield_claimed_usd
Connected source
The total yield the PUT vault has actually harvested from its strategies since inception, in dollars.
Unit
usd (2 dp)
Derivation
observed— read directly from a source
Source
ft.status.put.dashboard.v1
Upstream field
put.yield_all_time_usd
Aggregation
last— a stock or running total; never summed across buckets
Freshness
expected every 5 minutes, stale after 1 hour
Entity
chain:{chainId}:ft-put
Chains
whatever chains the payload lists — never a list we maintain
Thresholds
none — see the methodology notes for why one is not set
Counts toward claimable totals
no
Methodology notes
A cumulative all-time total (fixture observed 2026-07-13: $1,053,851.06), so it aggregates as LAST, never as SUM — adding consecutive readings would count the same yield many times over.
This is strategy yield earned by the PUT vault. It is NOT application-fee revenue, and it is the main reason DefiLlama's fee figure and our application-fee figure differ so widely (see discrepancy_fees).
PUT circuit breakerput_cb_active
Connected source
Whether the PUT vault's circuit breaker is currently armed and limiting how fast capital can leave.
Unit
boolean (0 dp)
Derivation
observed— read directly from a source
Source
ft.status.put.dashboard.v1
Upstream field
put.cb_active
Aggregation
last— a stock or running total; never summed across buckets
Freshness
expected every 5 minutes, stale after 1 hour
Entity
chain:{chainId}:ft-put
Chains
whatever chains the payload lists — never a list we maintain
Thresholds
state-transition
Counts toward claimable totals
no
PRODUCT.md §8: circuit-breaker state change, any transition, critical. Phase 9.
Methodology notes
The breaker limits the draw rate (maxDrawRateBps, fixture observed 2026-07-13: 500 = 5%) over a 6-hour main window with a 2-hour elastic window. Active does not mean tripped — it means the control is armed.
Every transition is an event, and history accrues from the day collection starts. Nobody else keeps this history.
How many seconds until the PUT breaker's withdrawal buffer is fully refilled — in effect, how long until normal capacity returns.
Unit
seconds (0 dp)
Derivation
observed— read directly from a source
Source
ft.status.put.dashboard.v1
Upstream field
put.cb_replenish_seconds
Aggregation
last— a stock or running total; never summed across buckets
Freshness
expected every 5 minutes, stale after 1 hour
Entity
chain:{chainId}:ft-put
Chains
whatever chains the payload lists — never a list we maintain
Thresholds
none — see the methodology notes for why one is not set
Counts toward claimable totals
no
Methodology notes
A countdown, so it is only meaningful against its own observed_at — a stale reading is a wrong reading, and it renders with its age attached.
No threshold: PRODUCT.md §8 alerts on breaker state CHANGES, not on the countdown value.
PUT collateral backing (daily)put_collateral_series_usd
Connected source
The dollar value of the collateral standing behind the put obligation, one point per day. This is the history of the headline backing figure — the same money, tracked over time.
Unit
usd (2 dp)
Derivation
observed— read directly from a source
Source
ft.status.put.dashboard.v1
Upstream field
put.collateral_value_usd
Aggregation
last— a stock or running total; never summed across buckets
Freshness
expected every 5 minutes, stale after 1 hour
Entity
chain:{chainId}:ft-put
Chains
whatever chains the payload lists — never a list we maintain
Thresholds
none — see the methodology notes for why one is not set
Counts toward claimable totals
no
Methodology notes
From the collateralPutValues daily series. This is the ONLY value series published from the PUT dashboard: ftPutValues, ftWithdrawnValues and cumulativeFtBurned are quarantined for an undocumented ~1e15 scale defect and are plotted nowhere.
A daily bucket is a snapshot, not a flow, so a range aggregates as LAST — adding consecutive days together would count the same collateral once per day.
A stock, so the series and the headline put_collateral_usd must agree at the latest point (fixture observed 2026-07-13: $51.53M).
Collateral by assetput_collateral_asset_usd
Connected source
How much of the put backing each individual asset provides, in dollars — how much of the $51.5M is USDC, how much is WETH, and so on.
Unit
usd (2 dp)
Derivation
observed— read directly from a source
Source
ft.status.put.dashboard.v1
Upstream field
put.collateral_asset_supply_usd
Aggregation
last— a stock or running total; never summed across buckets
Freshness
expected every 5 minutes, stale after 1 hour
Entity
chain:{chainId}:ft-put:asset:{collateralAddress}
Chains
whatever chains the payload lists — never a list we maintain
Thresholds
none — see the methodology notes for why one is not set
Counts toward claimable totals
no
Methodology notes
The SOURCE layer of signature visualization A: each asset is one collateral node, and its supply is the capital that node routes into its vault. Summed across assets it reconciles to put_collateral_usd, and the Sankey test asserts that it does.
Keyed on the collateral CONTRACT ADDRESS, not the symbol. Symbols are reused across chains and re-pointed upstream; addresses are not.
Collateral share by assetput_collateral_asset_share_pct
Connected source
What proportion of the total put backing a single asset accounts for.
Unit
percent (2 dp)
Derivation
observed— read directly from a source
Source
ft.status.put.dashboard.v1
Upstream field
put.collateral_asset_share_pct
Aggregation
last— a stock or running total; never summed across buckets
Freshness
expected every 5 minutes, stale after 1 hour
Entity
chain:{chainId}:ft-put:asset:{collateralAddress}
Chains
whatever chains the payload lists — never a list we maintain
Thresholds
none — see the methodology notes for why one is not set
Counts toward claimable totals
no
Methodology notes
Upstream sharePct for the COLLATERAL layer, which reconciles to 100% and is trustworthy. It is not to be confused with the per-STRATEGY deployedPct, which does not: the WETH vault reports Spark at 100% and Lido at 30.5% of the same vault. Strategy shares on this workspace are therefore recomputed from deployed dollars and deployedPct is never read.
Breaker withdrawal bufferput_cb_main_buffer_usd
Connected source
How many dollars the circuit breaker will currently let out of the PUT vault before it starts throttling — the capital that can actually leave right now.
Unit
usd (2 dp)
Derivation
observed— read directly from a source
Source
ft.status.put.dashboard.v1
Upstream field
put.cb_main_buffer_usd
Aggregation
last— a stock or running total; never summed across buckets
Freshness
expected every 5 minutes, stale after 1 hour
Entity
chain:{chainId}:ft-put
Chains
whatever chains the payload lists — never a list we maintain
Thresholds
none — see the methodology notes for why one is not set
Counts toward claimable totals
no
Methodology notes
The buffer refills over the breaker's main window. It is a CAPACITY, not a balance — it does not mean the vault holds only this much (fixture observed 2026-07-13: a $2.10M buffer against $51.46M of vault value).
No threshold: PRODUCT.md §8 alerts on breaker STATE CHANGES, not on buffer level, and §13 D2 freezes new dashboard thresholds until an owner is named. A "buffer below X" rule here would be our opinion presented as the protocol's policy.
The total dollar value the PUT circuit breaker is watching over — the base its draw-rate limit is calculated against.
Unit
usd (2 dp)
Derivation
observed— read directly from a source
Source
ft.status.put.dashboard.v1
Upstream field
put.cb_total_value_usd
Aggregation
last— a stock or running total; never summed across buckets
Freshness
expected every 5 minutes, stale after 1 hour
Entity
chain:{chainId}:ft-put
Chains
whatever chains the payload lists — never a list we maintain
Thresholds
none — see the methodology notes for why one is not set
Counts toward claimable totals
no
Methodology notes
The breaker's own view of vault value, which sits slightly below the collateral total because it is measured at a different moment in the same snapshot (fixture observed 2026-07-13: $51.46M breaker vs $51.53M collateral). The gap is timing, not a discrepancy, and neither figure is adjusted to close it.
Breaker max draw rateput_cb_max_draw_rate_bps
Connected source
The fastest capital is allowed to leave the PUT vault, in basis points of its value per window. 500 bps means 5% can be withdrawn before the breaker throttles.
Unit
bps (0 dp)
Derivation
observed— read directly from a source
Source
ft.status.put.dashboard.v1
Upstream field
put.cb_max_draw_rate_bps
Aggregation
last— a stock or running total; never summed across buckets
Freshness
expected every 5 minutes, stale after 1 hour
Entity
chain:{chainId}:ft-put
Chains
whatever chains the payload lists — never a list we maintain
Thresholds
none — see the methodology notes for why one is not set
Counts toward claimable totals
no
Methodology notes
A protocol PARAMETER, not a measurement — it says what the breaker is configured to allow, not what is happening (fixture observed 2026-07-13: 500 bps = 5% over a 6-hour main window with a 2-hour elastic window).
A change to this value is a governance action and shows up in the event feed. It is one of the few numbers on this workspace that a human chose rather than a market produced.
The running total of yield the PUT vault has harvested from its strategies, one point per UTC week.
Unit
usd (2 dp)
Derivation
observed— read directly from a source
Source
ft.status.put.dashboard.v1
Upstream field
put.yield_cumulative_usd
Aggregation
last— a stock or running total; never summed across buckets
Freshness
expected every 5 minutes, stale after 1 hour
Entity
chain:{chainId}:ft-put
Chains
whatever chains the payload lists — never a list we maintain
Thresholds
none — see the methodology notes for why one is not set
Counts toward claimable totals
no
Methodology notes
CUMULATIVE, so it aggregates as LAST and never as SUM. Adding two weekly snapshots of a running total together would count every dollar of yield twice.
The upstream series is Monday-labelled and weekly. Freshness accepts the current partial UTC week or the previous completed UTC week, while independently requiring a current collection.
This is strategy yield earned BY the vault. It is not application-fee revenue, and the two are never added — see the Revenue workspace and discrepancy_fees.
Yield claimed (weekly)put_yield_weekly_usd
Connected source
Yield harvested by the PUT vault in each week — a flow, not a running total.
Unit
usd (2 dp)
Derivation
observed— read directly from a source
Source
ft.status.put.dashboard.v1
Upstream field
put.yield_weekly_usd
Aggregation
sum— a flow; a range total is the sum of its parts
Freshness
expected every 5 minutes, stale after 1 hour
Entity
chain:{chainId}:ft-put
Chains
whatever chains the payload lists — never a list we maintain
Thresholds
none — see the methodology notes for why one is not set
Counts toward claimable totals
no
Methodology notes
A FLOW, so it aggregates as SUM — the opposite of put_yield_cumulative_usd, which is the same yield expressed as a stock. The two must never be plotted on one axis or added to each other.
The upstream series is Monday-labelled and weekly. Freshness accepts the current partial UTC week or the previous completed UTC week, while independently requiring a current collection.
Capital divesting by collateralput_collateral_capital_divesting_usd
Connected source
Dollar value currently being moved out of strategies for each PUT collateral asset.
Unit
usd (2 dp)
Derivation
observed— read directly from a source
Source
ft.status.put.dashboard.v1
Upstream field
put.collateral_capital_divesting_usd
Aggregation
last— a stock or running total; never summed across buckets
Freshness
expected every 5 minutes, stale after 1 hour
Entity
chain:{chainId}:ft-put:asset:{collateralAddress}
Chains
whatever chains the payload lists — never a list we maintain
Thresholds
none — see the methodology notes for why one is not set
Counts toward claimable totals
no
Methodology notes
Directly from capitalDivestingUsd. It is a stock at the snapshot time and therefore aggregates as LAST.
PUT collateral withdrawable nowput_collateral_available_to_withdraw
Connected source
Token amount the collateral vault reports as available to withdraw at the current snapshot.
Unit
token (6 dp)
Derivation
observed— read directly from a source
Source
ft.status.put.dashboard.v1
Upstream field
put.collateral_available_to_withdraw
Aggregation
last— a stock or running total; never summed across buckets
Freshness
expected every 5 minutes, stale after 1 hour
Entity
chain:{chainId}:ft-put:asset:{collateralAddress}
Chains
whatever chains the payload lists — never a list we maintain
Thresholds
none — see the methodology notes for why one is not set
Counts toward claimable totals
no
Methodology notes
The raw integer is divided by that collateral token's declared decimals. Token amounts from different assets must not be added.
PUT withdrawal capacity by collateralput_collateral_available_to_withdraw_usd
Connected source
Comparable dollar value of each collateral vault's currently withdrawable token amount.
Unit
usd (2 dp)
Derivation
observed— read directly from a source
Source
ft.status.put.dashboard.v1
Upstream field
put.collateral_available_to_withdraw_usd
Aggregation
last— a stock or running total; never summed across buckets
Freshness
expected every 5 minutes, stale after 1 hour
Entity
chain:{chainId}:ft-put:asset:{collateralAddress}
Chains
whatever chains the payload lists — never a list we maintain
Thresholds
none — see the methodology notes for why one is not set
Counts toward claimable totals
no
Methodology notes
Calculated only from fields in the same upstream snapshot: withdrawable token amount multiplied by collateralSupplyUsd divided by collateralSupply. It is not a separate price feed or forecast.
PUT collateral breaker utilisationput_collateral_cb_utilization_bps
Connected source
Per-collateral circuit-breaker utilisation in basis points for assets whose breaker is exposed.
Unit
bps (0 dp)
Derivation
observed— read directly from a source
Source
ft.status.put.dashboard.v1
Upstream field
put.collateral_cb_utilization_bps
Aggregation
last— a stock or running total; never summed across buckets
Freshness
expected every 5 minutes, stale after 1 hour
Entity
chain:{chainId}:ft-put:asset:{collateralAddress}
Chains
whatever chains the payload lists — never a list we maintain
Thresholds
none — see the methodology notes for why one is not set
Counts toward claimable totals
no
Methodology notes
Absent for collaterals whose upstream circuitBreaker is null; absence is not converted to zero.
PUT collateral low-liquidity flagput_collateral_cb_low_liquidity
Connected source
Whether the upstream collateral circuit breaker currently flags low liquidity for that asset.
Unit
boolean (0 dp)
Derivation
observed— read directly from a source
Source
ft.status.put.dashboard.v1
Upstream field
put.collateral_cb_low_liquidity
Aggregation
last— a stock or running total; never summed across buckets
Freshness
expected every 5 minutes, stale after 1 hour
Entity
chain:{chainId}:ft-put:asset:{collateralAddress}
Chains
whatever chains the payload lists — never a list we maintain
Thresholds
none — see the methodology notes for why one is not set
Counts toward claimable totals
no
Methodology notes
Published only when the per-collateral breaker object exists. A missing breaker remains unavailable rather than false.
Protocol share of collateral supplyput_collateral_protocol_supply_pct
Connected source
Percentage of the asset supply attributed to the protocol by the PUT dashboard.
Unit
percent (2 dp)
Derivation
observed— read directly from a source
Source
ft.status.put.dashboard.v1
Upstream field
put.collateral_protocol_supply_pct
Aggregation
last— a stock or running total; never summed across buckets
Freshness
expected every 5 minutes, stale after 1 hour
Entity
chain:{chainId}:ft-put:asset:{collateralAddress}
Chains
whatever chains the payload lists — never a list we maintain
Thresholds
none — see the methodology notes for why one is not set
Counts toward claimable totals
no
Methodology notes
Direct upstream percentage. It is contextual composition data, not a balance and not added across assets.
ftUSD
ftUSD supplyftusd_supply
Connected source
How many ftUSD tokens exist on each chain — the amount of the stablecoin actually issued.
Unit
token (4 dp)
Derivation
observed— read directly from a source
Source
ft.status.ftusd.dashboard.v1
Upstream field
ftusd.supply
Aggregation
last— a stock or running total; never summed across buckets
Freshness
expected every 5 minutes, stale after 1 hour
Entity
chain:{chainId}:ftusd
Chains
whatever chains the payload lists — never a list we maintain
Chain-scoped: the entity carries the chain id from the payload, so a new chain publishes without a registry change. Chains 1 (Ethereum) and 146 (Sonic) were the verified set on 2026-07-13.
Our figure covers Ethereum AND Sonic. DefiLlama's covers Ethereum only, which is why the two disagree — see discrepancy_ftusd_supply. Neither is wrong; they count different things.
ftUSD market priceftusd_market_peg
Partial
What one ftUSD actually trades for on the open market. This is the number that tells you whether the peg is holding — it is NOT the protocol's internal $1.00 accounting value.
Unit
usd_per_token (6 dp)
Derivation
observed— read directly from a source
Source
coingecko.coin.ftusd.v1
Upstream field
ftusd.market_price_usd
Aggregation
last— a stock or running total; never summed across buckets
Freshness
expected every 1 hour, stale after 2 days
Entity
token:ftusd
Chains
not chain-scoped
Thresholds
deviation-band
Counts toward claimable totals
no
PRODUCT.md §8: ±50 bps warn, ±100 bps critical. These are DASHBOARD thresholds, not confirmed Flying Tulip policy. §13 D2 freezes them until an owner is named — they must not be tuned without that decision.
Methodology notes
This drives signature visualization B, the peg-deviation band: a $1.0000 centre line with deviation in basis points. Using the accounting price there would draw a permanently perfect peg — a lie by construction.
Primary source is CoinGecko (flying-tulip-usd), pending its API key. DefiLlama stablecoin 421 publishes the same market price and IS enabled, so it acts as the live cross-check; its coverage went Ethereum-only on 2026-07-09.
Deviation bands are dashboard policy. They are labeled as such in the UI so nobody reads a warn band as a protocol guarantee.
The $1.00 value the protocol uses for ftUSD in its own books. It is fixed by definition and will essentially never move, so it says nothing about whether the peg is holding — compare it with the market price for that.
Unit
usd_per_token (6 dp)
Derivation
observed— read directly from a source
Source
ft.status.ftusd.dashboard.v1
Upstream field
ftusd.accounting_price_usd
Aggregation
last— a stock or running total; never summed across buckets
Freshness
expected every 5 minutes, stale after 1 hour
Entity
chain:{chainId}:ftusd
Chains
whatever chains the payload lists — never a list we maintain
Thresholds
none — see the methodology notes for why one is not set
Counts toward claimable totals
no
Methodology notes
Collected and published, but kept SEPARATE from the market peg and labeled "accounting value" everywhere it renders. It never appears on the peg band and is never used to compute deviation.
It exists in the registry precisely so that the difference between "what the protocol books" and "what the market pays" is visible rather than hidden.
No threshold: a fixed accounting constant cannot deviate. Alerting on it would be theatre.
ftUSD APYftusd_apy
Connected source
The annualised return currently being paid to ftUSD stakers.
Unit
percent (2 dp)
Derivation
observed— read directly from a source
Source
ft.status.ftusd.dashboard.v1
Upstream field
ftusd.apy_pct
Aggregation
mean— a rate; ranges average it, never sum it
Freshness
expected every 5 minutes, stale after 1 hour
Entity
chain:{chainId}:ftusd
Chains
whatever chains the payload lists — never a list we maintain
Thresholds
none — see the methodology notes for why one is not set
Counts toward claimable totals
no
Methodology notes
A rate, so ranges average it rather than summing it. It is a current rate, not a realised return, and not a forecast.
sftUSD stakedsftusd_staked
Connected source
How much ftUSD is currently staked, measured as the supply of the sftUSD receipt token you get in return.
Unit
token (4 dp)
Derivation
observed— read directly from a source
Source
ft.ftusd.staking.v1
Upstream field
ftusd.staking_sftusd_supply
Aggregation
last— a stock or running total; never summed across buckets
Freshness
expected every 5 minutes, stale after 1 hour
Entity
chain:{chainId}:ftusd:staking
Chains
whatever chains the payload lists — never a list we maintain
Thresholds
none — see the methodology notes for why one is not set
Counts toward claimable totals
no
Methodology notes
Scaled by the token's own declared decimals, which the contract pins and re-checks on every collection — a decimals change quarantines rather than silently rescaling the series.
Staking runs in epochs per chain (fixture observed 2026-07-13: Sonic epoch 182, Ethereum epoch 171), so a cross-chain comparison at a single instant compares different epochs.
ftUSD circuit breakerftusd_cb_active
Connected source
Whether ftUSD's circuit breaker is armed on this chain, capping how much can be withdrawn in a window.
Unit
boolean (0 dp)
Derivation
observed— read directly from a source
Source
ft.ftusd.cb-limits.v1
Upstream field
ftusd.cb_active
Aggregation
last— a stock or running total; never summed across buckets
Freshness
expected every 2 minutes, stale after 15 minutes
Entity
chain:{chainId}:ftusd:cb
Chains
whatever chains the payload lists — never a list we maintain
Thresholds
state-transition
Counts toward claimable totals
no
PRODUCT.md §8: circuit-breaker state change, any transition, critical. Phase 9.
Methodology notes
Armed is the normal, healthy state — it is a control that exists, not an alarm that is sounding. Paused is the state that stops redemptions (see ftusd_cb_paused).
ftUSD withdrawals pausedftusd_cb_paused
Connected source
Whether ftUSD withdrawals are currently paused on this chain. If this is true, holders cannot redeem right now.
Unit
boolean (0 dp)
Derivation
observed— read directly from a source
Source
ft.ftusd.cb-limits.v1
Upstream field
ftusd.cb_paused
Aggregation
last— a stock or running total; never summed across buckets
Freshness
expected every 2 minutes, stale after 15 minutes
Entity
chain:{chainId}:ftusd:cb
Chains
whatever chains the payload lists — never a list we maintain
Thresholds
state-transition
Counts toward claimable totals
no
PRODUCT.md §8: circuit-breaker state change, any transition, critical. Phase 9.
Methodology notes
This is the single most consequential boolean on the ftUSD workspace: it is the difference between "the peg is under pressure" and "you cannot get your money out". It is rendered as a state, never buried in a chart.
Settlement delayftusd_settlement_delay
Connected source
How long a redemption has to wait before it settles, in seconds — the queue a holder joins when they redeem ftUSD.
Unit
seconds (0 dp)
Derivation
observed— read directly from a source
Source
ft.ftusd.cb-limits.v1
Upstream field
ftusd.cb_settlement_delay_seconds
Aggregation
last— a stock or running total; never summed across buckets
Freshness
expected every 2 minutes, stale after 15 minutes
Entity
chain:{chainId}:ftusd:cb
Chains
whatever chains the payload lists — never a list we maintain
Thresholds
none — see the methodology notes for why one is not set
Counts toward claimable totals
no
Methodology notes
A protocol parameter, not a measurement of queue depth. PRODUCT.md §8 does have a "withdrawal queue depth" rule, but depth comes from the ftUSD circuit-breaker QUEUE endpoint, which is a separate internal contract that is still pending approval — so no threshold hangs on this metric.
ftUSD TVLftusd_tvl_usd
Connected source
The dollar value of the collateral backing ftUSD on each chain — what is actually held against the stablecoin that has been issued.
Unit
usd (2 dp)
Derivation
observed— read directly from a source
Source
ft.status.ftusd.dashboard.v1
Upstream field
ftusd.tvl_usd
Aggregation
last— a stock or running total; never summed across buckets
Freshness
expected every 5 minutes, stale after 1 hour
Entity
chain:{chainId}:ftusd
Chains
whatever chains the payload lists — never a list we maintain
Thresholds
none — see the methodology notes for why one is not set
Counts toward claimable totals
no
Methodology notes
Chain-scoped: the entity carries the chain id from the payload, so a new chain publishes without a registry change. Chains 1 (Ethereum) and 146 (Sonic) were the verified set on 2026-07-13.
Backing, against ftusd_supply's issuance. The two are published side by side precisely so a reader can compare them rather than being handed a ratio we computed for them.
ftUSD collateral by assetftusd_collateral_usd
Connected source
How much of the ftUSD backing each individual asset provides, in dollars.
Unit
usd (2 dp)
Derivation
observed— read directly from a source
Source
ft.status.ftusd.dashboard.v1
Upstream field
ftusd.collateral_tvl_usd
Aggregation
last— a stock or running total; never summed across buckets
Freshness
expected every 5 minutes, stale after 1 hour
Entity
chain:{chainId}:ftusd:asset:{collateralAddress}
Chains
whatever chains the payload lists — never a list we maintain
Thresholds
none — see the methodology notes for why one is not set
Counts toward claimable totals
no
Methodology notes
Keyed on the collateral contract address, never the symbol. The composition differs by chain (fixture observed 2026-07-13: Ethereum is USDC + USDT, Sonic is USDC + USSD), so a single cross-chain "collateral mix" would blur two different answers into one.
ftUSD collateral shareftusd_collateral_share_pct
Connected source
What proportion of a chain's ftUSD backing a single asset accounts for.
Unit
percent (2 dp)
Derivation
observed— read directly from a source
Source
ft.status.ftusd.dashboard.v1
Upstream field
ftusd.collateral_share_pct
Aggregation
last— a stock or running total; never summed across buckets
Freshness
expected every 5 minutes, stale after 1 hour
Entity
chain:{chainId}:ftusd:asset:{collateralAddress}
Chains
whatever chains the payload lists — never a list we maintain
Thresholds
none — see the methodology notes for why one is not set
Counts toward claimable totals
no
Methodology notes
A share of ONE CHAIN's collateral, not of the protocol's. Shares from different chains do not add up to anything and are never summed.
Withdrawable now (breaker limit)ftusd_cb_withdrawal_capacity
Connected source
How much of an asset the ftUSD circuit breaker will actually let you withdraw right now. This is the number that matters when you want your money out — it can be far below the total collateral held.
Unit
token (6 dp)
Derivation
observed— read directly from a source
Source
ft.ftusd.cb-limits.v1
Upstream field
ftusd.cb_withdrawal_capacity
Aggregation
last— a stock or running total; never summed across buckets
Freshness
expected every 2 minutes, stale after 15 minutes
Entity
chain:{chainId}:ftusd:cb:asset:{assetAddress}
Chains
whatever chains the payload lists — never a list we maintain
Thresholds
none — see the methodology notes for why one is not set
Counts toward claimable totals
no
Methodology notes
In TOKEN units of the asset, not dollars — it is a redemption capacity, and it is scaled by the asset's own declared decimals (fixture observed 2026-07-13: 254.18K USDC on Ethereum, 36.91K USDC on Sonic).
The distance between this and the chain's total collateral is the honest answer to "can I actually get out right now?", and it is why the number is shown rather than the reassuring one.
No threshold: PRODUCT.md §8's withdrawal rule keys on QUEUE DEPTH, which comes from the ftUSD circuit-breaker queue endpoint — a separate contract still pending approval. A capacity threshold invented here would not be that rule.
Breaker utilisationftusd_cb_utilization_bps
Connected source
How much of an asset's withdrawal capacity has already been used in the current window, in basis points. At 10,000 bps the breaker is exhausted and withdrawals of that asset stop until it replenishes.
Unit
bps (0 dp)
Derivation
observed— read directly from a source
Source
ft.ftusd.cb-limits.v1
Upstream field
ftusd.cb_utilization_bps
Aggregation
last— a stock or running total; never summed across buckets
Freshness
expected every 2 minutes, stale after 15 minutes
Entity
chain:{chainId}:ftusd:cb:asset:{assetAddress}
Chains
whatever chains the payload lists — never a list we maintain
Thresholds
none — see the methodology notes for why one is not set
Counts toward claimable totals
no
Methodology notes
The leading indicator on this workspace: it moves before ftusd_cb_paused does. Rising utilisation is the redemption pressure that a pause is the end state of.
No warn/critical band. PRODUCT.md §8 approves no utilisation threshold and §13 D2 freezes new ones until a named owner exists — an 80/90% band here would be our judgement wearing the protocol's clothes.
Asset withdrawals pausedftusd_cb_asset_paused
Connected source
Whether withdrawals of one specific asset are paused, as distinct from the whole breaker being paused. If this is true, that asset cannot be redeemed right now.
Unit
boolean (0 dp)
Derivation
observed— read directly from a source
Source
ft.ftusd.cb-limits.v1
Upstream field
ftusd.cb_asset_paused
Aggregation
last— a stock or running total; never summed across buckets
Freshness
expected every 2 minutes, stale after 15 minutes
Entity
chain:{chainId}:ftusd:cb:asset:{assetAddress}
Chains
whatever chains the payload lists — never a list we maintain
Thresholds
state-transition
Counts toward claimable totals
no
PRODUCT.md §8: circuit-breaker state change, any transition, critical. Phase 9.
Methodology notes
Per-asset, and therefore NOT the same fact as ftusd_cb_paused. One asset can be frozen while the rest redeem normally, and a workspace that showed only the chain-level flag would tell a USDC holder everything is fine while their withdrawal is blocked.
ftUSD staked (dashboard)ftusd_staked_dashboard
Connected source
How much ftUSD is staked on each chain, as the ftUSD dashboard reports it.
Unit
token (4 dp)
Derivation
observed— read directly from a source
Source
ft.status.ftusd.dashboard.v1
Upstream field
ftusd.staked
Aggregation
last— a stock or running total; never summed across buckets
Freshness
expected every 5 minutes, stale after 1 hour
Entity
chain:{chainId}:ftusd
Chains
whatever chains the payload lists — never a list we maintain
Thresholds
none — see the methodology notes for why one is not set
Counts toward claimable totals
no
Methodology notes
The SAME QUANTITY as sftusd_staked, from a different endpoint: the dashboard reports staked ftUSD, the staking endpoint reports the sftUSD receipt supply. They agree in the capture and are published separately anyway, so a future divergence between the two surfaces as a visible discrepancy instead of being resolved silently in favour of whichever one we happened to read.
ftUSD yield paidftusd_yield_total_usd
Connected source
The total dollar value of yield ftUSD has paid out to stakers on each chain.
Unit
usd (2 dp)
Derivation
observed— read directly from a source
Source
ft.status.ftusd.dashboard.v1
Upstream field
ftusd.yield_total_usd
Aggregation
last— a stock or running total; never summed across buckets
Freshness
expected every 5 minutes, stale after 1 hour
Entity
chain:{chainId}:ftusd
Chains
whatever chains the payload lists — never a list we maintain
Thresholds
none — see the methodology notes for why one is not set
Counts toward claimable totals
no
Methodology notes
A cumulative all-time total, so it aggregates as LAST and never as SUM.
This is yield paid TO STAKERS. It is not protocol revenue and the two are never added.
ftUSD capital by strategyftusd_strategy_capital_deployed_usd
Connected source
Dollar value deployed through each strategy allocation reported by the ftUSD dashboard.
Unit
usd (2 dp)
Derivation
observed— read directly from a source
Source
ft.status.ftusd.dashboard.v1
Upstream field
ftusd.strategy_capital_deployed_usd
Aggregation
last— a stock or running total; never summed across buckets
Freshness
expected every 5 minutes, stale after 1 hour
Entity
chain:{chainId}:ftusd:strategy:{strategyLabel}
Chains
whatever chains the payload lists — never a list we maintain
Thresholds
none — see the methodology notes for why one is not set
Counts toward claimable totals
no
Methodology notes
The upstream strategyLabel is the only stable strategy identifier in this payload. Currency-formatted amountUsd is parsed without changing its value.
Dollar value of the breaker buffer corresponding to current withdrawal capacity for each ftUSD collateral.
Unit
usd (2 dp)
Derivation
observed— read directly from a source
Source
ft.status.ftusd.dashboard.v1
Upstream field
ftusd.collateral_cb_available_to_withdraw_usd
Aggregation
last— a stock or running total; never summed across buckets
Freshness
expected every 5 minutes, stale after 1 hour
Entity
chain:{chainId}:ftusd:asset:{collateralAddress}
Chains
whatever chains the payload lists — never a list we maintain
Thresholds
none — see the methodology notes for why one is not set
Counts toward claimable totals
no
Methodology notes
Current USD capacity is derived inside the source contract from fields in one snapshot: circuitBreakerStatus.availableToWithdraw multiplied by tvlAmountUsd divided by tvlAmount.
circuitBreakerParams.mainBufferUsd is the maximum main-window buffer, not the remaining capacity. It is deliberately never substituted for the current withdrawable amount.
If a positive token amount has no usable same-snapshot collateral valuation, the USD point stays unavailable rather than assuming a one-dollar price.
whatever chains the payload lists — never a list we maintain
Thresholds
change-24h
Counts toward claimable totals
no
PRODUCT.md §8: TVL move ±15% / 24 h, warn. Phase 9. Applied to supplied value, which is the lending product's TVL.
Methodology notes
Published both protocol-wide and per chain; the two must never be added together.
DefiLlama reports a different TVL for the same product (fixture observed 2026-07-13: our $12.05M supplied vs their $11.15M) because their TVL treats borrowed value differently. Both are correct under their own definitions — see discrepancy_tvl.
Total borrowedlend_borrowed
Connected source
The dollar value currently borrowed out of the lending market — money that is lent out and not sitting available.
Unit
usd (2 dp)
Derivation
observed— read directly from a source
Source
ft.mm.lend.v1
Upstream field
lend.borrowed_usd
Aggregation
last— a stock or running total; never summed across buckets
whatever chains the payload lists — never a list we maintain
Thresholds
none — see the methodology notes for why one is not set
Counts toward claimable totals
no
Methodology notes
Supplied minus borrowed does not always equal available to the cent — caps and circuit-breaker limits also gate withdrawals. Read lend_available and lend_cb_available_to_withdraw for what can actually leave.
Available liquiditylend_available
Connected source
The dollar value sitting in the lending market that is not currently borrowed — the liquidity a supplier could draw on, before breaker limits are applied.
Unit
usd (2 dp)
Derivation
observed— read directly from a source
Source
ft.mm.lend.v1
Upstream field
lend.available_usd
Aggregation
last— a stock or running total; never summed across buckets
whatever chains the payload lists — never a list we maintain
Thresholds
none — see the methodology notes for why one is not set
Counts toward claimable totals
no
Methodology notes
Available is NOT the same as withdrawable: the per-asset circuit breaker can cap withdrawals below this figure. The safety view (signature visualization G) shows both, because the gap between them is the whole question.
Utilisationlend_utilization
Connected source
What share of supplied capital is currently borrowed. High utilisation means high yields for lenders and less room to exit.
Unit
percent (2 dp)
Derivation
observed— read directly from a source
Source
ft.mm.lend.v1
Upstream field
lend.utilization_pct
Aggregation
mean— a rate; ranges average it, never sum it
Freshness
expected every 5 minutes, stale after 1 hour
Entity
chain:{chainId}:lend
Chains
whatever chains the payload lists — never a list we maintain
Thresholds
none — see the methodology notes for why one is not set
Counts toward claimable totals
no
Methodology notes
No warn/critical band. PRODUCT.md §8 approves no utilisation threshold, and §13 D2 freezes new dashboard thresholds until a named owner exists. Inventing an 80/90% band here would be presenting our opinion as the protocol's policy.
Comes from the 31-day per-chain daily series, so it is a daily series, not a live tick.
Supply APYlend_supply_apy
Connected source
The annualised rate lenders are currently earning for supplying capital.
Unit
percent (2 dp)
Derivation
observed— read directly from a source
Source
ft.mm.lend.v1
Upstream field
lend.supply_apy_pct
Aggregation
mean— a rate; ranges average it, never sum it
Freshness
expected every 5 minutes, stale after 1 hour
Entity
chain:{chainId}:lend
Chains
whatever chains the payload lists — never a list we maintain
Thresholds
none — see the methodology notes for why one is not set
Counts toward claimable totals
no
Methodology notes
A rate: ranges average it, they never sum it. Per-asset supply APYs are also collected and are shown in the asset table.
Borrow APYlend_borrow_apy
Connected source
The annualised rate borrowers are currently paying.
Unit
percent (2 dp)
Derivation
observed— read directly from a source
Source
ft.mm.lend.v1
Upstream field
lend.borrow_apy_pct
Aggregation
mean— a rate; ranges average it, never sum it
Freshness
expected every 5 minutes, stale after 1 hour
Entity
chain:{chainId}:lend
Chains
whatever chains the payload lists — never a list we maintain
Thresholds
none — see the methodology notes for why one is not set
Counts toward claimable totals
no
Methodology notes
The spread between borrow and supply APY is where lending revenue comes from; the realised part of it lands in the fees workspace, not here.
Lender earningslend_earnings
Connected source
The dollar value lenders have earned in the lending market, as the protocol reports it.
Unit
usd (2 dp)
Derivation
observed— read directly from a source
Source
ft.mm.lend.v1
Upstream field
lend.earnings_usd
Aggregation
last— a stock or running total; never summed across buckets
whatever chains the payload lists — never a list we maintain
Thresholds
none — see the methodology notes for why one is not set
Counts toward claimable totals
no
Methodology notes
This is what LENDERS earned, not what the protocol earned. Protocol revenue lives in the Revenue workspace and is a different number with a different definition — the two are never added.
A cumulative total, so it aggregates as LAST, not SUM.
Withdrawable now (breaker limit)lend_cb_available_to_withdraw
Partial
How much of an asset the circuit breaker will actually let you withdraw right now, in dollars. This is the number that matters when you want to exit — it can be well below the headline available liquidity.
Unit
usd (2 dp)
Derivation
observed— read directly from a source
Source
ft.mm.lend.cb.v1
Upstream field
lend.cb_withdrawal_capacity_usd
Aggregation
last— a stock or running total; never summed across buckets
Freshness
expected every 5 minutes, stale after 1 hour
Entity
chain:{chainId}:lend:cb:asset:{assetAddress}
Chains
whatever chains the payload lists — never a list we maintain
Thresholds
none — see the methodology notes for why one is not set
Counts toward claimable totals
no
Methodology notes
Status is Partial: the contract is enabled and collecting, but the per-asset breaker endpoint is only verified for the asset/chain pairs we query — assets we cannot yet query are absent and labeled, not guessed.
The distance between this and lend_available is the honest answer to "can I get out?", and it is the point of signature visualization G.
Deposited (daily)lend_series_deposited
Connected source
The dollar value deposited into the lending market on each chain, as a daily history. This is the same quantity as Total supplied, but as the protocol's own 31-day daily series rather than as a live reading.
Unit
usd (2 dp)
Derivation
observed— read directly from a source
Source
ft.mm.lend.v1
Upstream field
lend.total_deposited_usd
Aggregation
last— a stock or running total; never summed across buckets
Freshness
expected every 5 minutes, stale after 1 hour
Entity
chain:{chainId}:lend
Chains
whatever chains the payload lists — never a list we maintain
Thresholds
none — see the methodology notes for why one is not set
Counts toward claimable totals
no
Methodology notes
A daily SNAPSHOT of a stock, so it aggregates as LAST — the deposits on consecutive days are the same capital counted twice, not two deposits.
The window is exactly 31 days because that is what the endpoint returns. History before it does not exist upstream and is rendered as absent, never back-filled.
Borrowed (daily)lend_series_borrowed
Connected source
The dollar value borrowed out of the lending market on each chain, as a daily history over the last 31 days.
Unit
usd (2 dp)
Derivation
observed— read directly from a source
Source
ft.mm.lend.v1
Upstream field
lend.total_borrowed_usd
Aggregation
last— a stock or running total; never summed across buckets
Freshness
expected every 5 minutes, stale after 1 hour
Entity
chain:{chainId}:lend
Chains
whatever chains the payload lists — never a list we maintain
Thresholds
none — see the methodology notes for why one is not set
Counts toward claimable totals
no
Methodology notes
A daily snapshot of a stock: LAST, never SUM.
Plotted against deposits on one canvas, because the GAP between them is the available liquidity — and the gap is what a supplier who wants to exit is actually asking about.
Lender earnings (daily)lend_series_earnings
Connected source
The cumulative dollar value lenders have earned on each chain, as a daily history.
Unit
usd (2 dp)
Derivation
observed— read directly from a source
Source
ft.mm.lend.v1
Upstream field
lend.total_earnings_usd
Aggregation
last— a stock or running total; never summed across buckets
Freshness
expected every 5 minutes, stale after 1 hour
Entity
chain:{chainId}:lend
Chains
whatever chains the payload lists — never a list we maintain
Thresholds
none — see the methodology notes for why one is not set
Counts toward claimable totals
no
Methodology notes
Cumulative, so LAST. The earnings series legitimately carries ONE FEWER POINT than the others on a young chain (30 against 31 in the verified capture) — the series are plotted on their own timestamps rather than zipped by index, so a missing day is a gap and never a zero.
What LENDERS earned, not what the protocol earned. Protocol revenue is a different number in a different workspace, and the two are never added.
Supplied (per asset)lend_asset_supplied
Connected source
The dollar value lenders have deposited of one specific asset on one chain.
Unit
usd (2 dp)
Derivation
observed— read directly from a source
Source
ft.mm.lend.v1
Upstream field
lend.asset_supplied_usd
Aggregation
last— a stock or running total; never summed across buckets
Freshness
expected every 5 minutes, stale after 1 hour
Entity
chain:{chainId}:lend:asset:{assetAddress}
Chains
whatever chains the payload lists — never a list we maintain
Thresholds
none — see the methodology notes for why one is not set
Counts toward claimable totals
no
Methodology notes
From the per-asset globalMetrics block of /mm/lend. Not to be confused with the per-asset userMetrics block on the same payload, which is WALLET-scoped and is never collected, never stored and never published (PRODUCT.md §6).
Keyed on the asset ADDRESS. The symbol is provenance metadata only.
Borrowed (per asset)lend_asset_borrowed
Connected source
The dollar value currently borrowed of one specific asset on one chain.
Unit
usd (2 dp)
Derivation
observed— read directly from a source
Source
ft.mm.lend.v1
Upstream field
lend.asset_borrowed_usd
Aggregation
last— a stock or running total; never summed across buckets
Freshness
expected every 5 minutes, stale after 1 hour
Entity
chain:{chainId}:lend:asset:{assetAddress}
Chains
whatever chains the payload lists — never a list we maintain
Thresholds
none — see the methodology notes for why one is not set
Counts toward claimable totals
no
Methodology notes
Per-asset borrowed value from /mm/lend globalMetrics. Protocol-level, never wallet-level.
Available (per asset)lend_asset_available
Connected source
The dollar value of one asset that is supplied but not borrowed — the liquidity that exists before the circuit breaker decides how much of it may actually leave.
Unit
usd (2 dp)
Derivation
observed— read directly from a source
Source
ft.mm.lend.v1
Upstream field
lend.asset_available_usd
Aggregation
last— a stock or running total; never summed across buckets
Freshness
expected every 5 minutes, stale after 1 hour
Entity
chain:{chainId}:lend:asset:{assetAddress}
Chains
whatever chains the payload lists — never a list we maintain
Thresholds
none — see the methodology notes for why one is not set
Counts toward claimable totals
no
Methodology notes
AVAILABLE IS NOT WITHDRAWABLE. The per-asset circuit breaker caps withdrawals well below this figure — in the verified capture, USDC on Ethereum showed $2.59M available against a $129K breaker limit, a 20x gap.
The workspace shows both, side by side, because that gap is the entire question a supplier is asking.
Utilisation (per asset)lend_asset_utilization
Connected source
What share of one asset's supplied capital is currently borrowed.
Unit
percent (2 dp)
Derivation
observed— read directly from a source
Source
ft.mm.lend.v1
Upstream field
lend.asset_utilization_pct
Aggregation
mean— a rate; ranges average it, never sum it
Freshness
expected every 5 minutes, stale after 1 hour
Entity
chain:{chainId}:lend:asset:{assetAddress}
Chains
whatever chains the payload lists — never a list we maintain
Thresholds
none — see the methodology notes for why one is not set
Counts toward claimable totals
no
Methodology notes
No warn/critical band. PRODUCT.md §8 approves no utilisation threshold and §13 D2 freezes new dashboard thresholds until an owner is named — an 80/90% band here would be our opinion wearing the protocol's clothes.
Supply caplend_asset_supply_cap
Connected source
The most of one asset the market will accept, in dollars — a risk parameter the protocol sets, not a measurement of anything.
Unit
usd (2 dp)
Derivation
observed— read directly from a source
Source
ft.mm.lend.v1
Upstream field
lend.asset_supply_cap_usd
Aggregation
last— a stock or running total; never summed across buckets
Freshness
expected every 5 minutes, stale after 1 hour
Entity
chain:{chainId}:lend:asset:{assetAddress}
Chains
whatever chains the payload lists — never a list we maintain
Thresholds
none — see the methodology notes for why one is not set
Counts toward claimable totals
no
Methodology notes
A configured parameter. A cap of zero means the asset is closed to new supply — that is a real, deliberate state (FT itself is capped at zero in the verified capture), not missing data, and it renders as zero rather than as a blank.
Caps are denominated in the token upstream; the USD figure is the protocol's own conversion at its own price, and it moves when the price moves even though the cap has not changed.
Supply cap headroomlend_asset_supply_cap_available
Connected source
How much more of one asset the market would still accept before hitting its supply cap.
Unit
usd (2 dp)
Derivation
observed— read directly from a source
Source
ft.mm.lend.v1
Upstream field
lend.asset_supply_cap_available_usd
Aggregation
last— a stock or running total; never summed across buckets
Freshness
expected every 5 minutes, stale after 1 hour
Entity
chain:{chainId}:lend:asset:{assetAddress}
Chains
whatever chains the payload lists — never a list we maintain
Thresholds
none — see the methodology notes for why one is not set
Counts toward claimable totals
no
Methodology notes
Read from the payload rather than computed as cap minus supplied: the protocol knows its own remaining headroom, and recomputing it here would substitute our arithmetic for its answer. The contract asserts headroom never exceeds the cap, so a unit mismatch between the two quarantines instead of rendering.
Borrow caplend_asset_borrow_cap
Connected source
The most of one asset that may be borrowed out, in dollars — a configured risk parameter.
Unit
usd (2 dp)
Derivation
observed— read directly from a source
Source
ft.mm.lend.v1
Upstream field
lend.asset_borrow_cap_usd
Aggregation
last— a stock or running total; never summed across buckets
Freshness
expected every 5 minutes, stale after 1 hour
Entity
chain:{chainId}:lend:asset:{assetAddress}
Chains
whatever chains the payload lists — never a list we maintain
Thresholds
none — see the methodology notes for why one is not set
Counts toward claimable totals
no
Methodology notes
A nominal borrow cap of 1 token — which several assets carry — is how this market says "effectively not borrowable" without setting a flag. Read it beside lend_asset_borrowable rather than on its own.
Borrow cap headroomlend_asset_borrow_cap_available
Connected source
How much more of one asset could still be borrowed before its borrow cap is reached.
Unit
usd (2 dp)
Derivation
observed— read directly from a source
Source
ft.mm.lend.v1
Upstream field
lend.asset_borrow_cap_available_usd
Aggregation
last— a stock or running total; never summed across buckets
Freshness
expected every 5 minutes, stale after 1 hour
Entity
chain:{chainId}:lend:asset:{assetAddress}
Chains
whatever chains the payload lists — never a list we maintain
Thresholds
none — see the methodology notes for why one is not set
Counts toward claimable totals
no
Methodology notes
Zero headroom against a non-zero cap means the cap is FULLY DRAWN — wS on Sonic and USSD on Sonic both read exactly zero in the verified capture. That is the state this column exists to make visible, and it renders as zero, not as empty.
Supply APY (per asset)lend_asset_supply_apy
Connected source
The annualised rate a lender currently earns for supplying one specific asset.
Unit
percent (2 dp)
Derivation
observed— read directly from a source
Source
ft.mm.lend.v1
Upstream field
lend.asset_supply_apy_pct
Aggregation
mean— a rate; ranges average it, never sum it
Freshness
expected every 5 minutes, stale after 1 hour
Entity
chain:{chainId}:lend:asset:{assetAddress}
Chains
whatever chains the payload lists — never a list we maintain
Thresholds
none — see the methodology notes for why one is not set
Counts toward claimable totals
no
Methodology notes
A current rate, not a realised return. Ranges average it; they never sum it.
Borrow APY (per asset)lend_asset_borrow_apy
Connected source
The annualised rate a borrower currently pays for one specific asset.
Unit
percent (2 dp)
Derivation
observed— read directly from a source
Source
ft.mm.lend.v1
Upstream field
lend.asset_borrow_apy_pct
Aggregation
mean— a rate; ranges average it, never sum it
Freshness
expected every 5 minutes, stale after 1 hour
Entity
chain:{chainId}:lend:asset:{assetAddress}
Chains
whatever chains the payload lists — never a list we maintain
Thresholds
none — see the methodology notes for why one is not set
Counts toward claimable totals
no
Methodology notes
A current rate. The borrow/supply spread is where lending revenue comes from; the realised part of it lands in Revenue, not here.
Suppliablelend_asset_suppliable
Connected source
Whether this asset may currently be supplied to the market at all.
Unit
boolean (0 dp)
Derivation
observed— read directly from a source
Source
ft.mm.lend.v1
Upstream field
lend.asset_suppliable
Aggregation
last— a stock or running total; never summed across buckets
Freshness
expected every 5 minutes, stale after 1 hour
Entity
chain:{chainId}:lend:asset:{assetAddress}
Chains
whatever chains the payload lists — never a list we maintain
Thresholds
none — see the methodology notes for why one is not set
Counts toward claimable totals
no
Methodology notes
A flag, rendered as a labelled chip with an icon — never as a coloured dot alone (WCAG 1.4.1).
Borrowablelend_asset_borrowable
Connected source
Whether this asset may currently be borrowed.
Unit
boolean (0 dp)
Derivation
observed— read directly from a source
Source
ft.mm.lend.v1
Upstream field
lend.asset_borrowable
Aggregation
last— a stock or running total; never summed across buckets
Freshness
expected every 5 minutes, stale after 1 hour
Entity
chain:{chainId}:lend:asset:{assetAddress}
Chains
whatever chains the payload lists — never a list we maintain
Thresholds
none — see the methodology notes for why one is not set
Counts toward claimable totals
no
Methodology notes
Distinct from borrowAgainst: this asks whether you can TAKE this asset out as a loan.
Usable as collaterallend_asset_borrow_against
Connected source
Whether this asset may be posted as collateral to borrow something else. It is a different question from whether the asset can itself be borrowed, and for real assets the two answers differ.
Unit
boolean (0 dp)
Derivation
observed— read directly from a source
Source
ft.mm.lend.v1
Upstream field
lend.asset_borrow_against
Aggregation
last— a stock or running total; never summed across buckets
Freshness
expected every 5 minutes, stale after 1 hour
Entity
chain:{chainId}:lend:asset:{assetAddress}
Chains
whatever chains the payload lists — never a list we maintain
Thresholds
none — see the methodology notes for why one is not set
Counts toward claimable totals
no
Methodology notes
The payload has always carried this flag; the source contract validated it and then dropped it, so until now it existed nowhere in FT Pulse. It is published because the per-asset table is supposed to answer "what can I do with this asset", and two of the three answers were missing.
Withdrawable now (per asset)lend_asset_cb_available
Connected source
How much of one asset the circuit breaker will actually let out right now, in dollars. This is the number that matters when you want to exit, and it is routinely a fraction of the headline available liquidity.
Unit
usd (2 dp)
Derivation
observed— read directly from a source
Source
ft.mm.lend.v1
Upstream field
lend.asset_cb_available_usd
Aggregation
last— a stock or running total; never summed across buckets
Freshness
expected every 5 minutes, stale after 1 hour
Entity
chain:{chainId}:lend:asset:{assetAddress}
Chains
whatever chains the payload lists — never a list we maintain
Thresholds
none — see the methodology notes for why one is not set
Counts toward claimable totals
no
Methodology notes
From the per-asset circuitBreakerStatus block on /mm/lend — the same quantity the dedicated /mm/lend/cb endpoint returns, and collected here for every asset rather than only for the asset/chain pairs we query individually.
The distance between this and lend_asset_available is the honest answer to "can I get out?", and it is the point of signature visualization G.
Whether the protocol itself flags this asset's withdrawal capacity as low. This is the protocol's own judgement, not our threshold.
Unit
boolean (0 dp)
Derivation
observed— read directly from a source
Source
ft.mm.lend.v1
Upstream field
lend.asset_cb_low_availability
Aggregation
last— a stock or running total; never summed across buckets
Freshness
expected every 5 minutes, stale after 1 hour
Entity
chain:{chainId}:lend:asset:{assetAddress}
Chains
whatever chains the payload lists — never a list we maintain
Thresholds
none — see the methodology notes for why one is not set
Counts toward claimable totals
no
Methodology notes
The ONE risk flag on this workspace that is not ours: upstream sets isLowAvailability itself. We surface it and attribute it, and we do not add a competing band of our own beside it (§13 D2).
Markets & TRS
Mark pricemarket_mark_price
Beta
The price the protocol uses to value positions and decide liquidations. It is not necessarily the last traded price, and that difference is the point of showing both.
Unit
usd_per_token (6 dp)
Derivation
observed— read directly from a source
Source
ft.mm.spot.markets-v2.v1
Upstream field
market.mark_price_usd
Aggregation
last— a stock or running total; never summed across buckets
whatever chains the payload lists — never a list we maintain
Thresholds
none — see the methodology notes for why one is not set
Counts toward claimable totals
no
Methodology notes
Entity is the base/quote ADDRESS PAIR, never the display symbol (LINK_VERIFICATION G-5) — symbols are reused and re-pointed upstream, addresses are not. The display symbol rides along as provenance metadata only.
Beta: the upstream surface is itself beta (beta.flyingtulip.com/trade). It is collected and published with the Beta flag, and is subject to upstream change without notice.
Open interestmarket_open_interest
Beta
The dollar value of positions currently open in a market — how much risk is actually on the book.
Unit
usd (2 dp)
Derivation
observed— read directly from a source
Source
ft.mm.spot.markets-v2.v1
Upstream field
market.open_interest_usd
Aggregation
last— a stock or running total; never summed across buckets
whatever chains the payload lists — never a list we maintain
Thresholds
none — see the methodology notes for why one is not set
Counts toward claimable totals
no
Methodology notes
Entity is the base/quote ADDRESS PAIR, never the display symbol (LINK_VERIFICATION G-5) — symbols are reused and re-pointed upstream, addresses are not. The display symbol rides along as provenance metadata only.
Beta: the upstream surface is itself beta (beta.flyingtulip.com/trade). It is collected and published with the Beta flag, and is subject to upstream change without notice.
Funding ratemarket_funding_rate
Beta
The periodic payment that flows between long and short position holders to keep the market price tethered to the underlying. Positive means longs pay shorts.
whatever chains the payload lists — never a list we maintain
Thresholds
none — see the methodology notes for why one is not set
Counts toward claimable totals
no
Methodology notes
Entity is the base/quote ADDRESS PAIR, never the display symbol (LINK_VERIFICATION G-5) — symbols are reused and re-pointed upstream, addresses are not. The display symbol rides along as provenance metadata only.
Beta: the upstream surface is itself beta (beta.flyingtulip.com/trade). It is collected and published with the Beta flag, and is subject to upstream change without notice.
A PERCENT, not a ratio and not basis points. This entry previously declared a ratio, on the reasonable assumption that a funding rate would arrive as one — the captured payload disproves it: `/mm/spot/markets-v2` returns fundingRate as a STRING WITH A PERCENT SIGN ("4.1682%"), which the contract parses to 4.1682. The registry now matches the observed payload rather than the assumption, and `defineMetric` is what caught the disagreement: it refuses to load a metric whose unit contradicts its source contract, so the two cannot drift apart silently.
The unit is worth this much fuss because a ratio/percent confusion here is a 100× error on every funding number in the product. The contract keeps a plausibility guard on the magnitude, so a payload that suddenly looks like a ratio (or like bps) quarantines rather than being silently rescaled into a plausible-looking lie.
Max leveragemarket_max_leverage
Beta
The highest leverage a trader is allowed to take in this market — a risk parameter the protocol sets, not a measurement.
Unit
ratio (1 dp)
Derivation
observed— read directly from a source
Source
ft.mm.spot.markets-v2.v1
Upstream field
market.max_leverage
Aggregation
last— a stock or running total; never summed across buckets
whatever chains the payload lists — never a list we maintain
Thresholds
none — see the methodology notes for why one is not set
Counts toward claimable totals
no
Methodology notes
Entity is the base/quote ADDRESS PAIR, never the display symbol (LINK_VERIFICATION G-5) — symbols are reused and re-pointed upstream, addresses are not. The display symbol rides along as provenance metadata only.
Beta: the upstream surface is itself beta (beta.flyingtulip.com/trade). It is collected and published with the Beta flag, and is subject to upstream change without notice.
A configured parameter. When it changes, that is a governance/config event worth surfacing — not market data drifting.
24 h price changemarket_price_change_24h
Beta
How much a market's price has moved over the last 24 hours, as an absolute amount in the quote token — not a percentage.
Unit
usd_per_token (6 dp)
Derivation
observed— read directly from a source
Source
ft.mm.spot.markets-v2.v1
Upstream field
market.price_change_24h_usd
Aggregation
last— a stock or running total; never summed across buckets
whatever chains the payload lists — never a list we maintain
Thresholds
none — see the methodology notes for why one is not set
Counts toward claimable totals
no
Methodology notes
Entity is the base/quote ADDRESS PAIR, never the display symbol (LINK_VERIFICATION G-5) — symbols are reused and re-pointed upstream, addresses are not. The display symbol rides along as provenance metadata only.
Beta: the upstream surface is itself beta (beta.flyingtulip.com/trade). It is collected and published with the Beta flag, and is subject to upstream change without notice.
The ABSOLUTE move. It is published alongside the percentage rather than instead of it, because the two together are self-checking: the percent is recoverable from this and the price, so a unit flip in either one breaks an arithmetic identity the source contract asserts.
A rolling 24-hour window reported by upstream, not a sum of our observations — consecutive readings are never added together.
24 h changemarket_price_change_pct_24h
Beta
How much a market's price has moved over the last 24 hours, as a percentage.
Unit
percent (4 dp)
Derivation
observed— read directly from a source
Source
ft.mm.spot.markets-v2.v1
Upstream field
market.price_change_pct_24h
Aggregation
last— a stock or running total; never summed across buckets
whatever chains the payload lists — never a list we maintain
Thresholds
none — see the methodology notes for why one is not set
Counts toward claimable totals
no
Methodology notes
Entity is the base/quote ADDRESS PAIR, never the display symbol (LINK_VERIFICATION G-5) — symbols are reused and re-pointed upstream, addresses are not. The display symbol rides along as provenance metadata only.
Beta: the upstream surface is itself beta (beta.flyingtulip.com/trade). It is collected and published with the Beta flag, and is subject to upstream change without notice.
A PERCENT (0.27 means 0.27%), and nothing in the wire form says so — upstream sends it as a bare decimal string, which is exactly the percent-or-ratio ambiguity that misread the funding rate by 100x. It is settled here by ARITHMETIC rather than by assumption: the contract asserts pct == change / (last - change) * 100 against the absolute move upstream also publishes, verified to 15 significant figures on the captured payload. A unit flip breaks the identity and quarantines.
That check invents no threshold. It compares two numbers upstream sent us, so it cannot be tuned, cannot drift, and cannot fire on a quiet market — which is why it is allowed to exist where a magnitude bound is not (PRODUCT.md §13 D2).
Safe margin health factormarket_margin_hf_safe_bps
Beta
The health-factor margin, in basis points, that the protocol treats as safe for a position in this market. Like max leverage, it is a risk parameter the protocol chose — not a measurement of the market.
Unit
bps (0 dp)
Derivation
observed— read directly from a source
Source
ft.mm.spot.markets-v2.v1
Upstream field
market.margin_hf_safe_bps
Aggregation
last— a stock or running total; never summed across buckets
whatever chains the payload lists — never a list we maintain
Thresholds
none — see the methodology notes for why one is not set
Counts toward claimable totals
no
Methodology notes
Entity is the base/quote ADDRESS PAIR, never the display symbol (LINK_VERIFICATION G-5) — symbols are reused and re-pointed upstream, addresses are not. The display symbol rides along as provenance metadata only.
Beta: the upstream surface is itself beta (beta.flyingtulip.com/trade). It is collected and published with the Beta flag, and is subject to upstream change without notice.
Published beside max leverage in the market header, because the two together are the public risk parameters of a market and neither is meaningful alone.
TRS exposuretrs_total_exposure
Beta
The total notional exposure open across the total-return-swap desk, in dollars.
Unit
usd (2 dp)
Derivation
observed— read directly from a source
Source
ft.trs.overview.v1
Upstream field
trs.total_exposure_usd
Aggregation
last— a stock or running total; never summed across buckets
Freshness
expected every 15 minutes, stale after 2 hours
Entity
protocol:trs
Chains
not chain-scoped
Thresholds
none — see the methodology notes for why one is not set
Counts toward claimable totals
no
Methodology notes
An all-zero reading is GENUINE (LINK_VERIFICATION G-3): the TRS desk is live but unused. Zero here is a measurement, not a missing value, and it is never rendered as an error or an empty state.
Sourced from GET /trs/ only. GET /trs/quote answers 405 and is blocklisted for every method — quoting is a write-shaped flow and FT Pulse never calls one.
TRS collateraltrs_total_collateral
Beta
The collateral posted against TRS positions, in dollars.
Unit
usd (2 dp)
Derivation
observed— read directly from a source
Source
ft.trs.overview.v1
Upstream field
trs.total_collateral_usd
Aggregation
last— a stock or running total; never summed across buckets
Freshness
expected every 15 minutes, stale after 2 hours
Entity
protocol:trs
Chains
not chain-scoped
Thresholds
none — see the methodology notes for why one is not set
Counts toward claimable totals
no
Methodology notes
An all-zero reading is GENUINE (LINK_VERIFICATION G-3): the TRS desk is live but unused. Zero here is a measurement, not a missing value, and it is never rendered as an error or an empty state.
Sourced from GET /trs/ only. GET /trs/quote answers 405 and is blocklisted for every method — quoting is a write-shaped flow and FT Pulse never calls one.
TRS equitytrs_equity
Beta
Collateral less debt across the TRS desk — what the book is actually worth.
Unit
usd (2 dp)
Derivation
observed— read directly from a source
Source
ft.trs.overview.v1
Upstream field
trs.equity_usd
Aggregation
last— a stock or running total; never summed across buckets
Freshness
expected every 15 minutes, stale after 2 hours
Entity
protocol:trs
Chains
not chain-scoped
Thresholds
none — see the methodology notes for why one is not set
Counts toward claimable totals
no
Methodology notes
An all-zero reading is GENUINE (LINK_VERIFICATION G-3): the TRS desk is live but unused. Zero here is a measurement, not a missing value, and it is never rendered as an error or an empty state.
Sourced from GET /trs/ only. GET /trs/quote answers 405 and is blocklisted for every method — quoting is a write-shaped flow and FT Pulse never calls one.
TRS maintenance margintrs_maintenance_margin
Beta
The collateral the desk must keep posted to avoid liquidation, in dollars — the floor, not the balance.
Unit
usd (2 dp)
Derivation
observed— read directly from a source
Source
ft.trs.overview.v1
Upstream field
trs.maintenance_margin_usd
Aggregation
last— a stock or running total; never summed across buckets
Freshness
expected every 15 minutes, stale after 2 hours
Entity
protocol:trs
Chains
not chain-scoped
Thresholds
none — see the methodology notes for why one is not set
Counts toward claimable totals
no
Methodology notes
An all-zero reading is GENUINE (LINK_VERIFICATION G-3): the TRS desk is live but unused. Zero here is a measurement, not a missing value, and it is never rendered as an error or an empty state.
Sourced from GET /trs/ only. GET /trs/quote answers 405 and is blocklisted for every method — quoting is a write-shaped flow and FT Pulse never calls one.
Collateral against exposure across the whole desk, expressed as the percentage supplied by the upstream API.
Unit
percent (2 dp)
Derivation
observed— read directly from a source
Source
ft.trs.overview.v1
Upstream field
trs.cross_collateral_ratio
Aggregation
last— a stock or running total; never summed across buckets
Freshness
expected every 15 minutes, stale after 2 hours
Entity
protocol:trs
Chains
not chain-scoped
Thresholds
none — see the methodology notes for why one is not set
Counts toward claimable totals
no
Methodology notes
An all-zero reading is GENUINE (LINK_VERIFICATION G-3): the TRS desk is live but unused. Zero here is a measurement, not a missing value, and it is never rendered as an error or an empty state.
The upstream field is named crossCollateralRatioPct. The contract therefore preserves it as percent instead of silently treating percent points as a unitless ratio.
TRS suppliedtrs_total_supplied
Beta
Capital supplied into the TRS desk, in dollars.
Unit
usd (2 dp)
Derivation
observed— read directly from a source
Source
ft.trs.overview.v1
Upstream field
trs.total_supplied_usd
Aggregation
last— a stock or running total; never summed across buckets
Freshness
expected every 15 minutes, stale after 2 hours
Entity
protocol:trs
Chains
not chain-scoped
Thresholds
none — see the methodology notes for why one is not set
Counts toward claimable totals
no
Methodology notes
An all-zero reading is GENUINE (LINK_VERIFICATION G-3): the TRS desk is live but unused. Zero here is a measurement, not a missing value, and it is never rendered as an error or an empty state.
Never added to the lending market's supplied figure — different product, different capital.
TRS debttrs_total_debt
Beta
Debt outstanding across the TRS desk, in dollars.
Unit
usd (2 dp)
Derivation
observed— read directly from a source
Source
ft.trs.overview.v1
Upstream field
trs.total_debt_usd
Aggregation
last— a stock or running total; never summed across buckets
Freshness
expected every 15 minutes, stale after 2 hours
Entity
protocol:trs
Chains
not chain-scoped
Thresholds
none — see the methodology notes for why one is not set
Counts toward claimable totals
no
Methodology notes
An all-zero reading is GENUINE (LINK_VERIFICATION G-3): the TRS desk is live but unused. Zero here is a measurement, not a missing value, and it is never rendered as an error or an empty state.
Sourced from GET /trs/ only. GET /trs/quote answers 405 and is blocklisted for every method — quoting is a write-shaped flow and FT Pulse never calls one.
TRS P&Ltrs_unrealized_pnl
Beta
Profit or loss reported by the TRS overview. The upstream field does not qualify the value as realised or unrealised, so this registry does not add that claim.
Unit
usd (2 dp)
Derivation
observed— read directly from a source
Source
ft.trs.overview.v1
Upstream field
trs.pnl_usd
Aggregation
last— a stock or running total; never summed across buckets
Freshness
expected every 15 minutes, stale after 2 hours
Entity
protocol:trs
Chains
not chain-scoped
Thresholds
none — see the methodology notes for why one is not set
Counts toward claimable totals
no
Methodology notes
An all-zero reading is GENUINE (LINK_VERIFICATION G-3): the TRS desk is live but unused. Zero here is a measurement, not a missing value, and it is never rendered as an error or an empty state.
The one TRS field that is legitimately signed. It is NOT range-checked as a non-negative USD amount, because a loss is not a unit violation.
The upstream field is pnlUsd with no realised/unrealised qualifier. It never appears in the Revenue workspace and is never added to fee revenue.
TRS account balancetrs_total_account_balance
Connected source
The total account balance reported by the TRS overview, in dollars. The upstream field does not publish a more specific accounting decomposition.
Unit
usd (2 dp)
Derivation
observed— read directly from a source
Source
ft.trs.overview.v1
Upstream field
trs.total_account_balance_usd
Aggregation
last— a stock or running total; never summed across buckets
Freshness
expected every 15 minutes, stale after 2 hours
Entity
protocol:trs
Chains
not chain-scoped
Thresholds
none — see the methodology notes for why one is not set
Counts toward claimable totals
no
Methodology notes
An all-zero reading is GENUINE (LINK_VERIFICATION G-3): the TRS desk is live but unused. Zero here is a measurement, not a missing value, and it is never rendered as an error or an empty state.
Sourced from GET /trs/ only. GET /trs/quote answers 405 and is blocklisted for every method — quoting is a write-shaped flow and FT Pulse never calls one.
The cross-collateral ratio the TRS overview reports as its target, expressed in percentage points.
Unit
percent (2 dp)
Derivation
observed— read directly from a source
Source
ft.trs.overview.v1
Upstream field
trs.target_cross_collateral_ratio_pct
Aggregation
last— a stock or running total; never summed across buckets
Freshness
expected every 15 minutes, stale after 2 hours
Entity
protocol:trs
Chains
not chain-scoped
Thresholds
none — see the methodology notes for why one is not set
Counts toward claimable totals
no
Methodology notes
An all-zero reading is GENUINE (LINK_VERIFICATION G-3): the TRS desk is live but unused. Zero here is a measurement, not a missing value, and it is never rendered as an error or an empty state.
This is an upstream risk parameter, not a dashboard-authored alert threshold. The field name explicitly says percent, so 150 means 150%, not a 1.5 unitless ratio.
The cross-collateral ratio at which the TRS overview reports liquidation risk, expressed in percentage points.
Unit
percent (2 dp)
Derivation
observed— read directly from a source
Source
ft.trs.overview.v1
Upstream field
trs.liquidation_cross_collateral_ratio_pct
Aggregation
last— a stock or running total; never summed across buckets
Freshness
expected every 15 minutes, stale after 2 hours
Entity
protocol:trs
Chains
not chain-scoped
Thresholds
none — see the methodology notes for why one is not set
Counts toward claimable totals
no
Methodology notes
An all-zero reading is GENUINE (LINK_VERIFICATION G-3): the TRS desk is live but unused. Zero here is a measurement, not a missing value, and it is never rendered as an error or an empty state.
This is the upstream protocol parameter, not a dashboard-authored threshold. It is preserved as percent exactly as named by the source.
TRS low-buffer warningtrs_low_buffer_warning
Connected source
Whether the TRS overview currently reports that its collateral buffer is low.
Unit
boolean (0 dp)
Derivation
observed— read directly from a source
Source
ft.trs.overview.v1
Upstream field
trs.low_buffer_warning
Aggregation
last— a stock or running total; never summed across buckets
Freshness
expected every 15 minutes, stale after 2 hours
Entity
protocol:trs
Chains
not chain-scoped
Thresholds
none — see the methodology notes for why one is not set
Counts toward claimable totals
no
Methodology notes
An all-zero reading is GENUINE (LINK_VERIFICATION G-3): the TRS desk is live but unused. Zero here is a measurement, not a missing value, and it is never rendered as an error or an empty state.
This is the source boolean isLowBufferWarning, exposed without inventing a numeric buffer threshold the API does not provide.
TRS base price in collateraltrs_price_in_collateral
Connected source
The requested collateral or quote-token amount per one base token for a TRS market address pair.
Unit
ratio (8 dp)
Derivation
observed— read directly from a source
Source
ft.trs.price-series.v1
Upstream field
trs.price_in_collateral
Aggregation
last— a stock or running total; never summed across buckets
whatever chains the payload lists — never a list we maintain
Thresholds
none — see the methodology notes for why one is not set
Counts toward claimable totals
no
Methodology notes
Address pairs are learned only from validated GET /trs/ market rows and then requested from GET /trs/price-series. Symbols never parameterize the request.
Direction is quote/collateral units per one base token, for example ftUSD per wS. It is not base units per collateral, and it is not labelled USD unless the requested quote token actually is dollar-denominated.
Overlapping daily and intraday timestamps are deduplicated deterministically in favour of the higher-resolution intraday observation.
Revenue
Application fees (lifetime)fees_lifetime_usd
Connected source
The cumulative application-fee total reported by Flying Tulip's first-party fees API since launch.
Unit
usd (2 dp)
Derivation
observed— read directly from a source
Source
ft.fees.application.v1
Upstream field
fees.lifetime_usd
Aggregation
last— a stock or running total; never summed across buckets
Freshness
expected every 15 minutes, stale after 2 hours
Entity
protocol:fees
Chains
not chain-scoped
Thresholds
none — see the methodology notes for why one is not set
Counts toward claimable totals
yes
Methodology notes
A cumulative lifetime total (fixture observed 2026-07-13: $42,993.54). Aggregates as LAST — summing it across buckets would count the protocol's entire history once per bucket.
This is the upstream-reported headline. It is not rebuilt from the rolling events endpoint, and it does not prove that every indexed RFQ liquidation row is protocol-owned or currently claimable.
DefiLlama reports roughly $3.99M for "fees" over the same protocol. That is not a contradiction: their figure includes PUT-vault strategy yield, ours counts application fees only. Both are correct under their own definitions — see discrepancy_fees.
Excludes anything the API flags synthetic_split (PRODUCT.md §9.5).
Fees by productfees_by_product
Connected source
Upstream-reported lifetime application fees split by product — lending, ftUSD, RFQ, the PUT marketplace and leverage.
Unit
usd (2 dp)
Derivation
observed— read directly from a source
Source
ft.fees.application.v1
Upstream field
fees.product_lifetime_usd
Aggregation
last— a stock or running total; never summed across buckets
Freshness
expected every 15 minutes, stale after 2 hours
Entity
protocol:fees:product:{product}
Chains
not chain-scoped
Thresholds
none — see the methodology notes for why one is not set
Counts toward claimable totals
yes
Methodology notes
Cumulative per product, so LAST, not SUM.
The separate statistics backend also breaks fees down by product and includes a `trade` product that the application-fees endpoint does not. The two product lists therefore differ; we do not merge them into one list, because that would silently change what "fees by product" means.
Fees by chainfees_by_chain
Connected source
Upstream-reported lifetime application fees split by chain.
Unit
usd (2 dp)
Derivation
observed— read directly from a source
Source
ft.fees.application.v1
Upstream field
fees.chain_lifetime_usd
Aggregation
last— a stock or running total; never summed across buckets
Freshness
expected every 15 minutes, stale after 2 hours
Entity
chain:{chainId}:fees
Chains
whatever chains the payload lists — never a list we maintain
Thresholds
none — see the methodology notes for why one is not set
Counts toward claimable totals
yes
Methodology notes
Chain-scoped: the entity carries the chain id from the payload, so a new chain publishes without a registry change. Chains 1 (Ethereum) and 146 (Sonic) were the verified set on 2026-07-13.
Cumulative per chain, so LAST, not SUM.
Fees per dayfees_daily
Connected source
Upstream-reported application-fee value for each calendar day (UTC) — the flow, as opposed to the running lifetime total.
Unit
usd (2 dp)
Derivation
observed— read directly from a source
Source
ft.fees.application.v1
Upstream field
fees.daily_usd
Aggregation
sum— a flow; a range total is the sum of its parts
Freshness
expected every 15 minutes, stale after 2 hours
Entity
protocol:fees
Chains
not chain-scoped
Thresholds
none — see the methodology notes for why one is not set
Counts toward claimable totals
yes
Methodology notes
The one fee metric that genuinely SUMS: these are daily flows, so a 30-day total is the sum of 30 days.
Daily series since 2026-01-27. Days before that do not exist and are rendered as gaps, never as zeros — a zero would claim the protocol earned nothing that day.
Pending sweep — treasuryfees_pending_treasury
Connected source
Fees collected but not yet swept to the treasury, as the API reports the total. Read the caveat: this figure includes rows the API itself marks as a synthetic estimate, so it is not a clean claimable number.
Unit
usd (2 dp)
Derivation
observed— read directly from a source
Source
ft.fees.pending.v1
Upstream field
fees.pending_treasury_usd
Aggregation
last— a stock or running total; never summed across buckets
Freshness
expected every 15 minutes, stale after 2 hours
Entity
protocol:fees:pending
Chains
not chain-scoped
Thresholds
none — see the methodology notes for why one is not set
Counts toward claimable totals
no
Methodology notes
Marked as NOT counting toward claimable totals, deliberately. Upstream builds this total with synthetic forecast rows included, and PRODUCT.md §9.5 forbids synthetic amounts inside claimable figures. The synthetic-free number is the on-chain claimable figure the same endpoint publishes separately.
Pending means collected-but-not-yet-swept. It is not revenue that has been booked, and it is not money in the treasury.
Pending sweep — lendersfees_pending_lender
Connected source
Fees collected but not yet distributed to lenders.
Unit
usd (2 dp)
Derivation
observed— read directly from a source
Source
ft.fees.pending.v1
Upstream field
fees.pending_lender_usd
Aggregation
last— a stock or running total; never summed across buckets
Freshness
expected every 15 minutes, stale after 2 hours
Entity
protocol:fees:pending
Chains
not chain-scoped
Thresholds
none — see the methodology notes for why one is not set
Counts toward claimable totals
yes
Methodology notes
Lender-bound pending fees. Unlike the treasury-bound total, upstream does not fold synthetic forecast rows into this one.
This is destined for lenders, not the protocol — it is never added to treasury figures.
Signed application eventsfees_events
Connected source
Upstream-reported signed application-event values, one row per on-chain transaction, with the product and event type attached.
Unit
usd (2 dp)
Derivation
observed— read directly from a source
Source
ft.fees.events.v1
Upstream field
fees.event_amount_usd
Aggregation
sum— a flow; a range total is the sum of its parts
whatever chains the payload lists — never a list we maintain
Thresholds
none — see the methodology notes for why one is not set
Counts toward claimable totals
no
Methodology notes
Transaction-level, so these SUM as signed values. A negative RFQ liquidation_bonus row means seized collateral value minus repaid debt and gas is below zero. Negative observations are never converted to absolute values or zero.
The upstream daily revenue series carries the same signed RFQ result, so preserving the sign keeps event drill-down consistent with the first-party aggregate.
The event endpoint also contains RFQ liquidation rows whose metadata says is_ours=false and protocol_fee_usd=0. These rows are upstream application activity, not proof that the protocol earned or can claim the value; this metric is therefore excluded from claimable totals.
The transaction hash and log index ride along as provenance, which makes every row independently verifiable on-chain — that is the whole point of publishing events rather than only totals.
The collector follows offset pagination to the advertised total, with the contract hard cap as a runaway guard. A short page or changing total cannot cause an unbounded crawl.
The upstream events endpoint is a rolling-window drill-down, not a complete lifetime receipt ledger. Public views state the earliest and latest stored event timestamps; they never imply that the event sum reconstructs the lifetime application-fee headline.
The entity keeps the fee-collecting contract prefix and appends txHash plus logIndex. That suffix is required because multiple real events can share the same recordedAt; without transaction identity the database uniqueness key would silently collapse them.
No wallet-level attribution appears in any normalized point or public payload.
Fee events by product and assetfees_event_asset_flow
Connected source
Upstream-reported signed application-event values keyed by product and asset, retaining transaction identity so the public flow view can aggregate without losing same-timestamp events.
Unit
usd (2 dp)
Derivation
observed— read directly from a source
Source
ft.fees.events.v1
Upstream field
fees.event_asset_amount_usd
Aggregation
sum— a flow; a range total is the sum of its parts
whatever chains the payload lists — never a list we maintain
Thresholds
none — see the methodology notes for why one is not set
Counts toward claimable totals
no
Methodology notes
This is the same upstream amountUsd as fees_events, re-keyed with the upstream product and asset address so a chain to product to asset flow can be computed without parsing display labels.
Alternate index only: it is the same dollars as fees_events and therefore never counts toward a claimable or fee total a second time.
Flow totals are net event values. The visualization also separates positive activity from negative costs so a signed RFQ liquidation result cannot disappear behind an absolute-value bar.
Product and asset describe the upstream event path; they do not establish protocol ownership of the value.
Range controls operate only over the event window the upstream endpoint actually exposes. The panel prints that observed coverage so a 90-day or All selection cannot be mistaken for 90 days or lifetime of receipts.
Each entity ends in txHash and logIndex. Those fields have zero duplicates in the live feed and prevent legitimate same-time events from overwriting one another.
The asset symbol is display metadata only; identity is always the lowercase contract address. User addresses are never normalized.
An ESTIMATE of how fees would split between the treasury and lenders, produced by applying an assumed reserve factor. The fees API flags this itself as a synthetic split, because the real on-chain reserve factor currently reads zero — so this is a modelled number, not an observed one.
last— a stock or running total; never summed across buckets
Freshness
expected every 15 minutes, stale after 2 hours
Entity
protocol:fees:product:{product}:type:{feeType}
Chains
not chain-scoped
Thresholds
none — see the methodology notes for why one is not set
Counts toward claimable totals
no
Methodology notes
NEVER counted inside a claimable or treasury total (PRODUCT.md §9.5). It renders as a visually and semantically separated overlay on the fees composition chart, with the word "estimate" attached — never as a bar in the same stack as realised fees.
The API itself is the source of the honesty here: it publishes reserveFactor.source = "synthetic_split" and an on-chain reserve factor of 0 bps against an assumed 1000 bps. We surface that self-declaration rather than quietly consuming the split as fact.
If the on-chain reserve factor ever becomes non-zero, this stops being an estimate and becomes an observation — which requires a contract change, not a registry edit.
Fees per day, by productfees_product_daily
Connected source
Application fees earned on each calendar day (UTC), split by which product earned them. This is the flow — what came in that day — as opposed to the running lifetime total.
Unit
usd (2 dp)
Derivation
observed— read directly from a source
Source
ft.fees.application.v1
Upstream field
fees.product_daily_usd
Aggregation
sum— a flow; a range total is the sum of its parts
Freshness
expected every 15 minutes, stale after 2 hours
Entity
protocol:fees:product:{product}
Chains
not chain-scoped
Thresholds
none — see the methodology notes for why one is not set
Counts toward claimable totals
yes
Methodology notes
A genuine daily FLOW, so it SUMS: a 30-day product total is the sum of that product's 30 days. This is the only fee breakdown that can honestly be range-scoped, and it is what the ranked contribution list on the Revenue workspace ranks.
Daily since 2026-01-27, 161 points at capture. Days before that do not exist and render as gaps — a zero would claim the product earned nothing that day.
Drives the product small multiples of signature visualization E.
Fees by fee typefees_by_fee_type
Connected source
Lifetime application fees split by product AND by the kind of fee within it — the OBSERVED rows only. The rows the API derives from an assumed reserve factor are a separate, clearly-labelled estimate and are not in this figure.
Unit
usd (2 dp)
Derivation
observed— read directly from a source
Source
ft.fees.application.v1
Upstream field
fees.product_fee_type_usd
Aggregation
last— a stock or running total; never summed across buckets
Freshness
expected every 15 minutes, stale after 2 hours
Entity
protocol:fees:product:{product}:type:{feeType}
Chains
not chain-scoped
Thresholds
none — see the methodology notes for why one is not set
Counts toward claimable totals
yes
Methodology notes
The source contract routes the synthetic reserve-factor rows to a DIFFERENT METRIC NAME (fees.product_fee_type_synthetic_usd), so this metric cannot contain one even by accident — the separation is structural, not a filter somebody has to remember to apply.
Cumulative per (product, fee type): LAST, never SUM.
Fees that are collected, unswept, and actually claimable on-chain right now — summed from only the real fee streams, with every synthetic forecast row excluded. This is the honest answer to "how much is actually there".
Unit
usd (2 dp)
Derivation
observed— read directly from a source
Source
ft.fees.pending.v1
Upstream field
fees.pending_claimable_onchain_usd
Aggregation
last— a stock or running total; never summed across buckets
Freshness
expected every 15 minutes, stale after 2 hours
Entity
protocol:fees:pending
Chains
not chain-scoped
Thresholds
none — see the methodology notes for why one is not set
Counts toward claimable totals
yes
Methodology notes
THE claimable number, and the reason it exists separately from fees_pending_treasury: the treasury-bound total the API publishes is built with the synthetic forecast rows ADDED IN. This one is summed by the source contract from the non-synthetic streams only (PRODUCT.md §9.5 — synthetic amounts never count toward claimable totals).
The two are both shown on the Revenue workspace, both labelled, and they are never added together.
Pending sweep, by streamfees_pending_stream
Connected source
Fees sitting unswept in one specific fee-collecting contract, and where they are bound — the treasury, or the lenders.
Unit
usd (2 dp)
Derivation
observed— read directly from a source
Source
ft.fees.pending.v1
Upstream field
fees.pending_stream_usd
Aggregation
last— a stock or running total; never summed across buckets
whatever chains the payload lists — never a list we maintain
Thresholds
none — see the methodology notes for why one is not set
Counts toward claimable totals
yes
Methodology notes
One row per (contract, destination). These are the REAL streams — the source contract routes synthetic ones to fees_pending_stream_synthetic, and it is their sum, not this metric's, that fees_pending_claimable_onchain reports.
Keyed on the fee-collecting CONTRACT address, never on a payer. No wallet-level attribution appears in any public payload.
Pending sweep, by stream (synthetic estimate)fees_pending_stream_synthetic
Connected source
A FORECAST of what one fee stream would hold if the assumed reserve factor were real. The fees API flags these rows itself, because the on-chain reserve factor currently reads zero — so these are modelled dollars, not collected ones.
Unit
usd (2 dp)
Derivation
estimated— modelled, never counted as observed
Source
ft.fees.pending.v1
Upstream field
fees.pending_stream_synthetic_usd
Aggregation
last— a stock or running total; never summed across buckets
whatever chains the payload lists — never a list we maintain
Thresholds
none — see the methodology notes for why one is not set
Counts toward claimable totals
no
Methodology notes
NEVER inside a claimable, swept or treasury total (PRODUCT.md §9.5). It renders in a visually and semantically separated panel, hatched, with the word "estimated" attached — never as a bar in the same stack as realised fees.
The honesty here originates upstream: the API self-declares reserveFactor.source = "synthetic_split", an assumed 1000 bps against an on-chain 0 bps. We surface that admission rather than quietly consuming the split as fact.
Marked "estimated" and declared as a DERIVED source precisely so the registry's own claim-integrity check refuses to let it count as claimable — the rule is enforced at module load, not by a reviewer noticing.
Application events indexedfees_events_total
Connected source
How many on-chain application events the rolling endpoint currently exposes. It is the denominator behind the transaction-level event table, not a lifetime fee count.
Unit
count (0 dp)
Derivation
observed— read directly from a source
Source
ft.fees.events.v1
Upstream field
fees.events_total
Aggregation
last— a stock or running total; never summed across buckets
Freshness
expected every 15 minutes, stale after 2 hours
Entity
protocol:fees:events
Chains
not chain-scoped
Thresholds
none — see the methodology notes for why one is not set
Counts toward claimable totals
no
Methodology notes
The upstream `total`, reported by the paginated events endpoint. The collector follows every advertised offset page, with a 200-page contract cap as a runaway guard, so normal upstream pagination is fully collected rather than silently stopping after page one.
A current endpoint count: LAST, not SUM. The observed coverage dates determine the actual window.
Risk
Fees: first-party vs DefiLlamadiscrepancy_fees
Connected source
The gap between the fees Flying Tulip reports and the fees DefiLlama reports for the same protocol. The gap is large and it is NOT an error: DefiLlama counts PUT-vault strategy yield as fees, Flying Tulip counts only application fees. Both numbers are right; they are answers to different questions.
Unit
usd (2 dp)
Derivation
calculated— computed by us from observed values
Source
ft.fees.application.v1, llama.fees.v1
Upstream field
fees.lifetime_usd, llama.fees_all_time_usd
Aggregation
last— a stock or running total; never summed across buckets
Freshness
expected every 1 hour, stale after 2 days
Entity
protocol:discrepancy:fees
Chains
not chain-scoped
Thresholds
none — see the methodology notes for why one is not set
Counts toward claimable totals
no
Methodology notes
fixture observed 2026-07-13: $42,993.54 first-party application fees against $3.99M DefiLlama fees — roughly a 93× gap, entirely explained by definition.
Rendered as a dumbbell (signature visualization D) with both definitions written out. It is never auto-labeled an error, never "reconciled", and neither side is corrected into the other.
This is the metric that most justifies FT Pulse existing: an aggregator number and a first-party number disagree by two orders of magnitude, and nobody else explains why.
No threshold. A stable, well-understood definitional gap is not an alert condition; alerting on it would train operators to ignore it.
ftUSD supply: ours vs DefiLlamadiscrepancy_ftusd_supply
Connected source
The gap between the ftUSD supply we measure and the figure DefiLlama publishes. We count Ethereum AND Sonic; DefiLlama indexes Ethereum only. The gap is missing coverage on their side, not an error on either.
Unit
usd (2 dp)
Derivation
calculated— computed by us from observed values
Source
ft.status.ftusd.dashboard.v1, llama.stablecoin.v1
Upstream field
ftusd.supply, ftusd.circulating_usd
Aggregation
last— a stock or running total; never summed across buckets
Freshness
expected every 1 hour, stale after 2 days
Entity
protocol:discrepancy:ftusd-supply
Chains
not chain-scoped
Thresholds
none — see the methodology notes for why one is not set
Counts toward claimable totals
no
Methodology notes
fixture observed 2026-07-13: $4.29M ours (Ethereum + Sonic) against $3.91M DefiLlama (Ethereum only since 2026-07-09).
The comparison values one ftUSD at the protocol's $1.00 accounting price so that a token count and a circulating-USD figure can be compared at all. That assumption is stated wherever this renders — and it is exactly why the MARKET peg is tracked as a separate metric.
Rendered as a discrepancy dumbbell (visualization D) with coverage notes on both sides.
The gap between the lending capital Flying Tulip reports as supplied and the TVL DefiLlama reports for the same product. They treat borrowed value differently, so the two figures do not — and should not — match.
Unit
usd (2 dp)
Derivation
calculated— computed by us from observed values
Source
ft.mm.lend.v1, llama.protocol.v1
Upstream field
lend.supplied_usd, llama.tvl_usd
Aggregation
last— a stock or running total; never summed across buckets
Freshness
expected every 1 hour, stale after 2 days
Entity
protocol:discrepancy:tvl
Chains
not chain-scoped
Thresholds
none — see the methodology notes for why one is not set
Counts toward claimable totals
no
Methodology notes
fixture observed 2026-07-13: $12.05M first-party supplied against $11.15M DefiLlama TVL — a netting/borrowed-treatment difference, not a discrepancy in the underlying capital.
DefiLlama splits Flying Tulip into sub-protocols (lend, ftUSD, yield); comparing a single sub-protocol against our protocol-wide figure would manufacture a gap that is not there, so the comparison is scoped to lending on both sides.
These are not gaps. Each is a number we could compute and have decided not to publish, because publishing it would mean asserting something we cannot support.
Burn / buyback counter
Not published, on two independent grounds — either alone would be sufficient.
The only burn-shaped signal Flying Tulip exposes arrives roughly a hundred million times larger than the collateral base it should be commensurate with, with no documented unit or decimals. It fails its scale contract and is quarantined. A counter built on it would be a fabricated number wearing a real metric’s clothes.
A burn total would not evidence a buyback in any case. Tokens leave circulation for several reasons; “burned” and “bought back from the market” are different claims, and the first does not substantiate the second.
Release requires Flying Tulip to confirm the units and decimals on-chain, plus a new source-contract version that passes its fixtures. It is not a display decision and cannot be undone by editing a page.
Unlock / vesting calendar
Pending source approval. CryptoRank’s terms do not license automated machine-readable extraction, and no licensed API contract exists for the FT unlock schedule. Collection is forbidden until a licence is obtained or a licensed alternative is approved.
No unlock dates or amounts are estimated from circulating supply in the meantime. An unlock schedule is a thing people position against, so a plausible-looking guess would be worse than the blank — it would be acted on.
Audit count and auditor names
Not published. No complete, citation-ready public source currently exposes an audit catalog that every reader can independently verify. Reports, auditor names, and an audit count therefore stay absent here.
A tally of audits by named firms is a security claim, not a decorative statistic. It will appear only when the underlying reports can be linked beside the number and checked by the same public audience reading it.
Unobserved capabilities
Capabilities without readable telemetry are not visualized or listed as public workspaces. A chart appears only after an approved source contract publishes validated observations.
