Participant Limits

Participant limits let your platform cap how much a given participant can move over a given window. A limit is a ceiling on activity — scoped to a specific operation (trades, deposits, withdrawals), a specific currency, and a specific participant — and these endpoints let you set defaults, read where a participant currently stands, and adjust their limits on demand.

For engineers and PMs, this is your programmatic control over participant risk and exposure. Rather than enforcing thresholds in your own application logic, you can push them down to zerohash and let the platform track usage against them. That gives you a single source of truth for "how much can this user do, and how much have they already done" — useful for risk controls, tiered account levels, regulatory caps, and per-user overrides.

📘

Availability

Participant limits are only enabled for certain flows. If you don't see limits on your integration and want them, reach out to your zerohash contact to have the feature turned on.

How a limit is defined

Each limit is a small, self-describing object made up of:

  • Operation — what the limit applies to: trades, deposits, or withdrawals.
  • Currency — the asset the limit is denominated in (e.g. USD), so you can set different ceilings per currency.
  • Limit — the cap: the maximum notional allowed within the period.
  • Balance — how much of that cap remains right now.
  • Period — the rolling window the cap applies over, in hours (for example 24 for daily, 720 for ~30 days). A period of 0 means a lifetime limit.

The period is a rolling window: as activity ages past it, that value is credited back into the available balance. Because operation, currency, and participant are all independent dimensions, you can express fine-grained policies — e.g. a $10k daily withdrawal cap in USD for one participant while trades are uncapped.

Setting defaults

Platforms can configure default limits that apply to participants out of the box, so new participants inherit a sensible policy without a per-user setup step. Defaults are your baseline; per-participant changes layer on top. Platforms must request default configurations to be configured by their zerohash Account Manager.

Reading limits

Query a participant's limits on demand to see both their configured ceilings and their remaining balances. This is the call to make before allowing an action, or to show a user how much headroom they have left in the current window.

Adjusting limits

Patch a participant's limits on demand to raise, lower, or override them — for example when a user upgrades an account tier, clears additional verification, or needs a temporary exception. Changes take effect for subsequent activity.