The liquidation price you wrote down at entry
Picture the moment an agent opens a leveraged long. It computes a liquidation price, writes it to its state file or its memory, and moves on. Hours later a risk check asks: how far is the market from liquidation? The agent reads the saved number and answers confidently.
That number may already be stale when the next risk check runs. This post is part of a series on agentic trading on perps, and it covers a narrow, practical problem: on a venue where fees count toward the liquidation condition, a liquidation price is not a constant. It is an output of a formula, and some of that formula's inputs change with the clock.
Nothing here is a recipe for avoiding liquidation. Leveraged positions can be liquidated, and no amount of bookkeeping removes that. The point is to make the agent's picture of the risk match the venue's, because a gap between the two is where surprises live.
What the docs' liquidation formula includes
LeverUp's liquidation documentation says a position is liquidated under either of two conditions: the market price reaches the liquidation price, or the collateral becomes insufficient to cover outstanding fees. For a long position, the page gives:
Liquidation Price = Entry Price − (Collateral × Liquidation Loss Rate − Fees) ÷ Position Size (in Quantity)
For a short, the liquidation formula adds (Collateral × Liquidation Loss Rate − Fees) ÷ Position Size (in Quantity) to the entry price. Three terms deserve attention.
- Liquidation Loss Rate is set per trading pair. The liquidation docs list 85% on most pairs and 80% on the high-leverage pairs (500BTC/USD, 500ETH/USD) and on MON/USD, LIT/USD, ZEC/USD and XMR/USD. Read the live page rather than trusting any cached copy, since the list is a configuration, not a law of nature.
- Initial Position Size is initial collateral × leverage ÷ entry price (liquidation docs). Use current quantity for subsequent checks: adding to the same position increases quantity, while a partial close reduces it.
- Fees include the Close Fee, Holding Fee and Funding Fee (liquidation docs). Holding and funding accrue while the position remains open (holding and funding docs).
The liquidation docs also give a simplified condition: total loss and fees ≥ liquidation threshold × position margin, where total loss and fees = Closing Fee + Holding Fee − Funding Fee − PnL. Those values are converted into the position's margin asset so they can be compared consistently. The docs do not spell out the sign convention for a funding payment beyond that expression; confirm it on the live page before encoding it.
Fee terms that move the threshold over time
The Holding & Funding Fees page describes the two time-driven pieces, which I also covered in post #6 on funding and holding costs.
- Holding Fee accrues every second, based on position notional, time held and a Holding Fee Rate locked at opening. It is deducted when the position closes (Holding & Funding Fees).
- Funding Fee is used to balance long and short open interest. The crowded side pays the other, and the rate is zero when the two sides are equal. It is calculated from elapsed seconds, and the protocol accounts for accrued funding when market state is read or changed, then fully reconciles at close (Holding & Funding Fees).
The Holding & Funding Fees docs also note that holding and funding fees are combined and displayed as "Funding Fee." So an agent reading a position's fee field may be looking at the sum, not one term.
Two inputs behave differently over time. The Holding & Funding Fees docs specify that the holding rate is locked at opening, so that piece grows predictably with duration. The funding rate depends on open interest skew, which belongs to the whole market rather than to the agent's position, so it can change direction. A long that pays funding at 6 p.m. may receive it at 6 a.m. if the skew flips. A saved liquidation price encodes none of that.
There is one more input for non-stable margin. The docs define margin value in USD as margin amount × margin asset price, and their worked example uses 800 MON of margin at an assumed MON price of $0.025. An agent that stores a USD-denominated threshold for a position margined in a volatile asset has a second moving part. That is my reading of the formula, not a documented behavior, so check it against how the venue values your specific margin asset (liquidation docs).
Assumed static calculation versus the formula
Here is an illustration. Every number below is assumed arithmetic, not a LeverUp quote, except where marked as a docs figure.
Assumptions: a long on a pair with an 85% Liquidation Loss Rate; entry price 100; margin 1,000 USDC at 10x, giving a 10,000 USDC position and 100 units. Close fee is 0.03% of position size, which on 10,000 USDC is 3 USDC (the Fee Overview lists 0.03% for 1–100x positions, before any discount). Funding uses the Holding & Funding Fees documentation's hypothetical example: 12.8% annualized, giving approximately 3.51 USDC per 24 hours on a 10,000 USDC position. The docs give no numeric holding-rate example, so I use a placeholder of 2 USDC per day purely to show the mechanics. It is not a LeverUp rate.
A notebook-style calculation takes collateral × 85% and divides by size (liquidation docs):
- Static: 100 − (1,000 × 0.85) ÷ 100 = 91.50 (liquidation docs)
The formula with only the close fee counted at entry:
- At entry: 100 − (850 − 3) ÷ 100 = 91.53
After 24 hours, with funding paid at the held 12.8% rate and the placeholder holding fee, fees total 3 + 3.51 + 2.00 = 8.51: (holding and funding docs)
- After 24h: 100 − (850 − 8.51) ÷ 100 ≈ 91.59
After seven days, assuming the same funding rate and direction persisted (it may not) and the holding placeholder scaled linearly, fees total 3 + 24.55 + 14.00 = 41.55: (holding and funding docs)
- After 7 days: 100 − (850 − 41.55) ÷ 100 ≈ 91.92 (liquidation docs)
If instead the long received the same funding amount for that first day, fees are 3 + 2.00 − 3.51 = 1.49, and the long's price moves the other way:
- After 24h, receiving funding: 100 − (850 − 1.49) ÷ 100 ≈ 91.51
At 10x the drift looks small. The next table shows why leverage changes that (liquidation docs).
| Scenario (long, entry 100, assumed; liq docs) | 10x (margin 1,000) | 50x (margin 200) |
|---|---|---|
| Static, no fees | 91.50 | 98.30 |
| Close fee only (at entry) | 91.53 | 98.33 |
| After 24h, paying funding | 91.59 | 98.39 |
| After 24h, receiving funding | 91.51 | 98.31 |
| After 7 days, paying funding | 91.92 | 98.72 |
The 50x column assumes the pair allows that leverage and keeps the same 10,000 USDC notional, so the dollar fees are identical. Against a 1.70 distance to the static liquidation price, the seven-day paying scenario cuts the distance to about 1.28, roughly a quarter less. At 10x the same fees trim the 8.50 distance to about 8.08, roughly five percent. The same fees take a larger share of a smaller buffer (liquidation docs).
None of these figures say a position will or will not be liquidated; they only show that the threshold is a moving quantity. Adverse price movement can also bring a position closer to liquidation; this example holds price constant to isolate fee drift.
Why overnight makes the drift obvious for agents
An agent can miss overnight fee accrual if its implementation relies on saved risk figures. Three possible failure modes illustrate the problem.
First, an agent might calculate the liquidation price at entry and save it in a variable or log line. If its monitoring loop does not refresh or invalidate that value, later checks can reuse a stale figure.
Second, an overnight hold can leave fees accruing for hours between human reviews, depending on the monitoring setup. If a process restarts, a context window rolls over, or a human is asleep, the stale number is what survives. The AI trading bot versus agent comparison explains why agents lean on remembered state more than rule-based bots tend to.
Third, a language model may restate a saved figure without checking its timestamp. An agent could report "liquidation at 91.50" even when that number is a day old. A fluent summary does not establish that the underlying figure is current.
A smaller related point: the ADL documentation describes a separate closure path when effective leverage falls below 1x, for example after collateral appreciates or a large amount of margin is added. Its leverage-based checks apply only to positions opened on the current UTC day. This is auto-deleveraging rather than liquidation, so the Liquidation Loss Rate does not apply (liquidation docs). An agent therefore needs to track applicable ADL conditions as well as its liquidation price.
What a guardrail should refresh
Post #4 on pre-trade guardrails covers checks that run before an order. The same discipline applies to checks that run while a position is open. Design ideas, not LeverUp features:
- Recompute, do not recall. Derive the liquidation price from current inputs at each check: position size, margin, the pair's current Liquidation Loss Rate, and the fee values the venue reports now.
- Prefer the venue's number when it provides one, and treat the agent's own calculation as a cross-check. If the two disagree by more than a small tolerance, flag it instead of picking one.
- Timestamp every stored risk figure and refuse to act on one older than a set age.
- Budget the holding period. Decide in advance the longest an unattended position may stay open, since fee drift scales with time.
- Fail closed. If fee data cannot be read, treat the position as at higher risk and escalate to a human instead of assuming the old figure holds.
Each of these is cheap compared with the cost of reasoning from a stale number.
Closing
A liquidation price is a result, not a fact about the position. The docs' formula includes time-dependent fees, so an agent that reuses the entry-time value without refreshing its inputs can misstate the current liquidation threshold. Read the liquidation and holding and funding pages directly, verify current pair parameters, and treat every example above as arithmetic to adapt rather than numbers to rely on. For where this series started, see the hub post.
This post is educational and is not financial advice. Trading perpetuals with leverage carries risk, including loss of your entire margin.
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 oracle pricing and order execution, VMMV settlement, protocol risk controls, liquidation, and holding and funding fees.