Rules and Limits
What a Pakt controls and how its exact rules are identified.
A Pakt defines what your agent may do, how much it may spend, and the account conditions required before it acts. You can combine rules to fit your strategy. Every applicable rule must pass before Pakt authorizes an action.
What Rules Check
Rules govern permissions, spending, account conditions, and timing. The tables below cover the supported rule families. Their applicability depends on the venue and action; adding a rule does not enable an unsupported operation. Your draft's readable rule groups explain its limits. The exhaustive ALLOWED / NOT ALLOWED readback is available for a technical audit.
Markets and Permissions
| Rule | What you control |
|---|---|
| Allowed assets | The markets or assets your agent may use |
| Allowed protocols | The venues or protocols through which actions may be routed |
| Allowed action kinds | Which supported actions are permitted, such as trading, withdrawals, or sweeps |
| Allowed order sides | Which buy, sell, or reduce-only order effects are permitted |
| Margin mode | Which supported account margin modes are acceptable |
Permissions can allow any supported value or only listed values. An empty “only” list allows none. “Any” remains limited to the capabilities of the approved policy program. Omitting a required permission is not equivalent to allowing everything.
Spending, Prices, and Destinations
| Rule | What you control |
|---|---|
| Trade-size cap | Maximum dollar value of an individual trade |
| Notional budget | Maximum combined dollar value of actions checked together |
| Actions per request | Maximum number of actions checked together |
| Price protection | An acceptable price or effective exchange-rate band relative to the authenticated reference price |
| Network-fee cap | Maximum dollar value of the network fee for an action |
| Collateral movement | Maximum collateral outflow in a single action |
| Withdrawal destinations | The addresses to which withdrawals may be sent |
| Bitcoin payout destination | One exact destination for a Bitcoin sweep through BOB Gateway |
The batch budget and action count apply to one checked group. They do not accumulate across requests and cannot enforce a daily or rolling spending limit. A Hyperliquid request may contain up to ten IOC limit-order legs.
Account Conditions
| Rule | What Pakt checks against the projected account |
|---|---|
| Concentration cap | No single asset exceeds the chosen share of the account's gross value |
| Liquid reserve | Liquid funds represent at least the chosen share of gross value |
| Equity floor | Account equity is at least the chosen dollar amount |
| Leverage cap | Projected total position notional divided by authenticated account equity is within the chosen limit |
| Health floor | Equity is at least the chosen multiple of required maintenance margin |
For Hyperliquid, these rules start from a fresh account snapshot and add the worst-case risk from the current batch and every prior signed risk increase whose 30-second venue expiry has not elapsed. Risk-increasing orders are assumed to fill; risk-reducing orders are assumed not to fill. A batch that sells one asset and buys two therefore must remain valid even if only the buys fill. These checks use the venue-selected leverage to conservatively reserve initial margin and liquidity, but that venue setting is not itself capped by the Pakt. They do not automatically close positions when market conditions change.
Timing and Data
| Control | What it specifies |
|---|---|
| Trading hours | An inclusive daily UTC window for the authenticated action time |
| Pakt validity | The time after which the Pakt's rules may no longer authorize new actions |
| Request expiry | The maximum lifetime of a request where the venue enforces an expiry |
| Data freshness | The maximum age of the account snapshot relative to the authenticated action time |
| Accepted data sources | The sources whose signed price, action, and account-state evidence the Pakt accepts |
Trading hours constrain the time checked by Pakt. A request's expiry separately limits late submission where supported. An Ethereum token approval has no generic wall-clock expiry: once signed, it remains usable until its nonce is consumed. Disabling a Pakt does not invalidate an already released signature.
Closing a Hyperliquid Position
A venue-enforced reduce-only order can reduce an existing position without increasing exposure. Pakt first verifies the authenticated position is on the opposite side and that the batch's total reduce-only size does not exceed it. Only then is the close exempt from the trade-size cap, batch notional budget, price band, pending-exposure reservation, and account risk thresholds.
Other applicable checks still apply, including market and side permissions, action counts, trading hours, fees, margin mode, and expiry. A pure venue-enforced reduce-only batch receives a bounded five-minute emergency expiry window instead of the 30-second entry window, so proof and submission retries do not trap an exit. Mixed batches retain the 30-second bound. Asking the agent to “close” a position is not enough; every order in the batch must be reduce-only.
Selected Markets
Pakt's current Hyperliquid policy program supports eligible default and HIP-3 perpetual markets using USDC collateral. It supports cross mode on cross-capable markets and isolated mode only where Hyperliquid requires it. Pakts committed to the retained legacy policy program remain cross-only. To use a venue-forced isolated market, permanently disable the legacy Pakt, wait the five-minute replacement cooldown, then approve a newly drafted Pakt. See Activate and disable.
User-selected isolated mode on a cross-capable market is unsupported. Every open position on a cross-capable market must use cross mode, even when that market is absent from the order. Each cross-capable market named by the order must also have its selected mode set to cross. Closing an isolated position removes the account-wide open-position blocker, but does not reset that market's selected mode. Spot, delisted, and non-USDC markets are outside this execution path. Your agent uses list_hyperliquid_perp_markets to resolve current market identities before drafting.
BOB Gateway supports USDT-to-Bitcoin orders on Ethereum, with a finite token approval and a committed Bitcoin payout address. Approval and order creation are authorized separately. Pakt's broader rule vocabulary does not add other transaction types to either integration.
The Pakt Root
The Pakt root is a cryptographic identifier for the exact compiled rules and the policy program that evaluates them. Changing a limit, market, destination, trusted data source, or program creates a different root.
The readable ALLOWED / NOT ALLOWED summary helps you review those rules. The compiled artifact is authoritative; a chat message or template name cannot change an active Pakt.
Your Pakt signer's approval binds that root to your account and environment. Another account having the same rules does not grant it signing or wallet access.
To change a Pakt, draft a replacement and approve its new root.
For the encoding, typed payload, and canonical identity, see The Pakt Artifact.