Funding and Holding Costs for an Always-On Agent

An always-on agent is not an always-open position

Software does not get tired. An agent can check a market every few seconds, around the clock. It is easy to let that slide into a different assumption: that "always-on" describes the trade as well as the process.

It does not. Uptime is a property of the agent. A perpetual futures position has its own clock, and that clock runs whenever the position is open, whether the agent is polling once a second, once an hour, or not at all because it crashed. Costs that depend on time keep accruing either way.

This is the sixth post in the Agentic Trading on Perps series. The hub post frames the category, post two covers how leverage changes failure modes, and post four covers pre-trade checks in code. This one covers a cost that guardrails on size and leverage do not address by themselves: what it costs to stay in a position.

"Always-on" in the title describes the process. It is not a suggestion that a position should be held continuously.

Two clocks: the agent loop and the position

It helps to separate two timers.

The first clock is yours to tune. The second is set by the market and the venue's fee schedule. Speeding up the first does nothing to the second. A fast polling loop and a slow one both pay for the same number of seconds if the position is open for the same span.

Builders often assume the opposite because an agent's other costs, such as model calls and data feeds, scale with loop frequency. Position-time costs scale with how long the exposure exists.

Holding fee and funding fee, as documented

LeverUp's documentation describes two time-based fees that accrue while a position is open. Everything in this section is from the Holding & Funding Fees page; it is worth reading in full before encoding any assumption into an agent.

Holding fee. According to the Holding & Funding Fees docs, the holding fee is charged when a position is closed, and it accrues every second based on position notional, holding duration, and the holding fee rate locked at opening:

Holding Fee = Position Size × Entry Price × Seconds Held × Holding Fee Rate Per Second

Each market can have separate long and short rates. The rate that applies is fixed when the position opens, and the accrued fee is deducted at close (Holding & Funding Fees).

Funding fee. The Holding & Funding Fees docs describe funding as a mechanism to keep long and short open interest balanced. When one side becomes crowded, that side pays funding to the opposite side. When long and short open interest are equal, the funding rate is zero. The rate comes from a cubic curve on the open interest skew, bounded by a configured minimum and maximum. Because skew moves with the market, the funding rate is not a constant you can read once and assume forever.

Settlement. Both fees accrue while the position is open and are settled in the position's margin token when it closes. The docs also note that the holding and funding fees are combined and displayed as a single "Funding Fee" (Holding & Funding Fees).

Two details matter for agents.

First, the Holding & Funding Fees docs say funding is "time-based and calculated from the elapsed seconds while a position is open." There is no per-check charge. The protocol accounts for accrued funding when market state is read or changed, which is bookkeeping, not an extra fee for looking.

Second, because holding charges and funding payments or receipts are reconciled at settlement, price-based unrealized profit and loss can differ from net PnL. An agent that evaluates "am I up?" from price alone can overstate or understate its net result; the calculation must include charges and any funding received (Holding & Funding Fees). LeverUp's liquidation page lists Close, Holding and Funding fees among the components in its liquidation condition, so accrued fees can also matter to the margin cushion, not only to the final tally.

A worked example from the docs, then an assumed extension

The docs include a BTC/USD example built on their own assumptions: 50 BTC long against 10 BTC short at a price of 100,000 USDC, a long-side open interest limit of 5,000,000 USDC, a full-utilization funding parameter of 25% annualized, and bounds of 5% to 75% annualized.

The skew is 40 BTC, or 4,000,000 USDC. Divided by the 5,000,000 limit, utilization is 0.80. Cubed, that is 0.512, so the raw rate is 25% × 0.512 = 12.8% annualized. That sits inside the bounds, so it is the effective rate, and because longs are the larger side, longs pay (source).

The docs then state that a 10,000 USDC long held for 24 hours accrues approximately 10,000 × 12.8% ÷ 365 ≈ 3.51 USDC (source).

