Conversion Mechanism Architecture: Integral Rate Decay and Half-Life Recovery
1. Overview
This chapter introduces the RIVER protocol’s conversion mechanism designed for converting PTS to RIVER in a scalable, incentive-aligned, and attack-resilient manner.
Traditional linear conversion models suffer from splitting attacks, MEV exploitation, flash conversions by whales, and unstable rate behavior that accelerates conversion rush cascades.
To address these vulnerabilities, RIVER introduces a novel Integral Conversion Model with Half-Life Recovery, which guarantees:
- The more someone converts, the worse the marginal rate becomes
- Time-based recovery prevents panic extraction behavior
- Splitting transactions provides no gain
- Conversion rate decays smoothly and predictably
- Whales and robots cannot exploit timing or granularity
- System-level controls through P_{one} and P_{epoch}
2. Design Goals
| Objective | Achieved by |
|---|---|
| Conversion penalty increases with depth | Exponential marginal rate decay |
| Prevent conversion rush | Natural diminishing returns |
| Eliminate splitting or MEV arbitrage | Continuous integral-based output |
| Restore system health after stress | Half-life recovery curve |
| Protect against flash conversion | P_{one} per-transaction cap |
| System pacing control | P_{epoch} epoch ceiling |
3. Model Formulation
Variable Definitions
| Symbol | Definition |
|---|---|
| P_{in} | Amount of PTS converted in a single transaction |
| P_{one} | Maximum PTS allowed per single conversion |
| P_{epoch} | Maximum PTS allowed to convert within the current epoch |
| p | Conversion progress variable ranging from 0 to P_{in} |
| r_{prev} | Conversion rate before the current conversion begins |
| r_{new} | Conversion rate after processing P_{in} |
| r(t) | Conversion rate after applying time-based recovery |
| r_{base}(t) | Target baseline conversion rate determined by time schedule |
| k | Penalty coefficient controlling curve steepness |
| R_{out} | RIVER output amount received from converting P_{in} |
| T_{half} | Half-life constant defining recovery speed |
| \lambda | Recovery rate constant derived from T_{half} |
| t | Current timestamp |
| t_{last} | Timestamp of the previous conversion trigger |
| \sum P_{in} | Cumulative conversion within the current epoch |
| epoch | Time period with a fixed conversion budget |
3.1 Single Conversion Limit
0 < P_{in} \le P_{one}
3.2 Marginal Conversion Rate
r(p) = r_{prev} \cdot e^{-k \cdot p / P_{epoch}}
3.3 Conversion Output (Integral Calculation)
R_{out} = \int_0^{P_{in}} r(p)\, dp
Closed-form:
R_{out} =
r_{prev} \cdot \frac{P_{epoch}}{k}
\cdot \left(1 - e^{-k \cdot P_{in} / P_{epoch}}\right)
3.4 Rate Update After Conversion
r_{new} = r_{prev} \cdot e^{-k \cdot P_{in} / P_{epoch}}
3.5 Half-Life Recovery
r(t) =
r_{new} +
(r_{base}(t) - r_{new})
\cdot \left(1 - e^{-\lambda \cdot (t - t_{last})}\right)
Half-life constant:
\lambda = \frac{\ln 2}{T_{half}}
3.6 Dynamic Base Rate (linear example)
r_{base}(t) =
r_{start} +
\frac{r_{end} - r_{start}}{t_{end} - t_{start}}
\cdot (t - t_{start})
3.7 Epoch Ceiling
\sum P_{in} \le P_{epoch}
4. Execution Flow
r_{prev} \xrightarrow{\text{recovery}} r(t) =
r_{prev} +
(r_{base}(t) - r_{prev})
\cdot (1 - e^{-\lambda (t - t_{last})})
P_{in} = \min(\text{user request}, P_{one}, P_{epoch} - \sum P_{in})
R_{out} =
r(t) \cdot \frac{P_{epoch}}{k}
\cdot \left(1 - e^{-k P_{in}/P_{epoch}}\right)
r_{new} =
r(t) \cdot e^{-k P_{in}/P_{epoch}}
