A bridge's rate limit is not the loss cap — its refill speed is
xERC20 (ERC-7281) puts a per-bridge mint/burn rate limit on-chain, and the limit refills over time. That refill is the part that decides the real exposure: a 1M limit that refills in an hour lets an attacker drain it 24 times a day, so the true loss cap is not the limit but limit × (time-to-detect ÷ refill period). The number most designs quote is the least binding one.
Not a build — one calculation per bridge, then a table. List every bridge you would attach and read three numbers from each: the rate limit, the refill period (how long a fully-consumed limit takes to return), and your own realistic time-to-detect-and-halt. Compute max loss = limit × (time-to-detect ÷ refill period), rounded up to whole refills. Assume a 30-minute detection-and-stop and see which bridges still clear a loss you can survive; that number, not the headline limit, is the cap. Then flip it: for a loss you can survive, solve for the refill period the bridge would need, and notice that slowing refill blocks honest users (bridge queues). Source: xERC20 / ERC-7281 rate-limit design (per-bridge mint & burn limits, time-based refill); confirm the refill mechanics of each specific bridge against its own docs — implementations differ.
Why
A rate limit reads like a loss cap, and it is not one. "This bridge can mint at most 1M" sounds like the most it can lose is 1M. But the limit is not a lifetime budget — it refills, because a limit that did not refill would throttle the bridge to uselessness within a day of normal traffic. The moment it refills, the ceiling stops being 1M and becomes 1M per refill period, and an attacker who has compromised the mint path spends it on every refill until someone notices and halts. The loss is therefore governed by two numbers the limit never mentions: how fast the limit comes back, and how fast you can stop it.
So the honest exposure is a rate, not a level: limit × (time-to-detect ÷ refill period). A 1M limit refilling hourly, against a 6-hour detection lag, is a 6M exposure, not a 1M one. This is the operational floor under the-bridge-is-inside-the-token — that card asks who can halt minting when supply and custody disagree; this one asks how much is gone before they do. And it is the same shape as governance-capture-cost and the manipulation-cost number in the decision-market card: a safety property is not a property of the mechanism, it is a property of the mechanism at a given speed, and mechanisms are usually described without the speed.
The refill period is a safety/availability trade, and there is no setting that is comfortable on both sides. Slow the refill and the loss cap drops — but honest users hit the limit and wait in a queue, which is who-holds-the-mint and third-party-blast-radius felt as latency instead of risk. Speed it up and the bridge is smooth and the cap is effectively the whole reserve. The right answer is not a default; it scales with the size of what sits behind the bridge, and the only way to choose it is to compute the loss at your real detection time and read the queue it implies. A rate limit quoted without its refill period has quoted the least binding half.
How it works
The limit is not the cap
Quantity
What it says
Binding?
Rate limit (e.g. 1M)
Most that can mint before the limit is exhausted
Least — it refills
Refill period
How long a spent limit takes to return
Sets how often the limit can be re-spent
Time-to-detect-and-halt
Your own operational reality
The number nobody publishes
Max loss
limit × ⌈detect ÷ refill⌉
The actual cap
Same limit, three refill speeds, 6-hour detection
Rate limit
Refill period
Max loss @ 6h detect
1M
24h (once/day)
~1M
1M
6h
~1M–2M
1M
1h
~6M
The headline "1M limit" is identical across all three; the exposure spans 6×.
The trade you cannot escape
Refill
Loss cap
Honest users
Slow
Low
Blocked — bridge queues
Fast
≈ whole reserve
Smooth
There is no setting that is safe and frictionless; the right point scales with the value behind the bridge.
Related cards
the-bridge-is-inside-the-token (who can halt minting), who-holds-the-mint (mint authority), third-party-blast-radius (correlated failure), erc-8141 (native-issuance mechanics).
xERC20(ERC-7281)은 브리지별 발행·소각 한도(rate limit)를 온체인에 두고, 그 한도는 시간에 따라 회복(refill)됩니다. 실제 노출을 결정하는 것이 바로 그 회복입니다 — 1시간에 회복되는 100만 한도는 공격자가 하루 24번 소진할 수 있으므로, 진짜 손실 상한은 한도가 아니라 한도 × (탐지까지 시간 ÷ 회복 주기)입니다. 대부분의 설계가 인용하는 숫자가 가장 덜 구속력 있는 숫자입니다.
만드는 일이 아니라 브리지당 계산 한 번, 그리고 표입니다. 붙일 모든 브리지를 나열하고 각각에서 세 숫자를 읽습니다 — 한도(rate limit), 회복 주기(완전히 소진된 한도가 돌아오는 데 걸리는 시간), 그리고 본인의 현실적인 탐지·정지 시간. 최대 손실 = 한도 × (탐지까지 시간 ÷ 회복 주기)를 회복 횟수 올림으로 계산합니다. 30분 탐지·정지를 가정하고 감당 가능한 손실을 통과하는 브리지가 어느 것인지 봅니다 — 그 숫자가, 헤드라인 한도가 아니라, 상한입니다. 그다음 뒤집습니다 — 감당 가능한 손실에 대해 브리지가 가져야 할 회복 주기를 역산하고, 회복을 느리게 하면 정상 사용자가 막힌다(브리지 대기)는 것을 확인합니다. 출처: xERC20 / ERC-7281 한도 설계(브리지별 발행·소각 한도, 시간 기반 회복); 각 브리지의 회복 메커니즘은 구현이 다르므로 해당 문서로 확인.
왜
한도는 손실 상한처럼 읽히지만 상한이 아닙니다. "이 브리지는 최대 100만까지 발행"은 최대 손실이 100만처럼 들립니다. 하지만 한도는 평생 예산이 아니라 회복됩니다 — 회복 안 되는 한도는 정상 트래픽 하루 만에 브리지를 무용지물로 조이니까요. 회복되는 순간 천장은 100만이 아니라 회복 주기당 100만이 되고, 발행 경로를 탈취한 공격자는 누군가 알아채고 멈출 때까지 매 회복마다 그것을 씁니다. 그래서 손실은 한도가 언급조차 않는 두 숫자가 지배합니다 — 한도가 얼마나 빨리 돌아오는가, 그리고 당신이 얼마나 빨리 멈출 수 있는가.
따라서 정직한 노출은 수준이 아니라 속도입니다 — 한도 × (탐지까지 시간 ÷ 회복 주기). 6시간 탐지 지연에 대해 1시간마다 회복되는 100만 한도는 100만이 아니라 600만 노출입니다. 이것은 the-bridge-is-inside-the-token의 운영 하부 바닥입니다 — 그 카드는 공급과 커스터디가 어긋날 때 누가 발행을 멈추냐고 묻고, 이 카드는 그 전에 얼마가 사라지냐고 묻습니다. 그리고 governance-capture-cost, 결정시장 카드의 조작비용 숫자와 같은 모양입니다 — 안전 속성은 메커니즘의 속성이 아니라 특정 속도에서의 메커니즘의 속성이고, 메커니즘은 보통 그 속도 없이 서술됩니다.
회복 주기는 안전 대 가용성의 교환이고, 양쪽 모두에서 편안한 설정은 없습니다. 회복을 느리게 하면 손실 상한은 내려가지만 — 정상 사용자가 한도에 걸려 대기 줄에 섭니다. 이것이 위험 대신 지연으로 체감되는who-holds-the-mint와 third-party-blast-radius입니다. 빠르게 하면 브리지는 매끄럽고 상한은 사실상 준비금 전체가 됩니다. 정답은 기본값이 아니라 브리지 뒤에 있는 것의 크기에 따라 달라지고, 고르는 유일한 방법은 본인의 실제 탐지 시간에서 손실을 계산하고 그것이 함의하는 대기 줄을 읽는 것입니다. 회복 주기 없이 인용된 한도는 가장 덜 구속력 있는 절반만 인용한 것입니다.
동작 방식
한도는 상한이 아니다
양
말하는 것
구속력
한도(rate limit) (예: 100만)
한도가 소진되기 전 발행 최대치
가장 약함 — 회복됨
회복 주기
소진된 한도가 돌아오는 시간
한도를 다시 쓸 수 있는 빈도를 정함
탐지·정지 시간
본인의 운영 현실
아무도 공표 않는 숫자
최대 손실
한도 × ⌈탐지 ÷ 회복⌉
실제 상한
같은 한도, 세 회복 속도, 6시간 탐지
한도
회복 주기
최대 손실 @6h 탐지
100만
24h (하루 1회)
~100만
100만
6h
~100만–200만
100만
1h
~600만
헤드라인 "100만 한도"는 셋 다 똑같지만, 노출은 6배까지 벌어집니다.
피할 수 없는 교환
회복
손실 상한
정상 사용자
느림
낮음
막힘 — 브리지 대기
빠름
≈ 준비금 전체
매끄러움
안전하면서 마찰 없는 설정은 없습니다. 옳은 지점은 브리지 뒤에 있는 가치에 따라 커집니다.
관련 카드
the-bridge-is-inside-the-token(누가 발행을 멈추나), who-holds-the-mint(발행 권한), third-party-blast-radius(상관 장애), erc-8141(네이티브 발행 메커니즘).