PaperlayerView exact revision on arXiv

Source-linked AI summary

On the (In)stability of Adaptive Fee Mechanisms in Multi-Chain Systems

Yifan Zhou, Jiang Xiao, Xuechao Wang, Ru Cheng, Shijie Zhang

arXiv:2610.23305v1cs.CRcs.DC

TL;DR

EIP-1559’s update rate trades responsiveness against stability, while delayed cross-chain feedback makes multi-chain fee-market stability a distinct challenge. The paper models and analyzes these interactions, finding a substantially smaller safe update-rate regime and proposing a mitigation for the destabilizing feedback.

  • Problem

    EIP-1559’s update rate trades responsiveness against stability, and cross-chain interactions create a distinct stability problem for multi-chain fee markets.

    Source: §1 · pp. 1–2

  • Method

    The paper models cross-chain fee markets as delayed dynamical systems, analyzes their stability, and proposes a locally deployable counter-force to re-price stale inbound load.

    Source: §1 · p. 2, §11 · p. 13, §8 · p. 13

  • Results

    84.8%: the safe regime of the EIP-1559 update rate shrinks relative to the monolithic baseline.

    Source: §1 · p. 2

  • Takeaways & Limitations

    A protocol-level mitigation is proposed to cancel destabilizing delayed feedback in multi-chain systems.

    Source: §11 · p. 13

    Weak demand keeps base fees at the floor, leaving the controller inactive and elasticity unidentified in the ex ante analysis.

    Source: §9 · p. 13

Abstract

from arXiv · show

EIP-1559 has become the dominant transaction fee mechanism in permissionless blockchains, regulating scarce block space through an adaptive base fee. The design balances a trade-off between responsiveness to demand fluctuations and stability of long-term resource usage. On a single chain, this trade-off is well understood and empirically stable. In multi-chain systems, however, cross-chain flows introduce delayed economic interactions across otherwise independent fee markets. These interactions alter the control dynamics and create stability risks that existing models do not capture. Deployed systems have already polarized. Polkadot enforces conservative update rates, effectively disabling fee adaptivity and reverting the market to inefficient first-price auctions. Cosmos adopts aggressive update rates without formal guarantees. To fill this gap, we propose a control-theoretic framework that formalizes multi-chain fee markets as a nonlinear dynamical system with delayed feedback. We identify delay-amplified over-correction as the structural root of instability. Experiments show that cross-chain coupling erodes stability relative to monolithic blockchains, reducing the safe parameter space for base fee update rates by up to 84.8%. Moreover, instability propagates across chains, contaminating the otherwise stable peer chains. At Ethereum's update rate, which leaves a monolithic chain stable, the multi-chain system exhibits extreme load oscillation between full and near-empty blocks, with over half of all blocks at full capacity. Mainstream Cosmos chains already exceed their safe bounds under their default configurations, and the resulting load oscillation raises their block failure rate by an order of magnitude. Guided by this mechanism, we design a lightweight protocol-level mitigation that removes the over-correction and stabilizes dynamics in multi-chain environments.

1 Introduction

EIP-1559 uses an adaptive base fee to balance responsiveness and stability, a trade-off that is empirically stable on monolithic chains. Cross-chain flows add delayed interactions that existing models miss, creating systemic stability risks and motivating a dedicated analysis and mitigation.

Background and motivation

  • EIP-1559 replaces volatile first-price auctions with an adaptive base fee and elastic capacity, but its update rate trades responsiveness against stability.Too-small update rates can regress to first-price auctions; too-large rates can destabilize load.Source: §1 · p. 1

Trade-off characterization

  • Multi-chain deployments have polarized: Polkadot’s conservative rates make the base fee quasi-static, while Cosmos’s aggressive rates lack formal guarantees and have not been tested under active demand.Weak demand keeps Cosmos chains outside the high-load regime where feedback dynamics become visible.Source: §1 · p. 2

Research problem

  • Cross-chain workflows turn stability into a systemic concern: disturbances propagate into connected fee loops, while delayed feedback responds to outdated states.Existing models do not capture these dynamics, leaving the multi-chain safe regime and security consequences unclear.Source: §1 · p. 2

Stability analysis

  • Cross-chain latency makes feedback act on stale deviations, producing delay-amplified over-correction that intensifies with higher inbound load.The analysis identifies this as the instability mechanism in a multi-chain model with delayed feedback.Source: §1 · p. 2

