Why a checklist, and what it is not
Last post in the Agentic Trading on Perps series. Earlier posts took failure modes apart; this compresses them into one pre-deploy pass.
Limits first: a checklist does not make a leveraged position safe, and passing every item says nothing about profitability. It also does not teach setup: the execution steps for LeverUp’s gasless / 1CT hosted-agent mode are covered in the walkthrough How to Build a Grok Bot Trading Agent on LeverUp — that tutorial is one setup path, not a claim that consumer assistants ship a LeverUp connector. Nothing here implies a LeverUp connector, partnership or endorsement for any consumer assistant. For the basics, start with the perpetual futures learning path.
Mechanism claims cite LeverUp documentation as read for earlier posts in this series. Anything marked as my reading is inference. Docs change — treat numbers as a snapshot and re-read the live pages.
1. Permissions scope
Check: what the agent’s key can do, listed action by action.
LeverUp’s gasless overview describes a hosted-agent mode in which a backend-held key can express trading intent but, per the docs, cannot transfer tokens or withdraw. The authorization docs say permissions are a bitmask set when the trader authorizes the agent, and that the maximum integer value is a wildcard that grants everything, including actions added later.
Before deploy, confirm:
- the agent holds an explicit mask, not the wildcard;
- the mask contains only the actions the strategy needs (for a first run, consider whether it needs margin removal at all);
- revocation is rehearsed from the main wallet;
- read-only work (prices, positions, history) uses the read-only REST API, which the docs describe as needing no authentication, so a monitoring component holds no trading key.
A narrow mask limits which actions exist, not how large they can be. Detail: scoped keys and delegated access, and the general argument in AI Trading Agents Need Scoped Permissions.
2. Guardrail parameters
Check: the numbers that bound size, written down and enforced outside the model.
A prompt that says “keep leverage modest” is a request. A guardrail is a config value the model cannot write, checked by deterministic code before any order leaves. The pre-trade checks post separates four: maximum leverage, maximum notional (per position and in total), maximum loss over a window, and human-confirm gates.
Two LeverUp mechanics change how you write them. Per the opening-a-position docs, adding to a position on the same pair, in the same direction, with the same margin token merges into the existing one, with quantity and margin summed. A check on the new order alone can pass an order that pushes the merged position past your cap, so evaluate the post-merge position. And the venue can reject an order, for example when open-interest caps pause new positions in a direction, so “rejected” must be a normal outcome that is logged, not retried with a reworded request until it passes.
Before deploy, confirm every parameter has a value, an owner, and a change process that sits outside the agent’s session. The values come from your risk budget; this post suggests none.
3. Funding and holding costs
Check: the agent counts time-based costs in its own accounting.
The Holding & Funding Fees page describes a holding fee that accrues per second on notional at a rate locked when the position opens, and a funding fee in which the crowded side pays the other and the rate is zero when open interest is balanced. The same page says both settle when the position closes and are shown combined as “Funding Fee.”
A faster polling loop does not shorten a position, so it does not reduce either fee. For 1x to 100x positions, the Fee Overview lists base opening and closing fees of 0.03% of position size each, with a 5% discount when opening and closing with LVUSD or LVMON. High-leverage tiers have different fee rules, so a churning loop must account for the applicable schedule on each round trip.
Before deploy, confirm:
- net PnL is computed after fees and funding, not from price alone;
- the agent has a maximum holding duration or a forced review;
- the strategy is tested against the fee stack, including paying funding rather than receiving it.
Detail: funding and holding costs for an always-on agent.
4. Liquidation distance, refreshed
Check: the agent recomputes its distance to liquidation on every risk check instead of reading a number saved at entry.
The liquidation docs say a position can be liquidated when price reaches the liquidation price, or when collateral cannot cover outstanding fees. The formula includes Close, Holding and Funding fees, and a loss rate set per pair; the docs list 85% for most pairs and 80% for the high-leverage pairs and a few others. Because holding and funding accrue while a position is open, the liquidation price is an output of a formula with time-varying inputs, not a constant.
The AnyCollateral docs explicitly describe collateral-price risk: when volatile collateral falls in price, its USD value shrinks, effective leverage rises, and the position moves closer to liquidation.
Before deploy, confirm:
- the loss rate is read per pair from the live page;
- the check uses current quantity, since adds and partial closes change it;
- below a minimum distance, the agent stops adding risk and alerts a human.
None of this removes liquidation risk. It aligns the agent’s picture of the risk with the venue’s. Detail: liquidation and fee drift for overnight positions, and the mechanics in How Liquidations Work on LeverUp.
5. Session hours for stock perps
Check: whether any market in the agent’s allowed list has hours, and what the agent does at the edges.
LeverUp’s Trading RWA page lists, for MAG7 equity perps, Monday to Friday trading hours of 9:31 AM to 3:59 PM Eastern Time, weekends closed, and holidays following the NYSE schedule. It says new positions can only be opened during market hours and that positions above 10x leverage are force-closed in full at market close, while positions at 10x or below can be held across off hours. During off hours the page lists adding collateral, cancelling an order and editing TP/SL as allowed, and opening, closing, creating orders and liquidation as not allowed.
Before deploy, confirm:
- a session check is a hard pre-trade gate, using the America/New_York time zone rather than a fixed UTC offset (design advice, not a docs claim);
- the allowed-markets list is explicit, since the page names MAG7 equities as the starting set;
- the agent has a decision, made in advance, for positions above 10x as the close approaches;
- “close is disabled” is a known off-hours state, not an error to retry.
The docs do not state the force-close clock time within the window or early-close handling, so do not hard-code a guess. Detail: stock perps hours and force-close.
6. Collateral and the dual-price risk
Check: the margin token, if it is not a stablecoin.
With AnyCollateral, a position margined in a volatile token has two prices that can hurt it: the market the agent is trading and the collateral itself. The liquidation documentation calculates margin value from the margin amount and the margin asset’s price. Confirm the current supported-token list in the trading UI; see tokenized stocks as margin for related risk framing. Decide whether the agent may use non-stable margin; if so, fold the collateral’s price into the item 4 distance check.
7. Oracle-referenced pricing
Check: the agent’s price inputs are not mistaken for the price the venue uses.
LeverUp uses a protocol-managed virtual liquidity system powered by the VMMV, where trades reference oracle pricing while execution, settlement and risk management are handled at the protocol layer. The opening-a-position docs say price feeds are delivered on demand using Pyth low-latency oracles, with a pull oracle that triggers price retrieval when a request is initiated. Our Pyth Pro oracle upgrade post covers that area further.
For an agent, a price read from a chart, a news feed or a social post describes the market; it is not the reference the venue uses, and the two can differ at execution. Before deploy, log both values side by side and decide what the agent does when they diverge.
8. Human takeover conditions
Check: a written list of events after which the agent stops and a person decides.
Write the triggers down before deploy, not after the first surprise. Candidates from the earlier posts:
- a guardrail rejection repeats, or the agent proposes a change to its own limits;
- liquidation distance falls below the minimum from item 4;
- a held market nears its session close (item 5) with leverage above 10x;
- realized loss reaches the window limit from item 2;
- an order result differs from the agent’s price reading by more than a tolerance you set (item 7);
- a request to reduce margin on an open position, or any action outside the granted permission bits;
- the agent’s data source, model or tool set changes.
Approval flows also differ by design. Meta Muse, connectors and human approval compares delegated, confirm-each-action setups with a hosted agent that signs on its own within its authorized permission mask. If you add a model-driven decision layer, the Jev decision layer describes a proposed architecture, not a live LeverUp feature. Either way, the takeover path must not depend on the agent.
One piece belongs to the venue. LeverUp’s risk controls page describes protocol-side abuse monitoring and says detection thresholds are not published. That is the protocol managing its own risk; it does not replace your limits.
The checklist on one screen
- Permissions: explicit mask, no wildcard, revocation rehearsed.
- Guardrails: leverage, notional (post-merge), loss window, confirm gates, all outside the model.
- Costs: holding, funding and open/close fees counted in net PnL.
- Liquidation distance: recomputed from live inputs on each check.
- Session hours: gate, explicit market list, plan for the 10x boundary.
- Collateral: margin token decided, its price included in the distance check.
- Oracle reference: agent price readings logged next to execution results.
- Takeover: written triggers, a path that does not rely on the agent.
Run it again after any change to the strategy, model, key, market list or docs.
This post is educational and is not financial advice. Trading perpetuals with leverage carries risk, including loss of your entire margin. Automated agents can fail in ways their operators do not anticipate.
LeverUp uses a protocol-managed virtual liquidity system powered by the VMMV, where trades reference oracle pricing while execution, settlement, and risk management are handled at the protocol layer. See the documentation on VMMV and settlement, oracle pricing and order execution, liquidation, holding and funding fees, trading RWA, closing a position, risk controls, and the gasless trading overview.