Live digital twin
Every three.ws payment passes one admission check: can the fee wallet afford the next settle? This page runs that exact function, imported from the settle path, in your browser, against live production balances. Drag a knob and watch the rail survive or starve.
Reading live rail state
Fetching the fee wallet balance, the governor config this deploy is running, and 24 hours of settle outcomes.
Read fresh on load. Nothing on this page is a fixture.
Slide right to simulate a deposit, left to simulate a drain.
Raising this shrinks spendable SOL one-for-one.
Shorter runway spends faster today and leaves less for tomorrow.
The only knob that does not depend on the balance.
What the rail is being asked to do, per hour.
Watch for the UTC midnight reset.
The governor's budget is one equation with three independent terms, so a stall always has three possible fixes. Name the throughput you want and each lever is solved exactly, including the ones that cannot work.
Emitted only for knobs that differ from live, with the flag that merges into the existing environment rather than replacing it.
The last 24 hours of real settle outcomes, next to what this model predicts for the same period. A gap between them is a bug in the model or a cause the model does not know about, and either is worth chasing.
The simulation imports
walletDailyFeeBudgetLamports() and
assessWalletFeeBudget() from
wallet-fee-governor.js, the same module the live
facilitator calls on every settle. Change the governor and this
page changes with it. A parallel model would drift; this one
cannot.
fee_wallet_below_floor, and the meter is never consulted.fee_runway_exhausted.
The governor recomputes from the live balance on
every settle, so spending shrinks the budget authorising
the next spend. That feedback settles at
spendable / (fee × (days + 1)) per day. At the
stock three-day runway the rail delivers a quarter of spendable
SOL per day, not a third: a 25% gap between the configured intent
and the real throughput, and the reason
“three days of runway” and
“settlement stopped today” are not contradictions.
Duplicate-signature retries and the dust guard are correct rejections, not capacity problems. Folding them into one number makes a healthy rail read as a starved one, so this page counts them separately and projects only against real demand.
Every figure is public: platform wallet balances, configured thresholds, and aggregate settle counts are already served by /api/x402-ring and /api/x402-status. No key material or per-user data is reachable from this page. The seed endpoint is /api/x402/runway-lab. Related surfaces: Money Pulse, Agent Economy Live, x402 revenue.