Experimental validation

  • The safe EIP-1559 update-rate regime shrinks by 84.8% under cross-chain coupling; at 0.125, a rate stable on a monolithic chain, about half of blocks saturate the gas limit.The deployed rates of Cosmos Hub and Osmosis already exceed their safe bounds, and saturation raises their block failure rate by an order of magnitude.Source: §1 · p. 2

2 Background

Instability can drive blocks toward full capacity, with consequences for validator participation and consensus timing. Multi-chain architectures execute user actions as dependent sub-transactions across chains, with relay latency between source and destination execution.

2.1 Security Implications of Instability

  • In the extreme, more than half of blocks can reach the gas limit, intensifying centralization and degrading consensus resilience through slower propagation and execution.The consequences vary by consensus family, including weaker honest-majority guarantees, missed LMD-GHOST voting deadlines, and BFT timing-threshold violations.Source: §2.1 · pp. 2–3
  • Earlier unprovisioned-load incidents required an adversary or mispriced opcode, whereas multi-chain instability can produce more than half full blocks at an update rate stable on monolithic chains.The cited examples include the 2016 Shanghai DoS attacks and gas-refund mechanisms later addressed by EIPs.Source: §2.1 · p. 3

2.2 Multi-Chain Architectures

  • Multi-chain workflows relay an inclusion proof from a source-chain sub-transaction to a destination-chain sub-transaction after rigid physical latency d.The destination action commits at time t + d after the source action at time t.Source: §2.2 · p. 3

3 Warmup: Single-Chain Baseline

The single-chain baseline models EIP-1559 as a negative-feedback controller that steers load toward a target. Local stability depends on the update rate and demand elasticity; beyond the stability boundary, load oscillates and can reach full and near-empty blocks.

3.1 The EIP-1559 Mechanism

  • The base fee rises above the target load and falls below it; update rate δ sets feedback strength, while target load T is tied to expanded block capacity.Small δ can leave users relying on priority tips, whereas large δ can over-suppress demand and induce instability.Source: §3.1 · p. 3

3.2 Definitions

  • Normalized price x(t) = P(t)/P* sets equilibrium to x* = 1, and demand elasticity λ describes local demand sensitivity around that equilibrium.The model uses the algorithmic base fee and excludes priority tips to isolate the EIP-1559 feedback loop.Source: §3.2 · p. 3

3.3 Monolithic Stability Analysis

  • The monolithic system is locally stable exactly when |1−δλ| < 1, or δ ∈ (0, 2/λ); with δ = 0.125, Ethereum is stable for λ < 16.On-chain elasticity estimates place Ethereum between 9.09 and 16.29, with a preferred estimate of 12.45.Source: §3.3 · p. 4
  • Beyond the monolithic stability boundary, load oscillates around the target and can progress from unsaturated swings to blocks alternating between the gas limit and near-zero load.The saturated stage includes full blocks; prior work bounds load inflation at 6.27% for δ = 0.125, with 53.13% full blocks in the extreme full-or-empty pattern.Source: §3.3 · p. 4

4 Motivation

Observed fee dynamics illustrate polarized deployments, while cross-chain workflows link otherwise independent fee controllers through economic coupling and delay. The section asks how these effects alter stability, safe update rates, load patterns, and consensus outcomes.

4.1 The Polarization Problem

  • 0.974 for Ethereum and 0.004 for Moonbeam quantify the base-fee/effective-gas-price correlation among the top 10% of blocks by load.Ethereum’s effective gas price moves with the base fee, while Moonbeam’s nearly fixed base fee leaves price variation largely to priority tips.Source: §4.1 · pp. 4–5, Figure 1 · p. 5

4.2 Delayed Economic Coupling

  • Cross-chain workflows couple fee markets because destination inbound load reflects earlier source-chain price conditions after latency d.A fee change can alter cross-chain demand and loads on connected chains; the resulting feedback loops are governed by coupling strength and delay.Source: §4.2 · p. 5
  • Capturing the coupled dynamics requires decomposing local, outbound, and inbound load, modeling demand responses to multiple prices, and representing latency explicitly.Source: §4.2 · p. 5

4.3 Research Questions

  • The research questions ask how delayed coupling changes stability and propagates instability, and whether it erodes safe update rates or harms consensus.The questions also target the severity of resulting load patterns.Source: §4.3 · p. 5

5 Multi-Chain Model

