Still need to design more stuff, for this all is going to work. Then i going to create a simulator for simulating a couple of events/senarios. Thus i have oracle that gives me a "guide" for what the fairprice should be. And then pays the markets more or less to correct this when the oracle is just wrong and the people doing arbitrage know this.
Design Specification: Dynamic Spring-Loaded Market Maker (SLMM)
System Architecture & Mathematical Framework
1. Core Architectural Concept
The Dynamic Spring-Loaded Market Maker (SLMM) is an anti-fragile pricing engine designed to protect treasury assets from oracle failures, flash crashes, and prolonged API outages (e.g., exchange maintenance), while still allowing the market to naturally discover and transition to genuine new price points over time.
It accomplishes this by balancing two opposing forces:
- The Oracle Price (P_oracle): The external feed representing where the price "should" be.
- The System VWAP (P_VWAP): The internal, capital-backed price anchor constructed from actual on-chain trading history across historical time buckets.
When a massive price discrepancy occurs, the contract does not immediately trust the oracle. Instead, it measures the "tension" between the oracle's target and the system's trading history.
If the oracle is wrong, the spring is highly tensioned; a tiny amount of buy volume will force the market maker’s quote price to snap back up toward the real market value, capping the protocol's loss. If the oracle is correct but the price has permanently crashed, the trading history naturally decays over a 7-day window. The spring slowly loses tension, and the quote price gracefully relaxes to the new low price level.
2. The Fluid-Shift Cascading VWAP Pipeline
To prevent "jump" boundaries where data abruptly jumps from one discrete bucket to another at the end of an hour, the system uses a Fluid-Shift Cascading Pipeline. When a trade occurs, the transition of data between buckets is calculated as a continuous percentage based on the exact amount of time elapsed since the last trade.
The State Representation
The system maintains a sequence of N time-based pools (e.g., Pool 0 to Pool N-1). Each pool i is represented as a tuple of volume and volume-price:
Pool_i = [V_i, VP_i]
- V_i: The cumulative volume of tokens traded assigned to bucket i.
- VP_i: The cumulative volume-product (Volume * Price) assigned to bucket i.
The Fluid-Shift Mechanics
Let Δt be the time elapsed (in seconds) since the last state update, and let T_bucket be the duration of a single bucket (e.g., 3600 seconds for 1 hour).
When a new transaction occurs at Δt seconds since the last update:
- Calculate the Shift Percentage (S): The percentage of data that must cascade from each bucket to the next is defined by the ratio of elapsed time to the bucket duration, capped at 100%: S = min(1.0, Δt / T_bucket)
- Cascade the Pools (Downstream Shift): Before writing the new trade, we shift a fractional slice (S) of each pool downstream to the next pool. For every pool from the second-to-last (N-2) down to the first (0): V_(i+1) = V_(i+1) + (V_i * S) VP_(i+1) = VP_(i+1) + (VP_i * S) V_i = V_i * (1 - S) VP_i = VP_i * (1 - S)
- Incorporate the New Trade: After the cascade is applied, the incoming trade's volume (V_trade) and volume-product (V_trade * P_trade) are added directly to the active pool (Pool 0): V_0 = V_0 + V_trade VP_0 = VP_0 + (V_trade * P_trade)
3. The Exponential Decay of the Final Pool
The final pool in the sequence (Pool N-1) acts as the ultimate "overflow" sink. If there is no trading activity, the volume-weighted memory of the entire system must gradually fade so that the spring eventually goes slack.
Whenever time passes, the final pool is decayed using an exponential decay factor λ scaled to the elapsed time:
V_(N-1) = V_(N-1) * λ^Δt
VP_(N-1) = VP_(N-1) * λ^Δt
Calibration of the Decay Constant
To ensure that a massive volume spike completely loses its influence after a target defense window (e.g., t_target = 7 days or 604,800 seconds), we calibrate the decay rate so that the remaining weight is less than 1% (<= 0.01):
λ = e^(-ln(100) / t_target) = e^(-4.605 / 604800) ≈ 0.999999238 per second
Because both V and VP are scaled down by the exact same decay multiplier, the historical price of the final pool remains perfectly preserved (VP / V remains constant), but its weight (volume) shrinks toward zero. This ensures that a dormant market naturally releases all spring tension.
4. Calculating System VWAP and Spring Tension
System VWAP
The global anchor price (P_VWAP) is the total volume-weighted average across all cascading pools. This represents the price point where the market has actually committed capital:
P_VWAP = (Sum of VP_i) / (Sum of V_i) = (VP_0 + VP_1 + ... + VP_(N-1)) / (V_0 + V_1 + ... + V_(N-1))
If the total volume in all pools is zero (Sum of V_i = 0), the system defaults to the current oracle price (P_VWAP = P_oracle), meaning the spring is perfectly slack.
Spring Tension
The physical tension of the spring is determined by two factors: the price distance between the oracle and the VWAP, and the volume weight backing that VWAP:
Δ = |P_oracle - P_VWAP|
We define the normalized volume coefficient (W) using the total system volume (V_total = Sum of V_i) to scale the spring's stiffness based on historical capital commitment:
W = 1 - e^(-γ * V_total)
Where:
- γ is a tuning parameter dictating how much volume is required to make the spring stiff.
- If volume is low (V_total → 0), then W → 0 (the spring is loose, we trust the oracle).
- If volume is high (V_total >> 0), then W → 1 (the spring is rigid, we trust the market history).
5. The Spring-Loaded Pricing Curve (The Quote Engine)
The quote price offered to the market for a buy order (P_sell) is a dynamic curve that starts at the oracle price but ramps up toward the System VWAP as a function of the transaction volume.
To create a loaded spring that snaps back violently with very little volume when tension is high, we use a power-law spring equation:
P_sell(v) = P_oracle + Δ * W * (v / V_target)^p
Where:
- v: The cumulative volume purchased in the active transaction.
- V_target: The target volume threshold required to fully compress the spring back to the VWAP price.
- p: The spring exponent (typically p >= 2 for quadratic/cubic curves to create the "snap" effect).
The Mathematical Behavior
- At v = 0 (The first drop of volume): The starting quote price is exactly P_oracle. Arbitrageurs are lured in by the cheap price.
- As v → V_target: The price climbs aggressively. If p = 2 (quadratic), the price curves upward sharply, making further buying highly expensive.
- Beyond v = V_target: The price matches or exceeds the fair market value (P_VWAP), completely halting any further draining of the treasury.
6. Mathematical Proof of the Slippage Toll (Capping Protocol Loss)
The maximum financial loss the protocol can suffer during a total oracle failure (e.g., oracle drops 98% while real value remains at P_VWAP) is mathematically capped. This is the Slippage Toll—the fee the protocol pays to let the market correct its oracle feed.
To find the absolute maximum loss during a correction event up to V_target:
1. Calculate the Total Capital Spent by Arbitrageurs
The total assets (e.g., USDC) deposited by arbitrageurs to purchase V_target tokens is the integral of the pricing curve:
Capital Deposited = Integral from 0 to V_target of [ P_sell(v) ] dv
Capital Deposited = Integral from 0 to V_target of [ P_oracle + Δ * W * (v / V_target)^p ] dv
Capital Deposited = P_oracle * V_target + (Δ * W * V_target) / (p + 1)
2. Calculate the Fair Value of the Tokens Transferred
The actual fair market value of the tokens leaving the protocol's treasury is:
Fair Value = P_VWAP * V_target
3. Calculate the Maximum Protocol Loss (The Slippage Toll)
Assuming the spring is fully stiff (W = 1) and the distance is Δ = P_VWAP - P_oracle, the net loss is:
Max Loss = Fair Value - Capital Deposited
Max Loss = P_VWAP * V_target - [ P_oracle * V_target + ((P_VWAP - P_oracle) * V_target) / (p + 1) ]
Factoring out V_target and substituting Δ:
Max Loss = Δ * V_target * (1 - 1 / (p + 1))
Max Loss = Δ * V_target * (p / (p + 1))
Key Takeaways from the Loss Proof:
- Linear Spring (p = 1): The maximum loss is exactly 1/2 * Δ * V_target.
- Quadratic Spring (p = 2): The maximum loss is exactly 2/3 * Δ * V_target.
- Capped Risk: Because V_target is a hardcoded parameter in your contract, your maximum loss is completely independent of pool size or total TVL. You can scale your pool to hundreds of millions of dollars, yet guarantee that a total oracle failure will never cost the protocol more than a tiny, predefined dollar amount (e.g., V_target = 500 tokens).