VOLUME_POLICY
Per-transaction min and/or max amount limits per denom. Used for dust prevention and large-transfer caps.
Enforces minimum and/or maximum transaction value limits for specific token denominations. Each transaction is evaluated independently against the limits — no rolling window, no cumulative tracking. For period-based cumulative limits, see PERIODIC_VOLUME_POLICY.
Parameter schema
``
json
{
"<denom>": {
"min_limit": "int (nullable)",
"max_limit": "int (nullable)"
}
}
`
is the chain-unit denomination (e.g. aokrw). Both limits are optional independently — pass only min_limit for dust prevention, only max_limit` for cap enforcement, or both. Values are big integers in the denom's smallest unit.Evaluation
For each token transferred in the transaction, the validator looks up the limits for that denom and checks: if
amount < min_limit → reject (VolumeBelowMinLimit); if amount > max_limit → reject (VolumeAboveMaxLimit). Multi-denom transactions are evaluated denom-by-denom.ReasonCodes on rejection
VolumeBelowMinLimit—min_limitnot met. Wallet UX: suggest a higher amount or block.VolumeAboveMaxLimit—max_limitexceeded. Wallet UX: suggest splitting the transfer or block.
Typical usage
- Single-tx caps:
max_limit: 100000000000000000000aokrw(= 100 OKRW = 100 × 10^18 aokrw) caps any one transaction at 100 OKRW. Combine withPERIODIC_VOLUME_POLICYfor daily/monthly caps that span multiple transactions. - Dust prevention: a small
min_limit(in aokrw) blocks tiny denial-of-service transactions targeting state bloat.