The model represents multiple EIP-1559 chains as coupled through cross-chain traffic and delayed feedback. It specifies how load composition, demand sensitivities, and latency shape those interactions.

5.1 General Assumptions

  • The model studies N EIP-1559 chains with cross-chain flows; multi-hop workflows add delayed dependencies, and the instability is structural rather than attacker-driven.Local stability analysis abstracts away the mempool near equilibrium, while simulation includes it to capture backlog; a one-block 1% perturbation exposes the instability.Source: §5.1 · p. 5

5.2 Model Specification

  • Each chain’s load comprises local, outbound, and delayed inbound flows, with equilibrium load shares determined by the system’s topology.Heterogeneous block intervals are absorbed into the inbound share, allowing a common block-step model.Source: §5.2 · p. 6
  • The model assigns separate elasticities to source-side and destination-side prices because chains use distinct native tokens with floating exchange rates.Around equilibrium, these per-price elasticities also capture linearized aggregate-cost demand specifications.Source: §5.2 · p. 6
  • Cross-chain latency is represented by normalized delay weights; inbound load responds to historical prices while local and outbound components respond to current prices.The model assumes a shared delay distribution across chains, and the distribution’s shape affects how delayed deviations enter load.Source: §5.2 · p. 6
  • The load equation combines local transactions, workflows initiated on the chain, and delayed inbound workflows to define the coupled dynamics.A workflow initiated from chain i contributes outbound load there and later arrives as inbound load on chain j.Source: §5.2 · p. 6

6 Stability Analysis of Multi-Chain EIP-1559

The analysis extends single-chain feedback to coupled chains with delayed interactions, identifying stale inbound feedback as a source of over-correction. It finds that this delay-driven pathway is the practical instability driver and derives a lag-sensitive stability bound.

6.1 Linearization of Multi-chain Dynamics

  • The four linearized channels combine current and delayed price effects from the chain and its peers; without cross-chain traffic, stability reduces to the single-chain bound δλ < 2.The channel coefficients depend on demand elasticities and equilibrium load shares.Source: §6.1 · p. 7

6.2 System-wide Stability Representation

  • The analysis represents delayed multi-chain dynamics with an augmented state spanning all chains and the delay window.The resulting matrix has dimension N(dmax+1) × N(dmax+1); its criterion gives a binary verdict for a configuration but no closed-form boundary for general deployments.Source: §6.2 · p. 7
  • The augmented system is stable if and only if ρ(Mext) < 1, and stability depends jointly on all chains’ update rates.Each chain’s update rate scales its matrix row; a single aggressive chain can destabilize the coupled system and inflate peer-chain load.Source: §6.2 · p. 7

6.3 Potential Instability Pathways

  • Cross-chain traffic adds three feedback channels beyond local self-feedback, including delayed self-feedback that can amplify stale deviations.The monolithic correction budget is based on the current deviation, whereas delayed inbound transactions reflect past deviations.Source: §6.3 · p. 8
  • Latency makes the correction depend on larger past deviations while its convergence budget is set by the smaller current deviation, lowering the tolerable update rate below the single-chain bound.For a purely inbound chain, stability requires δiε|∆xi(t−d)| < 2|∆xi(t)|.Source: §6.3 · p. 8

6.4 Validation of Potential Pathways

  • Only delay-amplified over-correction is a practical instability driver; the two cross-chain positive-feedback subpaths fail validation.During a monotonic return to equilibrium, past deviations exceed current ones, allowing delayed self-feedback to over-correct.Source: §6.4 · p. 8
  • At inbound ratio 0.99 and εj0 = 16 under spike latency L = 5, the predicted δ < 0.018 is one grid step from the simulated boundary of 0.019.The analytical budget recovers 2 at L = 0, falls to 1 at L = 1, and decays as π/(2L).Source: §6.4 · p. 9

7 Quantifying Instability Consequences

The evaluation measures how delayed cross-chain coupling changes stability, load oscillations, block failures, and the propagation of instability under uniform and non-uniform update rates. It finds that coupling sharply narrows safe update-rate bounds and can saturate otherwise conservative peer chains.

7.1 Experimental Setup

  • The experiments use a three-chain system, a one-block 1.01× source-demand perturbation, and 50,000-step trajectories, cross-checking convergence against ρ(Mext).The injected disturbance is small and does not directly amplify Chain 0’s inbound traffic.Source: §7.1 · p. 9

