INTELLIGENCE / BURN

Burn Intelligence

What is permanently reducing FLR and SGB supply.

Pro

SYNC

PRODUCTIVE FLOOR—24H —

FXRP LOOK-THROUGH—24H —

XRP COLLATERAL—24H —

FXRP POOLS—24H —

FLR CIRCULATING—24H —

SGB CIRCULATING—24H —

FLR BURNED—24H —

SGB BURNED—24H —CAPITAL ACTIVATION SPREAD—24H —

FLR USE FLOOR—24H —

SGB USE FLOOR—24H —WALLET ALERTS · 24H—24H —LARGE TRANSFERS · 24H—24H —

FLR WALLET PRESSURE—

SGB WALLET PRESSURE—

SMART ACCOUNT EVENTS · 24H—24H —

NET FLOW · 24H—THIRD-PARTY XRPFi—24H —

FLR—24H —

SGB—24H —

FLR TX · 24H—24H —

SGB TX · 24H—24H —

VALIDATORS—24H —

FLR STAKED—24H —

FXRP SUPPLY—24H —

MINT UTIL—24H —

PRODUCTIVE FLOOR—24H —

TOTAL ASSETS—24H —

FXRP SPOT—24H —

FXRP SUPPLIED—24H —

FXRP UTIL—24H —

FXRP LOOK-THROUGH—24H —

XRP COLLATERAL—24H —

FXRP POOLS—24H —

FLR CIRCULATING—24H —

SGB CIRCULATING—24H —

FLR BURNED—24H —

SGB BURNED—24H —CAPITAL ACTIVATION SPREAD—24H —

FLR USE FLOOR—24H —

SGB USE FLOOR—24H —WALLET ALERTS · 24H—24H —LARGE TRANSFERS · 24H—24H —

FLR WALLET PRESSURE—

SGB WALLET PRESSURE—

SMART ACCOUNT EVENTS · 24H—24H —

NET FLOW · 24H—THIRD-PARTY XRPFi—24H —

FLARESIGNAL · BURN INTELLIGENCE

What is reducing
FLR and SGB supply?

Separate permanent native-token burn from temporary supply sinks, identify what network activity is creating fee burn, track RewardManager burned rewards by epoch, and compare Flare with Songbird without double counting the same supply reduction twice.

Open burn pulse ↓Utilisation FLR vs SGB

ACCOUNTING RULEBURN ≠ SINK ≠ TOKEN REDEMPTION

TRANSACTION FEE BURNNative FLR/SGB destruction from gas accounting

DIRECT SINK BURNPositive changes at documented burn addresses

REWARD BURNRewardManager contract accounting, shown separately

FIRE / TEMPORARY POOLSNot called burned until destruction is measurable

FLAREFLR BURN

PARTIAL

PERMANENT SINK BALANCE4,233,485,928.92 FLRLive projected sink balance · anchored to the latest chain-exact wallet read

LIVE

24H DIRECT SINK—exact burn-wallet balance change

7D DIRECT SINK811,497.9683 FLRexact burn-wallet balance change

30D DIRECT SINK21,434,654.01 FLRexact burn-wallet balance change

24h avg direct sink / min—

24h avg direct sink / hour—

Animated counter = latest exact permanent-sink balance + trailing-24h verified direct-sink pace between chain refreshes. The stored burn metric remains the exact wallet balance; the projection re-anchors on every new chain observation.

30-DAY BURN RATEAcceleration

—7d vs prior 7d

Low —Now —High —

Rolling complete 24h native-burn windows. The curve remains blank for periods whose fee history is still reconstructing.

Observed burn composition · 24h740,041.52 FLR

Fee 4.0%Direct sink 96.0%

Transaction fee split · 24h80,227.63 FLR

Burned 36.7%Tip / non-burn 63.3%

Burn absorption · non-utilised supply19.62%

4.23B FLR permanent sink21.58B FLR non-utilised

Annualised supply burn pace—

30d share of circulating—

Burn absorption19.62%

CoveragePARTIAL

