On July 31, 2024, the Terra Luna network was hit by a major attack when a hacker exploited a vulnerability in the IBC module, resulting in the theft of $4 million in assets. This breach highlights the critical need for a robust mechanism to regulate the inflow and outflow of tokens, ensuring that transactions do not surpass a predefined threshold. By implementing this control, we can safeguard the network from similar attacks in the future.

This proposal aims to introduce a rate limit mechanism that carefully monitors token inflows and outflows within a fixed threshold. The goal is to prevent sudden spikes and mitigate the risk of malicious actors executing large-scale dump transactions, thus enhancing the overall security of the network.

Proposed Solution
A sliding time window will track the tokens transferred in and out of the chain. If the amount transferred exceeds 30% compared to the previous window, transactions will be blocked until the next time window.

Benefit

Implementing the IBC Token Ratelimit Module brings multiple benefits to the Terra Luna network. First, it significantly strengthens security by mitigating the risk of large-scale exploits similar to the July 2024 incident, ensuring that no single entity can drain liquidity in a short period of time. Second, it promotes network stability by smoothing token flows and reducing sudden volatility that could harm users and dApps. Third, it increases community confidence and trust in the chain’s resilience, which is critical for long-term adoption and growth. Finally, by introducing configurable parameters, the module provides flexibility for governance to adapt thresholds as market conditions evolve, ensuring the system remains both secure and efficient.

3. IBC Ratelimit Module
Architecture:

This module will store parameters in its settings to define the maximum token inflow/outflow per time window as well as the acceptable token rate changes. Specifically, if the token inflow in a time window exceeds a defined threshold compared to the previous window, incoming transactions will be considered invalid and must wait until the next window.

The time window will be defined as a series of consecutive blocks (the number of blocks can be defined and adjusted in the module parameters). At the end of each block, the earliest block in the window will be removed, and a new block will be added.

This structure ensures that the module tracks recent transactions while maintaining enough historical data for comparisons.

The module will handle IBC packets, checking if the packet is a transfer. If it is, the inflow/outflow of tokens will be updated. If the total or percentage of token flow exceeds the defined threshold, the packet will be considered to exceed the rate limit and will be reverted. If there are no transactions in the previous window, the module will compare the current transactions to a fixed base value (which can also be adjusted in the parameters).

State Structure:

1. To implement the rate limit with tokens, a proposal is needed to set the rate limit parameters.

type TokenRatelimitSpecs struct {
    Denom                 string 
    Channel               []string
}

2. For each IBC token, the module will maintain a state called Ratelimit in a key-value store:

type Ratelimit struct {
    prev_in          math.Int // Total tokens transferred in the previous time window
    prev_out         math.Int // Total tokens transferred out in the previous time window
    current_in       math.Int // Total tokens transferred in the current time window
    current_out      math.Int // Total tokens transferred out in the current time window
}

Additionally, the module will have specific parameters such as:
Param – Type : Value
Example
WindowSize – uint64: 10

MaxPercentSend- math.LegacyDec: “0.15”

MaxPercentRecv- math.LegacyDec: “0.15”

This proposal is intended to gauge community interest and gather feedback on the concept. If the community supports it, we (BLV Labs) will submit a follow-up technical proposal detailing the implementa