7.2 Stability Boundary and Load Pattern

  • The study locates the multi-chain boundary by simulation while varying inbound ratio and destination-side elasticity, then uses ρ(Mext) to order unstable configurations.For the reported Pathway 1 experiments, the simulated boundary agrees with ρ(Mext) on 15,938 of 15,939 configurations.Source: §7.2 · pp. 9–10
  • At an inbound ratio of 99%, the safe update rate falls to δ < 0.019 from the monolithic δ < 0.125, an 84.8% erosion; more than half of blocks reach capacity at the deepest instability.At the far end of the saturated stage, load alternates between full blocks and 0.82% of the gas limit.Source: §7.2 · p. 10, Figure 4 · p. 10

7.3 Security Implication

  • At deployed settings, Cosmos Hub and Osmosis exceed their stable update-rate bounds and have simulated block failure rates of 2.4% and 12.5%, respectively.These rates are 15× and 2.4× their observed historical rates; the four tested Polkadot chains remain stable.Source: §7.3 · p. 11, Figure 5 · p. 11
  • When instability deepens to 6.27% load inflation, Cosmos Hub’s failure rate reaches 9.1% and Osmosis’s reaches 20.1%.At this bound, more than half of all blocks are at the gas limit.Source: §7.3 · p. 11

7.4 Evaluating Non-Uniform Update Rate

  • With non-uniform update rates, each chain’s stability boundary depends on its own update rate and load structure, yet an unstable Chain 0 can drive up to 49.5% of conservative peers’ blocks to capacity.Even at δpeer = 0.001, the median peer full-block share is 30.9%.Source: §7.4 · p. 11, Figure 6 · p. 12
  • The propagation is asymmetric: peers’ outbound demand toward unstable Chain 0 responds at elasticity 16 and can saturate their own blocks, while weak inbound response does not saturate Chain 0.Activating Chain 0’s Channel (II) also propagates peer instability to Chain 0; strengthening peers’ Channel (I) instead makes peers more stable.Source: §7.4 · p. 12

8 Protocol-level mitigation

The proposed protocol-level mitigation rebalances local and delayed feedback to counter stale-load overshoot. It uses a locally deployable compensation term and is experimentally validated to mitigate instability.

8 Protocol-level mitigation

  • The added compensation term re-prices stale inbound load, strengthening Channel (I) and weakening Channel (III).Its counter-force adds H_i to Channel (I) and subtracts H_i from Channel (III).Source: §8 · pp. 12–13
  • Each chain can deploy the added term using locally observable inputs, without cross-chain coordination.H_i is calculated from load topology and elasticities.Source: §8 · p. 13
  • The authors experimentally validate that the augmented update rule mitigates instability, and report that accurate elasticity estimates are not required to restore stability.The full analysis is deferred to Appendix D.Source: §8 · p. 13

9 Discussion

The discussion frames the analysis as ex ante because low demand leaves base fees at the floor and elasticity unidentified. It also describes modeling choices and participant behavior that may make real-world instability more severe.

9 Discussion

  • The analysis uses two-hop workflows, fixed delays, and memoryless, non-strategic demand to isolate instability from coupling and delay.The authors state that congestion-dependent delays and longer workflows would push the system toward more instability.Source: §9 · p. 13
  • Low demand keeps base fees at the floor, leaving the controller inactive and demand elasticity unidentified; low demand does not imply low elasticity.The paper describes Ethereum’s first year of blob-market operation as an “inelasticity horizon.”Source: §9 · p. 13
  • Real participants’ response lag, including wallet fee estimators, adds delayed feedback that the authors expect to widen the unstable region.Source: §9 · p. 13

10 Related Work

The paper distinguishes its analysis from prior work on transaction-fee mechanisms, monolithic EIP-1559 dynamics, and strategic fee-mechanism design. Its focus is multi-chain instability and its consensus consequences.

10 Related Work

  • Prior transaction-fee-mechanism research examined first-price auctions, EIP-1559, adaptive update rates, and multidimensional resource pricing.The paper notes that this control-theoretic paradigm informs upgrades including EIP-4844 and EIP-8037.Source: §10 · p. 13
  • Earlier EIP-1559 dynamical analyses characterize monolithic-chain stability and oscillation stages; this paper extends the setting to multi-chain instability and measures consensus consequences.It adopts prior oscillation stages and the 6.27% load-inflation cap rather than reproving them.Source: §10 · p. 13
  • Strategic fee-mechanism design studies incentives and manipulation, a line the paper describes as orthogonal to its analysis.Source: §10 · p. 13