The permanent-sink balance is read directly from the network-recognised burn address (Songbird includes both documented burn addresses). It stays on the last verified chain balance until the next one-minute refresh; it is never interpolated. The 24h, 7d and 30d direct-sink figures are only shown when an exact chain block checkpoint exists for that lookback. Transaction-fee destruction is reconstructed independently from every indexed block below.

Fee burn 24h29,434.059635

Total fees paid 24h80,227.629148

Burn share of paid fees36.688%

Non-burn / tip component50,793.870363

Direct sink inflow 24h710,607.463408

Fee burn / 10k tx637.158781

RewardManager burned253,862,384.83

Recognised burn address4,233,485,928.92

Current reward epoch433

SONGBIRDSGB BURN

PARTIAL

PERMANENT SINK BALANCE584,251,277.29 SGBLive projected sink balance · anchored to the latest chain-exact wallet read

LIVE

24H DIRECT SINK—exact burn-wallet balance change

7D DIRECT SINK727,934.0723 SGBexact burn-wallet balance change

30D DIRECT SINK8,399,536.59 SGBexact burn-wallet balance change

24h avg direct sink / min—

24h avg direct sink / hour—

30-DAY BURN RATEAcceleration

—7d vs prior 7d

Low —Now —High —

Rolling complete 24h native-burn windows. The curve remains blank for periods whose fee history is still reconstructing.

Observed burn composition · 24h724,021.89 SGB

Fee 3.4%Direct sink 96.6%

Transaction fee split · 24h69,945.91 SGB

Burned 35.4%Tip / non-burn 64.6%

Burn absorption · non-utilised supply6.15%

584.25M SGB permanent sink9.50B SGB non-utilised

Annualised supply burn pace—

30d share of circulating—

Burn absorption6.15%

CoveragePARTIAL

Fee burn 24h24,795.597732

Total fees paid 24h69,945.914050

Burn share of paid fees35.449%

Non-burn / tip component45,150.837958

Direct sink inflow 24h699,226.291434

Fee burn / 10k tx643.650294

RewardManager burned137,824,812.97

Recognised burn address577,673,264.04

Current reward epoch433

SGB accounting is deliberately evidence-bounded.Gas burn uses the base-fee component. The official Songbird explorer exposes burnt-fee values, but FlareSignal does not assume every possible fee component is burned until that rule is documented as explicitly as FLR.

Technical burn telemetry

Permanent Sink Intensity & Cumulative Destruction

The filled path shows exact trailing-24h inflow into the network-recognised permanent burn address set. The cumulative path is the exact burn-address balance change from the selected-range starting observation. Transaction-fee burn remains separate because gas destruction does not require a transfer into a burn address.

—24H sink flow —Cumulative sink —Fee burn 24h —Run-rate —

Direct-sink flow intensity · trailing 24hCumulative sink balance change · selected window

The cumulative line is a state-difference measurement from exact burn-address balances, so it remains valid even when long history is sampled. It is not transaction-fee burn, RewardManager burn or an all-mechanism burn total.

FLR visual mix

FLR Native Burn Composition

The 30-day fee ledger is being reconstructed backwards from chain history. Direct burn-address change is shown only from an exact historical block checkpoint; no partial window is promoted to a completed 30-day total.

0.0% INDEXED

30D FEE HISTORY0.0%COVERED

30d composition locked0.0% fee history reconstructed

Fee burn reconstructed0.00 FLR0.0% of 30d indexed

Direct sink change—exact checkpoint building

RewardManager context0.00 FLRlatest 12 verified epochs

30d run-rate—available when 30d history is complete

Top fee-burn driverBuildingclassification history building

SGB visual mix

SGB Native Burn Composition

0.0% INDEXED

30D FEE HISTORY0.0%COVERED

30d composition locked0.0% fee history reconstructed

Fee burn reconstructed0.00 SGB0.0% of 30d indexed

Direct sink change—exact checkpoint building

RewardManager context0.00 SGBlatest 12 verified epochs

30d run-rate—available when 30d history is complete

Top fee-burn driverBuildingclassification history building

Activity → Burn

What Is Creating Transaction-Fee Burn?

