PERIODIC_VOLUME_POLICY
Cumulative transaction-volume limits per denom over a sliding window (24h, 30d, etc.).
Tracks cumulative transaction volume per sender per denom over a configured time window and rejects transactions that would push the running total over the limit. Distinct from VOLUME_POLICY, which checks each transaction independently. Used for daily / monthly transfer caps and Travel-Rule–compliant thresholds.
Parameter schema
``
json
{
"<denom>": {
"limit": "int",
"period": "24h | 7d | 30d | <duration string>"
}
}
`
is the chain-unit denomination (e.g. aokrw). limit is the cumulative ceiling in the denom's smallest unit. period is a Go duration-style string (24h, 30d, 168h, etc.). The window is sliding — at any block, the policy looks back period` seconds and sums the sender's outgoing transactions of that denom.Evaluation
For each token transferred:
1. Compute
2. If
3. Otherwise admit, and the new transaction's amount counts against future evaluations until it ages out of the window.
The accounting is per-sender, not per-recipient. Sending to many different recipients does not reset the counter.
1. Compute
usedSoFar = sum of sender's outgoing transactions in this denom over the past period.2. If
usedSoFar + amount > limit → reject (PeriodicVolumeAboveLimit).3. Otherwise admit, and the new transaction's amount counts against future evaluations until it ages out of the window.
The accounting is per-sender, not per-recipient. Sending to many different recipients does not reset the counter.
ReasonCode on rejection
PeriodicVolumeAboveLimit — wallet UX should show "daily/monthly limit reached; resets at <next window boundary>".Typical usage
- Travel-Rule thresholds (e.g.
limit: 1,000,000 OKRW per 24hfor un-attested users — most jurisdictions require additional reporting above this). - Anti-fraud / pace limits (e.g. cap a hot wallet at 10 M OKRW per 30d to catch compromise faster).
- Combined with
EAS_POLICY: the EAS-conditional variantOKRW_EAS_PERIODIC_VOLUME_LIMIT_POLICYlets you have different limits for attested vs un-attested users, which is the more common production setup.