11 Conclusion

The paper models multi-chain EIP-1559 markets as delayed dynamical systems, identifies delayed-feedback over-correction as a stability mechanism, and proposes a protocol-level mitigation. In the evaluated Cosmos configurations, deployed update rates exceed safe bounds.

11 Conclusion

  • Cross-chain coupling strictly shrinks the safe update-rate regime relative to the monolithic baseline, and the deployed rates of Cosmos Hub and Osmosis exceed their safe bounds.The proposed protocol-level mitigation cancels the destabilizing delayed feedback.Source: §11 · p. 13

Open Science

The appendix documents reproducible artifacts, derives coefficients for the four feedback channels, and tests the proposed instability pathways. Its validation finds strong delay-amplified over-correction, while the alternative pathways produce weaker or narrower effects.

Open Science

  • The Open Science artifact includes the simulator, a script checking whether ρ(Mext) < 1, and figure-specific raw data, plotting scripts, and reproduction instructions.Replotting from released raw data takes a few minutes; rerunning simulations is more expensive, with each boundary figure evaluating 15,939 trajectories.Source: Open Science · pp. 14–15

A Derivation of the Channel Coefficients

  • The appendix derives coefficients for four channels: instantaneous self-feedback, instantaneous peer feedback, delayed self-feedback, and delayed peer feedback.The coefficients are obtained by differentiating demand at equilibrium; without cross-chain traffic, stability reduces to the single-chain bound δλ < 2.Source: A Derivation of the Channel Coefficients · pp. 17–18

B Additional Experiments

  • The experiments rerun pathway validation across delay shapes, delay bounds, chain counts, price-dependent elasticity, and mempool capacities to test sensitivity to those settings.The appendix frames these as checks of whether the results are insensitive to the varied parameters.Source: B Additional Experiments · p. 18

B.1 Validation of Potential Pathways

  • Under spike latency, κdef reaches 11.8, versus 5.6 under uniform and 5.5 under bimodal latency, supporting delay-amplified over-correction as an effective mechanism.The maximum κdef reaches 1.4×10^5 under spike latency, but the authors use the 90th percentile to assess the trend because near-zero crossings dominate the maximum.Source: §B.1 · p. 19, Figure 7 · p. 19
  • Channel (IV) yields no simulated stability boundary in 47,817 tested configurations, while Channel (II) alone produces only narrow, mild failures under dmax = 1.The positive instantaneous pathway has some failures under spike latency, but the simulated boundary does not closely track the Mext boundary in that experiment.Source: §B.1 · pp. 20–21
  • Only 77 of 15,939 configurations fail when dmax = 1 isolates Channel (II), and the worst configuration fills 10.5% of blocks.Most failing points never fill a block, so this channel alone yields only a narrow instability region under extreme conditions.Source: Figure 9 · p. 20, §B.1 · p. 21

B.2 Experimental Analysis Varying Other System Configurations

Additional experiments show that the stability boundary varies with delay distribution and maximum delay, but is nearly invariant to chain count and price-dependent elasticity shapes. Varying mempool capacity leaves the boundary unchanged, and the appendix describes how block-failure rates are mapped from observed data.

B.2 Experimental Analysis Varying Other System Configurations

  • At dmax = 10, the critical elasticity is 2.4 under spike latency and 4.5 under uniform latency, corresponding to boundary contractions of 85.0% and 71.9%, respectively.Figure 12 presents the boundaries for the two latency distributions at dmax values of 7 and 10; under spike latency, the critical elasticity falls from 3.1 at dmax = 5 to 2.4 at dmax = 10.Source: §B.2 · p. 21, Figure 12 · p. 22

B.3 Evaluation Under Price-Dependent Elasticity

  • The stability boundary is identical across the three price-dependent elasticity shapes and matches the constant-elasticity boundary, including δ < 0.019 at inbound ratio 0.99.All three shapes have elasticity 16 at the equilibrium price x = 1; their maximum full-block shares are 52.5% for logarithmic and 52.7% for both linear and logistic shapes.Source: §B.3 · pp. 22–23, Figure 14 · p. 23