Fee burn is attributed from chain transactions to verified protocol contracts and known transaction classes. Unknown contracts remain unclassified until evidence is available. Each range shows its actual indexed-history coverage until the requested window is complete.

FLR fee-burn attribution

0.0% OF 24H FEE HISTORY RECONSTRUCTED

SGB fee-burn attribution

0.0% OF 24H FEE HISTORY RECONSTRUCTED

A delegation, FAssets mint, DEX interaction or reward claim does not create a special fee-burn mechanism. Its normal transaction gas is burned, and FlareSignal attributes that burn to the activity that caused it.

RewardManager · Flare

Recent Burned Rewards By Epoch

The latest verified RewardManager epochs are shown directly from getRewardEpochTotals. Burned rewards remain separate from native-burn totals because their final sink path can overlap direct burn accounting.

E4330.00 FLR0.00% of epoch rewards

E4320.00 FLR0.00% of epoch rewards

E4310.00 FLR0.00% of epoch rewards

E4300.00 FLR0.00% of epoch rewards

E4290.00 FLR0.00% of epoch rewards

E4280.00 FLR0.00% of epoch rewards

E4270.00 FLR0.00% of epoch rewards

E4260.00 FLR0.00% of epoch rewards

E4250.00 FLR0.00% of epoch rewards

E4240.00 FLR0.00% of epoch rewards

E4230.00 FLR0.00% of epoch rewards

E4220.00 FLR0.00% of epoch rewards

RewardManager · Songbird

SGB Recent Burned Rewards By Epoch

The latest verified Songbird RewardManager epochs are shown directly from getRewardEpochTotals. The generic burned-reward field is retained without inventing a more specific reason than the contract reports.

E4330.00 SGB0.00% of epoch rewards

E4320.00 SGB0.00% of epoch rewards

E4310.00 SGB0.00% of epoch rewards

E4300.00 SGB0.00% of epoch rewards

E4290.00 SGB0.00% of epoch rewards

E4280.00 SGB0.00% of epoch rewards

E4270.00 SGB0.00% of epoch rewards

E4260.00 SGB0.00% of epoch rewards

E4250.00 SGB0.00% of epoch rewards

E4240.00 SGB0.00% of epoch rewards

E4230.00 SGB0.00% of epoch rewards

E4220.00 SGB0.00% of epoch rewards

Burn mechanisms

Live, Historical And Rollout Mechanisms

Approved tokenomics changes are not presented as live burn until FlareSignal can observe the actual mechanism. This is particularly important for FIP.16 rollout items.

FLR mechanisms

LIVEObservable transaction fee burn

FlareSignal counts gasUsed × block baseFeePerGas as the directly observable burn component and attributes it to transaction activity. Current explorer data can show a separate priority fee / tip, which is not counted as burned.

COUNTED IN OBSERVED FLOW

LIVERewardManager burned rewards

IRewardManager exposes cumulative and per-epoch burned rewards. It is shown as attribution/context and not added again to direct sink flows.

CONTEXT / NON-ADDITIVE

LIVECanonical dead-address burns

Positive balance changes at 0x000…dEaD are counted as direct sink inflow.

COUNTED IN OBSERVED FLOW

HISTORICALBacker-token scheduled burn

The documented monthly backer-token burn programme ran through January 2026. Historical context only; not counted in current observed burn flow.

CONTEXT / NON-ADDITIVE

APPROVED / ROLLOUTFailed/unconfirmed FDC request burn

FIP.16 describes supply reduction for request payments that do not yield confirmations. Kept outside observed totals until live contract behaviour is independently measurable.

CONTEXT / NON-ADDITIVE

APPROVED / ROLLOUTTemporary unearned-reward pool burn

FIP.16 describes burning the non-reallocated portion of temporary unearned reward pools. Not presumed live without measurable evidence.

CONTEXT / NON-ADDITIVE

FRAMEWORK / ROLLOUTFIRE supply sink

FLR held in FIRE can be unavailable to circulation, but it is not permanently burned until an actual burn occurs.

CONTEXT / NON-ADDITIVE

SGB mechanisms

LIVEObservable transaction fee burn