Everything below this line is our extension, not from the docs. Suppose, for illustration only, the market state held perfectly still for seven days. At the same 12.8% rate, the docs' 3.51 USDC per day (from the holding and funding page) gives 10,000 × 12.8% × 7 ÷ 365 ≈ 24.55 USDC, retaining full precision until the final rounding. In practice the open interest skew would change over seven days, so the rate would move, and the direction of payment could flip if the crowded side switched. Treat 24.55 as a picture of how time-based cost scales linearly with duration at a fixed rate, not as a forecast. The holding fee is separate and additional; the docs do not give a numeric holding-rate example, so none is invented here.

An agent that holds positions for days should treat these costs as a running line item in its own accounting.

Why polling faster does not reduce time-based fees

A common misconception in agent design is that tighter monitoring lowers cost. It lowers some risks. It does not lower the fees that depend on seconds held.

• Faster polling shortens a position only if the agent decides to close sooner. The saving comes from the close decision.
• Faster polling alone does not change the rate. The holding fee rate is locked at opening, while funding depends on market-wide open interest skew. Reading more often does not itself change either calculation (Holding & Funding Fees).
• Faster polling adds its own costs: more model calls, more data, more chances to act on noise.

Duration is one lever over carrying costs. Position size, market, and direction also affect the amount paid or received under the documented fee calculations (Holding & Funding Fees). Faster polling alone cannot make an otherwise uneconomic position economical.

A related trap involves what an agent reads. Grok's X Search tool can retrieve and analyze public posts, which may include commentary about funding or market positioning. A narrative about funding is not the venue's live funding rate. If an agent acts on text about funding rather than reading rate parameters and open interest from the venue's own documented sources, it is trading a description of the market, not the market.

Open/close churn: the fee stack when an agent loops

Time-based fees punish staying too long. The one-off fees punish the opposite behavior, which agents are well suited to: opening and closing repeatedly.

LeverUp's Fee Overview lists, for 1x to 100x leverage, an open fee of 0.03% of position size and a close fee of 0.03% of position size, with a 5% discount when opening and closing with $LVUSD or $LVMON. The execution fee is listed as free. Higher-leverage tiers have a different, separately documented fee structure, which this post does not cover.

Using only those 0.03% figures from the Fee Overview, and an assumed 10,000 USDC position with no discount, opening costs 3 USDC and closing costs 3 USDC, so one round trip is 6 USDC. Ten round trips come to 60 USDC, or 0.6% of notional (fee percentages).

These numbers are arithmetic on the docs' percentages, not a prediction of anyone's results. They ignore price moves, the discount, and any other cost.

The structure matters. For the 1–100x positions discussed here, opening and closing fees apply regardless of whether the trade is profitable (Fee Overview). A human who feels that cost hesitates. A loop with no memory of previous cost does not. For an agent reacting to short-lived signals, the fee stack is a hurdle each signal must clear before it earns anything.

The two failure modes mirror each other:

• Hold too long: time-based fees accumulate quietly and can outweigh a thin edge.
• Churn too often: one-off fees accumulate quietly and can outweigh a thin edge.

An agent needs a view of both, in the same units.

Guardrail implications

Post four argued that limits belong in code the model cannot rewrite. Cost limits are a natural extension. These are design suggestions, not LeverUp features, and any numbers are yours to choose.

• Max hold time. A ceiling on seconds a position may stay open without a human confirming the extension. Closing ends further holding-fee accrual for that position (Holding & Funding Fees), so a hold-time limit can bound this component of cost.
• Max fee budget per day. A running total of estimated open, close, holding and funding cost. When it is reached, the agent stops opening new positions and alerts a person, the same pattern as a daily loss limit.
• Round-trip cap. A limit on opens per market per day, so a noisy signal cannot become dozens of fee-paying cycles.
• Fee-aware profit check. Compute PnL net of accrued fees, not from price alone.
• Fail closed on missing fee data. If current rate parameters cannot be read, reject the new position rather than assume zero cost.

What comes next

The next post covers overnight holds: how liquidation conditions and fee drift interact when nobody is watching the clock.

Closing

An agent can monitor continuously, while an open position can keep accruing time-based costs throughout that period. The figures above are the docs' own example plus clearly labelled arithmetic, so read the Holding & Funding Fees and Fee Overview pages directly and confirm current parameters before building anything on them.

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-referenced pricing and execution, VMMV settlement, protocol risk controls, holding and funding fees, and fee overview.