Withdrawal Rate Limiter

How the protocol caps fund outflows to survive an exploit — burst window, linear refill, bypass addresses, and owner force reset.

Smart contract exploits rarely drain a vault instantaneously. Most attacks are iterative: the attacker finds a bug, calls the vulnerable function repeatedly, and accumulates the stolen funds over several transactions. The window between the first suspicious withdrawal and a full drain is often minutes or hours — long enough to act, if the protocol can create that window.

The withdrawal rate limiter is Perpl's circuit breaker. It places a hard cap on how quickly funds can leave the protocol, expressed as a percentage of total value locked per hour. In a hack, the attacker is limited to draining at most that percentage per cycle, regardless of how many times they call the withdraw function. Operators have at least one full cycle — typically 60 minutes — to detect the exploit, freeze the attacker, and begin recovery before the vault is meaningfully depleted.

The Hourly Limit

Every withdrawal attempt is checked against a live allowance. That allowance is constrained by an hourly limit, computed from two protocol parameters:

The first term scales the limit with the vault: a larger protocol allows more absolute throughput. The floor ensures the limit never drops so low that legitimate users are routinely blocked — even at modest TVL, at least $1M per hour can flow out. Both parameters are owner-configurable and can be adjusted as the protocol scales.

Critically, the hourly limit is recomputed at the start of each new cycle from current TVL. If an attacker drains the vault across multiple cycles, each subsequent cycle starts with a lower TVL, reducing the absolute limit. At $10M TVL the limit is $1M/hr. After draining $4M over four cycles, TVL is $6M and the computed rate is $600k/hr — but the floor of $1M still applies. The floor prevents the "spiral" where a small account becomes effectively unwithdrawable.

Burst Window and Linear Refill

The hourly limit is not made immediately available in full. Instead, the protocol splits each cycle into two phases. This prevents an attacker from draining the entire hour's allocation in a single transaction at the start of the cycle.

At the start of a new cycle, the contract makes approximately 25% of the hourly limit available upfront as the burst amount. This accommodates normal user behavior — most withdrawals are routine and well within a reasonable burst window. After that burst is consumed or the first 15 minutes elapse, the remaining 75% unlocks gradually, block by block, at a rate of hourlyLimit / 8,571 tokens per block (8,571 blocks = one hour at Monad's 0.42 s block time).

The contract tracks when the current burst window ends via _wrlsLastBlock. If a withdrawal arrives before that block, no additional refill is added — the allowance is exactly what was set at cycle start. Once past _wrlsLastBlock, the contract accrues the elapsed blocks' worth of refill before checking the request.

How Cycles Work

The rate limiter is stateful. A "cycle" is a 60-minute period initialized when the first withdrawal arrives after the previous cycle expires. The contract does not proactively start or end cycles — it is entirely reactive, updating state only when a withdrawal is attempted.

On each withdrawal call, the contract first determines which phase it is in:

No active cycle (block > _wrlsExpiryBlock): A new cycle starts. The hourly limit is computed from current TVL, the per-block rate is set, and the burst allowance is loaded. The expiry block is set 8,571 blocks (one hour) in the future.

Within burst window (block ≤ _wrlsLastBlock): No refill is accrued. The allowance is exactly what was set at cycle start, minus any withdrawals already made.

Linear refill phase (_wrlsLastBlock < block ≤ _wrlsExpiryBlock): The contract adds (block − _wrlsLastBlock) × perBlock to the allowance and advances _wrlsLastBlock. The withdrawal is then checked against this updated allowance.

Surviving an Exploit

The rate limiter's primary purpose is to bound the damage from a contract exploit. Without it, an attacker who discovers a reentrancy bug or unauthorized withdrawal vector can drain an entire vault in a single block. With it, the maximum damage in any 60-minute window is capped at the hourly limit — typically 10% of TVL.

The burst window creates an additional chokepoint. Even at cycle start, when the allowance is highest, an attacker can only extract the burst amount (~25% of the hourly limit) before the rate limiter forces them to wait for the linear drip. Their maximum theoretical throughput from a cold start is:

The remaining 75% of any given cycle's capacity is locked behind the block-by-block refill. An attacker willing to wait can eventually claim it — but waiting is dangerous. Each passing block is another block during which monitoring systems can detect anomalous outflow, on-chain alerts can fire, and operators can invoke the bypass lockdown or force reset.

In practice, an attacker cannot drain the maximum each cycle. Partial refill, retry failures, and gas costs all reduce real throughput. The interactive simulation shows a realistic attack pattern: the burst is taken immediately, subsequent attempts are blocked, and the attacker can only extract smaller amounts as each cycle's linear refill trickles in.

Bypass Addresses

Some protocol actors need to move funds without touching the rate limiter. The operator of a market-making vault needs to rebalance. An automated liquidation keeper needs to sweep collateral immediately. A protocol treasury contract may manage funds on a schedule that doesn't align with 60-minute cycles.

For these actors, the owner can designate bypass addresses. When _wrlsBypassAddrs[msg.sender] is true, the rate limiter check is skipped entirely — the withdrawal proceeds directly without consulting or modifying any of the four state variables. The bypass is per-address and owner-controlled.

Because bypass transactions do not touch the allowance, they also do not affect the refill schedule. A large bypass withdrawal by a market maker does not consume cycle capacity — subsequent non-bypass users still have the full allowance available.

Owner Force Reset

When operators detect an exploit in progress and have frozen the attacker's account-level access, the rate limiter may still be in mid-cycle state with depleted allowance. Legitimate users — who had nothing to do with the attack — may find themselves unable to withdraw because the attacker consumed the cycle's capacity. The force reset addresses this.

Calling forceResetWithdrawRateLimit() zeroes all four state variables:

The next withdrawal after a force reset will trigger a completely fresh cycle, computed from current TVL at that moment. This means legitimate users immediately regain access to a full burst window. The reset is instantaneous and requires no waiting for the current cycle to expire.

In a typical response sequence: (1) exploit detected, (2) attacker's accounts frozen at the position/account level, (3) force reset called to restore withdrawal capacity for legitimate users, (4) investigation begins. The rate limiter served its purpose — it bought the time needed to execute steps 1–3.

TVL Scaling and Deposits

Because the hourly limit is a function of current TVL, the limit grows as the protocol grows. A vault with $50M TVL at 10% can sustain $5M/hr in legitimate withdrawals — appropriate for a large protocol with significant trading volume. A smaller vault at $2M is capped at the $1M floor rather than $200k/hr, keeping the protocol usable at all sizes.

Deposits made mid-cycle do not affect the current cycle's parameters. The per-block rate and expiry block are fixed at cycle start and unchanged by incoming deposits. However, when the current cycle expires and the next withdrawal triggers a new cycle, the hourly limit is recomputed from the new (higher) TVL. A $3M deposit during a $10M-TVL cycle will raise the next cycle's limit from $1M to $1.3M/hr.