The official Songbird explorer exposes burnt fees on transactions. FlareSignal records the observable EVM base-fee component and does not assume an additional fee component is burned unless evidenced.

COUNTED IN OBSERVED FLOW

LIVEExpired FTSO reward burn

SIP.01 aligned Songbird with Flare so unclaimed FTSO delegation rewards expire and are burned. RewardManager burned totals are tracked on-chain.

CONTEXT / NON-ADDITIVE

LIVECanonical dead-address burns

STP.05 identifies 0x000…dEaD as the address used for unwrapped SGB that needs to be burned.

COUNTED IN OBSERVED FLOW

LIVE ACCOUNTINGLegacy Avalanche burn address

STP.05 documents the older 0x0100…0000 burn address and requires both burn addresses to be monitored for supply accounting.

COUNTED IN OBSERVED FLOW

LIVE MECHANISM / NON-ATTRIBUTEDProvider reward penalty burn

SIP.04 states that a provider with no passes who fails minimum participation requirements loses all rewards for the epoch and those rewards are burned. The generic RewardManager burned total is retained without attributing an exact amount to this cause unless reward-level evidence supports it.

CONTEXT / NON-ADDITIVE

GAS BURN ONLYGovernance voting

A vote transaction consumes SGB gas like another transaction. No separate vote-token burn mechanism is assumed.

CONTEXT / NON-ADDITIVE

Direct burn addresses

Permanent Sink Balances

Each address is anchored to its latest exact chain balance. Where that address has a verified trailing-24h increase, the display advances smoothly between chain reads and re-anchors on refresh.

FLR recognised dead address4,233,485,928.92 FLRLIVE · exact-chain anchored0x0000…dEaD

SGB recognised dead address577,673,264.04 SGBLIVE · exact-chain anchored0x0000…dEaD

SGB legacy Avalanche burn address6,578,013.24 SGBLIVE · exact-chain anchored0x0100…0000

Dead-address balances are direct sinks, not total burn. The animation is a visual projection from the latest exact address balance using that address's verified 24-hour sink pace; transaction-fee destruction remains separate.

Supply context

Burn Against Circulating Supply

Exact direct-sink change is available independently of the slower transaction-fee history, so this section remains available while the 30-day fee history is still being reconstructed.

Open Utilisation →

FLR 30d burn context0.0% FEE HISTORY

21,434,654.01 FLRexact direct sink · 30d

Direct sink 30d 21,434,654.01 FLRDirect / circulating 0.0246539%Fee burn indexed 0.00 FLRMeasured native burn so far 21,434,654.01 FLRMeasured / circulating 0.0246539%Fee-history coverage 0.0%

SGB 30d burn context0.0% FEE HISTORY

8,399,536.59 SGBexact direct sink · 30d

Direct sink 30d 8,399,536.59 SGBDirect / circulating 0.0451083%Fee burn indexed 0.00 SGBMeasured native burn so far 8,399,536.59 SGBMeasured / circulating 0.0451083%Fee-history coverage 0.0%

Direct-sink 30-day change is an exact historical burn-address balance difference. While fee history is incomplete, the fee and native totals are explicitly shown as reconstructed-to-date, not promoted to a complete 30-day total. At 100% coverage the card switches automatically to verified native burn.

FAssets distinction

Native Burn vs FAsset Token Burn

Open FAssets →

FXRP token burn

FXRP redemption/liquidation can reduce FXRP ERC-20 supply. That is an FAsset supply event.

≠

FLR / SGB gas burn

The native gas consumed by the FAssets transaction is a separate native-token burn mechanism.

≠

Protocol fee / revenue

Protocol economic fees are tracked separately and are not automatically burned unless an observed mechanism destroys them.

Source + methodology health

Burn Data Provenance

chain_verifiedFlare Native Burn Chain AccountingHEALTHY2026-09-14 15:49:21 UTC

chain_verifiedSongbird Native Burn Chain AccountingHEALTHY2026-09-14 15:49:26 UTC

Official FLR token / fee-burn documentation ↗IRewardManager burn totals ↗SIP.01 Songbird reward burning ↗STP.05 Songbird burn addresses ↗FIP.16 supply-reduction framework ↗