Dynamic L1 Fees
ADR-026 replaces one global L1 minimum slip floor with whitelisted per-thorname and per-pair floors that move by a TOR-denominated fee-revenue signal. Live values below are THORNode snapshots, not durable governance history.
Page Source Posture
retrieval details
+4 sources
retrieval details
retrieval details
retrieval details
retrieval details
ADR-026 dynamic L1 minimum fee experiment, live whitelisted thorname records, and current-only THORNode tracker.
Use This Page For
- ADR-026 design context, dynamic L1 fee controls, whitelist state, pair scope, and live THORNode endpoint evidence.
- Current-only sealed records and current-epoch accumulators with explicit source warnings and insufficient-sample states.
Verify Elsewhere Before Claiming
- Durable revenue lift, route competitiveness, partner attribution quality, or final governance history.
- Current trading, signing, chain, app-layer, secured-asset, or broader network availability outside the dynamic-fee endpoint snapshot.
Static context
retrieval details
+3 sources
retrieval details
retrieval details
retrieval details
Live snapshot
Loading live source...
ADR text is design context; THORNode values are current-only operational evidence.
Look Here First
Start with these four signals. ADR-026 is testing whether partner-pair floors can improve revenue without losing useful flow.
1. Revenue signal
Loading
current accumulators loading; sealed history total Insufficient samples
Why: fees_tor is the objective. Without sealed-epoch improvement, lower bps has not shown revenue lift.
2. Demand signal
Loading
Current epoch volume_tor from current accumulators loading; matching loading
Why: Volume is demand context, not proof that the lower floor won routing flow.
3. Controller movement
Loading
floor loading / ceiling loading
Why: dynamic_bps shows whether the experiment is learning, floor-pinned, or ceiling-pinned.
4. Evidence quality
Loading
0 history pairs / 0 sealed records / matching loading
Why: Sparse samples are operational evidence, not enough to claim a durable trend.
Coverage Check
Coverage loadingCurrent epoch rows
Loading
/dynamic_l1_fees_current accumulators included in revenue and volume cards.
Rows with sealed record
Loading
Waiting for current and sealed endpoint reads.
Sealed history
Loading
Waiting for per-thorname history endpoint reads.
Source posture
Loading
Waiting for source warning classification.
Related Checks
Use these before turning current dashboard values into a broader claim.
Current Controls
These are the control-surface values behind the tracker. The fallback floor is still the base L1 minimum; dynamic floors only apply to active whitelisted thorname and pair records.
Loading
Loading
Loading
Loading
Loading
Show controller configuration
Unavailable
Unavailable
Unavailable
Unavailable
Unavailable
Unavailable
Historical Results
Sealed epoch history from /dynamic_l1_fees/{thorname}. Showing 0 samples across 0 pairs; this is operational history, not proof of durable revenue lift.
No sealed historical samples are available from the per-thorname history endpoint. Treat this as insufficient samples, not as zero revenue.
Tracked Records
Raw sealed records show the maintained dynamic floor for each tracked thorname and pair. Active whitelist records may apply that floor at swap time; monitor records are computed but still use the base L1 floor.
Loading dynamic fee records from THORNode...
Dynamic bps distribution
No sealed dynamic-fee records are available from THORNode.
Operational evidence
Show exact Mimir keys and endpoint fields
Mimir keys
L1DynamicFeeEnabled: UnavailableL1SlipMinBPS: UnavailableL1DynamicFeeEpochBlocks: default UnavailableL1DynamicFeeFloorBPS: default UnavailableL1DynamicFeeCeilingBPS: default UnavailableL1DynamicFeeStepBPS: default UnavailableL1DynamicFeeDeadbandBPS: default UnavailableL1DynamicFeeWindowEpochs: default Unavailable
Endpoint fields
/dynamic_l1_fees: thorname, pair, dynamic_bps, whitelist_state, last_active_epoch, latest_fees_tor.
/dynamic_l1_fees_current: epoch, thorname, pair, volume_tor, fees_tor.
/dynamic_l1_fees/{thorname}: thorname, whitelist_state, pair, dynamic_bps, last_active_epoch, history.epoch, history.volume_tor, history.fees_tor, history.bps_at_close.
Experiment Context
The live tracker above is the decision surface. Use these lower disclosures for design mechanics, community framing, and proof boundaries.
How the Experiment Works
From one floor to many
Instead of applying one network-wide L1SlipMinBPS to every L1 swap, ADR-026 creates a floor per whitelisted thorname and normalized pair.
Pair normalization
Pairs are direction-agnostic. Non-RUNE endpoints are sorted by full asset string, while swaps with RUNE use ASSET|THOR.RUNE as the pair identity.
Governance-curated whitelist
DYNAMICFEE-WHITELIST-{thorname}=1 applies the dynamic floor. State 2 monitors without applying it. Absent or zero means the default floor is used.
Attribution versus application
Eligible listed thornames can receive full TOR credit for a swap, but the fee floor is selected from the largest affiliate-bps thorname in the memo.
TOR-denominated signal
The controller compares fees_tor across epochs, so RUNE/USD movement is less likely to look like fee-policy performance.
Closed-loop movement
If the last bps change increased fee revenue, the floor keeps moving in that direction. If it reduced revenue, the controller reverses inside configured floor, ceiling, step, window, and deadband settings.
Community Read
Why supporters like it
Context onlyA single fee floor is too blunt. Dynamic floors can compete for price-sensitive aggregator flow while preserving revenue where THORChain demand is stickier.
What skeptics worry about
Zero-bps or tie-ordered memos can still make a whitelisted thorname the largest affiliate-bps selector, large frontends may gain an edge, and sparse routes may never create enough data for the controller.
What it may prove
If low dynamic floors still fail to win flow, the bottleneck may be routing quality, liquidity, speed, or app-layer integration rather than base protocol fees.
Interpretation Notes And Non-Claims
Keep these as guardrails for the live numbers. They are important, but they should not compete with the operational dashboard above.
- L1-to-L1 scope: ADR-026 v1 applies to eligible L1 swaps selected by whitelisted thornames and normalized pairs; trade assets, secured assets, synths, and many arb flows remain outside this model.
- Current THORNode values can change every block or epoch. This page pins reads to one provider and height; current snapshot: Loading snapshot; warnings: Unavailable.
- Affiliate attribution versus applied floor: eligible thornames can receive TOR credit while the applied floor comes from the largest affiliate-bps thorname.
- Discord can explain debate and operating concerns, but it is not canonical protocol evidence.
- Current records and sparse sealed history do not prove revenue lift, route competitiveness, or partner attribution quality.
Show what would improve proof
- Scope expansion
- A later ADR or endpoint that explicitly covers trade, secured, synth, or arb classes.
- Durable state history
- Longer sealed history, indexed block-by-block Mimir changes, or a governance/event timeline independent of latest THORNode state.
- Attribution quality
- Per-swap evidence exposing the memo thornames, affiliate bps splits, credited thornames, selected floor thorname, and applied dynamic bps.
- Revenue and routing lift
- Before/after route-share baselines, quote-win rates, partner traffic attribution, comparable non-whitelisted control flow, and enough sealed epochs to separate fee changes from demand or liquidity changes. Current sealed coverage: Loading sealed samples.