# The Countermeasure 2.3 : Conversion Mechanism Formula Specification

**URL:** <https://gov.riverai.inc/t/the-countermeasure-2-3-conversion-mechanism-formula-specification/25>\
**Category:** Proposal Lab\
**Tags:** countermeasure\
**Created:** [November 18, 2025, 4:51am UTC](https://gov.riverai.inc/t/the-countermeasure-2-3-conversion-mechanism-formula-specification/25 "2025-11-18T04:51:02Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![River](https://yyz2.discourse-cdn.com/flex008/user_avatar/gov.riverai.inc/river/32/13_2.png) [@River](https://gov.riverai.inc/u/River)\
**Post date:** [November 18, 2025, 4:51am UTC](https://gov.riverai.inc/t/the-countermeasure-2-3-conversion-mechanism-formula-specification/25/1 "2025-11-18T04:51:02Z")

</div>

## 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}}

---

<div class="post-metadata">

**Author:** ![SabTheTrader](https://yyz2.discourse-cdn.com/flex008/user_avatar/gov.riverai.inc/sabthetrader/32/34_2.png) [@SabTheTrader](https://gov.riverai.inc/u/SabTheTrader)\
**Post date:** [November 18, 2025, 1:32pm UTC](https://gov.riverai.inc/t/the-countermeasure-2-3-conversion-mechanism-formula-specification/25/2 "2025-11-18T13:32:06Z")

</div>

谢谢公开公式规范。

公式有很清晰地跟大家展示了River的防御，确保即便恢复得慢，系统也不会被打入无法挽回的深渊。关于极端的情况昨晚AMA Naka也有回复说有在进行测试中。

但我暂时还没有看到如果Thalf过长的应对。比如我会好奇，当一个极端的Thalf(如7天）和一个短的Pepoch填满的情况，r(t)恢复到90%需要多长的时间？

因为如果届时时间过长，是否会超过用户的耐心阈值，导致届时保护了系统，但是流失了部分用户？团队是否有考虑若Thalf过长的过程中，加入奖励机制？还是团队届时会通过DAO投票或管理员多签来修改缩短Thalf？

希望在接下来的文档里，可以看到相关的回答。

Thank you for your time. 🙂  
Hope River being better and better. 🍀

---

<div class="post-metadata">

**Author:** ![Riverlaoge](https://avatars.discourse-cdn.com/v4/letter/r/b3f665/32.png) [@Riverlaoge](https://gov.riverai.inc/u/Riverlaoge)\
**Post date:** [November 18, 2025, 3:47pm UTC](https://gov.riverai.inc/t/the-countermeasure-2-3-conversion-mechanism-formula-specification/25/3 "2025-11-18T15:47:49Z")

</div>

> [@River](#):
>
> ymbol Definition Amount of PTS converted in a single transaction Maximum PTS allowed per single conversion Maximum PTS allowed to convert within the current epoch Conversion progress variable ranging from to Conversion rate before the current conversion begins Conversion rate after processing Conversion rate after applying time-based recovery Target baseline conversion rate determined by time schedule Penalty coefficient controlling curve steepness RIVER output amount received from converting Half-life constant defining recovery speed Recovery rate constant derived from Current timestamp Timestamp of the previous conversion trigger Cumulative conversion within the current epoch Time period with a fixed conversion budget

用个聪明公式管住代币转换，别让短期玩家抢光饭碗，匀点给咱们长期粉丝，比如我。

---

<div class="post-metadata">

**Author:** ![HiSeven](https://yyz2.discourse-cdn.com/flex008/user_avatar/gov.riverai.inc/hiseven/32/23_2.png) [@HiSeven](https://gov.riverai.inc/u/HiSeven)\
**Post date:** [November 18, 2025, 6:10pm UTC](https://gov.riverai.inc/t/the-countermeasure-2-3-conversion-mechanism-formula-specification/25/4 "2025-11-18T18:10:18Z")

</div>

RIVER 最新的转换机制引入了积分速率衰减和半衰期恢复，有效抑制大额集中转换、MEV 利用和鲸鱼套利，同时通过单笔和时期上限保证系统稳健。边际收益递减与时间恢复机制兼顾长期参与和公平性，公式透明可验证，整体提升了生态安全性和抗攻击能力。但机制较复杂，普通用户理解和操作门槛较高，需要社区配套教育与工具支持。总体来看，这是一个面向长期稳健发展的前瞻性升级方案。

---

<div class="post-metadata">

**Author:** ![0xmywallet](https://yyz2.discourse-cdn.com/flex008/user_avatar/gov.riverai.inc/0xmywallet/32/25_2.png) [@0xmywallet](https://gov.riverai.inc/u/0xmywallet)\
**Post date:** [November 18, 2025, 11:39pm UTC](https://gov.riverai.inc/t/the-countermeasure-2-3-conversion-mechanism-formula-specification/25/5 "2025-11-18T23:39:47Z")

</div>

I still need the team to clarify this issue. After converting River Points into River Staking, can I unstake at any time and convert it back into River?

---

<div class="post-metadata">

**Author:** ![Roper](https://avatars.discourse-cdn.com/v4/letter/r/ac91a4/32.png) [@Roper](https://gov.riverai.inc/u/Roper)\
**Post date:** [November 19, 2025, 4:05am UTC](https://gov.riverai.inc/t/the-countermeasure-2-3-conversion-mechanism-formula-specification/25/6 "2025-11-19T04:05:44Z")

</div>

So…. in the end,

is it still 1 River Point = 0.03 River?

is it lower, is that why the team has decided to do buybacks?

---

<div class="post-metadata">

**Author:** ![River](https://yyz2.discourse-cdn.com/flex008/user_avatar/gov.riverai.inc/river/32/13_2.png) [@River](https://gov.riverai.inc/u/River)\
**Post date:** [November 19, 2025, 9:18am UTC](https://gov.riverai.inc/t/the-countermeasure-2-3-conversion-mechanism-formula-specification/25/7 "2025-11-19T09:18:33Z")

</div>

Will update in the latest AMA recap