Alpha Testing
Set up a BTC and ETH Pakt, run a recurring strategy, and test its refusal boundaries.
Use these three prompts to exercise the complete alpha flow. You need full access, completed Hyperliquid setup, and an agent with both Pakt and a Hyperliquid client. Use small limits and amounts you are prepared to trade. Hyperliquid perpetuals are leveraged derivatives, not spot purchases.
Replace the values in angle brackets before sending a prompt. A Pakt constrains each request; the recurring task contains the strategy and schedule. Per-request limits do not cap cumulative trading across scheduled runs.
1. Set Up a BTC and ETH Pakt
An account can have only one active Pakt. To replace one, follow Activate or Disable a Pakt: disable the current Pakt, then wait five minutes before activating its replacement.
Help me set up a Hyperliquid Pakt for a simple BTC and ETH perpetuals
strategy. Allow only BTC and ETH immediate-or-cancel orders. Before drafting,
ask me for the maximum order size, maximum actions per request, price-protection
band relative to the authenticated reference price, projected-account leverage
cap and other account-risk thresholds, and whether the strategy may open
positions, close them, or both. Do not describe the Pakt leverage cap as a cap
on Hyperliquid's venue leverage setting. Keep the limits small for alpha testing.
Compile one exact draft, show me its readable rules, and give examples of an
allowed action and refusals for the wrong asset, excessive size, and excessive
price. Do not activate it automatically. After I approve the rules in chat,
first list my Pakts. If another root is active, stop and direct me to disable it
and wait five minutes; do not prepare replacement activation yet. Otherwise,
prepare the activation and give me the dashboard review link. I will review the
account, environment, rules, and root there and enable it with my Pakt signer.
Afterward, list my Pakts, confirm that the same root is active, and show its exact
pakt_root in a copyable form for step 2. Never ask for or handle a seed phrase or
private key.Open the link the agent returns, select Review and enable, check every rule,
then select Enable Pakt and approve with your Pakt signer. Continue only when
the agent confirms that the exact root you reviewed is active. Copy that
pakt_root into the next two prompts.
2. Start a Recurring Trading Agent
Create a recurring task named "BTC and ETH alpha strategy" using the scheduler
available in this agent environment. Run it <schedule, including time zone> and
apply this strategy: <one-sentence deterministic BTC/ETH strategy>. Use no more
than <amount> per order. The Pakt root I reviewed is <pakt-root>. Show me the
final schedule, strategy, and exact root and get my confirmation before enabling
the task. If this environment cannot create a recurring task, stop and tell me
instead of claiming that it was created.
On every run, refresh Pakt execution context and require an active_pakts entry
whose pakt_root exactly equals <pakt-root>. If execution context is unavailable
or that exact root is absent or inactive, stop and report the problem; never
select or substitute another root. Fetch fresh account and market data with the
connected Hyperliquid client, evaluate only the strategy above, and prepare
exactly one IOC order. Pakt must validate the order; do not ask it to plan or
repair one. If Pakt refuses the request, stop that run and report the reason
without retrying or changing the order. If Pakt signs it, submit the returned
request unchanged with the existing Hyperliquid client, report the Pakt decision
and venue result separately, and record the supported terminal result. Do not
treat per-order or per-request limits as a cumulative schedule budget, and do
not create catch-up trades after a missed or refused run. Never widen the Pakt,
bypass it, or introduce another signing path.After enabling it, check the agent's scheduled-tasks view and confirm the name, next run time, time zone, and enabled status. The exact location and available scheduling features depend on the agent environment.
3. Test the Refusal Boundaries
Pause the recurring BTC and ETH alpha task and confirm that no Pakt operation is
in progress. The Pakt root I reviewed is <pakt-root>. Require that exact root to
be active or stop. Then help me test it with three deliberately invalid,
position-opening, non-reduce-only Hyperliquid orders, one at a time: an order for
a supported asset outside the Pakt, a BTC or ETH order above its maximum size,
and a BTC or ETH order whose limit price is outside its price-protection band.
Do not use reduce-only orders; they are exempt from the size cap and
price-protection band and cannot test those boundaries.
Before requesting authorization, show each exact test order, <pakt-root>, and
the reviewed rule boundary it is intended to cross. Keep every other field valid
and use the smallest practical test values. Wait for my confirmation, then
request authorization sequentially. Do not submit any returned request to
Hyperliquid. Record each exact decision, reason, and receipt ID. A refusal is the
expected result, but its reason may be generic: compare the order with the rules
reviewed in step 1 and do not claim that the refusal proves which rule fired. Do
not repair, retry, or bypass a refusal. If any test is signed or returns a
recovery-required result, stop immediately, leave the recurring task paused, and
show me the exact response for investigation.You are done when all three requests are refused, each exact order independently falls outside its intended reviewed rule, and no request was submitted. See Closing a Hyperliquid Position for the reduce-only exemptions and Execution and Retries for unexpected results. Resume the recurring task only after reviewing the results and confirming its exact root and next run time.