THE MACHINE THAT BURNS
BEFORE SOLANA DOES.

01 · WHAT SIMD-553 IS

SIMD-553 — Resource Fee Burn is a draft Solana Improvement Document (merged into the official repository 2026-06-03, currently Draft status). It introduces a resource fee charged on every transaction and burned 100%:

resource_fee = ceil_div(requested_cost_units × num, den)

requested_cost_units =
    signature_cost
  + write_lock_cost
  + data_bytes_cost
  + programs_execution_cost   (requested CUs)
  + loaded_accounts_data_size_cost

The rate ladder is staged through three feature gates: 1/10 → 1/4 → 1/2 lamports per cost unit. Today Solana burns roughly 648 SOL/day against ~60,000 SOL/day of issuance — SIMD-553 at the terminal rate is an order-of-magnitude change to that balance. It is Solana's structural answer to EIP-1559, whose activation in 2021 produced the "ultrasound money" narrative on Ethereum.

02 · ORACLE METHODOLOGY

The oracle answers one question honestly: how much SOL would have burned in the last 24 hours?

• Measure slotsPerDay from getRecentPerformanceSamples (latest reading: 203,400 slots).
• Stratify 96 target slots evenly across the trailing 24h slot window; fetch one finalized block per target via getBlock, with +1/+2 fallback for skipped slots.
• For every transaction, read meta.costUnits — the SIMD itself notes clients MAY use this field with the rate to estimate the resource fee — and compute ceil_div(costUnits × num, den) in integer arithmetic. No floats touch the fee math.
• Classify vote transactions by the presence of Vote111… in account keys, and report vote-inclusive and vote-exclusive projections (SIMD-553 charges vote transactions too, pre-Alpenglow).
• Extrapolate the sampled per-block average across the measured day: 132,032 sampled transactions in the latest full reading, 0 missing costUnits fields.

Sampling error, honestly: 96 blocks out of ~203,400 slots is a ~0.05% sample. Activity is bursty; readings taken minutes apart differ by several percent (the archive shows this openly — including one deliberately thin 2-block probe from a cycle smoke-test). The oracle publishes its raw sample counts with every datapoint so anyone can judge the confidence for themselves, and the methodology string ships inside every record. This beats quoting someone else's model: current readings land at 740 SOL/day at 1/10 and 3,697 SOL/day at 1/2 — measured, versus Blockworks' modeled 7,500–9,000 SOL/day at higher assumed activity.

03 · THE MIRROR FORMULA

The mirror loop converts the network's would-be burn into a daily reserve burn. The machine wallet holds a reserve (planned: 75,000,000 DD from the dev buy). Each day:

base_pct   = 1 / runway_days                    (runway: 90 days)
multiplier = clamp(today_would_be_burn / baseline, 0.5, 2.0)
             (baseline: 2,700 SOL/day)
burn_today = reserve × base_pct × multiplier

A heavy network day burns up to 2× the base rate; a dead-quiet day still burns at least 0.5×. The mirror fires even in zero-volume weeks — the machine never sleeps, exactly like the protocol wouldn't. The floor/cap clamp guarantees ≥90 days of runway at baseline. Latest cycle plan: 1,172,762 DD (1.56% of reserve, ×1.41 clamped multiplier).

04 · THE FLYWHEEL

The second loop scales with trading activity. pump.fun pays creator fees on every trade of $DD; the machine claims them each cycle, market-buys $DD (bonding curve pre-graduation, Jupiter routing after), and burns what it buys. Every burn transaction is memo-tagged with that day's network number:

"Solana would have burned 3,420 SOL today. We burned with it."

Mirror plus flywheel means supply decays on two independent clocks: one deterministic (the protocol's math), one reflexive (the market's attention).

05 · THE PROPHECY

SIMD-553 activates through three feature-gate accounts with vanity addresses — the countdown clock is already on-chain:

resource_fee_burn_1_10  BurnUeW8qFgJm3Y4uroMvqEQDrYWbhv7p231hHbrq8LV
resource_fee_burn_1_4   Burn2YJ9k9wTcyQCEMztMsbnBReV3FzXpW1aBB7MhwuY
resource_fee_burn_1_2   BurnSoLN7d4ASk4zVVxTg4ob3C8z71dN6cr8YsyEnaZ6

The machine checks all three every cycle. Ladder per gate: NOT_SUBMITTED → SUBMITTED → ACTIVATED. The day resource_fee_burn_1_10 activates on mainnet, the network starts burning for real — and the machine executes its final burn: the entire remaining reserve, in one transaction. The console flips to a memorial state. If governance never ships the proposal, the machine simply keeps burning — in protest. Both endings complete the story; there is no dead-end state.

06 · MACHINE ARCHITECTURE

┌─ CRANKER (daily cycle) ──────────────────────────────────┐
│                                                          │
│  ORACLE      sample blocks → would-be burn (3 rates)     │
│     │                                                    │
│  MIRROR      formula → reserve burn plan → burnChecked   │
│     │                                                    │
│  GATE WATCH  3× Burn* accounts → prophecy trigger        │
│     │                                                    │
│  CLAIM       pump.fun creator vault → SOL                │
│     │                                                    │
│  BUYBACK     curve buy / Jupiter route → $DD             │
│     │                                                    │
│  BURN        memo-tagged, on-chain, verifiable           │
│                                                          │
└──> data/status.json · history.jsonl · totals.json ──────┘
                          │
                          └──> this site (/api/status)

The site reads snapshot copies of the machine's output files through a single data-source interface; pointing it at the live Redis feed post-launch changes one module and zero components. Current state: DRY_RUN — transactions are built and logged, never signed, never sent. The mint does not exist yet, and the console says so instead of pretending.

07 · SAFETY RAILS

• HALT file kill switch — its presence forces dry-run regardless of any config.
• Max 0.5 SOL spent per cycle — no runaway buybacks.
• Max slippage 500 bps on any route.
• Min claim 100,000 lamports — dust is left alone.
• Max burn 1% of supply per cycle (final prophecy burn excepted, by design).
• Execution requires execute === true AND a loaded signer AND no HALT file — three independent switches.

08 · HONEST RISKS

The proposal may never ship. SIMD-553 is a Draft. It could be rewritten, replaced, or abandoned. That is the bet — and the machine is built so that either outcome resolves it: activation triggers the final burn; abandonment means the protest burn continues until the reserve is gone.

• Sampling variance. Block-sampled readings carry real error bars; the oracle publishes sample sizes rather than hiding them.
• Draft-spec drift. If the SIMD's formula or rates change, the oracle changes with it, publicly, in the archive.
• Pre-launch state. Until the mint exists, every execution stage is SKIPPED_NO_MINT and all ledger totals are genuinely zero. No fabricated history, ever.
• This is a meme token. It mirrors monetary policy; it is not monetary policy. Assume total loss is possible. Nothing here is financial advice.