B.4 Experiment on Varying Mempool Sizes

  • All four mempool capacities mark the same 8,008 of 15,939 configurations unstable, with no verdict changes across Q = 10, 20, 50, and 100.A 10× increase in Q raises the largest full-block share from 51.9% to 53.1%; no configuration moves by more than 5.2 percentage points.Source: Figure 15 · p. 23, §B.4 · p. 23

C.1 Load-Failure Mapping

  • The load-failure mapping estimates one failure probability per 0.01-wide load bin using failures whose preceding block falls in that bin and the bin’s block count.The analysis counts every failure event and samples every 50th block at load below 0.5, multiplying that denominator count by 50; isotonic regression pools bins where failure rates do not rise with load.Source: §C.1 · p. 24

C.2 Cosmos and Polkadot Statistics

The authors reconstruct representative chain operating profiles from explorer data and on-chain measurements, including gas-based cross-chain shares and measured packet delays. Cosmos Hub and Osmosis remain above their safe update-rate bounds across the reported sampling intervals; Polkadot coupling is estimated with an upper-bound proxy.

C.2 Cosmos and Polkadot Statistics

  • Cosmos Hub’s inbound gas ratio is 21.6% and its total cross-chain share is 23.9%; Osmosis’s corresponding values are 24.8% and 26.1%.The estimates use uniformly sampled blocks because classifying every transaction requires transaction bodies and per-transaction gas.Source: §C.2 · p. 25
  • Across the reported sampling intervals, Cosmos Hub’s maximum stable update rate is 0.061–0.052 and Osmosis’s is 0.023–0.017, leaving both unstable at deployed rates.The intervals reflect resampling uncertainty in the inbound gas-share estimates.Source: §C.2 · p. 25
  • For Polkadot parachains, message counts serve as an explicit upper bound on coupling because per-message gas attribution is not publicly recoverable and the proxy overcounts multi-message actions.The study also derives operational profiles by combining explorer data with direct on-chain measurements and uses official documentation and code for update rates.Source: §C.2 · pp. 24–25
  • Measured mean inbound packet delays are 10.07 blocks for Cosmos Hub and 25.47 blocks for Osmosis; the model sets dmax to 10 and 25, respectively.The delay-weight shape is treated as a sensitivity parameter because recovering it requires pairing arrivals with source blocks and having archives for every source chain.Source: §C.2 · p. 25

D Protocol-Level Migation

The mitigation re-prices delayed inbound load using each chain’s own fee history to remove stale feedback. Exact compensation restores the monolithic stability bound, and experiments recover stable operating regimes.

D Protocol-Level Migation

  • The controller subtracts the gap between stale and current-price inbound load at each lag, using the chain’s own fee history and measured latency weights.The chain can deploy the rule without cross-chain coordination.Source: D Protocol-Level Migation · p. 26
  • Exact compensation cancels delayed self-feedback at every lag, independent of delay shape, restoring the monolithic self-feedback condition δ_i λ_max,i < 2.With estimated elasticities, the resulting gain uses measured on-chain inbound shares and estimated destination-side elasticities, which are not observable.Source: D Protocol-Level Migation · p. 26
  • Stability holds over an interval of γ around 1: underestimation leaves some over-correction, while overestimation flips the residual into reinforcing delayed feedback.At γ = 1 the estimate is exact; γ = 0 corresponds to plain EIP-1559.Source: D Protocol-Level Migation · pp. 26–27
  • All 28,314 tested configurations converge, while the maximum full-block share falls from 52.7% to zero.At inbound ratio 0.99, the compensated boundary recovers the monolithic bound; the shaded band marks the recovered regime.Source: Figure 16 · p. 27, D Protocol-Level Migation · p. 27
  • At δ = 0.125 in the 99%-inbound, elasticity-16 setting, γ ∈ [0.75, 1.030]; a 3% overestimate destabilizes, while up to 25% underestimation is tolerated.At δ = 0.05, the stable interval extends from γ = 0.405 to beyond the scanned upper limit of 1.5.Source: D Protocol-Level Migation · p. 27
  • Cosmos Hub is stable at deployed δ = 0.125 for γ ∈ [0.23, 2.66], and Osmosis at δ = 0.1 for γ ∈ [0.30, 2.88].These intervals are wider than the worst-case setting because both chains’ inbound ratios are near 25%, rather than 99%.Source: Table 3 · p. 27, D Protocol-Level Migation · p. 28
Loading 2610.23305v1…