INTELLIGENCE4 pages⌄
ECONOMY4 pages⌄
SIG-METRICS11 pages⌄
XRPFi12 pages⌄
WALLET + MARKET4 pages⌄
NETWORK OPERATIONS2 pages⌄
Command search · jump directly into the Intelligence Hub or public FlareSignal areas.
FLARESIGNAL · FAQ & DATA PRINCIPLES
Clear evidence.
Clear boundaries.
Customer-facing guidance for interpreting FlareSignal data, charts, XRPFi intelligence, history, Pro features and privacy. It focuses on what the outputs mean, their evidence boundaries and their important limitations.
FLARESIGNAL
Scope and interpretation boundaries
What the platform is designed to measure, and what it deliberately refuses to claim without evidence.
What is FlareSignal?+
FlareSignal is an independent Flare and Songbird ecosystem-intelligence platform. It joins verified network state, FTSO reference pricing, exchange market microstructure, FAssets/FXRP state, XRPFi protocol capital, yield and credit observations, wallet evidence, event context and live flow visualisation into one shared analytical data layer. It is not an official Flare Networks product and does not speak on behalf of Flare or any integrated third-party protocol.
What problem is FlareSignal designed to solve?+
The platform is designed to make the Flare/Songbird system observable as a connected economic network rather than as a collection of unrelated token-price pages. A researcher can move from price and liquidity into chain activity, supply structure, FAssets, XRPFi deployment, protocol yield/credit, wallet routing and event context while retaining provenance and accounting boundaries.
How does FlareSignal keep metrics consistent?+
FlareSignal uses shared metric definitions so the same measurement keeps the same meaning across customer-facing charts, pages and supported data interfaces. This reduces contradictory totals and interpretation drift. Internal implementation details are not part of the public FAQ.
Why can metric counts differ between the FAQ and API catalogue?+
Different FlareSignal surfaces can expose different metric populations depending on their purpose and access scope. A count should therefore be interpreted in the context of the surface that reports it rather than assumed to represent every metric available across the platform.
How does FlareSignal separate facts from analysis?+
FlareSignal distinguishes directly observed or source-reported facts from derived analysis. Derived outputs remain labelled as analysis and do not become source-reported facts simply because they are displayed beside them.
What is the difference between an observation, an attribution and an inference?+
An observation is directly supported by the source, such as an executed exchange fill or an on-chain event. Attribution links that observation to a protocol, address role or economic component using verified evidence. Inference interprets what the evidence may mean. FlareSignal keeps these levels distinct because the confidence requirements are different.
Does an event marker or correlated signal mean the event caused the market move?+
No. Event time, market co-movement and causal attribution are separate. FlareSignal can show that a protocol launch, governance action, macro event or wallet incident occurred near a price/volume change. Causation requires a defensible mechanism and supporting evidence; temporal proximity alone is not sufficient.
Does FlareSignal provide trading or investment advice?+
No. The platform exposes market structure, liquidity, volatility, protocol economics, wallet evidence and other decision-useful data, but it does not convert those observations into personalised buy, sell or hold instructions. A signal can describe measurable conditions without claiming a future return.
Why can two FlareSignal totals that both reference XRP or FXRP differ?+
Because they may answer different accounting questions. FXRP system supply, protocol balance, receipt-token look-through, collateral deployment, generated yield and derivatives notional are not interchangeable. FlareSignal intentionally keeps capital-location, economic-output and market-activity measures separate unless the accounting relationship is explicitly defined.
Why does FlareSignal sometimes show partial history?+
FlareSignal shows only retained or otherwise verified historical evidence. If an older period cannot be supported, the available coverage boundary is disclosed instead of manufacturing observations or presenting an incomplete period as complete.
How should a reviewer evaluate a FlareSignal metric?+
Check the measurement name, classification, unit, time window, freshness, provenance, historical coverage and stated limitations shown with the output. These are the fields intended for interpretation and review.
DATA · TRUST
Provenance, timestamps and coverage
The customer-facing evidence principles needed to interpret FlareSignal outputs correctly.
How does FlareSignal describe evidence quality?+
Customer-facing outputs distinguish direct or source-reported observations from aggregated or FlareSignal-derived analysis. Provenance, timestamps, freshness, coverage and relevant limitations are exposed where they affect interpretation.
What is the difference between source time and observed time?+
Source time is the timestamp carried by the underlying block, event, trade or source payload where available. Observed time is when FlareSignal collected or stored the record. Both are preserved because collection latency must not be confused with the time the underlying economic event occurred.
How does FlareSignal handle exchange trade timestamp precision?+
Where an exchange supplies millisecond execution time, the retained trade record stores that millisecond timestamp alongside the normal database execution time. If only second precision is available, FlareSignal preserves the best precision the venue provides rather than inventing sub-second ordering.
How does FlareSignal handle repeated market records?+
Where records carry sufficient identity evidence, repeated observations are prevented from being counted as separate economic events.
What does a rolling window mean?+
A rolling window moves continuously with the observation boundary. For example, rolling 24h at 14:00 covers qualifying source observations from approximately 14:00 the previous day to the current boundary. It is not a UTC-calendar-day bucket unless the metric explicitly says so.
How are percentage deltas calculated?+
Unless a metric definition specifies another transform, percentage change uses (current − baseline) / baseline × 100. A missing or zero denominator is not silently coerced into a percentage. Positive changing values are rendered positive, negative values negative, and exact zero/unavailable states remain neutral. Explanatory percentages are not colour-coded as market movement.
How does FlareSignal handle decimal precision?+
Source integers are decoded using authoritative token/feed decimals. Stored observations retain the precision required by the measurement. UI formatting can round for readability, but display rounding does not alter the underlying observation or downstream calculation input.
How are historical coverage gaps handled?+
Historical coverage is dataset-specific. FlareSignal exposes the earliest and latest supported observations and keeps unsupported periods explicit. Missing periods are not presented as verified history.
What does “All” history mean?+
For a standard historical chart, All means the complete retained/indexed history available to that chart, not a 90-day alias. It can still be shorter than protocol inception if the source or available historical evidence cannot support older reconstruction. Coverage state remains part of the interpretation.
Does every dataset retain the same amount of history?+
No. Historical availability is dataset-specific and can differ by measurement type and source. FlareSignal exposes the coverage available to the requested surface rather than implying that every dataset begins at network or protocol inception.
How does FlareSignal avoid misleading combined totals?+
Values that may represent overlapping economic exposure are not automatically treated as additive. Where a combined total is shown, its public label and scope describe what is being measured and any important limitations.
How should live estimates be interpreted?+
Where FlareSignal displays a live estimate, it is labelled as an estimate rather than an exact historical observation. Exact retained observations remain the authoritative evidence for historical analysis, and unavailable evidence is not converted into realised results.
What happens when a customer-facing measurement changes?+
Material changes that affect how a customer should interpret an output are reflected in the relevant product or data guidance. Internal implementation and release-control procedures remain private.
Does “verified” mean infallible?+
No. Verification describes the evidence path and current validation state. Upstream interfaces can change, contracts can migrate, APIs can alter field semantics and implementation bugs can exist. Provenance, health state, methodology boundaries and regression checks make those risks inspectable rather than pretending they do not exist.
CHARTS · HISTORY
Time-domain semantics, history entitlements and inspection
Normal historical charts share one range standard so the plotted window, axis and inspection logic do not drift by page.
What is the standard FlareSignal historical chart range set?+
Normal full historical charts expose 1D, 3D, 7D, 15D, 30D, 90D, 1Y and All. Public users can select 1D, 3D and 7D. The 15D, 30D, 90D, 1Y and All buttons remain visible with the Pro lock state. Pro members unlock the complete range set.
How does the compact range control work?+
The current range is displayed in one compact control at the top-right above the chart. Activating it opens a rectangular range panel directly beneath the control with a small gap over the chart. Selecting a range closes the panel and changes the compact control to the active range.
What is the standard chart-tools layout?+
For normal full charts, colour/series keys occupy the left of the tool row, chart-specific mode/filter toggles occupy the centre, and the range control occupies the top-right. The tool row sits immediately above the plot. This ordering is a presentation standard and does not change the underlying series.
Does changing the range only hide points?+
No. The selected range changes the actual filtered time window and the x-axis time domain. Timestamp spacing, bottom axis labels and pointer/crosshair nearest-point selection are recalculated from the selected period. The chart does not keep a 90-day axis while merely hiding older points.
How are irregularly spaced observations plotted?+
Where source observations are not uniformly spaced, the chart uses real timestamps for x-position rather than assuming every array row represents an equal interval. Crosshair inspection uses the same time-domain model so the marker and plotted line refer to the same observation.
How does a chart communicate incomplete history?+
A chart can only render observations present in the retained archive. Coverage/readiness metadata is used where available to distinguish a short history because the user selected 1D from a short history because the dataset itself has not yet accumulated the requested range. Missing history is not visually invented.
Which visuals are exempt from the seven-range control?+
Small KPI sparklines/radials and genuinely cross-sectional structural visuals are exempt when a historical window would not make semantic sense. The dedicated Pro Charting workstation is also excluded because it is a trading-chart environment with its own interval, indicator, drawing and order-book controls.
How do public charts differ from Pro Depth charts?+
The public protocol page remains useful with current state and public short-window history. A final Pro Depth section uses the same retained history for longer-window structural analysis, such as derivatives structure, credit-market structure or term-structure persistence. Pro Depth is not created by simply moving an ordinary public chart behind a lock.
What do chart event markers mean?+
An event marker places a classified ecosystem, protocol, market or policy event in temporal context. It does not assert causation. Event type, relevance, source quality and observed post-event metrics are separate from causal confidence.
Why are positive and negative values colour-coded but some percentages are not?+
Colour is reserved for genuine changing/directional values. Positive deltas are green, negative deltas red, and exact zero or unavailable values neutral. A static percentage such as current utilisation share, collateral share or portfolio composition is explanatory state and does not inherit gain/loss colouring merely because it contains a percent sign.
What is Pro Charting designed for?+
Pro Charting is the dedicated research chart terminal for market candles, indicators, drawings, order-book context and saved analysis. It is intentionally separate from the site-wide historical chart component so trading-chart interactions do not dictate the behaviour of every intelligence chart.
NETWORK · FLR / SGB
Chain state, FTSO/FDC, staking and network participation
Flare and Songbird are measured as separate network domains even where the same analytical transform is applied.
Where do FLR, SGB and XRP reference prices come from?+
FlareSignal uses the relevant Flare FTSO data layer for reference prices where available. Feed integers are decoded using the authoritative feed decimals. Public exchange executions are stored separately for venue market structure and are not silently substituted for the FTSO reference price.
How is the standard 24-hour price change calculated?+
The current reference price is compared with a historical observation approximately 24 hours earlier using (current − historical) / historical × 100. The current and historical prices remain primary observations; the percentage is a derived comparison.
What does Transactions 24h measure?+
It is the rolling sum of observed C-chain transaction counts whose source timestamps fall in the previous 24 hours. It is not a unique-wallet count, user count, application count or measure of economic value.
Why is transaction-count change shown beside price on some network cards?+
Price and network use answer different questions. The companion TX delta provides a network-activity change alongside the market-price change without asserting that transaction growth caused price movement.
What is the difference between P-chain stake and FTSO delegation?+
P-chain validator stake is capital committed to validator self-bond/delegation. FTSO delegation is vote-power delegation associated with wrapped native assets. They are different mechanisms and can overlap economically, so they are not added as independent capital without overlap resolution.
Why is WFLR or WSGB total supply not called “total delegated”?+
Wrapped-native supply is the vote-power base from which power can be owned or delegated. It includes balances that are not delegated to another provider. FlareSignal therefore does not relabel total wrapped supply as delegated-only capital.
How are active validators and connected validators different?+
Active validator count describes membership of the current authoritative validator set. Connected validators are the subset reported connected by the queried public P-chain interface at observation time. Connectivity is a current state observation, not a permanent performance or quality rating.
What do FSP/FTSO provider weights represent?+
Provider/reward observations are derived from authoritative reward-epoch data. Wrapped-native vote-power weight can include owned and delegated power; mirrored node/stake weights represent provider weighting. Mirrored weights are not counted again as new capital on top of the underlying stake.
How are FDC requests and fees interpreted?+
AttestationRequest events are counted over their stated window and native request fees are summed from the event fee field. A request is not automatically a successful finalised attestation, and a request fee is not labelled burned unless the network fee semantics support that conclusion.
How does FLR vs SGB comparison avoid false equivalence?+
The comparison view synchronises like-for-like measurements where the underlying network concepts are comparable. It does not assume the two networks have identical supply structures, market liquidity, protocol deployment or governance state. The comparison layer preserves network scope for each source.
How is network account growth treated when history is incomplete?+
Account-growth series require historical account-state observations or a defensible archive source. FlareSignal will not synthesize old account counts from current totals. Until a source supports backfill, the chart begins at the earliest verified observation.
REGISTERED METRIC REFERENCE
Network & FLR / SGB
Prices, chain state, supply, staking, FTSO/FSP and FDC.
Flare Data Connector6
Flare Average FDC Request Fee 24hFlareSignal-derived · FLARE / FLR+
Average native fee per observed Flare FDC attestation request over the trailing 24 hours.
Flare FDC Attestation Requests 24hFlareSignal-derived · FLARE / FLR+
FdcHub attestation requests observed on Flare during the trailing 24 hours.
Flare FDC Request Fees 24hFlareSignal-derived · FLARE / FLR+
Native FLR submitted with FDC attestation requests during the trailing 24 hours.
Songbird Average FDC Request Fee 24hFlareSignal-derived · SONGBIRD / SGB+
Average native fee per observed Songbird FDC attestation request over the trailing 24 hours.
Songbird FDC Attestation Requests 24hFlareSignal-derived · SONGBIRD / SGB+
FdcHub attestation requests observed on Songbird during the trailing 24 hours.
Songbird FDC Request Fees 24hFlareSignal-derived · SONGBIRD / SGB+
Native SGB submitted with FDC attestation requests during the trailing 24 hours.
FSP / FTSO providers10
Flare Active WNat Provider WeightAggregated observation · FLARE / WFLR+
Sum of WNat vote-power weight attributed to registered Flare providers for the published reward epoch. Includes owned and delegated WFLR and is not delegated-only.
Flare FSP ProvidersAggregated observation · FLARE / FLR+
Number of providers represented in the latest published Flare signing/reward epoch data.
Flare Mirrored Provider StakeAggregated observation · FLARE / FLR+
Sum of nodeWeights assigned to Flare providers in the latest official reward-epoch registration data.
Flare Published Reward EpochRaw / source-reported · FLARE / FLR+
Latest Flare reward epoch published in the authoritative FSP rewards repository.
Flare Reward-Eligible ProvidersAggregated observation · FLARE / FLR+
Providers marked eligibleForReward in the latest official Flare passes data.
Songbird Active WNat Provider WeightAggregated observation · SONGBIRD / WSGB+
Sum of WNat vote-power weight attributed to registered Songbird providers for the published reward epoch. Includes owned and delegated WSGB and is not delegated-only.
Songbird FSP ProvidersAggregated observation · SONGBIRD / SGB+
Number of providers represented in the latest published Songbird signing/reward epoch data.
Songbird Mirrored Provider StakeAggregated observation · SONGBIRD / SGB+
Sum of nodeWeights assigned to Songbird providers in the latest official reward-epoch registration data.
Songbird Published Reward EpochRaw / source-reported · SONGBIRD / SGB+
Latest Songbird reward epoch published in the authoritative FSP rewards repository.
Songbird Reward-Eligible ProvidersAggregated observation · SONGBIRD / SGB+
Providers marked eligibleForReward in the latest official Songbird passes data.
FTSO delegation4
FLR Total FTSO DelegatedAggregated observation · FLARE / FLR+
Reserved delegated-only WFLR metric. Not populated until delegation-state reconstruction is verified.
SGB Total FTSO DelegatedAggregated observation · SONGBIRD / SGB+
Reserved delegated-only WSGB metric. Not populated until delegation-state reconstruction is verified.
WFLR Vote-Power BaseRaw / source-reported · FLARE / WFLR+
Total WFLR supply. This is the wrapped-native token base from which FTSO vote power is owned/delegated; it is not a delegated-only total.
WSGB Vote-Power BaseRaw / source-reported · SONGBIRD / WSGB+
Total WSGB supply. This is the wrapped-native token base from which FTSO vote power is owned/delegated; it is not a delegated-only total.
Network state4
Flare Block HeightRaw / source-reported · FLARE / FLR+
Latest block height returned by the official public Flare RPC.
Flare Transactions 24hAggregated observation · FLARE / FLR+
Rolling count of transactions in Flare C-chain blocks observed over the previous 24 hours.
Songbird Block HeightRaw / source-reported · SONGBIRD / SGB+
Latest block height returned by the official public Songbird RPC.
Songbird Transactions 24hAggregated observation · SONGBIRD / SGB+
Rolling count of transactions in Songbird C-chain blocks observed over the previous 24 hours.
Price & market6
FLR / USDRaw / source-reported · FLARE / FLR+
Flare price in US dollars from the official FTSO data layer.
FLR 24h Price ChangeFlareSignal-derived · FLARE / FLR+
Rolling FLR/USD percentage change using two exact official FTSO voting-round anchors separated by 86,400 seconds.
SGB / USDRaw / source-reported · SONGBIRD / SGB+
Songbird price in US dollars from the official FTSO data layer.
SGB 24h Price ChangeFlareSignal-derived · SONGBIRD / SGB+
Rolling SGB/USD percentage change using two exact official Songbird FTSO voting-round anchors separated by 86,400 seconds.
XRP / USDRaw / source-reported · FLARE / XRP+
XRP price in US dollars from Flare FTSO.
XRP 24h Price ChangeFlareSignal-derived · FLARE / XRP+
Rolling XRP/USD percentage change using two exact official Flare FTSO voting-round anchors separated by 86,400 seconds.
Staking5
Connected Flare ValidatorsAggregated observation · FLARE / FLR+
Validators in the official active set reported connected by the queried public P-chain API.
Flare Validator CountAggregated observation · FLARE / FLR+
Number of active validators returned by the official Flare P-chain validator set.
FLR P-Chain Delegated StakeAggregated observation · FLARE / FLR+
Total active FLR delegated to validators on the P-chain. This is staking delegation, not FTSO delegation.
FLR Total StakeAggregated observation · FLARE / FLR+
Current FLR locked in active P-chain validator self-bonds plus P-chain stake delegations from the official validator set.
FLR Validator Self-BondAggregated observation · FLARE / FLR+
Total active validator self-bond on the Flare P-chain.
Supply4
FLR Circulating SupplyRaw / source-reported · FLARE / FLR+
Current FLR circulating supply from the official Flare supply endpoint.
FLR Total Coin SupplyOfficial Indexed · FLARE / FLR+
Native FLR total coin supply reported by the official Flare explorer index after the explorer burn adjustment.
SGB Circulating SupplyRaw / source-reported · SONGBIRD / SGB+
Current SGB circulating supply from the official Flare supply endpoint.
SGB Total Coin SupplyOfficial Indexed · SONGBIRD / SGB+
Native SGB total coin supply reported by the official Songbird explorer index after the explorer burn adjustment.
ECONOMY · SUPPLY
Burn, issuance, utilisation, scarcity and capital mobility
Supply destruction, fee expenditure, productive use and market availability are related but distinct economic variables.
What is the difference between transaction fees and observable fee burn?+
Total paid transaction fees measure native-asset expenditure. Observable EVM fee burn measures the base-fee component destroyed under the network fee mechanism. Priority/tip components are retained as fee context and are not assumed burned when explorer/chain semantics expose them separately.
What does Total Burned represent?+
It is the current balance held at documented permanent burn addresses for the relevant network. Burn-wallet accumulation and EVM transaction-fee destruction are tracked as distinct accounting mechanisms so the same destruction is not silently double counted.
How are burn-wallet 24h, 7d and 30d changes measured?+
The current documented burn-wallet balance is compared with the latest verified balance at or before the relevant lookback boundary. The result is the change in permanent-sink balance over the trailing period, not an estimate derived from current transaction activity.
What is Burn Share of Paid Fees?+
It is observable base-fee burn / total paid transaction fees × 100. It measures the share of transaction-fee expenditure represented by the observable burn component. It is not the share of total token supply burned.
When can FLR be described as net deflationary?+
The existence of burns is insufficient. A defensible net-supply state compares verified issuance/inflation with verified permanent supply reductions or offsets over a common period. FlareSignal should only describe net deflation when the measured net supply change is negative under that accounting scope.
What does utilisation measure?+
Utilisation attempts to identify supply measurably engaged in productive network/protocol roles rather than simply outstanding. Delegation, staking, wrapped balances, FAssets, protocol positions and other states can overlap, so the utilisation layer requires explicit non-overlap/look-through rules.
What does Supply Availability & Scarcity measure?+
Scarcity intelligence combines supply structure with visible market liquidity and productive/committed states. It asks how much supply appears readily available versus engaged elsewhere. It is not a deterministic price model and does not assume every non-exchange token is illiquid.
How should visible order-book depth be interpreted?+
Depth is a snapshot of displayed bids/asks at connected venues and the observation time. Orders can be cancelled or replaced, public depth does not include all liquidity, and displayed size is not guaranteed executable as one trade. Historical order-book snapshots are therefore treated as market-state observations.
What does Capital Flow Intelligence mean by a flow?+
A flow can be an exact transaction/event route or a measured state delta, depending on the source. FlareSignal only presents a specific transaction path when the evidence supports it. If a verified protocol balance changed without depositor-level transfer evidence, the movement remains a measured capital change.
Why are supply availability, utilisation and TVL not added into one “locked supply” total?+
They can describe overlapping claims on the same tokens. A token can be wrapped, delegated, deposited and represented by a receipt token without creating four independent units of capital. Combined totals therefore require a proven non-overlap model rather than arithmetic addition.
REGISTERED METRIC REFERENCE
Economy & Supply
Burn, utilisation, scarcity, capital flow and supply-availability measures.
Burn Intelligence29
FLR Annualised Observed Burn RateFlareSignal-derived · FLARE / FLR+
Observed 30-day FLR burn flow annualised as a percentage of current circulating supply.
FLR Burn AbsorptionFlareSignal-derived · FLARE / FLR+
All-time FLR burn-wallet balance as a percentage of current FLR outside measured utilisation.
FLR Burn Share of Paid Fees 24hFlareSignal-derived · FLARE / FLR+
Share of total paid FLR transaction fees represented by the observable base-fee burn component.
FLR Burn-Wallet Change 24hFlareSignal-derived · FLARE / FLR+
Increase in the canonical FLR burn-wallet balance over the trailing 24 hours.
FLR Burn-Wallet Change 30dFlareSignal-derived · FLARE / FLR+
Increase in the canonical FLR burn-wallet balance over the trailing 30 days.
FLR Burn-Wallet Change 7dFlareSignal-derived · FLARE / FLR+
Increase in the canonical FLR burn-wallet balance over the trailing seven days.
FLR Direct Burn-Address BalanceChain-verified · FLARE / FLR+
Current FLR balance at the canonical dead address.
FLR Fee Burn per 10,000 TransactionsFlareSignal-derived · FLARE / FLR+
FLR fee burn normalized per 10,000 observed transactions.
FLR Observable Fee Burn 24hFlareSignal-derived · FLARE / FLR+
Native FLR burned through the observable EVM base-fee component over the last 24 hours.
FLR Observed Native Burn Flow 24hFlareSignal-derived · FLARE / FLR+
Observed FLR burn flow from fee burn plus positive direct burn-address balance change.
FLR Observed Native Burn Flow 30dFlareSignal-derived · FLARE / FLR+
Observed FLR native burn flow over the last 30 days.
FLR RewardManager Burned Rewards TotalChain-verified · FLARE / FLR+
Cumulative burned rewards reported by the Flare RewardManager contract.
FLR Total BurnedChain-verified · FLARE / FLR+
Current FLR balance held at the canonical network burn address.
FLR Total Transaction Fees Paid 24hFlareSignal-derived · FLARE / FLR+
Total native FLR transaction fees paid over the retained last 24 hours, including the observable burned base-fee component and non-burn/tip component.
SGB Annualised Observed Burn RateFlareSignal-derived · SONGBIRD / SGB+
Observed 30-day SGB burn flow annualised as a percentage of current circulating supply.
SGB Burn AbsorptionFlareSignal-derived · SONGBIRD / SGB+
All-time SGB burn-wallet balance as a percentage of current SGB outside measured utilisation.
SGB Burn Share of Paid Fees 24hFlareSignal-derived · SONGBIRD / SGB+
Share of total paid SGB transaction fees represented by the observable base-fee burn component.
SGB Burn-Wallet Change 24hFlareSignal-derived · SONGBIRD / SGB+
Increase across Songbird’s documented burn-wallet balances over the trailing 24 hours.
SGB Burn-Wallet Change 30dFlareSignal-derived · SONGBIRD / SGB+
Increase across Songbird burn-wallet balances over the trailing 30 days.
SGB Burn-Wallet Change 7dFlareSignal-derived · SONGBIRD / SGB+
Increase across Songbird burn-wallet balances over the trailing seven days.
SGB Direct Burn-Address BalanceChain-verified · SONGBIRD / SGB+
Current SGB balance at the canonical dead address.
SGB Fee Burn per 10,000 TransactionsFlareSignal-derived · SONGBIRD / SGB+
Conservative SGB base-fee burn normalized per 10,000 observed transactions.
SGB Legacy Avalanche Burn-Address BalanceChain-verified · SONGBIRD / SGB+
Current SGB balance at the legacy Avalanche burn address tracked by Songbird supply accounting.
SGB Observable Fee Burn 24hFlareSignal-derived · SONGBIRD / SGB+
Native SGB base-fee burn observed over the last 24 hours.
SGB Observed Native Burn Flow 24hFlareSignal-derived · SONGBIRD / SGB+
Observed SGB burn flow from conservative fee burn plus positive direct burn-address balance change.
SGB Observed Native Burn Flow 30dFlareSignal-derived · SONGBIRD / SGB+
Observed SGB native burn flow over the last 30 days.
SGB RewardManager Burned Rewards TotalChain-verified · SONGBIRD / SGB+
Cumulative burned rewards reported by the Songbird RewardManager contract.
SGB Total BurnedChain-verified · SONGBIRD / SGB+
Current SGB balance held across Songbird’s documented permanent burn addresses.
SGB Total Transaction Fees Paid 24hFlareSignal-derived · SONGBIRD / SGB+
Total native SGB transaction fees paid over the retained last 24 hours.
Capital flow8
FLR Verified Exchange-to-Wallet Routing 24hFlareSignal-derived · FLARE / FLR+
Observed FLR routed from positively verified exchange addresses to indexed wallets over 24 hours.
FLR Verified Route Interactions 24hFlareSignal-derived · FLARE / FLR+
Count of FLR interactions between indexed wallets and positively verified exchange addresses over 24 hours.
FLR Verified Wallet-to-Exchange Routing 24hFlareSignal-derived · FLARE / FLR+
Observed FLR routed from indexed wallets to positively verified exchange addresses over 24 hours.
FXRP Productive Capital CeilingFlareSignal-derived · FLARE / FXRP+
Upper bound of productive FXRP under current overlap uncertainty.
FXRP Productive Capital FloorFlareSignal-derived · FLARE / FXRP+
Conservative lower bound of uniquely productive FXRP capital.
SGB Verified Exchange-to-Wallet Routing 24hFlareSignal-derived · SONGBIRD / SGB+
Observed SGB routed from positively verified exchange addresses to indexed wallets over 24 hours.
SGB Verified Route Interactions 24hFlareSignal-derived · SONGBIRD / SGB+
Count of SGB interactions between indexed wallets and positively verified exchange addresses over 24 hours.
SGB Verified Wallet-to-Exchange Routing 24hFlareSignal-derived · SONGBIRD / SGB+
Observed SGB routed from indexed wallets to positively verified exchange addresses over 24 hours.
Supply availability16
FLR +10% Visible Asks / Total SupplyFlareSignal-derived · FLARE / FLR+
Tracked FLR asks within +10% as a percentage of current total supply.
FLR +2% Visible Asks / Total SupplyFlareSignal-derived · FLARE / FLR+
Tracked FLR asks within +2% as a percentage of current total supply.
FLR Not Visibly Offered Within +2%FlareSignal-derived · FLARE / FLR+
Circulating FLR minus tracked asks currently posted within +2% of market mid.
FLR Outside Measured Utilisation / Total SupplyFlareSignal-derived · FLARE / FLR+
FLR outside the measurable utilisation floor as a percentage of current total supply.
FLR Outside Measured Utilisation FloorFlareSignal-derived · FLARE / FLR+
Circulating FLR not captured by the current measurable utilisation floor.
FLR Visible +2% Ask Depth / CirculatingFlareSignal-derived · FLARE / FLR+
Tracked FLR asks within +2% expressed as a share of current circulating FLR.
FLR Visible +2% Supply DaysFlareSignal-derived · FLARE / FLR+
Tracked +2% FLR ask depth divided by tracked FLR 24h base volume.
FLR Visible Near-Market Sell LiquidityFlareSignal-derived · FLARE / FLR+
Tracked FLR ask quantity within +2% of market mid.
SGB +10% Visible Asks / Total SupplyFlareSignal-derived · SONGBIRD / SGB+
Tracked SGB asks within +10% as a percentage of current total supply.
SGB +2% Visible Asks / Total SupplyFlareSignal-derived · SONGBIRD / SGB+
Tracked SGB asks within +2% as a percentage of current total supply.
SGB Not Visibly Offered Within +2%FlareSignal-derived · SONGBIRD / SGB+
Circulating SGB minus tracked asks currently posted within +2% of market mid.
SGB Outside Measured Utilisation / Total SupplyFlareSignal-derived · SONGBIRD / SGB+
SGB outside the measurable utilisation floor as a percentage of current total supply.
SGB Outside Measured Utilisation FloorFlareSignal-derived · SONGBIRD / SGB+
Circulating SGB not captured by the current measurable utilisation floor.
SGB Visible +2% Ask Depth / CirculatingFlareSignal-derived · SONGBIRD / SGB+
Tracked SGB asks within +2% expressed as a share of current circulating SGB.
SGB Visible +2% Supply DaysFlareSignal-derived · SONGBIRD / SGB+
Tracked +2% SGB ask depth divided by tracked SGB 24h base volume.
SGB Visible Near-Market Sell LiquidityFlareSignal-derived · SONGBIRD / SGB+
Tracked SGB ask quantity within +2% of market mid.
Utilisation11
FLR At Verified Exchange AddressesFlareSignal-derived · FLARE / FLR+
Current FLR held at addresses positively attributed to exchange entities and present in the current holder index.
FLR Measurable Utilisation FloorFlareSignal-derived · FLARE / FLR+
Conservative current FLR participation floor from mutually distinct measured layers: WFLR supply plus Flare P-chain stake, capped at circulating supply.
FLR Measurable Utilisation Floor %FlareSignal-derived · FLARE / FLR+
FLR measurable utilisation floor as a percentage of circulating supply.
FLR Observed Utilisation CeilingFlareSignal-derived · FLARE / FLR+
Broader observed FLR utilisation ceiling adding sampled verified protocol-native balances not already explicitly counted, capped at circulating supply.
FLR Observed Utilisation Ceiling %FlareSignal-derived · FLARE / FLR+
Observed FLR utilisation ceiling as a percentage of circulating supply.
FLR Provably Locked / Restricted FloorFlareSignal-derived · FLARE / FLR+
Current FLR in the separately measured P-chain staking layer.
SGB At Verified Exchange AddressesFlareSignal-derived · SONGBIRD / SGB+
Current SGB held at addresses positively attributed to exchange entities and present in the current holder index.
SGB Measurable Utilisation FloorFlareSignal-derived · SONGBIRD / SGB+
Conservative current SGB participation floor using WSGB supply.
SGB Measurable Utilisation Floor %FlareSignal-derived · SONGBIRD / SGB+
SGB measurable utilisation floor as a percentage of circulating supply.
SGB Observed Utilisation CeilingFlareSignal-derived · SONGBIRD / SGB+
Broader observed SGB utilisation ceiling including sampled verified protocol-native balances, capped at circulating supply.
SGB Observed Utilisation Ceiling %FlareSignal-derived · SONGBIRD / SGB+
Observed SGB utilisation ceiling as a percentage of circulating supply.
XRPFi · FXRP
FAssets, productive XRP-linked capital and generated economics
Capital location, receipt-token representation, yield generation and derivatives activity are intentionally separated.
What does FlareSignal mean by XRPFi?+
XRPFi describes programmable use of XRP-linked capital and infrastructure across Flare, including FXRP/FAssets, stXRP and supported protocols/strategies that deploy or transform that capital. It is an accounting and activity domain rather than a synonym for one token balance.
What is FXRP in FlareSignal accounting?+
FXRP is the FAsset representation of XRP on Flare. System supply, mint/redemption workflow state, protocol balances and derivative/receipt-token claims can describe different layers of the same underlying XRP-linked capital. Those layers require look-through rather than naive addition.
What does “Where Is The XRP?” measure?+
It is a capital-location framework. FlareSignal identifies defensible XRP/FXRP-equivalent positions across FAssets and supported XRPFi protocols. Where a receipt/share token represents underlying FXRP, the look-through amount is used to describe location without counting the receipt and the underlying as independent XRP.
What does “What Has XRPFi Generated?” measure?+
It is an economic-output framework, not TVL. It attributes verified/defensible fees, lender interest, rewards or other generated value to XRPFi only when the source and additive accounting rule are known. Principal deposits and derivative notional are not generated yield.
How are FAssets mint and redemption events treated?+
Mint and redemption are separate workflow operations with their own event/timestamp/transaction evidence. Requests, completed operations and current FXRP supply are distinct measurements. A request event is not automatically counted as a completed mint or redemption.
How does stXRP affect XRPFi look-through?+
stXRP is treated as a receipt/claim layer over XRP-derived capital. Where a verified exchange/conversion relationship exists, FlareSignal can express stXRP positions in FXRP/XRP-equivalent terms. The receipt-token balance is not added again as newly created XRP.
How does FlareSignal avoid double counting protocol stacks?+
The platform distinguishes underlying asset, receipt token, vault share, lending claim and term instrument. If stXRP is deposited into another protocol, for example, FlareSignal can show both protocol locations while using look-through rules to avoid declaring each representation as additional underlying XRP.
What do Smart Account event counts mean?+
They count recognised MasterAccountController event classes in the stated window. Event volume is not automatically a unique-user count. Event-class breadth, backlog and trailing-window coverage are separate measurements.
What does Smart Accounts coverage percentage mean?+
It measures reconstruction coverage of the trailing window relative to current chain head. A 100% trailing-window value means that window is caught up; it does not claim complete Smart Account history since contract launch.
How are third-party XRPFi integrations represented?+
A protocol can be relevant to Flare/XRPFi without being a Flare-native protocol. FlareSignal preserves deployment/network scope and the specific XRPFi linkage. External integrations are not added to native Flare totals unless the capital relationship is explicitly reconciled.
Why does FlareSignal maintain separate third-party XRPFi accounting?+
External XRPFi venues can expose legitimate XRP/FXRP capital and economic activity while still overlapping capital already represented in the native Flare accounting graph. FlareSignal therefore maintains a separate third-party accounting domain with its own totals, history, live cycling and provenance. This leaves the Flare-native productive-capital floor/ceiling and additive-output accounting unchanged.
How should native XRPFi and third-party XRPFi totals be read together?+
They are parallel scopes, not two operands in one total. Native XRPFi answers what can be defensibly located/attributed inside the Flare-native accounting model. Third-party XRPFi answers what external venues report or expose for XRP-linked capital/economics. Until overlap is reconciled at protocol and capital-path level, the correct combined interpretation is comparative, not additive.
Why are native and third-party protocols now shown together inside the XRPFi sections?+
The XRPFi page is an intelligence surface, not a single accounting union. FlareSignal therefore co-locates Flare-native and third-party protocol tiles inside Where Is The XRP? and What Has XRPFi Generated? so traders and analysts can compare deployment and economics in one view. Each tile carries an accounting scope, and the section displays native and third-party totals separately. Visual co-location never changes the underlying non-additivity rule.
What do the two XRPFi headline totals mean?+
In capital intelligence, the Flare-native headline is the verified productive FXRP floor → evidence-bounded ceiling, while the third-party headline is gross observed XRP/FXRP capital across supported third-party XRPFi protocols. In economic-output intelligence, the native headline is verified additive FXRP output, while the third-party headline is verified protocol fees in their reported accounting unit. They are intentionally not converted into a synthetic combined total.
Why can derivatives activity be XRPFi intelligence without being yield?+
Options/perpetual open interest, premium, notional volume, funding, implied volatility and Greeks describe market structure around XRP-linked collateral and risk transfer. They can be economically relevant to XRPFi without representing passive yield generated by deposited FXRP.
REGISTERED METRIC REFERENCE
XRPFi & FXRP
FAssets, FXRP, Smart Accounts and XRPFi system/economic measures.
FAssets / FXRP16
Agent Available Mint CapacityFlareSignal-derived · FLARE / FXRP+
Indicative FXRP minting capacity across currently available agents.
Agents in LiquidationRaw / source-reported · FLARE / FXRP+
Observed available agents currently reporting LIQUIDATION or FULL_LIQUIDATION status.
Available FXRP AgentsRaw / source-reported · FLARE / FXRP+
Agents currently accepting new FXRP minting requests.
Completed Mint Workflows 24hAggregated observation · FLARE / FXRP+
FXRP amount from verified successful minting workflow events.
Completed Redemption Workflows 24hAggregated observation · FLARE / FXRP+
FXRP amount from verified RedemptionPerformed events.
FXRP Mint UtilisationRatio · FLARE / FXRP+
FXRP total supply as a percentage of the current documented FAssets minting cap.
FXRP Minting CapRaw / source-reported · FLARE / FXRP+
Current documented FAssets minting cap for FXRP. Stored as official-reported protocol configuration until direct settings decoding is implemented.
FXRP Net Supply Flow 24hFlareSignal-derived · FLARE / FXRP+
Rolling 24-hour FXRP token mint volume minus token burn volume.
FXRP Token Burned 24hAggregated observation · FLARE / FXRP+
FXRP ERC-20 tokens burned over the rolling 24-hour window, derived from Transfer events whose to address is zero.
FXRP Token Minted 24hAggregated observation · FLARE / FXRP+
FXRP ERC-20 tokens minted over the rolling 24-hour window, derived from Transfer events whose from address is zero.
FXRP Total SupplyRaw / source-reported · FLARE / FXRP+
Current ERC-20 total supply of FXRP on Flare.
FXRP Transfers 24hAggregated observation · FLARE / FXRP+
Count of FXRP ERC-20 Transfer events observed during the rolling 24-hour window.
Median Agent Mint FeeFlareSignal-derived · FLARE / FXRP+
Median published minting fee among available FXRP agents.
Mint Payment Defaults 24hAggregated observation · FLARE / FXRP+
Count of MintingPaymentDefault events in rolling 24h.
Redemption Defaults 24hAggregated observation · FLARE / FXRP+
Count of RedemptionDefault events in rolling 24h.
Total FXRP AgentsRaw / source-reported · FLARE / FXRP+
All registered FXRP agents.
Smart Accounts24
Flare Smart Account Controller Events 15mFlareSignal-derived · FLARE / FXRP+
Recognized MasterAccountController activity observed during the trailing 15 minutes.
Flare Smart Account Controller Events 1hFlareSignal-derived · FLARE / FXRP+
Recognized MasterAccountController activity observed during the trailing hour.
Flare Smart Account Controller Events 24hFlareSignal-derived · FLARE / FXRP+
Recognized MasterAccountController activity observed during the trailing 24 hours.
Smart Account 24h Window CoverageFlareSignal-derived · FLARE / FXRP+
Share of the trailing 24-hour Smart Accounts event window reconstructed and caught up to the current chain head.
Smart Account Active Event Types 24hFlareSignal-derived · FLARE / FXRP+
Number of recognized MasterAccountController event classes with non-zero activity during the trailing 24 hours.
Smart Account Chain HeadChain-verified · FLARE / FLR+
Flare chain head observed by the Smart Accounts collector.
Smart Account Claims 24hFlareSignal-derived · FLARE / FXRP+
Claimed events emitted by the MasterAccountController during the trailing 24 hours.
Smart Account Collateral Reservations 24hFlareSignal-derived · FLARE / FXRP+
CollateralReserved events emitted by the MasterAccountController during the trailing 24 hours.
Smart Account Collector BacklogFlareSignal-derived · FLARE / FLR+
Flare blocks remaining between the Smart Accounts event collector cursor and the current chain head.
Smart Account Direct Minting Events 24hFlareSignal-derived · FLARE / FXRP+
DirectMintingExecuted events emitted by the MasterAccountController during the trailing 24 hours.
Smart Account Executor Removal Events 24hFlareSignal-derived · FLARE / FXRP+
ExecutorRemoved events emitted during the trailing 24 hours.
Smart Account Executor Set Events 24hFlareSignal-derived · FLARE / FXRP+
ExecutorSet events emitted during the trailing 24 hours.
Smart Account FXRP Redemptions 24hFlareSignal-derived · FLARE / FXRP+
FXrpRedeemed events emitted by the MasterAccountController during the trailing 24 hours.
Smart Account FXRP Transfers 24hFlareSignal-derived · FLARE / FXRP+
FXrpTransferred events emitted by the MasterAccountController during the trailing 24 hours.
Smart Account Ignore Memo Events 24hFlareSignal-derived · FLARE / FXRP+
IgnoreMemoSet events emitted during the trailing 24 hours.
Smart Account Instructions Executed 24hFlareSignal-derived · FLARE / FXRP+
InstructionExecuted events emitted by the MasterAccountController during the trailing 24 hours.
Smart Account Nonce Increases 24hFlareSignal-derived · FLARE / FXRP+
NonceIncreased events emitted during the trailing 24 hours.
Smart Account Redeem Requests 24hFlareSignal-derived · FLARE / FXRP+
RedeemRequested events emitted by the MasterAccountController during the trailing 24 hours.
Smart Account Replacement Fee Events 24hFlareSignal-derived · FLARE / FXRP+
ReplacementFeeSet events emitted during the trailing 24 hours.
Smart Account User Operations 24hFlareSignal-derived · FLARE / FXRP+
Memo-dispatched UserOperationExecuted events observed during the trailing 24 hours.
Smart Account Vault Approvals 24hFlareSignal-derived · FLARE / FXRP+
Approved events emitted by the MasterAccountController during the trailing 24 hours.
Smart Account Vault Deposits 24hFlareSignal-derived · FLARE / FXRP+
Deposited events emitted by the MasterAccountController during the trailing 24 hours.
Smart Account Vault Redeems 24hFlareSignal-derived · FLARE / FXRP+
Redeemed events emitted by the MasterAccountController during the trailing 24 hours.
Smart Account Withdrawal Claims 24hFlareSignal-derived · FLARE / FXRP+
WithdrawalClaimed events emitted by the MasterAccountController during the trailing 24 hours.
Third-Party XRPFi Truth23
Derive Share of Third-Party Observed XRP CapitalFlareSignal-derived · EXTERNAL / XRP+
Derive reported XRP/FXRP capital as a percentage of the separately accounted third-party XRPFi capital total.
Derive Share of Third-Party Verified FeesFlareSignal-derived · EXTERNAL / XRP+
Derive cumulative verified XRP options/perpetual fees as a percentage of separately accounted third-party verified fees.
Derive Third-Party Canonical CapitalFlareSignal-derived · EXTERNAL / XRP+
Derive XRP/FXRP capital admitted to the third-party truth layer.
Derive Third-Party Capital Inflow 24hFlareSignal-derived · EXTERNAL / XRP+
Observed positive changes in Derive-reported XRP collateral supply over 24 hours.
Derive Third-Party Capital Outflow 24hFlareSignal-derived · EXTERNAL / XRP+
Observed absolute negative changes in Derive-reported XRP collateral supply over 24 hours.
Derive Third-Party Net Flow 24hFlareSignal-derived · EXTERNAL / XRP+
Observed Derive XRP/FXRP capital inflow minus outflow over 24 hours inside the third-party truth layer.
Derive Third-Party Notional 24hFlareSignal-derived · EXTERNAL / XRP+
Derive XRP derivatives notional activity represented in the third-party truth layer over 24 hours.
Derive Third-Party Premium Activity 24hFlareSignal-derived · EXTERNAL / XRP+
Derive XRP derivative premium activity represented in the third-party truth layer over 24 hours.
Derive Third-Party Trades 24hFlareSignal-derived · EXTERNAL / XRP+
Derive XRP derivative trades represented in the third-party truth layer over 24 hours.
Derive Third-Party Verified Fees 24hFlareSignal-derived · EXTERNAL / XRP+
Derive XRP options and perpetual protocol fees admitted to third-party economic-output truth for the latest 24 hours.
Derive Third-Party Verified Fees All TimeFlareSignal-derived · EXTERNAL / XRP+
Cumulative Derive XRP options and perpetual protocol fees admitted to third-party economic-output truth.
Third-Party XRPFi Capital Inflow 24hFlareSignal-derived · EXTERNAL / XRP+
Rolling positive XRP/FXRP capital-state changes across admitted third-party protocols.
Third-Party XRPFi Capital Net Flow 24hFlareSignal-derived · EXTERNAL / XRP+
Third-party capital inflow minus outflow over the trailing 24 hours.
Third-Party XRPFi Capital Outflow 24hFlareSignal-derived · EXTERNAL / XRP+
Rolling absolute negative XRP/FXRP capital-state changes across admitted third-party protocols.
Third-Party XRPFi Notional Activity 24hFlareSignal-derived · EXTERNAL / XRP+
Total reported XRP derivatives notional activity across admitted external third-party venues during the latest 24 hours.
Third-Party XRPFi Observed CapitalFlareSignal-derived · EXTERNAL / XRP+
Gross observable XRP/FXRP capital state reported across protocols admitted to the external third-party truth layer.
Third-Party XRPFi Premium Activity 24hFlareSignal-derived · EXTERNAL / XRP+
Total reported premium activity across admitted external XRP derivative venues during the latest 24 hours.
Third-Party XRPFi Registered ProtocolsFlareSignal-derived · EXTERNAL / XRP+
Count of protocols currently admitted to the external third-party truth registry.
Third-Party XRPFi Reporting ProtocolsFlareSignal-derived · EXTERNAL / XRP+
Count of registered external third-party protocols with a current observable capital-state metric.
Third-Party XRPFi Trade CoverageFlareSignal-derived · EXTERNAL / XRP+
Average public trade-tape coverage for admitted third-party venues that expose an explicit coverage metric.
Third-Party XRPFi Trades 24hFlareSignal-derived · EXTERNAL / XRP+
Reported trade count across admitted external XRPFi venues during the latest 24 hours.
Third-Party XRPFi Verified Fees 24hFlareSignal-derived · EXTERNAL / XRP+
Reported or independently verified protocol fee economics across admitted external XRPFi venues during the latest 24 hours.
Third-Party XRPFi Verified Fees All TimeFlareSignal-derived · EXTERNAL / XRP+
Cumulative reported or independently verified protocol fee economics across admitted external XRPFi venues.
XRPFi16
Firelight Share of FXRPRatio · FLARE / FXRP+
Percentage of total FXRP supply currently represented as underlying Firelight capital.
FXRP in FirelightFlareSignal-derived · FLARE / FXRP+
Unique underlying FXRP currently assigned to Firelight as productive capital.
Gross Productive FXRP ExposureFlareSignal-derived · FLARE / FXRP+
Gross observed productive-role exposure from Firelight totalAssets, direct SparkDEX FXRP and Kinetic FXRP market cash.
Gross Productive FXRP Exposure ShareRatio · FLARE / FXRP+
Gross productive-role exposure as a percentage of total FXRP supply.
Maximum Unallocated FXRPFlareSignal-derived · FLARE / FXRP+
Maximum FXRP that can remain outside the current productive-capital lower bound.
Minimum Unallocated FXRPFlareSignal-derived · FLARE / FXRP+
Minimum FXRP that is not captured by the current productive-capital upper bound.
Observed stXRP Location CoverageFlareSignal-derived · FLARE / STXRP+
Share of total stXRP supply physically located across the currently decoded SparkDEX, Kinetic and Spectra destinations.
Observed stXRP LocationsFlareSignal-derived · FLARE / STXRP+
Physical stXRP located in SparkDEX pools, Kinetic market cash and verified Spectra contracts.
Productive FXRP Lower BoundFlareSignal-derived · FLARE / FXRP+
Conservative lower bound for unique productive FXRP after allowing maximum plausible overlap between Firelight externally managed assets and direct SparkDEX/Kinetic FXRP locations.
Productive FXRP Lower-Bound ShareFlareSignal-derived · FLARE / FXRP+
Conservative productive FXRP lower bound as a share of total FXRP supply.
Productive FXRP Overlap WindowFlareSignal-derived · FLARE / FXRP+
Difference between productive FXRP upper and lower bounds caused by unresolved Firelight external-position overlap.
Productive FXRP Upper BoundFlareSignal-derived · FLARE / FXRP+
Upper bound for unique productive FXRP before Firelight external-position provenance is fully reconciled.
Productive FXRP Upper-Bound ShareFlareSignal-derived · FLARE / FXRP+
Productive FXRP upper bound as a share of total FXRP supply.
stXRP on SparkDEX ShareRatio · FLARE / STXRP+
Percentage of outstanding stXRP currently held in current SparkDEX V2/V3.1/V4 target pools.
stXRP Outside Decoded LocationsFlareSignal-derived · FLARE / STXRP+
Outstanding stXRP not currently located in SparkDEX pool balances, Kinetic market cash or verified Spectra contracts.
XRPFi Material Events 24hAggregated observation · FLARE+
Count of indexed FAssets workflows, Firelight vault operations and Kinetic lending events during the rolling 24-hour window.
PROTOCOLS · YIELD
Protocol state, lending, term structure, derivatives and attribution
TVL, balances, rates, generated economics and market pricing have different semantics and remain separately labelled.
What qualifies a protocol for FlareSignal coverage?+
A protocol must have defensible Flare, Songbird or XRPFi relevance and evidence sufficient to support the measurements shown. Promotion or mention alone is not sufficient to create a live metric.
How does protocol onboarding handle historical data?+
Protocol onboarding records the earliest defensible evidence boundary and makes historical completeness explicit. Where earlier evidence cannot be verified, the unavailable period remains a stated gap rather than being estimated.
Does protocol TVL equal generated yield?+
No. TVL/supplied capital measures capital positioned in a protocol. Generated economics measures fees, borrower-paid interest, rewards or another value-production mechanism across time. Principal and earnings are different accounting categories.
How are APR and APY treated?+
FlareSignal preserves source rate semantics. APR is not silently converted to APY without an explicit compounding assumption, and an official quoted APY is not relabelled as realised historical return. Derived rates state the compounding/window basis in their methodology.
What is yield attribution?+
Yield attribution decomposes additive economic-output components while preventing the same return from being counted through multiple protocol/receipt layers. The live attribution radial identifies the largest currently verified additive contributor and its share dynamically from the included components rather than repeating the total.
Which XRPFi components are additive in the current generated-output ledger?+
Generated-output accounting includes only economic output that can be supported as additive within the stated accounting scope. Principal, overlapping receipt layers, quoted rates and market notional are not automatically treated as realised XRPFi output.
How is Kinetic lending state interpreted?+
Supplied claim, borrowed amount, debt, utilisation and APR are distinct lending variables. Receipt-value accretion can isolate lender-interest growth from principal supply/redeem changes. Borrower-level Credit Intelligence then analyses debt attribution, collateral contribution, health factor and liquidation pressure without treating a borrower identity as a real-world person.
How is Spectra term structure interpreted?+
Spectra intelligence treats maturities, fixed/term rates, liquidity and current yield-curve shape as market structure. A fixed quoted APY is a market price for term exposure, not proof that the underlying XRP has already generated that return. Pro analysis can examine weighted APY movement, curve slope, liquidity concentration, duration and regime persistence over longer history.
How is Firelight represented?+
Firelight positions are treated as XRP-derived receipt/vault capital with explicit look-through. Reward output is not backfilled from assumption. Organic generated output begins only from a verified activation/evidence point and is kept separate from principal movements and incentive classes that have different semantics.
How is SparkDEX fee output treated?+
LP fee output is shown as realised historical output only where the available evidence supports that treatment. Estimates can provide context but remain labelled as estimates rather than settled earnings.
What does FlareSignal collect from Derive?+
Derive is a third-party XRPFi derivatives venue. FlareSignal can show supported collateral and derivatives market observations such as options/perpetual structure, trade activity, open interest, funding, volatility, Greeks, spreads and expiry/strike context where evidence is available. These are market observations, not trade recommendations.
Why can Derive show zero XRP collateral while XRP derivatives fees are non-zero?+
A reported zero collateral state can coexist with non-zero derivatives activity or cumulative fees because current collateral and period activity measure different things. Market activity is not used as proof of an unobserved collateral balance, and a reported zero remains distinct from unavailable data.
How is a Derive collateral flow represented when the API reports only state changes?+
A change between supported collateral observations can establish that the reported balance increased or decreased, but it does not by itself prove an individual depositor route. Sig-Flow therefore distinguishes a measured capital change from an exact transfer claim.
How is Ēnosys represented?+
Ēnosys Intelligence separates direct liquidity, swap activity, lending context and receipt-token representation. Rate, fee and volume observations retain their stated semantics and are not automatically upgraded into realised historical output.
How is BlazeSwap represented?+
BlazeSwap Intelligence separates direct FXRP pool inventory, stXRP receipt representation and supported swap activity. Historical fee or reward output remains unavailable where the evidence does not support an exact realised amount.
How are Morpho and Mystic separated?+
Morpho and Mystic coverage separates lending state, interface context and stXRP receipt representation. Gross interest-accrual evidence is not automatically relabelled as supplier-net yield unless the evidence supports that claim.
How are Upshift earnXRP and MXRPY represented?+
Upshift vault surfaces distinguish vault value, share representation, quoted yield and underlying-capital overlap. Vault shares are receipt claims, so quoted APY or share appreciation is not automatically added to ecosystem capital or realised-output totals.
How is the Superform / Bizantine bizFXRP SuperVault represented?+
The bizFXRP SuperVault surface separates vault assets, share representation, current quoted context and possible underlying overlap. bizFXRP is a receipt layer and is not automatically counted as new productive capital on top of the assets it represents.
Did protocol-page parity change XRPFi aggregate accounting?+
No. Protocol onboarding presents already verified protocol evidence without forcing every protocol into one additive total. Direct capital, receipt layers, vault value, market activity and quoted yields retain their existing accounting semantics. Derive remains a separately reported external third-party XRPFi truth domain unless an overlap can be reconciled defensibly.
How are option Greeks aggregated?+
A published market-surface Greek describes the observed derivatives market under the metric’s stated context. It is not a user-portfolio Greek and should not be interpreted as a personalised risk measure.
What visual template do protocol intelligence pages follow?+
Protocol intelligence pages use a consistent customer-facing structure while keeping each protocol’s measurements appropriate to its own evidence and economic model. Unlike units are not forced into a common chart or percentage simply for visual consistency.
What does the Protocol Flow / Structure visual prove?+
The protocol flow visual explains the verified protocol mechanism and current measured state in one consistent visual language. Structural rails are explanatory and are not automatically transactions. A balance, rate or contract value can be shown as measured state; a travelling or explicitly verified flow claim requires unique event-level provenance. Receipt and wrapper layers remain non-additive, and Sig-Flow retains its separate unique-event evidence rules.
What is the protocol-page Pro Depth standard?+
Normal protocol intelligence remains public first. The final section is a specialist analytical lab rather than just a longer public chart. Where the retained evidence supports it, Pro Depth answers four questions: when verified protocol activity is arriving, where capital or activity is concentrated, how structure is changing through extended/full history, and where the current reading sits versus its own retained median, range and historical percentile. Routine state snapshots are excluded from activity counts, incompatible units are not casually combined, and historical context is descriptive rather than predictive. Derive keeps derivatives-specific flow, expiry, volatility and market-structure analysis; DEX, lending and vault pages use equivalent protocol-specific evidence.
What is Protocol Compare?+
Protocol Compare is the Pro-only comparison layer for supported protocol intelligence. It only compares dimensions that are sufficiently compatible and supported by the available evidence; unavailable comparisons remain unavailable rather than being forced.
Why does Indexed Growth rebase protocols to 100?+
Protocols expose different economic quantities, so raw FXRP liquidity, vault shares, lending claims, receipt-token locations and derivatives open interest must not be added or ranked as though they were the same unit. Indexed Growth rebases each eligible protocol’s declared headline metric to 100 at the first non-zero observation in the selected range. The chart therefore compares relative growth trajectory, not economic magnitude.
What does Comparable Capital include?+
Comparable Capital is narrower than Indexed Growth. It only admits verified direct or underlying XRP/FXRP measures whose accounting semantics support an absolute side-by-side comparison. Receipt layers, lending supply claims and vault totals that can overlap downstream protocols remain unavailable in that mode rather than being double counted. The displayed values are compared, not summed into a universal ecosystem total.
Does Protocol Compare decide which protocol is best?+
No. FlareSignal does not create a universal best-protocol score from unlike products. Protocol Compare surfaces objective dimensions such as selected-range growth, comparable capital where valid, historical percentile, retained history depth and family-specific metrics. DEX, lending, vault, yield-market and derivatives comparisons remain semantically separated so users can decide which dimensions matter to their own research.
REGISTERED METRIC REFERENCE
Protocols & Yield
Protocol liquidity, lending, yield, credit and Derive market structure.
Credit7
FXRP-Weighted USDT0 Debt EstimateEstimated · FLARE / USDT0+
Portion of Kinetic USDT0 debt proportionally allocated to direct FXRP collateral contribution.
Kinetic XRPFi Stablecoin DebtFlareSignal-derived · FLARE / USDT0+
Outstanding USDT0 debt inside Kinetic FXRP/stXRP isolated lending market.
stXRP-Weighted USDT0 Debt EstimateEstimated · FLARE / USDT0+
Portion of Kinetic USDT0 debt proportionally allocated to stXRP collateral contribution.
USDT0 Debt in Accounts Using XRP-Derived CollateralFlareSignal-derived · FLARE / USDT0+
USDT0 debt held by borrower accounts with any enabled FXRP or stXRP collateral contribution.
USDT0 Debt Near LiquidationFlareSignal-derived · FLARE / USDT0+
USDT0 debt held by Kinetic accounts with reconstructed health factor <=1.20.
USDT0 Debt with XRP-Only CollateralFlareSignal-derived · FLARE / USDT0+
USDT0 debt in accounts whose enabled adjusted collateral consists entirely of FXRP and/or stXRP.
XRP-Weighted USDT0 Debt EstimateEstimated · FLARE / USDT0+
USDT0 debt allocated to XRP-derived collateral in proportion to each account’s adjusted borrowing-power contribution.
DeFi6
BlazeSwap Verified Pool CountAggregated observation · FLARE+
Number of BlazeSwap Flare pairs discovered from the on-chain factory resolved via the verified BlazeSwap router.
Enosys Verified Pool CountAggregated observation · FLARE+
Number of Enosys-operated Flare DEX pools currently verified on-chain by FlareSignal.
FXRP in BlazeSwap PoolsAggregated observation · FLARE / FXRP+
Direct FXRP balance held by verified BlazeSwap pools on Flare.
FXRP in Enosys PoolsAggregated observation · FLARE / FXRP+
Direct FXRP balance held by verified Enosys pools.
stXRP in BlazeSwap PoolsAggregated observation · FLARE / STXRP+
stXRP balance held by verified BlazeSwap pools on Flare.
stXRP in Enosys PoolsAggregated observation · FLARE / STXRP+
stXRP balance held by verified Enosys pools.
Derive58
Derive XRP Active Option ExpiriesFlareSignal-derived · DERIVE / XRP+
Number of distinct active XRP option expiries discovered from Derive instruments.
Derive XRP Active Option InstrumentsOfficially reported · DERIVE / XRP+
Number of active XRP option instruments reported by Derive.
Derive XRP Call Open InterestFlareSignal-derived · DERIVE / XRP+
Current open interest attributed to active XRP call instruments.
Derive XRP Call/Put OI RatioFlareSignal-derived · DERIVE / XRP+
Call open interest divided by put open interest.
Derive XRP Collateral Inflow 24hFlareSignal-derived · DERIVE / FXRP+
Rolling positive changes in the Derive-reported XRP collateral supply between verified API observations.
Derive XRP Collateral Net Flow 24hFlareSignal-derived · DERIVE / FXRP+
Trailing 24-hour Derive collateral inflow minus outflow.
Derive XRP Collateral Outflow 24hFlareSignal-derived · DERIVE / FXRP+
Rolling negative changes in the Derive-reported XRP collateral supply between verified API observations.
Derive XRP Collateral SupplyOfficially reported · DERIVE / FXRP+
Current XRP collateral/base-asset supply reported by Derive for the XRP market; FXRP is the supported Flare collateral path.
Derive XRP Option Ask Depth 5%Aggregated observation · DERIVE / XRP+
Aggregate 5% ask depth reported across the active XRP option surface.
Derive XRP Option Bid Depth 5%Aggregated observation · DERIVE / XRP+
Aggregate 5% bid depth reported across the active XRP option surface.
Derive XRP Option Premium Activity 24hFlareSignal-derived · DERIVE / XRP+
Observed option premium exchanged in settled public XRP option trades during the trailing 24 hours.
Derive XRP Option Settled Trades 24hFlareSignal-derived · DERIVE / XRP+
Number of settled XRP option trades observed in the public 24-hour trade window.
Derive XRP Option Trades 24hAggregated observation · DERIVE / XRP+
Aggregate 24-hour trade count reported across active XRP option tickers.
Derive XRP Options All-Time FeesOfficially reported · DERIVE / XRP+
Official cumulative XRP option fees reported by Derive.
Derive XRP Options All-Time Notional VolumeOfficially reported · DERIVE / XRP+
Official cumulative XRP option notional volume reported by Derive.
Derive XRP Options All-Time Premium VolumeOfficially reported · DERIVE / XRP+
Official cumulative XRP option premium volume reported by Derive.
Derive XRP Options All-Time TradesOfficially reported · DERIVE / XRP+
Official cumulative XRP option trade count reported by Derive.
Derive XRP Options Contract Volume 24hAggregated observation · DERIVE / XRP+
Aggregate 24-hour contract volume across active XRP option tickers.
Derive XRP Options Fees 24hOfficially reported · DERIVE / XRP+
Official Derive 24-hour fees reported for XRP options.
Derive XRP Options Forward PriceFlareSignal-derived · DERIVE / XRP+
Open-interest-weighted forward price reported by active XRP option tickers.
Derive XRP Options Notional Volume 24hOfficially reported · DERIVE / XRP+
Official Derive 24-hour XRP option notional volume.
Derive XRP Options Official Trades 24hOfficially reported · DERIVE / XRP+
Official Derive 24-hour XRP option trade count from the market statistics surface.
Derive XRP Options Open InterestAggregated observation · DERIVE / XRP+
Aggregate current open interest across active XRP option tickers.
Derive XRP Options Premium Volume 24hOfficially reported · DERIVE / XRP+
Official Derive 24-hour premium exchanged across XRP options.
Derive XRP Options Statistics Open InterestOfficially reported · DERIVE / XRP+
Current XRP option open interest reported by Derive on its aggregate statistics surface.
Derive XRP Perpetual All-Time FeesOfficially reported · DERIVE / XRP+
Official cumulative XRP perpetual fees reported by Derive.
Derive XRP Perpetual All-Time Notional VolumeOfficially reported · DERIVE / XRP+
Official cumulative XRP perpetual notional volume reported by Derive.
Derive XRP Perpetual All-Time Premium VolumeOfficially reported · DERIVE / XRP+
Official cumulative XRP perpetual premium-volume field where reported.
Derive XRP Perpetual All-Time TradesOfficially reported · DERIVE / XRP+
Official cumulative XRP perpetual trade count reported by Derive.
Derive XRP Perpetual Fees 24hOfficially reported · DERIVE / XRP+
Official Derive 24-hour fees reported for XRP perpetuals.
Derive XRP Perpetual Funding RateFlareSignal-derived · DERIVE / XRP+
Average current hourly funding rate across active XRP perpetual tickers where reported.
Derive XRP Perpetual Notional Volume 24hOfficially reported · DERIVE / XRP+
Official Derive 24-hour XRP perpetual notional volume.
Derive XRP Perpetual Official Trades 24hOfficially reported · DERIVE / XRP+
Official Derive 24-hour XRP perpetual trade count from aggregate statistics.
Derive XRP Perpetual Open InterestAggregated observation · DERIVE / XRP+
Current open interest for active Derive XRP perpetual markets where available.
Derive XRP Perpetual Premium Volume 24hOfficially reported · DERIVE / XRP+
Official Derive 24-hour XRP perpetual premium-volume field where reported.
Derive XRP Perpetual Settled Trades 24hFlareSignal-derived · DERIVE / XRP+
Number of settled XRP perpetual trades observed in the public 24-hour trade window.
Derive XRP Perpetual Statistics Open InterestOfficially reported · DERIVE / XRP+
Current XRP perpetual open interest reported by Derive on its aggregate statistics surface.
Derive XRP Perpetual Trades 24hAggregated observation · DERIVE / XRP+
Current 24-hour XRP perpetual trade count where available.
Derive XRP Perpetual Volume 24hAggregated observation · DERIVE / XRP+
Current 24-hour XRP perpetual contract volume where available.
Derive XRP Put Open InterestFlareSignal-derived · DERIVE / XRP+
Current open interest attributed to active XRP put instruments.
Derive XRP Settled Trades 24hAggregated observation · DERIVE / XRP+
Number of settled XRP trades observed in the public Derive 24-hour trade window.
Derive XRP Taker Buy Notional 24hFlareSignal-derived · DERIVE / XRP+
Observed 24-hour USD-equivalent notional for settled public Derive XRP trades whose taker direction is buy.
Derive XRP Taker Net Notional 24hFlareSignal-derived · DERIVE / XRP+
Observed taker-buy notional minus taker-sell notional during the trailing 24-hour public trade window.
Derive XRP Taker Sell Notional 24hFlareSignal-derived · DERIVE / XRP+
Observed 24-hour USD-equivalent notional for settled public Derive XRP trades whose taker direction is sell.
Derive XRP Trade Fees 24hFlareSignal-derived · DERIVE / XRP+
Observed trade fees reported on settled public XRP trades during the trailing 24 hours.
Derive XRP Trade-Tape CoverageFlareSignal-derived · DERIVE / XRP+
Share of the Derive-reported 24-hour public trade-history pages observed in the current collector pass.
Derive XRP Weighted Ask IVFlareSignal-derived · DERIVE / XRP+
Open-interest-weighted ask implied volatility across active XRP options.
Derive XRP Weighted Best AskFlareSignal-derived · DERIVE / XRP+
Open-interest-weighted best ask across active XRP option tickers where quoted.
Derive XRP Weighted Best BidFlareSignal-derived · DERIVE / XRP+
Open-interest-weighted best bid across active XRP option tickers where quoted.
Derive XRP Weighted Bid IVFlareSignal-derived · DERIVE / XRP+
Open-interest-weighted bid implied volatility across active XRP options.
Derive XRP Weighted DeltaFlareSignal-derived · DERIVE / XRP+
Open-interest-weighted option delta across the active XRP option surface.
Derive XRP Weighted GammaFlareSignal-derived · DERIVE / XRP+
Open-interest-weighted option gamma across the active XRP option surface.
Derive XRP Weighted Implied VolatilityFlareSignal-derived · DERIVE / XRP+
Open-interest-weighted implied volatility across active XRP options.
Derive XRP Weighted Option Mark PriceFlareSignal-derived · DERIVE / XRP+
Open-interest-weighted option mark price across the current XRP options surface.
Derive XRP Weighted Option SpreadFlareSignal-derived · DERIVE / XRP+
Spread between the weighted best ask and weighted best bid across the observed XRP options surface.
Derive XRP Weighted RhoFlareSignal-derived · DERIVE / XRP+
Open-interest-weighted option rho across the active XRP option surface.
Derive XRP Weighted ThetaFlareSignal-derived · DERIVE / XRP+
Open-interest-weighted option theta across the active XRP option surface.
Derive XRP Weighted VegaFlareSignal-derived · DERIVE / XRP+
Open-interest-weighted option vega across the active XRP option surface.
Firelight11
Firelight Deposit CapRaw / source-reported · FLARE / FXRP+
Current officially published Firelight FXRP deposit cap.
Firelight Deposit Cap UtilisationRatio · FLARE / FXRP+
Firelight totalAssets as a percentage of the current officially published deposit cap.
Firelight Deposit Count 24hAggregated observation · FLARE / FXRP+
Count of Firelight ERC-4626 deposit events during the rolling 24-hour window.
Firelight Deposits 24hAggregated observation · FLARE / FXRP+
FXRP assets deposited into the Firelight ERC-4626 vault over the rolling 24-hour window.
Firelight Direct FXRP BalanceRaw / source-reported · FLARE / FXRP+
Direct FXRP token balance held by the Firelight stXRP vault contract.
Firelight Net Flow 24hFlareSignal-derived · FLARE / FXRP+
Firelight deposits minus withdrawals over the rolling 24-hour window.
Firelight Total AssetsRaw / source-reported · FLARE / FXRP+
FXRP-denominated total assets reported by the Firelight ERC-4626 stXRP vault.
Firelight Withdrawal Count 24hAggregated observation · FLARE / FXRP+
Count of Firelight ERC-4626 withdrawal events during the rolling 24-hour window.
Firelight Withdrawals 24hAggregated observation · FLARE / FXRP+
FXRP assets withdrawn from the Firelight ERC-4626 vault over the rolling 24-hour window.
stXRP Exchange RateFlareSignal-derived · FLARE / STXRP+
FXRP assets represented by one stXRP according to the Firelight ERC-4626 vault.
stXRP Total SupplyRaw / source-reported · FLARE / STXRP+
Outstanding Firelight stXRP vault shares / liquid staking receipt tokens.
Kinetic25
Kinetic Active BorrowersAggregated observation · FLARE+
Discovered Kinetic XRPFi accounts with a current non-zero borrow balance.
Kinetic At-Risk Borrower ShareFlareSignal-derived · FLARE+
Percentage of active borrowers currently at-risk, critical or liquidatable.
Kinetic At-Risk BorrowersFlareSignal-derived · FLARE+
Active borrowers with FlareSignal health band at-risk or critical, but not yet liquidatable.
Kinetic Borrow Events 24hAggregated observation · FLARE+
Count of Borrow events across the Kinetic XRPFi isolated market in rolling 24h.
Kinetic Borrower UniverseAggregated observation · FLARE+
Unique accounts discovered from verified historical Kinetic XRPFi market events.
Kinetic FXRP Borrow APRFlareSignal-derived · FLARE / FXRP+
Annualized simple borrow rate derived from borrowRatePerTimestamp.
Kinetic FXRP BorrowedRaw / source-reported · FLARE / FXRP+
Outstanding FXRP principal borrowed from the Kinetic XRPFi market.
Kinetic FXRP CashRaw / source-reported · FLARE / FXRP+
Actual FXRP currently held as available liquidity by the Kinetic FXRP market contract.
Kinetic FXRP Supplied ClaimFlareSignal-derived · FLARE / FXRP+
Underlying FXRP represented by lender claims in Kinetic XRPFi ISO market: cash + borrows - reserves.
Kinetic FXRP Supply APRFlareSignal-derived · FLARE / FXRP+
Annualized simple supply rate derived from supplyRatePerTimestamp.
Kinetic FXRP UtilisationRatio · FLARE / FXRP+
Outstanding FXRP borrows divided by supplied FXRP claim.
Kinetic Liquidatable BorrowersFlareSignal-derived · FLARE+
Borrowers whose on-chain Comptroller reports shortfall or whose reconstructed health factor is <=1.
Kinetic Liquidations 24hAggregated observation · FLARE+
Count of LiquidateBorrow events across FXRP, stXRP and USDT0 markets in the rolling 24-hour window.
Kinetic Median Health FactorFlareSignal-derived · FLARE+
Median reconstructed health factor across currently active borrowers.
Kinetic Repay Events 24hAggregated observation · FLARE+
Count of RepayBorrow events across the Kinetic XRPFi isolated market in rolling 24h.
Kinetic stXRP BorrowedRaw / source-reported · FLARE / STXRP+
Outstanding stXRP principal borrowed from Kinetic.
Kinetic stXRP CashRaw / source-reported · FLARE / STXRP+
stXRP currently held as available liquidity by Kinetic.
Kinetic stXRP FXRP Look-throughFlareSignal-derived · FLARE / FXRP+
Firelight FXRP backing represented by the stXRP supplied to Kinetic.
Kinetic stXRP Supplied ClaimFlareSignal-derived · FLARE / STXRP+
stXRP supplied into the Kinetic XRPFi isolated lending market.
Kinetic stXRP UtilisationRatio · FLARE / STXRP+
Outstanding stXRP borrows divided by supplied stXRP claim.
Kinetic USDT0 Borrow APRFlareSignal-derived · FLARE / USDT0+
Annualized simple USDT0 borrow rate derived from the market per-block rate.
Kinetic USDT0 BorrowedRaw / source-reported · FLARE / USDT0+
Outstanding USDT0 debt in Kinetic FXRP/stXRP isolated market.
Kinetic USDT0 SuppliedFlareSignal-derived · FLARE / USDT0+
USDT0 supplied into the Kinetic XRPFi isolated market.
Kinetic USDT0 UtilisationRatio · FLARE / USDT0+
Outstanding USDT0 borrows divided by supplied USDT0 liquidity.
USDT0 Top-10 Borrower ConcentrationFlareSignal-derived · FLARE / USDT0+
Share of outstanding reconstructed USDT0 borrower debt held by the ten largest USDT0 borrowers.
Lending5
Morpho FXRP BorrowedAggregated observation · FLARE / FXRP+
Current FXRP borrowed on the loan-token side of Morpho XRPFi markets.
Morpho FXRP SuppliedAggregated observation · FLARE / FXRP+
Current FXRP supplied on the loan-token side of Morpho XRPFi markets.
Morpho stXRP BorrowedAggregated observation · FLARE / STXRP+
Current stXRP borrowed on the loan-token side of Morpho XRPFi markets.
Morpho stXRP SuppliedAggregated observation · FLARE / STXRP+
Current stXRP supplied on the loan-token side of Morpho XRPFi markets.
Morpho XRPFi Market CountAggregated observation · FLARE / FXRP+
Number of Morpho Blue markets on Flare where FXRP or stXRP is the loan or collateral asset.
Protocol liquidity28
FLR Median Tracked SpreadFlareSignal-derived · FLARE / FLR+
Median bid/ask spread across currently tracked FLR spot books.
FLR Returned Tracked Buy BookFlareSignal-derived · FLARE / FLR+
Total FLR bid quantity returned by connected official exchange order-book APIs.
FLR Returned Tracked Sell BookFlareSignal-derived · FLARE / FLR+
Total FLR ask quantity returned by connected official exchange order-book APIs.
FLR Tracked Order-Book MarketsFlareSignal-derived · FLARE / FLR+
Number of connected FLR spot order books with recent depth snapshots.
FLR Visible Ask Depth +0.5%FlareSignal-derived · FLARE / FLR+
Tracked FLR posted ask liquidity from mid-price to +0.5% across connected official exchange order books.
FLR Visible Ask Depth +1%FlareSignal-derived · FLARE / FLR+
Tracked FLR posted ask liquidity within +1% of market mid.
FLR Visible Ask Depth +10%FlareSignal-derived · FLARE / FLR+
Tracked FLR posted ask liquidity from market mid to +10%.
FLR Visible Ask Depth +2%FlareSignal-derived · FLARE / FLR+
Tracked FLR posted ask liquidity within +2% of market mid.
FLR Visible Ask Depth +5%FlareSignal-derived · FLARE / FLR+
Tracked FLR posted ask liquidity from market mid to +5% across connected official exchange order books.
FLR Visible Bid Depth -0.5%FlareSignal-derived · FLARE / FLR+
Tracked FLR posted bid liquidity within -0.5% of market mid.
FLR Visible Bid Depth -1%FlareSignal-derived · FLARE / FLR+
Tracked FLR posted bid liquidity within -1% of market mid.
FLR Visible Bid Depth -10%FlareSignal-derived · FLARE / FLR+
Tracked FLR posted bid liquidity within -10% of market mid.
FLR Visible Bid Depth -2%FlareSignal-derived · FLARE / FLR+
Tracked FLR posted bid liquidity within -2% of market mid.
FLR Visible Bid Depth -5%FlareSignal-derived · FLARE / FLR+
Tracked FLR posted bid liquidity within -5% of market mid.
SGB Median Tracked SpreadFlareSignal-derived · SONGBIRD / SGB+
Median bid/ask spread across currently tracked SGB spot books.
SGB Returned Tracked Buy BookFlareSignal-derived · SONGBIRD / SGB+
Total SGB bid quantity returned by connected official exchange order-book APIs.
SGB Returned Tracked Sell BookFlareSignal-derived · SONGBIRD / SGB+
Total SGB ask quantity returned by connected official exchange order-book APIs.
SGB Tracked Order-Book MarketsFlareSignal-derived · SONGBIRD / SGB+
Number of connected SGB spot order books with recent depth snapshots.
SGB Visible Ask Depth +0.5%FlareSignal-derived · SONGBIRD / SGB+
Tracked SGB posted ask liquidity from mid-price to +0.5% across connected official exchange order books.
SGB Visible Ask Depth +1%FlareSignal-derived · SONGBIRD / SGB+
Tracked SGB posted ask liquidity within +1% of market mid.
SGB Visible Ask Depth +10%FlareSignal-derived · SONGBIRD / SGB+
Tracked SGB posted ask liquidity from market mid to +10%.
SGB Visible Ask Depth +2%FlareSignal-derived · SONGBIRD / SGB+
Tracked SGB posted ask liquidity within +2% of market mid.
SGB Visible Ask Depth +5%FlareSignal-derived · SONGBIRD / SGB+
Tracked SGB posted ask liquidity from market mid to +5% across connected official exchange order books.
SGB Visible Bid Depth -0.5%FlareSignal-derived · SONGBIRD / SGB+
Tracked SGB posted bid liquidity within -0.5% of market mid.
SGB Visible Bid Depth -1%FlareSignal-derived · SONGBIRD / SGB+
Tracked SGB posted bid liquidity within -1% of market mid.
SGB Visible Bid Depth -10%FlareSignal-derived · SONGBIRD / SGB+
Tracked SGB posted bid liquidity within -10% of market mid.
SGB Visible Bid Depth -2%FlareSignal-derived · SONGBIRD / SGB+
Tracked SGB posted bid liquidity within -2% of market mid.
SGB Visible Bid Depth -5%FlareSignal-derived · SONGBIRD / SGB+
Tracked SGB posted bid liquidity within -5% of market mid.
SparkDEX22
Direct FXRP in SparkDEX Spot PoolsAggregated observation · FLARE / FXRP+
Direct FXRP held by current SparkDEX V2, V3.1 and V4 target pools.
SparkDEX FXRP Pool CountRaw / source-reported · FLARE / FXRP+
Current SparkDEX V2, V3.1 and V4 pools containing direct FXRP.
SparkDEX Generation CoverageFlareSignal-derived · FLARE+
Number of SparkDEX spot generations with current target-pool coverage complete.
SparkDEX stXRP Look-through FXRPFlareSignal-derived · FLARE / FXRP+
FXRP-equivalent backing represented by stXRP held across supported SparkDEX generations.
SparkDEX stXRP Pool CountRaw / source-reported · FLARE / STXRP+
Current SparkDEX V2, V3.1 and V4 pools containing stXRP.
SparkDEX V2 Direct FXRPAggregated observation · FLARE / FXRP+
Direct FXRP held by SparkDEX V2 pools.
SparkDEX V2 FXRP PoolsRaw / source-reported · FLARE / FXRP+
Current V2 pools containing FXRP.
SparkDEX V2 stXRPAggregated observation · FLARE / STXRP+
stXRP held by SparkDEX V2 pools.
SparkDEX V2 stXRP PoolsRaw / source-reported · FLARE / STXRP+
Current V2 pools containing stXRP.
SparkDEX V2 Target PoolsRaw / source-reported · FLARE+
Current V2 FXRP/stXRP target pools.
SparkDEX V3.1 Direct FXRPAggregated observation · FLARE / FXRP+
Direct FXRP held by SparkDEX V3.1 pools.
SparkDEX V3.1 FXRP PoolsRaw / source-reported · FLARE / FXRP+
Current V3.1 pools containing FXRP.
SparkDEX V3.1 stXRPAggregated observation · FLARE / STXRP+
stXRP held by SparkDEX V3.1 pools.
SparkDEX V3.1 stXRP PoolsRaw / source-reported · FLARE / STXRP+
Current V3.1 pools containing stXRP.
SparkDEX V3.1 Target PoolsRaw / source-reported · FLARE+
Current V3.1 FXRP/stXRP target pools.
SparkDEX V4 Direct FXRPAggregated observation · FLARE / FXRP+
Direct FXRP held by SparkDEX V4 pools.
SparkDEX V4 FXRP PoolsRaw / source-reported · FLARE / FXRP+
Current V4 pools containing FXRP.
SparkDEX V4 stXRPAggregated observation · FLARE / STXRP+
stXRP held by SparkDEX V4 pools.
SparkDEX V4 stXRP PoolsRaw / source-reported · FLARE / STXRP+
Current V4 pools containing stXRP.
SparkDEX V4 Target PoolsRaw / source-reported · FLARE+
Current V4 FXRP/stXRP target pools.
SparkDEX XRPFi Spot PoolsRaw / source-reported · FLARE+
Discovered SparkDEX V2, V3.1 and V4 spot pools containing FXRP and/or stXRP.
stXRP in SparkDEX Spot PoolsAggregated observation · FLARE / STXRP+
stXRP receipt tokens held by current SparkDEX V2, V3.1 and V4 target pools.
Yield & term markets71
Attributed Firelight RewardsFlareSignal-derived · FLARE / FXRP+
Firelight FXRP-equivalent post-activation reward output eligible for additive XRPFi yield accounting.
Attributed Kinetic FXRP InterestFlareSignal-derived · FLARE / FXRP+
Kinetic FXRP borrower-paid base lender interest eligible for additive XRPFi yield accounting.
Attributed SparkDEX LP FeesFlareSignal-derived · FLARE / FXRP+
Direct-FXRP SparkDEX V3.1 LP trading-fee output eligible for additive XRPFi yield accounting.
Bizantine FXRP SuperVault Chain Share-Value ChangeFlareSignal-derived · FLARE / FXRP+
Change between earliest and latest chain-verified Bizantine FXRP SuperVault share-value observations available to FlareSignal.
bizFXRP Share PriceFlareSignal-derived · FLARE / FXRP+
FXRP assets represented by one bizFXRP vault share.
bizFXRP Share SupplyRaw / source-reported · FLARE / FXRP+
Current Bizantine FXRP SuperVault receipt-share supply.
bizFXRP Total AssetsRaw / source-reported · FLARE / FXRP+
Current FXRP assets reported by the chain-verified Bizantine SuperVault ERC-4626 state.
Clearstar earnXRP Chain Share-Value ChangeFlareSignal-derived · FLARE / FXRP+
Change between earliest and latest chain-verified earnXRP FXRP-per-share observations available to FlareSignal.
Days to Next stXRP MaturityFlareSignal-derived · FLARE / STXRP+
Days remaining until the nearest active Spectra stXRP maturity.
Direct stXRP in Spectra PoolsAggregated observation · FLARE / STXRP+
Physical stXRP held on the IBT side of verified Spectra stXRP pools.
earnXRP Official Displayed APYOfficially reported · FLARE / FXRP+
Current 30-day APY displayed by the first-party Upshift vault page.
earnXRP Share PriceFlareSignal-derived · FLARE / FXRP+
Gross FXRP assets previewed for one earnXRP share from the Upshift vault.
earnXRP Share SupplyRaw / source-reported · FLARE / FXRP+
Current earnXRP LP-token supply for the Clearstar Upshift vault.
earnXRP Vault Idle FXRPRaw / source-reported · FLARE / FXRP+
FXRP directly held at the Clearstar Upshift vault contract.
Farthest stXRP Fixed APYOfficially reported · FLARE / STXRP+
Spectra official-app Max Fixed APY for the farthest active stXRP maturity.
Firelight Attributed Output TodayFlareSignal-derived · FLARE / FXRP+
Current UTC-day Firelight reward output from exact RewardsDistributed events.
Firelight Organic Output Since Verified Reward ActivationFlareSignal-derived · FLARE / FXRP+
Cumulative Firelight FXRP rewards from exact on-chain RewardsDistributed vault-asset amounts.
Firelight Post-Activation Organic Output 24hFlareSignal-derived · FLARE / FXRP+
FXRP-equivalent Firelight vault reward accretion over 24 hours only after a verified reward activation point.
Kinetic Attributed Interest TodayFlareSignal-derived · FLARE / FXRP+
Current UTC-day Kinetic FXRP base lender interest in the Wave 4 live accounting bridge.
Kinetic FXRP Base Lender Interest Since Market InceptionFlareSignal-derived · FLARE / FXRP+
Cumulative borrower-paid FXRP base lender-interest accretion reconstructed for the Kinetic FXRP market since deployment.
Kinetic FXRP Lender Interest 24hFlareSignal-derived · FLARE / FXRP+
Observed FXRP lender interest accrued in the Kinetic FXRP market over 24 hours.
Kinetic stXRP Lender Interest 24hFlareSignal-derived · FLARE / STXRP+
Observed additional stXRP lender interest accrued in the Kinetic stXRP market over 24 hours.
Kinetic stXRP Lender Interest 24h FXRP Look-throughFlareSignal-derived · FLARE / FXRP+
Observed Kinetic stXRP lender interest converted to FXRP-equivalent through the current Firelight exchange rate.
Kinetic USDT0 Lender Interest 24hFlareSignal-derived · FLARE / USDT0+
Observed USDT0 lender interest accrued in Kinetic over 24 hours.
Liquidity-Weighted stXRP Fixed APYFlareSignal-derived · FLARE / STXRP+
Liquidity-weighted summary of Spectra official Max Fixed APY quotes across active stXRP maturities.
Monarq MXRPY Chain Share-Value ChangeFlareSignal-derived · FLARE / FXRP+
Change between earliest and latest chain-verified MXRPY FXRP-per-share observations available to FlareSignal.
Morpho FXRP Gross Borrower InterestFlareSignal-derived · FLARE / FXRP+
Exact FXRP interest amount emitted by verified Morpho Blue AccrueInterest events across XRPFi markets.
Morpho stXRP Gross Borrower InterestFlareSignal-derived · FLARE / STXRP+
Exact stXRP interest amount emitted by verified Morpho Blue AccrueInterest events across XRPFi markets.
MXRPY Official Displayed APYOfficially reported · FLARE / FXRP+
Current APY displayed by the first-party Upshift Monarq vault page when available.
MXRPY Share PriceFlareSignal-derived · FLARE / FXRP+
Gross FXRP assets previewed for one MXRPY share.
MXRPY Share SupplyRaw / source-reported · FLARE / FXRP+
Current MXRPY LP-token supply for the Monarq Upshift vault.
MXRPY Vault Idle FXRPRaw / source-reported · FLARE / FXRP+
FXRP directly held at the Monarq Upshift vault contract.
Nearest stXRP Fixed APYOfficially reported · FLARE / STXRP+
Spectra official-app Max Fixed APY for the nearest active stXRP maturity.
SparkDEX Attributed LP Fees TodayFlareSignal-derived · FLARE / FXRP+
Current UTC-day exact-eligible SparkDEX direct-FXRP LP-fee output in the Wave 4 live accounting bridge.
SparkDEX Buyback/Burn Fee DistributionFlareSignal-derived · FLARE / FXRP+
FXRP-equivalent share of reconstructed direct-FXRP V3.1 gross trading fees allocated to buyback/burn.
SparkDEX Fee Distribution Reconciliation DeltaFlareSignal-derived · FLARE / FXRP+
Difference between reconstructed SparkDEX gross FXRP fee parent and the sum of its distribution children.
SparkDEX Foundation Fee DistributionFlareSignal-derived · FLARE / FXRP+
FXRP-equivalent share of reconstructed direct-FXRP V3.1 gross trading fees allocated to the foundation.
SparkDEX FXRP LP Fees Since Indexed Pool InceptionFlareSignal-derived · FLARE / FXRP+
Cumulative direct-FXRP LP fee earnings reconstructed from verified SparkDEX V3.1 pool events and the documented 87.5% V3 LP fee share.
SparkDEX LP Share of Gross FXRP FeesFlareSignal-derived · FLARE / FXRP+
Percentage of reconstructed direct-FXRP V3.1 gross trading fees attributable to liquidity providers.
SparkDEX Reconstructed Gross FXRP FeesFlareSignal-derived · FLARE / FXRP+
Gross direct-FXRP V3.1 trading-fee pool reconstructed from exact LP fee checkpoints and the documented distribution split.
SparkDEX xSPRK Fee DistributionFlareSignal-derived · FLARE / FXRP+
FXRP-equivalent share of reconstructed direct-FXRP V3.1 gross trading fees allocated to xSPRK distribution.
Spectra Active stXRP MaturitiesAggregated observation · FLARE / STXRP+
Current verified Spectra Flare stXRP fixed-yield markets with future maturity.
Spectra Fixed-Rate Yield Priced Annual Run-RateFlareSignal-derived · FLARE / STXRP+
Annualized fixed-rate yield notional implied by Spectra official fixed APY and official active stXRP market liquidity.
Spectra stXRP FXRP Look-throughFlareSignal-derived · FLARE / FXRP+
Firelight FXRP backing represented by unique stXRP physically located in Spectra contracts.
Spectra stXRP Pool LiquidityOfficially reported · FLARE / STXRP+
Total Spectra official-app liquidity across active verified stXRP markets on Flare.
Spectra Yield Priced TodayFlareSignal-derived · FLARE / STXRP+
Current UTC-day term-yield notional priced by Spectra markets.
stXRP Locked in Spectra PT ContractsAggregated observation · FLARE / STXRP+
Physical stXRP held by verified Spectra PrincipalToken contracts backing PT/YT positions.
stXRP Markets Expiring in 30 DaysFlareSignal-derived · FLARE / STXRP+
Count of active verified Spectra stXRP maturities within the next 30 days.
stXRP on Spectra ShareRatio · FLARE / STXRP+
Share of total outstanding stXRP physically located in verified Spectra contracts.
stXRP Yield Curve SlopeFlareSignal-derived · FLARE / STXRP+
Farthest active stXRP fixed APY minus nearest active fixed APY in percentage points.
Tracked Organic XRPFi Output 24hFlareSignal-derived · FLARE / FXRP+
Tracked FXRP-equivalent organic output from currently provable XRPFi accounting layers over the rolling 24-hour window.
Tracked Organic XRPFi Output 24h USDFlareSignal-derived · FLARE / XRP+
USD value of the tracked rolling 24-hour organic XRPFi output.
Unique stXRP Located in SpectraFlareSignal-derived · FLARE / STXRP+
Unique physical stXRP located in verified Spectra pool and PrincipalToken contracts.
Verified Additive XRPFi Yield AttributionFlareSignal-derived · FLARE / FXRP+
Cumulative FXRP-equivalent output that FlareSignal can currently add without double counting across independently reconstructed XRPFi yield components.
Wave 4 Evidence Gate CompletionFlareSignal-derived · FLARE / XRP+
Percentage of Wave 4 historical attribution gates currently verified.
Wave 4 Historical Data ReadyFlareSignal-derived · FLARE / XRP+
Binary readiness state for the Wave 4 historical attribution evidence set.
Wave 4 Total Evidence GatesFlareSignal-derived · FLARE / XRP+
Total number of evidence gates in the locked Wave 4 attribution completion manifest.
Wave 4 Verified Evidence GatesFlareSignal-derived · FLARE / XRP+
Count of Wave 4 historical attribution gates currently verified.
XRPFi Attributed Output This WeekFlareSignal-derived · FLARE / FXRP+
Wave 4 additive XRPFi output accumulated during the current ISO week from canonical daily attribution clocks plus the current evidence-backed live rate.
XRPFi Attributed Output TodayFlareSignal-derived · FLARE / FXRP+
Wave 4 additive XRPFi output accumulated during the current UTC day from the evidence-backed live accounting bridge.
XRPFi Live Attributed Output RateFlareSignal-derived · FLARE / FXRP+
Current evidence-backed Wave 4 additive XRPFi rate used only to animate the today counter between verified anchors.
XRPFi Live Clock Tracked Organic USDFlareSignal-derived · FLARE / XRP+
Cumulative USD organic output integrated from currently verified live XRPFi accounting rates.
XRPFi Live Clock Tracked Organic XRP-EquivalentFlareSignal-derived · FLARE / XRP+
Cumulative XRP-equivalent organic output integrated from verified live accounting observations.
XRPFi Organic Ledger CoverageFlareSignal-derived · FLARE / XRP+
Average completion percentage of currently active additive organic-output reconstruction ledgers.
XRPFi Tracked Organic Annualized Run-Rate USDFlareSignal-derived · FLARE / XRP+
Annualized USD value implied by the current tracked organic XRPFi run-rate.
XRPFi Tracked Organic Daily Run-RateFlareSignal-derived · FLARE / FXRP+
FXRP-equivalent daily organic-output pace from currently measurable XRPFi accounting layers.
XRPFi Tracked Organic Daily Run-Rate USDFlareSignal-derived · FLARE / XRP+
USD value of the current tracked organic XRPFi daily run-rate.
XRPFi Tracked Organic Output Today USDFlareSignal-derived · FLARE / XRP+
Current UTC-day integrated tracked organic-output clock for XRPFi.
XRPFi Verified Organic Output Since Earning StartFlareSignal-derived · FLARE / XRP+
Cumulative FXRP/XRP-equivalent organic output reconstructed from verified earning-start points and continued by the live clock.
XRPFi Verified Organic Output Since Earning Start USDFlareSignal-derived · FLARE / XRP+
Historical USD value of cumulative tracked organic XRPFi output from verified earning-start points.
Yield Attribution Historical CompletionFlareSignal-derived · FLARE / XRP+
Average historical completion of the additive yield-attribution ledgers currently eligible for the XRPFi headline.
REGISTERED METRIC REFERENCE
Ecosystem
Measured ecosystem rails and defensible adoption/availability observations.
Ecosystem rails8
Ecosystem Capital Activation SpreadFlareSignal-derived+
Difference in percentage points between the highest and lowest of the FLR measurable utilisation floor, SGB measurable utilisation floor and productive FXRP lower-bound share.
Joey Official Surface LiveOfficially reported · XRPL / XRP+
Availability of the first-party Joey XRPL wallet surface at collection time.
Joey Public iOS RatingOfficially reported · XRPL / XRP+
Public average rating displayed through Apple distribution metadata.
Joey Public iOS Ratings CountOfficially reported · XRPL / XRP+
Public count of ratings displayed through Apple distribution metadata.
Luminite Official Surface LiveOfficially reported · FLARE+
Availability of the first-party Luminite wallet surface at collection time.
Oxen Flow Official Surface LiveOfficially reported · FLARE+
Availability of the first-party Oxen Flow product surface at collection time.
Oxen Flow Public iOS RatingOfficially reported · FLARE+
Public average rating displayed through Apple distribution metadata.
Oxen Flow Public iOS Ratings CountOfficially reported · FLARE+
Public count of ratings displayed through Apple distribution metadata.
WALLETS · MARKET
Address evidence, entity attribution and market microstructure
Blockchain addresses are observable. Beneficial ownership, intent and CEX participant identity usually are not.
Does one address equal one person or institution?+
No. An address can be an EOA, contract, protocol component, exchange, custodian, treasury, routing wallet or one part of a larger wallet system. FlareSignal describes address behaviour unless beneficial ownership or entity role has been positively verified.
How are holder cohorts used?+
Holder cohorts group current balances into defined balance/supply-share bands so concentration and distribution can be tracked over time. Cohorts describe addresses, not unique human holders. Exchange/custodial structures can contain balances belonging economically to many users.
What qualifies for Wallet Watch?+
For FLR and SGB market-impact monitoring, the automatic wallet floor is a current canonical balance of at least 1,000,000 tokens. The address must be an externally held EOA in the current holder sample: positively verified exchange hot/cold wallets, custodians, protocol contracts, burn/system addresses and other verified infrastructure are excluded. Other Wallet Watch rules can still surface major transfers, holder changes and verified entity routing. This is an address-level risk/context classification, not a claim about personal wealth, ownership or trading intent.
Why are verified protocol/exchange/infrastructure addresses excluded from anonymous wallet classification?+
A large address that is positively verified as an exchange, custodian, protocol, burn or other infrastructure address should be described by that verified role. Exchange-to-exchange hot/cold operations remain real chain activity but are explicitly excluded from Market-Impact Wallet Watch so operational treasury movement cannot masquerade as whale behaviour.
How does large-transfer capture adapt to supply?+
Large-transfer capture uses an asset-specific threshold equal to the greater of a fixed floor and a supply-relative floor. Current fixed floors are 1,000,000 FLR, 250,000 SGB, 500,000 WFLR, 100,000 WSGB, 1,000 FXRP and 500 stXRP. FLR/SGB/WFLR/WSGB use a 0.005% supply-relative floor; FXRP/stXRP use 0.05%.
How is large-transfer severity calculated?+
Severity is primarily the transfer amount as a share of tracked supply. At or above 0.5% is severity 5, at or above 0.1% severity 4, at or above 0.02% severity 3, and qualifying transfers below 0.02% severity 2. The score measures transfer significance, not identity or intent.
What does MARKET-IMPACT WALLET → VERIFIED EXCHANGE mean?+
It means an on-chain FLR/SGB transfer from a current million-plus external EOA to an address positively verified as exchange infrastructure. FlareSignal treats this as a verified exchange inflow / potential supply event and, when current connected-venue order-book depth is available, compares the transfer amount with visible 2% bid depth. It is not automatically a sale, market order or proof that the exchange trade tape contains the corresponding execution. The reverse route is a verified exchange outflow, not automatic proof of a purchase or accumulation.
Can FlareSignal identify which wallet executed a public CEX trade?+
Normally no. Public centralised-exchange trade feeds expose execution price, size, timestamp and sometimes taker side, not the blockchain wallet/beneficial owner. On-chain deposits/withdrawals and CEX trade executions can be analysed as separate evidence streams without asserting they belong to the same actor.
What does market microstructure measure?+
Market Microstructure analyses official public execution tape for directional streaks, repeated sizes, repetitive two-sided patterns, burst behaviour and other statistically observable execution structures. Pattern detection is not an accusation of manipulation and does not reveal trader identity.
What is a correlated market + wallet incident?+
It is a multi-source time overlap between a significant execution-tape pattern and independently verified wallet/exchange-address routing evidence. Correlation can increase analytical interest, but it does not prove one actor caused both observations.
How should order-book imbalance/depth be interpreted?+
Displayed order-book size is a volatile market-state observation. Orders can disappear before execution, hidden/internal liquidity is not visible and connected venues differ in depth. Order-book intelligence therefore describes observable liquidity conditions, not guaranteed executable quantity.
REGISTERED METRIC REFERENCE
Wallets & Market
Holders, wallets, exchange liquidity, wallet patterns and market microstructure.
Exchange liquidity8
FLR Active Tracked CEX VenuesFlareSignal-derived · FLR+
Connected official exchange venues with at least one current FLR market snapshot.
FLR Bybit Reference Volume 5mOfficially reported · FLR+
Official Bybit FLR/USDT spot base-asset volume for one real five-minute venue candle.
FLR Tracked CEX MarketsFlareSignal-derived · FLR+
Current FLR spot markets discovered across connected official exchange APIs.
FLR Tracked Official CEX Volume 24hFlareSignal-derived · FLR+
Sum of FLR base-asset 24h trading volume across markets discovered through connected official exchange APIs.
SGB Active Tracked CEX VenuesFlareSignal-derived · SGB+
Connected official exchange venues with at least one current SGB market snapshot.
SGB MEXC Reference Volume 5mOfficially reported · SGB+
Official MEXC SGB/USDT spot base-asset volume for one real five-minute venue candle.
SGB Tracked CEX MarketsFlareSignal-derived · SGB+
Current SGB spot markets discovered across connected official exchange APIs.
SGB Tracked Official CEX Volume 24hFlareSignal-derived · SGB+
Sum of SGB base-asset 24h trading volume across markets discovered through connected official exchange APIs.
Holder Intelligence24
Flare Total AddressesOfficial Indexed · FLARE / FLR+
Current total Flare addresses reported by the official Flare Blockscout stats endpoint.
FLR Known Contract Share in Top 100FlareSignal-derived · FLARE / FLR+
Share of supply held by addresses in the top 100 that FlareSignal can positively match to known registered contracts.
FLR Top 10 Account ShareFlareSignal-derived · FLARE / FLR+
Share of the relevant supply reference held at the ten highest current account locations in the official explorer ranking.
FLR Top 100 Account ShareFlareSignal-derived · FLARE / FLR+
Share of the relevant supply reference held at the hundred highest current account locations in the official explorer ranking.
FXRP Holder CountOfficial Indexed · FLARE / FXRP+
Current holder count reported by the official explorer token counter endpoint.
FXRP Known Contract Share in Top 100FlareSignal-derived · FLARE / FXRP+
Share of supply held by addresses in the top 100 that FlareSignal can positively match to known registered contracts.
FXRP Top 10 Account ShareFlareSignal-derived · FLARE / FXRP+
Share of the relevant supply reference held at the ten highest current account locations in the official explorer ranking.
FXRP Top 100 Account ShareFlareSignal-derived · FLARE / FXRP+
Share of the relevant supply reference held at the hundred highest current account locations in the official explorer ranking.
SGB Known Contract Share in Top 100FlareSignal-derived · SONGBIRD / SGB+
Share of supply held by addresses in the top 100 that FlareSignal can positively match to known registered contracts.
SGB Top 10 Account ShareFlareSignal-derived · SONGBIRD / SGB+
Share of the relevant supply reference held at the ten highest current account locations in the official explorer ranking.
SGB Top 100 Account ShareFlareSignal-derived · SONGBIRD / SGB+
Share of the relevant supply reference held at the hundred highest current account locations in the official explorer ranking.
Songbird Total AddressesOfficial Indexed · SONGBIRD / SGB+
Current total Songbird addresses reported by the official Songbird Blockscout stats endpoint.
stXRP Holder CountOfficial Indexed · FLARE / STXRP+
Current holder count reported by the official explorer token counter endpoint.
stXRP Known Contract Share in Top 100FlareSignal-derived · FLARE / STXRP+
Share of supply held by addresses in the top 100 that FlareSignal can positively match to known registered contracts.
stXRP Top 10 Account ShareFlareSignal-derived · FLARE / STXRP+
Share of the relevant supply reference held at the ten highest current account locations in the official explorer ranking.
stXRP Top 100 Account ShareFlareSignal-derived · FLARE / STXRP+
Share of the relevant supply reference held at the hundred highest current account locations in the official explorer ranking.
WFLR Holder CountOfficial Indexed · FLARE / WFLR+
Current holder count reported by the official explorer token counter endpoint.
WFLR Known Contract Share in Top 100FlareSignal-derived · FLARE / WFLR+
Share of supply held by addresses in the top 100 that FlareSignal can positively match to known registered contracts.
WFLR Top 10 Account ShareFlareSignal-derived · FLARE / WFLR+
Share of the relevant supply reference held at the ten highest current account locations in the official explorer ranking.
WFLR Top 100 Account ShareFlareSignal-derived · FLARE / WFLR+
Share of the relevant supply reference held at the hundred highest current account locations in the official explorer ranking.
WSGB Holder CountOfficial Indexed · SONGBIRD / WSGB+
Current holder count reported by the official explorer token counter endpoint.
WSGB Known Contract Share in Top 100FlareSignal-derived · SONGBIRD / WSGB+
Share of supply held by addresses in the top 100 that FlareSignal can positively match to known registered contracts.
WSGB Top 10 Account ShareFlareSignal-derived · SONGBIRD / WSGB+
Share of the relevant supply reference held at the ten highest current account locations in the official explorer ranking.
WSGB Top 100 Account ShareFlareSignal-derived · SONGBIRD / WSGB+
Share of the relevant supply reference held at the hundred highest current account locations in the official explorer ranking.
Live Intelligence5
Active Protocols 24hAggregated observation+
Distinct protocol/event domains contributing normalized LIVE events during the rolling 24-hour window.
Capital Events 24hAggregated observation · FLARE+
FAssets, Firelight, Kinetic and SparkDEX pool-balance events observed in the rolling 24-hour window.
LIVE Events 24hAggregated observation+
Normalized meaningful FlareSignal LIVE events observed during the rolling 24-hour window.
Major LIVE Events 24hFlareSignal-derived+
LIVE events with FlareSignal severity 4 or higher during the rolling 24-hour window.
Significant LIVE Events 24hFlareSignal-derived+
LIVE events with FlareSignal severity 3 or higher during the rolling 24-hour window.
Market microstructure9
FLR Max Microstructure Significance 1hFlareSignal-derived · FLR+
Highest FLR market-pattern significance score during the last hour.
FLR Repetitive Two-Sided Windows 1hFlareSignal-derived · FLR+
FLR windows classified as highly repetitive two-sided execution.
FLR Significant Microstructure Windows 1hFlareSignal-derived · FLR+
Significant FLR market-tape pattern windows detected across connected official exchange trade feeds during the last hour.
FLR Strong Directional Windows 1hFlareSignal-derived · FLR+
FLR strong directional buy-side or sell-side execution windows.
Market + Wallet Correlated Incidents 24hFlareSignal-derived+
Multi-source incidents where significant exchange-tape patterns overlap verified exchange-address routing evidence.
SGB Max Microstructure Significance 1hFlareSignal-derived · SGB+
Highest SGB market-pattern significance score during the last hour.
SGB Repetitive Two-Sided Windows 1hFlareSignal-derived · SGB+
SGB windows classified as highly repetitive two-sided execution.
SGB Significant Microstructure Windows 1hFlareSignal-derived · SGB+
Significant SGB market-tape pattern windows detected across connected official exchange trade feeds during the last hour.
SGB Strong Directional Windows 1hFlareSignal-derived · SGB+
SGB strong directional buy-side or sell-side execution windows.
Wallet Intelligence24
Flare Large Transfers 24hAggregated observation · FLARE+
Large tracked-asset transfers on Flare during the rolling 24-hour window.
FLR Wallet Balance Pressure 24HFlareSignal-derived · FLARE / FLR+
Net measured balance change across addresses observed on both sides of holder-snapshot comparisons, normalized by the current Top-100 balance. Positive means monitored top-account balances increased; negative means they decreased.
FLR Wallet Balance Pressure 30DFlareSignal-derived · FLARE / FLR+
Net measured balance change across addresses observed on both sides of holder-snapshot comparisons, normalized by the current Top-100 balance. Positive means monitored top-account balances increased; negative means they decreased.
FLR Wallet Balance Pressure 7DFlareSignal-derived · FLARE / FLR+
Net measured balance change across addresses observed on both sides of holder-snapshot comparisons, normalized by the current Top-100 balance. Positive means monitored top-account balances increased; negative means they decreased.
FXRP Large Transfers 24hAggregated observation · FLARE / FXRP+
Large FXRP ERC-20 transfers observed during the rolling 24-hour window.
FXRP Wallet Balance Pressure 24HFlareSignal-derived · FLARE / FXRP+
Net measured balance change across addresses observed on both sides of holder-snapshot comparisons, normalized by the current Top-100 balance. Positive means monitored top-account balances increased; negative means they decreased.
FXRP Wallet Balance Pressure 30DFlareSignal-derived · FLARE / FXRP+
Net measured balance change across addresses observed on both sides of holder-snapshot comparisons, normalized by the current Top-100 balance. Positive means monitored top-account balances increased; negative means they decreased.
FXRP Wallet Balance Pressure 7DFlareSignal-derived · FLARE / FXRP+
Net measured balance change across addresses observed on both sides of holder-snapshot comparisons, normalized by the current Top-100 balance. Positive means monitored top-account balances increased; negative means they decreased.
Known Protocol Wallet Inflows 24hAggregated observation · FLARE+
Large tracked transfers whose destination is a positively-known protocol contract during the rolling 24-hour window.
Large Transfers 24hAggregated observation+
Exact large-transfer observations across tracked FLR, SGB, WFLR, WSGB, FXRP and stXRP during the rolling 24-hour window.
SGB Wallet Balance Pressure 24HFlareSignal-derived · SONGBIRD / SGB+
Net measured balance change across addresses observed on both sides of holder-snapshot comparisons, normalized by the current Top-100 balance. Positive means monitored top-account balances increased; negative means they decreased.
SGB Wallet Balance Pressure 30DFlareSignal-derived · SONGBIRD / SGB+
Net measured balance change across addresses observed on both sides of holder-snapshot comparisons, normalized by the current Top-100 balance. Positive means monitored top-account balances increased; negative means they decreased.
SGB Wallet Balance Pressure 7DFlareSignal-derived · SONGBIRD / SGB+
Net measured balance change across addresses observed on both sides of holder-snapshot comparisons, normalized by the current Top-100 balance. Positive means monitored top-account balances increased; negative means they decreased.
Songbird Large Transfers 24hAggregated observation · SONGBIRD+
Large tracked-asset transfers on Songbird during the rolling 24-hour window.
stXRP Wallet Balance Pressure 24HFlareSignal-derived · FLARE / STXRP+
Net measured balance change across addresses observed on both sides of holder-snapshot comparisons, normalized by the current Top-100 balance. Positive means monitored top-account balances increased; negative means they decreased.
stXRP Wallet Balance Pressure 30DFlareSignal-derived · FLARE / STXRP+
Net measured balance change across addresses observed on both sides of holder-snapshot comparisons, normalized by the current Top-100 balance. Positive means monitored top-account balances increased; negative means they decreased.
stXRP Wallet Balance Pressure 7DFlareSignal-derived · FLARE / STXRP+
Net measured balance change across addresses observed on both sides of holder-snapshot comparisons, normalized by the current Top-100 balance. Positive means monitored top-account balances increased; negative means they decreased.
Top-Rank Entries 24hAggregated observation+
Tracked holder addresses newly entering Top 10 or Top 50 samples during the rolling 24-hour window.
WFLR Wallet Balance Pressure 24HFlareSignal-derived · FLARE / WFLR+
Net measured balance change across addresses observed on both sides of holder-snapshot comparisons, normalized by the current Top-100 balance. Positive means monitored top-account balances increased; negative means they decreased.
WFLR Wallet Balance Pressure 30DFlareSignal-derived · FLARE / WFLR+
Net measured balance change across addresses observed on both sides of holder-snapshot comparisons, normalized by the current Top-100 balance. Positive means monitored top-account balances increased; negative means they decreased.
WFLR Wallet Balance Pressure 7DFlareSignal-derived · FLARE / WFLR+
Net measured balance change across addresses observed on both sides of holder-snapshot comparisons, normalized by the current Top-100 balance. Positive means monitored top-account balances increased; negative means they decreased.
WSGB Wallet Balance Pressure 24HFlareSignal-derived · SONGBIRD / WSGB+
Net measured balance change across addresses observed on both sides of holder-snapshot comparisons, normalized by the current Top-100 balance. Positive means monitored top-account balances increased; negative means they decreased.
WSGB Wallet Balance Pressure 30DFlareSignal-derived · SONGBIRD / WSGB+
Net measured balance change across addresses observed on both sides of holder-snapshot comparisons, normalized by the current Top-100 balance. Positive means monitored top-account balances increased; negative means they decreased.
WSGB Wallet Balance Pressure 7DFlareSignal-derived · SONGBIRD / WSGB+
Net measured balance change across addresses observed on both sides of holder-snapshot comparisons, normalized by the current Top-100 balance. Positive means monitored top-account balances increased; negative means they decreased.
Wallet Patterns10
DEX Interaction Pattern WalletsFlareSignal-derived · FLARE+
Current indexed wallets with repeated positively-known DEX or swap-method interactions.
Evidence-Backed Wallet Exchanges 24hFlareSignal-derived · FLARE+
Reconstructed wallet transactions in the indexed Wallet Lab universe with both inbound and outbound asset legs plus positively-known DEX or swap-method evidence.
High Wallet Pattern Deviations 24hFlareSignal-derived+
Reconstructed transactions scoring HIGH or VERY HIGH against the same wallet’s own prior behavioural baseline.
Proven Directional Asset PairsFlareSignal-derived · FLARE+
Distinct current evidence-backed one-asset-out to one-asset-in conversion signatures across the Wallet Lab universe.
Rapid In/Out Pattern WalletsFlareSignal-derived+
Current indexed wallets with repeated incoming-to-outgoing activity inside the configured 30-minute pattern window.
Recurring Conversion PairsFlareSignal-derived · FLARE+
Current indexed wallets with at least one evidence-backed conversion pair observed three or more times in the configured lookback.
Verified Exchange Interaction Patterns 24hFlareSignal-derived+
Significant recurring wallet-to/from-verified-exchange interaction patterns during the last 24 hours.
Verified Exchange Wallet Interactions 24hFlareSignal-derived+
On-chain interactions between indexed wallets and positively verified exchange addresses during the last 24 hours.
Wallets Pattern-IndexedAggregated observation+
Unique wallet addresses with a current Wallet Patterns Lab snapshot.
Wallets With Pattern FlagsFlareSignal-derived+
Current indexed wallets with one or more descriptive pattern flags.
Wallet Watch6
Active Verified Watch AddressesFlareSignal-derived+
Verified address-level watch entries currently active in the Wallet Watch registry.
Major Wallet Watch Alerts 24hFlareSignal-derived+
Wallet Watch incidents at severity 4 or higher during the rolling 24-hour window.
Verified Entities Awaiting Address AttributionFlareSignal-derived+
Verified institution/custodian entities known from primary sources but without a verified Flare/Songbird address in the registry.
Verified Entity Intakes 24hFlareSignal-derived+
Large-transfer incidents entering positively verified vault, market, protocol, custodian or institutional addresses during the rolling 24-hour window.
Verified Entity Outflows 24hFlareSignal-derived+
Large-transfer incidents leaving positively verified watched entity addresses during the rolling 24-hour window.
Wallet Watch Alerts 24hFlareSignal-derived+
Normalized Wallet Watch incidents generated during the rolling 24-hour window.
SIG-FLOW
Event routing, particle mechanics and adaptive notifications
Sig-Flow visualises verified evidence. It does not create market trades, transfers or protocol facts that are absent from the underlying ledger.
What are the three Sig-Flow views?+
Flow Atlas maps individual verified market executions between asset origins and quote-currency nodes while retaining the existing wallet/protocol/burn overlays. Ecosystem Flow shows core Flare/Songbird on-chain or verified state movement across FAssets, delegation, wallets, burns and network infrastructure. Ecosystem Flow · Third Party shows supported third-party protocol movement such as SparkDEX, Kinetic, Spectra, Firelight and Derive.
What does one Flow Atlas currency-market particle represent?+
One particle represents one verified executed exchange trade/fill for FLR or SGB against a supported non-FLR/SGB quote. Resting order-book orders are not animated as trades. The venue, market, trade ID/fingerprint, execution timestamp, price, size, quote amount and reported side remain attached to the retained trade record.
What does a currency node represent?+
A currency node represents quote-currency market context, not the physical location of the trader or exchange server. FLR/KRW activity is routed to KRW context, for example. The venue identity remains in the evidence record while the map stays organised around quote currencies. USD-like stablecoin quote contexts can be mapped to the relevant USD-like node.
Why is the Flow Atlas currency animation intentionally delayed?+
Verified trades are stored with their real execution timestamps immediately, but the visual market runway uses a default approximately 90-second replay lag, constrained to 60 to 120 seconds. This absorbs source-observation timing and lets fills replay in chronological execution order rather than appearing as artificial one-minute clumps. The fixed replay shift preserves each fill’s original execution timestamp spacing: fills stamped in the same millisecond/second dispatch together at that same relative instant, so a real burst appears as multiple individual assets rather than one aggregated particle. Charts, database timestamps, KPIs and APIs remain on real source/observation time.
How is market-fill ordering preserved during busy periods?+
Every qualifying currency-node fill inside the replay runway is queued; there is no burst sampling. The queue is sorted by millisecond source timestamp when available, then retained record ID. If rendering capacity is temporarily saturated, fills wait in the visual queue rather than being removed from the underlying ledger.
How is particle size calculated?+
Particle size is scaled non-linearly from the reported amount so larger observations remain visually distinct without overwhelming the map. Missing amount data uses a neutral presentation size.
How is normal particle travel speed calculated?+
Normal particle travel is presentation-aware: route distance and current activity influence animation duration while preserving the distinction between visual timing and the underlying source timestamp.
How do large-transaction and Whale Watch speeds differ?+
Large Transaction and Whale Watch observations use deliberately slower visual treatments so they are easier to inspect. These presentation choices do not change the underlying source timestamps.
How is a market trade classified as Big Volume or Large Transaction?+
The trade amount is compared with the latest 240 valid fills for that exact market. Once at least 20 samples exist, Big Volume requires amount ≥ the 95th percentile and ≥ 1.75× the sample median. Large Transaction requires amount ≥ the 99th percentile and ≥ 4× the median. The classification is relative to that market’s own recent print-size distribution. Big Volume remains analytical per-fill context only; it does not create a special Flow Atlas particle or node colour.
How is currency-node traffic burst activity calculated?+
Currency-node burst activity compares recent execution intensity with that route’s own recent baseline. It is an activity classification, not a claim about manipulation, intent or future price direction.
How is high traffic calculated for protocol and wallet nodes?+
Protocol and wallet traffic classifications compare recent activity with each node’s own recent baseline. The result is descriptive activity context and does not imply economic intent or abnormal conduct.
What is the sustained 30-minute asset activity pulse?+
The sustained activity pulse compares a recent activity window with the asset or node’s own recent baseline. Market, protocol and wallet activity retain separate evidence semantics rather than being merged into one universal activity score.
What do Sig-Flow notification colours and sounds mean?+
Directional market identity remains green for venue-reported buy/inflow and red for venue-reported sell/outflow where direction is defensibly known; unavailable side remains neutral. Amber is the Wallet Watch shell for qualifying external-wallet movement, including million-plus FLR/SGB wallets interacting with positively verified exchange addresses. Large Transaction is the separate high-value execution treatment with a pulsing white/pearl shell. High-volume/burst evidence no longer recolours particles or nodes blue/cyan. Sounds and analytical burst detection can remain active without changing these colour meanings.
What is the landing confirmation splash?+
The destination node outer splash keeps the applicable significance shell: Wallet Watch lands amber and a Large Transaction uses its existing high-value confirmation treatment. Ordinary market fills retain buy-green, sell-red or neutral direction semantics; high-volume state does not recolour the landing blue/cyan. Only currency quote nodes add the execution-identity confirmation inside the node. Wallet, protocol, burn and ecosystem nodes do not invent an inner trade-direction marker.
What is the difference between an ON-CHAIN EVENT and a MEASURED CAPITAL CHANGE?+
An ON-CHAIN EVENT has transaction/event evidence that supports the represented route. A MEASURED CAPITAL CHANGE means FlareSignal observed a verified state difference, such as a protocol API balance increase/decrease, but cannot prove one unique transaction/depositor path. Sig-Flow preserves that distinction in the ledger and map semantics.
How is Derive represented on Ecosystem Flow · Third Party?+
Derive collateral changes are shown as measured capital changes when the evidence supports a balance movement but not a unique on-chain transfer route.
What is the Third-Party XRPFi Truth layer?+
Third-party XRPFi accounting is kept separate for externally hosted or otherwise non-native XRPFi venues. It can expose its own capital, flow, fee, activity and coverage context without changing the Flare-native accounting scope.
Can Third-Party XRPFi Truth be added to native Flare XRPFi totals?+
No. The default accounting invariant is non-additivity across layers. A third-party venue can contain FXRP/XRP exposure that originated from capital already represented elsewhere in FlareSignal. Until protocol-level overlap reconciliation proves the unique union, adding the third-party total to native XRPFi would risk double counting. The two totals must therefore be read as separate accounting scopes.
What does the third-party XRP capital total represent?+
It is the gross observable XRP/FXRP capital state across supported third-party protocols. It is not presented as unique incremental XRP relative to native Flare, and overlap limitations remain part of its interpretation.
Which Derive values count as third-party economic output?+
Only reported or independently verified fees enter the third-party economic-output total. Options/perpetual premium volume, notional turnover, open interest and trade count remain market-activity or market-structure measures. They can be displayed alongside fee output but are not relabelled as XRP holder earnings or protocol-wide APY.
How are burn movements represented?+
Burn nodes use the verified burn-wallet observation and current direct-sink rate to produce a visual minute of projected live burn. The visual stream is a projection between exact observations, explicitly labelled PROJECTED LIVE BURN; it is not fabricated as a transaction-by-transaction burn ledger when that granularity is unavailable.
Why do the three Sig-Flow maps have separate particle budgets?+
The three Sig-Flow views are kept visually independent so heavy activity in one view does not make another view unreadable. Their evidence labels retain the same interpretation boundaries.
What does the Verified Flow Ledger provide?+
Every rendered route retains an evidence record with time, asset, direction, amount when available, source/destination labels, movement class and transaction/source evidence. The ledger can be filtered by wallet, protocol, market, mint/redeem and burn categories, and supported rows can be replayed without changing the underlying timestamp/evidence.
EVENTS · ALERTS
Significance, temporal context and alert semantics
Alerts are evidence-ranked observations. They are not automatically directional trading signals.
What is Live Intelligence?+
Live Intelligence is the significance-ranked event surface fed by verified network, protocol and wallet evidence. It can show exact chain events and explicitly derived/measured events while preserving source, quality and transaction context where available.
How does FlareSignal distinguish exact events from derived events?+
Exact events retain their transaction/event reference and chain semantics. A derived event represents a defensible state change or analytical classification generated from verified observations. The UI labels the evidence class so a state delta is not visually promoted to an exact transaction.
What does alert severity mean?+
Severity ranks the significance of an observation within its metric/event class. It is not a probability that price will move and is not a recommendation. Wallet-transfer severity, for example, is based primarily on current supply-share significance, while other event families can use their own documented thresholds.
What makes an alert adaptive rather than fixed?+
Adaptive thresholds compare activity with the relevant asset, market, route or node’s own baseline rather than using one global number. This is important because a normal print rate for USD may be exceptional for a smaller quote route, and a busy protocol should not set the threshold for every other protocol.
How are market bursts different from large individual trades?+
A market burst is repeated activity concentrated in a short timestamp window relative to the route’s historical baseline. A large transaction is an individual fill that is extreme relative to the exact market’s recent fill-size distribution. The two classifications can coexist but neither substitutes for the other.
What is a Wallet Watch verified intake?+
A verified intake is a new/updated address or entity relationship admitted only after the required evidence threshold is met. It is distinct from an unverified label or a heuristic guess. Verified infrastructure classification also protects Whale Watch from misclassifying known protocol/exchange addresses as anonymous whales.
What does a correlated alert prove?+
It proves that independently sourced qualifying observations overlapped under the correlation rule. It does not prove common beneficial ownership, coordinated intent or causation. Correlation is an investigation trigger, not an identity claim.
How are ecosystem and macro/regulatory events used?+
Events can be retained as market context when they are materially relevant to FLR/SGB/XRPFi or broad crypto conditions. The event record should preserve timestamp, source quality, affected assets/networks, mechanism where defensible and observed post-event metrics. Broad-market events can act as controls rather than being attributed directly to Flare.
What is Event Intelligence?+
Event Intelligence is FlareSignal’s permanent research layer for material Flare, Songbird, XRPFi, protocol, market, governance, security, institutional and macro/regulatory events. Unlike the rolling LIVE feed, promoted events remain available for later investigation with their classification, timing precision, source trail and scheduled outcome checkpoints.
What does the Event Lens show?+
The Event Lens brings one archived event into focus with its observed time, classification, severity/significance, source quality, affected network/protocol/asset context, catalyst notes where documented and the status of its baseline, +1h, +1d, +7d, +30d and +90d research checkpoints. It does not turn temporal proximity into causal attribution.
How are Event Intelligence outcome checkpoints captured?+
Each checkpoint searches the shared metric archive for the nearest defensible observation around the scheduled horizon. The snapshot can include market price, network activity, utilisation, holder, volume, FXRP and protocol-capital metrics where those registered observations exist. Missing observations are not interpolated merely to complete the event record.
Can an Event Intelligence baseline improve after it was first captured?+
Yes, but only when genuinely missing historical evidence later becomes verifiable for the same checkpoint window. Reconciliation may deepen the evidence set, but it never replaces an already preserved checkpoint value, borrows today’s value for an older event or fills a future horizon before it is due.
Why can an event checkpoint be PARTIAL?+
A checkpoint is partial when the scheduled horizon was reached and some registered observations were captured but the expected evidence set was incomplete. PARTIAL therefore describes evidence coverage, not whether the event was important or whether its effect was positive or negative.
What does Pro add to Event Intelligence?+
The public surface exposes the permanent classified archive, source/evidence context and checkpoint availability. Pro opens the captured outcome values and changes from baseline across the research horizons so market and ecosystem movement can be compared without redefining the underlying source metrics.
How does Event Intelligence distinguish captured, partial and pending checkpoints?+
Captured means the scheduled horizon has a defensible verified observation set. PARTIAL means some expected evidence was available but coverage was incomplete. Pending means the research horizon has not yet produced a completed evidence checkpoint. The interface keeps those states visually distinct and does not turn a future checkpoint into a zero or a missing-data line.
Can the permanent Event Intelligence archive be searched and filtered?+
Yes. The Event Intelligence archive can be narrowed by event domain, minimum severity and text search across the retained event context shown on the page. Filtering changes only the view; it does not change event significance, source evidence, outcome status or the permanent archive record.
How should security incidents be treated?+
Security intelligence should classify the failure mechanism, affected assets/chains, losses and trust assumptions using evidence. Comparisons with Flare mechanisms should be technical and bounded. The platform should not imply any architecture is immune to compromise, and incidents that challenge a Flare-related thesis should be retained rather than excluded.
Do notification sounds change the significance classification?+
No. Sound is a presentation channel tied to event class, such as traffic burst, large transaction, Whale Watch or direct swap. Audio throttling can suppress repeated sounds for usability without suppressing the underlying event ledger or changing its analytical classification.
PRO · API
Research depth and data access
Public surfaces preserve useful intelligence; Pro and API add depth, workflow and delivery rather than redefining the underlying truth.
What is the Public versus Pro principle?+
Top-level intelligence remains useful publicly. Pro adds longer retained history, deeper analytical structures, specialist investigation and workflow tools. Public pages should not be advertised as Pro unlocks merely because a deeper section exists on the same page.
Which standard chart ranges are Public and which are Pro?+
1D, 3D and 7D are public. 15D, 30D, 90D, 1Y and All remain visible but locked for non-Pro users and unlock for Pro. Server-side entitlement checks are also applied where historical endpoints are protected so the visual lock is not the only access control.
What are Signal Metrics / Sig-Metrics?+
Signal Metrics are FlareSignal-derived indices, ratios, classifications and analytical states built from verified input data. Released Sig-Metrics pages provide a useful public surface first and deeper Pro analysis where available. Each released metric explains what it measures, its output semantics, interpretation, evidence context and important uncertainty without turning the public FAQ into an implementation specification.
How is the Sig-Metrics area organised?+
Sig-Metrics is a first-class Intelligence area. Released families follow the same public-first, Pro-depth contract: useful public derived intelligence first, with longer retained history, deeper diagnostics and specialist analytical tools where available.
What is the Pro Lens Structure and Sig-Metric Matrix?+
Lens Structure is the technical map of the eight defined Sig-Lenses rather than a ninth score. Its concentric analytical tracks expose current state, retained-history position, persistence and evidence coverage independently. The Sig-Metric Matrix is the structural-input drill-down for those lenses: current values, retained changes, historical percentile/regime context, robust z* where statistically defensible, confidence and evidence status. Matrix rows do not become additive simply because they appear together.
How does Capital Activation measure Productive Capital?+
Capital Activation keeps FLR utilised floor, SGB utilised floor and productive FXRP floor as three independent layers because each has a different denominator and economic mechanism. The concentric tracks and retained histories compare activation structure, leader/lagger behaviour and spread, but the percentages are never summed into a synthetic productive-capital percentage. Missing source evidence remains unavailable rather than zero.
What does Value Capture / Realised Economics measure?+
Realised Economics separates observed organic XRPFi output from productive FXRP and from network-activity context. Capture efficiency is Organic FXRP output over the same 24-hour basis divided by the positive productive FXRP floor, scaled per one million productive FXRP. Activity components are independently normalised only for contextual comparison. They are not treated as output and no coincident activity/output movement is labelled causal.
How is Economic Security / Security Depth calculated?+
Security Depth is active Flare P-chain stake divided by circulating FLR, multiplied by 100. The 100% denominator is a measurement boundary, not a security target. Validator self-bond versus delegated stake is a composition of the same active stake total and is not added again. Validator connectivity, stake expansion versus circulating-supply expansion, Top-N stake share, HHI and the validator count needed to cover one third of stake remain separate structural diagnostics.
How does Network Use / Activity Pulse avoid adding incompatible activity units?+
Activity Pulse evaluates FLR transactions, Songbird transactions and recognised Smart Account events as three independent operating lanes. Each lane receives its own selected-range empirical position, Rᵢ(t) = 100 × count(Xᵢ ≤ xᵢ(t)) / count(Xᵢ), and its own persistence/baseline diagnostics. Raw transactions and events are never summed. A high activity position means activity is high relative to that lane’s own selected history; it does not prove unique users, adoption, revenue or economic value.
How is Supply Pressure / Available Float defined?+
Available Float is an evidence-bounded proxy, not a claim that remaining supply is sellable. For each network, outside-measured-utilisation is 100% minus the measurable utilisation floor as a share of circulating supply. Relative tightness is Tᵢ(t) = 100 − percentile(outside-measured-utilisation within the selected range). FLR and SGB are ranked independently. Productive utilisation, posted +2% asks, supply-days, concentration, verified routing, wallet pressure, burns and circulating-supply change overlap economically and are therefore never added into a synthetic token total.
How does Deflation Progress / Net Supply Path decide whether FLR is inflationary or deflationary over a selected window?+
Net Supply Path uses the change in the official indexed FLR total-supply series between the first and selected real observations in the active range. A negative change is a deflationary observed window, a positive change is an inflationary observed window, and the annualised net rate is only a backward-looking normalisation of that measured window, not a forecast. Observed native burn, RewardManager cumulative inflation and burned-reward deltas, and FIP.16 policy parameters remain separate evidence lanes. RewardManager burned rewards are not added again to native burn because overlap can exist, and FIRE-linked inflation substitution, buyback or burn is excluded until first-class independently verifiable FIRE accounting exists. The public Sig-Core Deflation Progress lens therefore remains BUILDING rather than promoting this analytical lab into a 0–100 score prematurely.
Why does Supply Pressure keep FLR and SGB separate?+
FLR and SGB are ranked independently against their own retained outside-measured-utilisation histories. The lab reports each network’s exact historical tightness position plus the factual cross-network spread in percentage points. The positions are not averaged because their network denominators and histories remain independent.
What exactly is Wallet Behaviour balance pressure?+
Wallet Behaviour uses measured sequential address-balance deltas for the monitored Top-100 address set. For network i and rolling window w, Bᵢ,w = Σ measured sequential Top-100 address balance deltas / current Top-100 balance × 100. Positive pressure means the measured monitored-address balance increased over the window and negative pressure means it decreased. It is address-location evidence and is not proof of buying, selling, custody identity, common control or beneficial ownership.
How does Wallet Behaviour prevent Top-100 sample churn from becoming false accumulation or distribution?+
A balance delta is measured only when the same address has a defensible balance observation on both sides of the comparison. An address that enters or exits the monitored Top-100 sample with an unknown prior or current comparison balance is excluded from measured pressure rather than being assigned a zero. This prevents sample-boundary movement from being silently converted into economic flow.
What is verified exchange-routing asymmetry in Wallet Behaviour?+
Verified routing uses only positively identified exchange addresses. For each network, Aᵢ = 100 × (E→W − W→E) / (E→W + W→E), where E→W is verified exchange-to-wallet routed amount and W→E is verified wallet-to-exchange routed amount. +100 means all measured verified routed amount was exchange-to-wallet and −100 means the reverse. Unknown exchange identities remain outside the calculation, and the result is never labelled buy flow or sell flow.
What do Wallet Behaviour cohort and pattern diagnostics prove?+
Top-100, Mega, Whale and Large cohort pressure rows are current address-balance snapshots, not identities or ownership groups. Pattern evidence such as rapid in/out structure, repeated DEX interaction, rank entry or known-protocol inflow describes indexed transaction behaviour only. A pattern flag is not a fraud, manipulation, misconduct or intent classification.
What does the Wallet Behaviour Pattern Evidence · Structure panel measure?+
The panel keeps descriptive wallet-pattern families separate rather than collapsing them into a single suspiciousness or intent score. Patterns describe observed transaction structure and remain bounded by the evidence available for the selected wallet sample.
How are Wallet Behaviour pattern shares and historical positions calculated?+
Wallet Behaviour shares describe the proportion of the indexed sample matching each displayed pattern at the selected observation. Pattern classes can overlap, so their percentages are not additive. Historical position and local change use retained observations; missing values remain unavailable rather than becoming zero.
Does cursor inspection change Wallet Behaviour pattern semantics?+
No. Cursor inspection follows retained observations and keeps the linked Wallet Behaviour diagnostics on the same selected timestamp. Pinning changes the inspection state only; it does not alter the underlying data or create interpolated observations.
What does Sig-Metrics Liquidity & Slippage measure?+
Liquidity & Slippage describes observable execution conditions using retained FLR/SGB market-depth evidence. It covers depth, spread, slippage, venue structure and resilience while making clear that visible connected-venue liquidity is not total global liquidity or guaranteed execution.
How should Liquidity Quality be interpreted?+
Liquidity Quality is descriptive context built from observed liquidity conditions, not a trade recommendation or guarantee of execution. Unavailable or unfillable states remain unavailable rather than being converted into favourable values. Longer Pro ranges add historical context without changing that interpretation.
How should Ecosystem Price Impact / Transmission be interpreted?+
Price Impact · Transmission compares retained ecosystem measurements with FLR or SGB market response to surface observable relationships across time. Component families remain separate, the output is descriptive rather than causal, and missing evidence is not filled to strengthen a relationship.
What does lead / lag mean in Price Impact?+
Lead / lag describes the observed timing relationship between retained component evidence and retained market response. It is a descriptive timing screen, not proof of causation, prediction or statistical significance. FlareSignal does not invent intermediate observations to make the relationship appear smoother.
What does the Price Impact Pairwise Evidence Surface show?+
The Pairwise Evidence Surface shows which component and asset relationships have enough retained evidence to be displayed and how those observed relationships compare. Evidence depth is shown as context and is not presented as proof of independent samples, causation or future market behaviour.
What does the Price Impact XRP reference control mean?+
The Price Impact lab uses retained XRP/USD as a related-market reference because FlareSignal already retains verified FTSO history for it. It helps show when FLR/SGB response is moving with a closely related market reference. XRP is not presented as a whole-crypto-market benchmark, and neither high nor low correlation is treated as causal proof.
How does Network Use chart pinning behave?+
The three Activity Pulse lane charts share one inspection lifecycle. Hover follows the nearest real retained observation. The first click pins that observation across the linked Network Use diagnostics, a second click releases the pin, and leaving an unpinned lane returns the section to the latest observation. A pinned point can remain fixed while the user reads the surrounding Network Use section; leaving the full Network Use lab clears the pin and returns to latest. Arrow/Home/End inspect retained observations, Enter/Space pins or releases, and Escape returns live.
How are cursor-selected Pro observations interpreted?+
Interactive Pro mini charts and full Sig-Charts map pointer x to the selected timestamp domain and then to the nearest real retained observation. Selected-point values are not interpolated merely to make a cursor look smooth. Analysis-range statistics such as medians, persistence and historical position keep their documented range semantics, while point-local values and changes follow the selected real observation. Leaving inspection restores the live/latest state.
How much methodology does FlareSignal publish?+
FlareSignal publishes the customer-facing information needed to interpret an output, including its meaning, unit and time context, evidence class, freshness, coverage and important limitations.
Can a derived FlareSignal score be mistaken for source-reported data?+
No. Derived analysis remains identified as derived, and its customer-facing guidance explains the meaning and limitations needed to interpret the output.
What is Pro Depth on protocol pages?+
Pro Depth is the final analytical section after the complete public protocol intelligence. It uses longer retained history and derived structural diagnostics specific to the protocol. Existing specialist implementations include Derive’s XRP Derivatives Structure Lab, Kinetic’s Credit Market Structure, Spectra’s Term Structure Intelligence and Kinetic Credit’s Borrower Credit Structure Lab. They remain distinct because derivatives structure, lending structure, term structure and borrower risk are not interchangeable analytical problems.
What is Pro Charting?+
Pro Charting is the specialist multi-asset market chart environment with candles, indicators, drawings, crosshair/pan/measurement tools and order-book context. It does not execute trades. Its controls are intentionally independent of the normal site-history range component.
What is the Pro Workstation / Workspace concept?+
The workstation allows entitled users to assemble FlareSignal components into saved research layouts for their own analysis.
Is API access the same entitlement as Pro?+
No. API is a separate developer/research product. Pro is interactive research access. API access exposes documented subsets of the FlareSignal data layer with separate credentials and entitlements and is not automatically included because a user has Pro.
Will API values differ from the website?+
The website and API are intended to use consistent definitions for the same metric even when presentation or aggregation differs by use case. Timestamps, units, evidence quality and historical coverage remain part of the API contract where relevant.
What should API users expect around historical coverage?+
Coverage is dataset-specific. Permanent historical series can deepen indefinitely, while high-frequency raw market data follows retention rules. API consumers should use the documented earliest/latest observation, interval, quality and retention semantics rather than assuming every endpoint begins at network/protocol inception.
What happens when someone joins an API waiting list?+
The waiting list records only the submitted contact/use context and consent needed for API availability communication. It does not itself create paid API entitlement, a member order or a live API credential.
PRIVACY · MEMBERSHIP
Data minimisation, account integrity and payment evidence
A crypto research service should avoid collecting identity data that is not required to operate the product safely and lawfully.
Why does FlareSignal minimise personal data?+
A digital intelligence membership does not require the same identity/delivery profile as a physical-commerce business. FlareSignal’s design principle is to collect information genuinely required for account operation, payment/order verification, security, legal obligations or requested communications, and avoid making unrelated identity data a condition of access.
What personal details does a normal member account require?+
The customer-facing profile is designed around email and password credentials rather than requiring real name, postal address, phone number or company for the digital membership/API products. WordPress stores its normal one-way password hash rather than the readable password. Order/payment evidence is retained as required to verify access.
Does data minimisation mean anonymity?+
No. Email, payment/order records, network infrastructure and third-party systems can create identifying context. The claim is minimisation of unnecessary data, not perfect anonymity. If a genuine legal/tax requirement needs additional information, the principle is to request the minimum required field.
Why is identity minimisation particularly relevant in crypto?+
Linking a real-world identity to a belief that the person controls valuable digital assets can create security risk beyond ordinary account compromise. Minimisation reduces avoidable identity-to-asset context held by the service, although it cannot eliminate physical, social-engineering or external data-linkage risk.
What is the “$5 wrench attack” security concept?+
It is an informal crypto-security thought experiment about physical coercion of a key holder. It illustrates that strong cryptography does not remove human/physical attack surfaces. FlareSignal references the concept to explain data-minimisation rationale, not to claim a specific member is under threat.
When is a crypto membership account created?+
The account is created after the membership payment reaches the required verified paid state. Beginning or abandoning checkout does not itself create a customer account. Existing-member emails are expected to sign in for renewal rather than creating duplicate identities.
How are generated membership passwords handled?+
After a verified paid purchase, the system can generate a strong random credential using a cryptographically secure generator. The readable password is not emailed. WordPress retains its one-way password hash, and the branded reset flow remains the recovery path if the credential is not saved.
Can one paid account be used concurrently by several people?+
Paid membership uses a single-active-session policy. A successful login on another browser/device revokes older WordPress session tokens for that member, while multiple tabs in the same browser session continue normally. The design avoids permanent IP, user-agent or device-fingerprint storage solely for this control.
Does FlareSignal custody member crypto?+
The PayChain membership-payment design is non-custodial in the sense that supported crypto payments are sent directly to the configured receiving address rather than held as a customer balance. FlareSignal still retains the order/payment evidence required to prove that entitlement was purchased.
What should a security-conscious member do?+
Use a strong unique password, protect the email account used for membership, secure blockchain keys independently of FlareSignal and avoid volunteering unnecessary sensitive information in support messages or public posts. FlareSignal cannot protect credentials or identity information a user discloses elsewhere.
What does FlareSignal publish about platform security?+
Public documentation explains user-relevant security outcomes, privacy responsibilities and account/payment expectations. Detailed defensive implementation, server secrets, internal control paths and recovery procedures are restricted to authorised administration and internal engineering records rather than published as customer methodology.
PLATFORM OVERVIEW
Need the shorter product overview?
The What is FlareSignal? page explains the platform at a glance. This FAQ covers customer-facing data principles, product interpretation and privacy.