Why It Matters

The Securities and Exchange Commission (SEC) order dated September 17, 2026 requires written notice before trading stock tokenized by an unaffiliated third party; an issuer's written objection within 30 calendar days following receipt bars that token from trading on the receiving venue under the exemption. This is a scoped objection mechanism, rather than a general veto over stock-price exposure. The public notice plans round-the-clock trading through permissioned liquidity pools. Our interpretation is that extended trading infrastructure still needs a usable roster. A prospective participant should distinguish a proposed stock from a verified listing, and a verified listing from an executable market. A missing objection does not establish issuer endorsement or a launch commitment. Equally, a recorded objection should not be turned into a claim about an issuer's motives or its willingness to participate in a different structure. Traders need the relevant notice, the token's legal form and the route through which they would gain access.

The hedging consequence is conditional. Suppose a market maker intends to offset stock-price exposure using a tokenized share in the proposed pool. If that token is excluded, the intended route may disappear from its available choices. The firm might need an alternative instrument or a different place to transact, with its own access requirements, hours and execution costs. That is a scenario for diligence, rather than evidence that hedging costs have risen. Permission to list and permission to participate are separate checks; the proposed pool structure is permissioned. Even an available token would need sufficient executable depth for the intended hedge. A substitute tied to a broader basket could leave residual exposure to the particular stock. The practical questions are whether the replacement tracks the desired exposure closely, whether it can be traded when needed, and whether usable balances can reach the intended destination. Listing coverage can therefore matter to strategy design without proving a market-wide shortage.

Separate perpetual contracts require their own assessment. The SEC order's definition excludes instruments providing synthetic exposure, such as tokenized security-based swaps. We should not infer from these stock-token objections that a separate perp is delisted, prohibited or dependent on this particular pool. Our analysis concerns a potential hedge input, not a demonstrated change to a derivative contract. A trader evaluating a stock perp would still examine its reference-price methodology, trading schedule, margin rules and executable exit liquidity. If a strategy assumes access to a tokenized share as an offset, that assumption deserves verification against the current listing and participation conditions. If it uses a different hedge route, this objection list by itself provides little evidence about that route's availability. The useful next evidence would be a verified tradable roster and observable execution conditions. Until then, proposed coverage should remain a planning assumption rather than a substitute for tested hedge access.

Go deeper

• Tokenized equity and atomic settlement — how settlement mechanics interact with inventory and access.

• Tokenized stock hedges and ADL ranking — further context for assessing hedging assumptions.

On LeverUp, perpetual futures trade through a protocol-managed virtual liquidity architecture.

Originally published on the LeverUp Blog.

Why It Matters

The SEC's September 17, 2026 order provides temporary, conditional exemptions for permissioned trading of tokenized NMS stocks through automated market makers and liquidity pools. That scope matters when interpreting the announcement: the framework has conditions, rather than conferring a general permission for unrestricted tokenized-stock trading. The issuer describes atomic settlement as delivery versus payment, with shares and payment transferring together or the transaction failing together. In our interpretation, linking those transfers reduces exposure to delivering the asset while waiting for the corresponding payment, provided the mechanism works as described. That benefit concerns completion of the exchange. It should be assessed separately from exposure to a changing share price, the payment asset, or operational disruption. A liquidity provider would still need to examine what happens before submission, when a transaction fails, and when its resulting inventory becomes usable for another trade.

For inventory management, our analysis is that immediate linked settlement can make completed balances easier to distinguish from pending transfers. A liquidity provider could use that distinction to decide what capital is available for a subsequent quote. However, obtaining the assets needed at settlement may require funding in advance; faster completion should not be assumed to reduce total capital requirements. If customers predominantly buy shares, the provider's stock inventory may decline while its payment balance grows. Rebalancing then depends on the routes available to acquire stock or reduce exposure elsewhere. The issuer describes 24/7 trading availability, subject to regulatorily required trading stoppages, maintenance, risk controls and trading volume limits. Extended availability therefore deserves a separate hedging assessment: a quoting window may outlast convenient access to a hedge. We would ask how quotes, inventory limits and funding arrangements respond when that hedge becomes harder to execute.

Participation determines which firms could perform that rebalancing. The issuer says its transfer agent maintains the official onchain ownership record, verifies and approves holders and wallets, and applies identity-verification and sanctions-screening requirements before holding or trading. Our interpretation is that a visible price difference is insufficient to establish an executable arbitrage: a participant also needs authorized access, usable balances and a workable transfer route. Permissioning may narrow the set of firms able to replenish pool inventory or trade against a divergent price. That could matter most when existing providers approach their risk limits, although the announcement does not quantify such effects. Traders should request evidence on executable depth, quote resilience and the process for moving stock into or out of the pool. Atomic delivery against payment addresses the linked settlement legs; price alignment still depends on participants' capacity and willingness to act. The practical test is whether eligible liquidity can arrive when it is needed, at a cost that supports the intended trade.

Go deeper

• Tokenized stocks as margin: haircuts and weekend risk — background on collateral usability and off-hours exposure.

• What is slippage in DeFi? — context for assessing executable liquidity.

On LeverUp, perpetual futures trade through a protocol-managed virtual liquidity architecture.

Originally published on the LeverUp Blog.

Why It Matters

The paper describes designated operators running private domains rooted in Monad; users encrypt domain transactions and wrap them in ordinary network transactions addressed to a hub contract. The hub queues those transactions, Monad supplies their shared ordering, and domain operators pull them for private execution. Public sequencing therefore need not expose the transaction contents. However, operators can read confidential execution, state and transactions in the baseline design, while alternative implementations can restrict operator access too. Access policies govern permitted disclosure, and the domain configuration specifies operators and restrictions that authorized parties can change. For a trader, our interpretation is that privacy requires examining who sees positions, who can change permissions and what evidence supports the chosen implementation. Public ordering should not be mistaken for public visibility into private balances, or for a guarantee of identical operator trust assumptions across domains.

After execution, operators submit attestations alongside state and message roots for the hub to verify; the hub checks message inclusion proofs and replays before routing messages. Cross-domain calls are asynchronous, and messages destined for another private domain are encrypted. In our reading, shared ordering helps coordinate activity but does not establish simultaneous completion of a multi-step trading workflow. A prospective perp builder would need to explain when collateral becomes usable, how pending messages affect margin and how a failed or delayed leg is handled. There is also a privacy boundary: the paper says asset movements on the public network expose transferred amounts and the sending and receiving domains, and describes shielded pools and confidential transactions as next-release protections. Those protections should be treated as planned. An inventory hedge using public liquidity could therefore reveal information even when the originating position stays private; users should examine the actual route before assuming equivalent confidentiality throughout.

For traders and liquidity providers, our proposed diligence starts with liquidation visibility: which authorized actors could observe margin deterioration, obtain reference prices and execute a liquidation? What records could a trader or auditor inspect afterward? For liquidity providers, the parallel question is whether access to inventory and exposure data would be sufficient to assess risk without exposing individual customer positions. These are implementation questions, rather than demonstrated controls in a launched perp product. Timing deserves scrutiny too: the specification lets the hub apply backpressure when a domain processes too slowly. Builders should explain how a proposed margin engine would handle delayed processing, queued collateral updates and asynchronous hedge messages during stress. Our takeaway is to request documented access policies, liquidation procedures, inventory reporting and delay handling before allocating capital. Confidential execution could reduce position exposure, but the risk assessment still depends on who can act, what they can verify and when their actions take effect.

Go deeper

• Monad Private Settlement explained — background on the earlier design proposal.

• How liquidation cascades happen — context for assessing liquidation and inventory stress.

On LeverUp, perpetual futures trade through a protocol-managed virtual liquidity architecture.

Originally published on the LeverUp Blog.

Why It Matters

Under Selig's statement, the contracts are subject to the Commodity Exchange Act, U.S. Federal securities laws, and the regulatory frameworks of both the CFTC and the SEC. A footnote clarifies that CFTC-registered exchanges here means designated contract markets dually registered with the SEC as notice-registered national securities exchanges to trade security futures products. Cointelegraph reported on Nov 3, 2026 that the contracts could be offered on exchanges registered with both the CFTC and SEC to trade security futures products, and Selig's statement distinguishes the statutory framework for joint CFTC-SEC oversight from the March memorandum supporting agency coordination. The Block reported Selig said both the SEC and CFTC would oversee the contracts. On our reading, margin, listing standards and customer protections for these equity perps would therefore be set inside joint US security-futures rules, which can differ from the discretionary funding schedules and margin terms common on offshore perpetual markets. Selig argued in the statement that bringing the products into regulated US markets helps traders access them within the protections of the CFTC's regulatory framework rather than being forced to turn to offshore, and often unregulated, venues—wording that frames the policy choice without guaranteeing identical economics to crypto-native perps.

Selig tied the move to the CFMA's joint-regulation design and to agency coordination this year. He wrote that the CFTC and SEC entered into a memorandum of understanding earlier this year to guide coordination, with a footnote pointing to a March 11, 2026 joint release. He also cited SEC Chairman Paul S. Atkins's description of innovative products stranded in a regulatory "no man’s land" when agencies lacked harmonization. The statement said today's Equity Perps build on a May 29, 2026 order approving a bitcoin perpetual futures contract on a CFTC-regulated exchange, extending the same perpetual instrument from digital commodities into traditional securities. These equity contracts fall into the security-futures category and are subject to both CFTC and SEC frameworks.

Cointelegraph wrote that Selig did not identify which exchanges would offer the contracts or provide a timeline for when trading would begin. The same report noted a June lawsuit arguing cryptocurrency perpetual futures should be regulated as swaps rather than futures, and reported the Capital Markets Alliance filed suit Tuesday afternoon seeking to overturn the CFTC approval—legal friction that could affect timing even after the deeming. Traders should check each contract's published specifications for funding cadence, leverage caps and session rules rather than assume those terms match an offshore perpetual contract. Maintaining a perpetual position requires meeting applicable margin requirements. Any funding payments or settlement cash flows depend on the contract specifications and relevant exchange and clearing rules.

Go deeper

• Regulated US perps and clearing — how regulated US perpetual futures fit clearing and listing rules.

• What are perpetual futures? — funding, margin and how perps differ from dated futures.

On LeverUp, perpetual futures trade through a protocol-managed virtual liquidity architecture.

Originally published on the LeverUp Blog.

Why It Matters

Selig’s statement said the Commission deemed the equity perps approved under Regulation 40.3 as security futures products under the Commodity Futures Modernization Act of 2000. His statement says the contracts are subject to both agencies’ regulatory frameworks; its footnote defines the relevant exchanges as designated contract markets dually registered with the SEC as notice-registered national securities exchanges to trade security futures products. The coalition’s own announcement argues instead that the products are security-based swaps under SEC jurisdiction and that the CFTC violated the Administrative Procedure Act by failing to explain its decision or reasonably consider investor and securities-market impacts. These are the plaintiffs’ allegations, rather than findings by a court. On our reading, the classification dispute matters because it challenges the legal framework through which traders would access the contracts, rather than establishing particular leverage or funding settings.

The coalition asks the court to vacate the approvals, declare the products security-based swaps and bar the CFTC from giving the approvals effect while the case is pending. That last request is for interim relief that, if granted, could restrict listings or trading, depending on the court’s order. Cointelegraph noted Selig did not identify which venues would offer the contracts or provide a timeline for when trading would begin. That omission does not establish whether individual contract specifications were already available. On our reading, a stay could delay access under the security-futures path, depending on the order’s scope; the court could also deny relief and leave the approvals in place pending review. The practical distinction is between permission to offer a product, an actual venue launch and a court order affecting access. An announcement about the first should not be treated as proof of the other two.

A CFTC spokesperson told CoinDesk the case was troubling interference with CFTC-regulated markets and said, “Our markets should be governed by law, not litigation campaigns intended to block innovation.” Cointelegraph placed the filing against the backdrop of litigation brought in June by a major US futures exchange operator over cryptocurrency perpetual futures, arguing swaps treatment rather than futures treatment. That earlier dispute supplies context, rather than deciding the equity case. For traders, our takeaway is to watch for venue launch information and the scope of any court order before assuming when access will be available. Contract specifications should be checked separately: the reported omissions in Selig’s statement do not establish missing margin or funding rules. If the court accepts the swap framing or grants interim relief, access under the security-futures path could be affected, depending on the ruling.

Go deeper

• Regulated US perps and clearing — how regulated US perpetual futures fit listing and clearing rules.

• What are perpetual futures? — margin, funding and how perps differ from dated futures.

On LeverUp, perpetual futures trade through a protocol-managed virtual liquidity architecture.

Originally published on the LeverUp Blog.

Weekly reported volume came in at $12.43M, down from $22.2M the week before. Trading fees and protocol revenue both fell week over week, and the variable LVMON staking APY was 33% at this report's snapshot.

What shipped

Cross-Exchange Early Access

Cross-Exchange connects traders to external market liquidity through the LeverUp Perps aggregator.

• Aggregated Liquidity: Access external order books and available market depth.

• More Markets: Crypto, stocks, indices, commodities, FX, and pre-IPO.

• One Platform: Access multiple asset classes through a single trading interface.

Cross-Exchange uses a separate USDC trading balance. Market hours, fees, and limits follow the corresponding venue.

Currently in Early Access.

• Ongoing Programs still open: AnyCollateral Program, $LVMON Staking (Open to Everyone), LeverUp Agent Wallet, and Fair Launch.

→ How it works → Explore Early Access

Protocol metrics (Oct 26–Nov 1)

WoW figures compare this week with the previous recap week.

Trading activity

• Reported Volume (7D): $12.43M (-44.0% WoW)

• TVL: $2.11M (-7.0% WoW)

Revenue and fees

• Trading Fees (7D): $3,602 (-21.4% WoW)

• Protocol Revenue (7D): $1,223 (-32.3% WoW)

Vault

• Protocol Vault Value (MON): 62.17M (-5.0% WoW)

• Protocol Vault Value (LVUSD): $918,914.97 (+0.1% WoW)

LVMON staking

• Total Staked: 13,706,260 LVMON (-6.2% WoW)

• Current APY: 33%

APY is variable and reflects the reporting snapshot.

Recent recaps

• LeverUp Weekly Recap — Oct 5–11 — CHOG competition rewards were fully distributed after $99.08M in trading volume, and the Clash of Perps competition entered its final days before its Oct 14 close.

• LeverUp Weekly Recap — Oct 12–18 — Cross-Exchange opened in Early Access with stocks, indices, commodities, FX and pre-IPO markets, and CL/USD perps went live on LeverUp with up to 20x leverage.

• LeverUp Weekly Recap — Oct 19–25 — Cross-Exchange Early Access continued and S&P500/USD, GOLD/USD and XYZ/USD joined the LeverUp lineup, while 7D reported volume rose to $22.2M this week.

Related reading

• Cross-Exchange Markets: Early Access Is Live on LeverUp

Built for traders. Returned to traders.

Trade on LeverUp: app.leverup.xyz

Originally published on the LeverUp Blog.

Why It Matters

AMBCrypto describes a contrast. On CFTC-regulated markets, participants are partially hidden, so traders do not know the identities of those they trade against. The onchain exchange's order book, by comparison, is described as "fully transparent," and wallets and trades can be tracked. Wilson asked a backer of the deal whether they were aware that "the world will be able to track your positions and trades in real time," and whether they see that as a benefit. The report does not describe a CFTC position on that question. Wilson concluded, according to AMBCrypto, that the onchain trading plan could present trading inefficiencies and regulatory hiccups. That is an assessment, not a regulatory finding, and the report does not say how likely those outcomes are.

AMBCrypto wrote that perhaps the most crucial questions were about possible front-running of trades using priority fees and whether the US order book will be merged with a more liquid global order book. Rebecca Rettig, legal chief at Jito Labs, said there could be privacy solutions to address the transparency issue, but she agreed that merging onshore and offshore order books was the most crucial issue. As a case in point, the report cites a US crypto exchange that has thinner liquidity because it does not share an order book with its global counterpart. On our reading, a separate US book could carry less liquidity than a merged one. That is our inference from the report's example, not a forecast.

The report does not say which core principles Wilson had in mind. For context, the CFTC's rules reproduce the statutory text, including Core Principle 9, which says a board of trade shall provide "a competitive, open, and efficient market and mechanism for executing transactions." Core Principle 12 calls for rules "to protect markets and market participants from abusive practices committed by any party" and "to promote fair and equitable trading on the contract market." Our interpretation is that these are the kinds of tests that priority-fee ordering and order book design could be measured against. The report does not say any principle was applied, and it adds that it remains to be seen how the CFTC will address the flagged issues. Until then, a redesign or a separate US book is a possibility, not an outcome. For traders, three details are worth watching if US access arrives: whether positions stay public, how priority fees affect order handling, and whether the US book is merged or separate. Those details would show how each question is handled, and none is settled in the report.

Go deeper

• Regulated US perps and clearing — related reading on regulated US perpetual futures.

• Perp DEX vs CEX — how onchain and centralized venues differ for perpetual futures.

On LeverUp, perpetual futures trade through a protocol-managed virtual liquidity architecture.

Originally published on the LeverUp Blog.

Why It Matters

A hijacked domain changes what a visitor's browser loads, not what a protocol's contracts do. The Vercel bulletin and The Block's report describe domain takeovers and redirected websites. Neither describes a flaw in a protocol's contract code, so a code audit may not have covered this path. That is our interpretation, not a finding from either source. The Block reported that one wallet pulled tokenized stocks, including NVDA and AAPL, out of a lending protocol and swapped them for ETH. On our reading, that shows assets deposited in DeFi can sit behind the same wallet that a compromised page asks to sign.

Traders usually ask who holds collateral, who sets prices and who runs liquidations. Anyone trading in a browser also relies on a registrar account, a DNS record and a hosting provider to deliver the real interface. Frontend provenance is therefore a separate layer of counterparty risk: a trader may trust a protocol and still be exposed to whoever controls the address bar. A familiar web address that now resolves somewhere else looks the same to a visitor, so the interface on screen is weak evidence of where its code came from. Provenance here means who controls the domain, the registrar account and the hosting behind the page a wallet is connected to. Crypto Briefing reports that Name.com urged customers to review their DNS settings and enable two-factor authentication.

Much remains unclear. Crypto Briefing reports that Name.com said 15 customer domains were affected. Separately, The Block reports that Blockaid identified 12 affected DeFi websites and that no affected project had reported a victim count. These counts describe different scopes. The Vercel bulletin describes Name.com as investigating a domain takeover campaign targeting crypto companies, and the reports reviewed do not establish a root cause. As a general habit, traders can bookmark known addresses, read each signing prompt before approving it and keep trading balances in a separate wallet from long-term holdings. Waiting for a project to confirm that its domain is secure before reconnecting a wallet after a security notice is also a reasonable step. Those habits reduce exposure to this kind of attack but do not remove it.

Go deeper

• Setting Up Your Wallet for Monad — how to prepare a wallet before connecting to a trading interface.

• Risk Management for New Traders on LeverUp — position sizing and other habits that limit loss on any single trade.

On LeverUp, perpetual futures trade through a protocol-managed virtual liquidity architecture.

Originally published on the LeverUp Blog.

Why It Matters

The approval path is the center of the story. The release says the two companies intend to seek regulatory approvals for a market and clearing structure that would operate regulated, KYC and AML-compliant perpetual futures markets, "including approvals needed to support leveraged trading." It adds that verified customers would reach the markets through futures commission merchants (FCMs) that become platform members, and that the retail business would run separately from the operator's institutional futures and clearing franchise. Identity checks, leverage and clearing are therefore described as approval-dependent items, not features of a market that is already open.

The structure separates three jobs: on-chain infrastructure, market design and a regulated operator that handles clearing and customer access. That reading is an interpretation of the described setup, not a claim made in the release. Splitting the jobs is one way a US retail offering could place KYC, AML and leverage approvals with a regulated entity while the markets themselves are still built with public-chain tooling. The release states that the plans depend on regulatory approvals, and it does not detail how the layers would interact day to day. It describes the target customers as retail traders who want short-duration, around-the-clock exposure to crypto, equities, commodities, foreign exchange and other real-world assets, many of whom use offshore venues today. Jeffrey Sprecher, the operator's chief executive, said "We see these perp markets as additive to our futures markets, not a replacement for them."

Much remains open. CoinDesk reported that the firm "said it will share details on products, eligibility and timing as approvals progress," so contract lists, eligible customers and launch dates have not been announced. On the financial side, the release says the operator's minority position in the firm is not expected to have a material impact on its 2026 adjusted financial results. Leverage limits, margin rules and clearing terms that would apply to retail customers are not set out in the pages reviewed here. Until those details appear, the plan is best read as a proposed structure that is pending approval, and readers comparing venues should check which entity holds each role: infrastructure, market design, clearing or customer access.

Go deeper

• What Are Perpetual Futures? — how perpetual contracts work, including funding and margin.

• Perp DEX vs CEX: Where to Trade Perpetuals — how venue structure, custody and clearing differ.

• Cross Margin vs Isolated Margin — how margin mode shapes risk on a leveraged position.

On LeverUp, perpetual futures trade through a protocol-managed virtual liquidity architecture.

Originally published on the LeverUp Blog.

Most crypto perpetual markets trade around the clock, and an agent built on that assumption has no concept of a market being "closed." Its loop is simple: read the signal, size the position, send the order, repeat. Nothing in that loop asks whether the market is open to accept the order.

Now picture the same agent pointed at a stock perp on a Friday evening. A general-purpose assistant has summarized the day's earnings coverage, and the agent decides to open a leveraged position. This is a hypothetical, and nothing in it predicts a price. The question is only whether the venue will take the order at that hour, and what happens to a high-leverage position when the underlying stock market closes.

This post is part of a series on agentic trading on perps. It reads LeverUp's Trading RWA documentation, which I re-opened at write time, and turns its session rules into things a trading agent has to encode. I did not find a documented LeverUp connector for any consumer assistant, and none is implied here. LeverUp's gasless / 1CT documentation describes a hosted-agent mode for backend-held signing keys. Our tutorial, How to Build a Grok Bot Trading Agent on LeverUp, walks through one setup — it is not a claim that consumer assistants ship a LeverUp connector.

What the docs say about session hours

The Trading RWA page says LeverUp supports perpetual trading on real-world assets, starting with MAG7 equities. For those markets, the page lists:

• Trading hours: Monday to Friday, 9:31 AM to 3:59 PM Eastern Time. A buffer is introduced so that submitted trades can go through (Trading RWA docs).

• Weekends: closed (Trading RWA docs).

• Holidays: the page points to the NYSE market hours and holidays schedule rather than listing dates (Trading RWA docs).

• Opening: new positions can only be opened during market hours (Trading RWA docs).

• Maximum leverage: 100x for RWA pairs (Trading RWA docs).

• Existing positions held off hours: they remain active and are subject to funding rates, which the page describes as reflecting the cost of holding (Trading RWA docs).

Two cautions. The page names MAG7 equities as the starting set, so an agent should not assume the same schedule for any other RWA pair without reading that pair's rules. And the docs do not describe how irregular sessions such as early closes are handled; the Trading RWA docs refer to the NYSE schedule for holidays. Whether an early close shortens the window here is not stated, so an agent should treat that as an open question to check, not a given.

Leverage tiers and the force-close rule

The same documentation splits RWA positions by leverage:

The force-close section adds detail. At market close, the page says LeverUp automatically force-closes every RWA position with leverage greater than 10x, to avoid carrying high-leverage exposure into off hours when the underlying market is closed and prices cannot be hedged. The entire position is closed at the prevailing market-close price, with no partial deleverage. PnL is settled and remaining collateral is returned to the trader's account. The page says this applies to every RWA pair on every regular trading day (Trading RWA).

To keep a position past the close, the Trading RWA docs say leverage must be brought to 10x or below before the market closes. The simplest way they give is adding collateral, which lowers effective leverage without changing position size. Once at or below 10x, the position is treated as an Overnight Position and is not force-closed.

What the Trading RWA page does not say: it gives no exact clock time for the force-close within the session, and no price source beyond "prevailing market-close price." An agent should not hard-code a guess. It should read the live page and treat the close as an event that can happen at or near the end of the window.

Adding collateral also changes risk. More margin on the same position means more capital exposed to it, and that tradeoff belongs in the agent's rules, not just a leverage target. That is my reading, not a documented claim.

Off-hours restrictions

For non-trading hours, the Trading RWA page lists what is allowed and what is not:

• Allowed: add collateral, cancel an open order, edit TP/SL (Trading RWA docs).

• Not allowed: open a new position, close an existing position, create a new order, and liquidation (Trading RWA docs).

Two consequences follow from the documented off-hours restrictions, and both are inference rather than separate documented statements. First, an agent holding an overnight position cannot close it off hours; its only documented levers are adding collateral, cancelling an order and editing TP/SL. A rule like "exit if the news turns" has no off-hours execution path. Second, because the page lists liquidation as disabled off hours, an agent should not infer from a quiet weekend that a thinly margined position is safe. The docs do not describe what happens at the next session, so I will not guess.

A related point: in the overnight drift post, I covered how fees accrue and move a position's liquidation threshold over time, as reflected in the documented liquidation-price formulas. Holding fees accrue over time, while funding can be paid or earned depending on long/short open-interest imbalance. An agent should refresh accrued fees and risk calculations before the next session rather than reuse Friday's saved figures.

What an agent must encode

None of this is a LeverUp feature request; these are design ideas for the agent's own code, extending the pre-trade guardrails post.

1. A session check as a hard pre-trade gate. Before any open or close order, compute whether the market is in its documented window, using the America/New_York time zone rather than a fixed UTC offset, since Eastern Time shifts with daylight saving. If the check fails, do not queue the order and do not retry in a loop.

2. A calendar source of truth. The Trading RWA docs defer to the NYSE schedule for holidays. The agent should read a maintained calendar, and fail closed when the calendar is missing or ambiguous.

3. A per-position leverage tier. Tag every open RWA position using the documented day-trade and overnight leverage tiers, and re-tag it when margin is added or the position changes.

4. A pre-close decision, made in advance. Define before the session what happens at the end of the window: accept the documented market-close force-close, or reduce leverage to 10x or below. If it chooses to add collateral, the agent needs a spending limit for that, as described in the scoped-keys post (Trading RWA docs).

5. An off-hours behavior spec. Treat "close disabled" as a known state, not an error to retry. Limit the agent to the three documented off-hours actions: add collateral, cancel orders, edit TP/SL.

6. A margin-asset check. If the margin is a volatile collateral token, the agent must monitor both the position and the collateral's price: the liquidation documentation calculates margin value from the margin amount and the margin asset's price. Read the AnyCollateral docs for the collateral rules, and confirm the current supported-token list in the trading UI before assuming a token can be used as margin.

7. A fresh read of the rules. Protocol risk-control parameters can change. Re-open the page on a schedule rather than trusting a cached copy, including the numbers quoted in this post.

Closing

An agent built for 24/7 crypto logic can run into a different rulebook on stock perps: session windows, a leverage threshold at 10x, an automatic close of the whole position for anything above it, and a short list of actions allowed off hours. None of this makes stock perps unsuitable for an agent, but it does mean the agent should read the rules before it places an order, not after. Start with the Trading RWA page, check the current schedule and parameters yourself, and treat everything above as design guidance rather than instruction.

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 VMMV and settlement, trading RWA, oracle pricing and order execution, liquidation, holding and funding fees, opening a position, closing a position, and risk controls.

Originally published on the LeverUp Blog.

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

1. Permissions: explicit mask, no wildcard, revocation rehearsed.

2. Guardrails: leverage, notional (post-merge), loss window, confirm gates, all outside the model.

3. Costs: holding, funding and open/close fees counted in net PnL.

4. Liquidation distance: recomputed from live inputs on each check.

5. Session hours: gate, explicit market list, plan for the 10x boundary.

6. Collateral: margin token decided, its price included in the distance check.

7. Oracle reference: agent price readings logged next to execution results.

8. 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.

Originally published on the LeverUp Blog.

Why It Matters

The Bank is not proposing a separate rulebook for tokenised assets. According to the paper, the draft supervisory statement does not create a separate regulatory regime for tokenised collateral. It is meant to clarify what the Bank would expect CCPs to consider when they apply through the existing supervisory process for new collateral. The Bank's initial view, as set out in the paper, is that the existing framework does not prevent CCPs from accepting tokenised forms of eligible collateral, under a principle of "same risk, same regulatory outcome". Cointelegraph reported the consultation on 29 October 2026 in similar terms. The paper adds that CCPs are not mandated to accept tokenised collateral, and that a CCP seeking to accept it is expected to demonstrate, in the approval process, that it meets the criteria and can manage the risks. The paper says the expectations would apply to UK CCPs and to recognised non-UK CCPs that the Bank has determined to be, or are likely to become, systemically important to UK financial stability.

The attraction is speed. The paper says respondents pointed to near-real time collateral mobility, including moving collateral outside traditional market operating hours and across jurisdictions, and that firms noted these features could potentially support meeting margin requirements. The paper describes delays between market moves, margin calls and actual collateral delivery that can require firms to pre-position collateral or hold buffers, and it says tokenised government bonds may be one of the most impactful use cases. The same paper also flags a trade-off: collateral that moves at instant or near-instant speed can reduce the need for buffers but could leave fewer resources available to absorb shocks in difficult market conditions. Our reading is that this trade-off explains why the paper pairs the speed argument with eligibility tests rather than treating faster movement as a benefit on its own.

Speed does not settle eligibility. The paper says CCPs are required to assess factors including valuation, liquidity, transferability and the resilience of operational and custody arrangements, and that tokenisation does not, in itself, determine whether collateral is eligible. It states that "more efficient transferability in normal market conditions does not automatically equate to efficient liquidation in stress." For a token that is a digital twin of an off-chain asset, the paper says that in stressed conditions the token could trade at a discount to the underlying asset, with implications for valuation and liquidation. Our reading is that these are the tests a tokenised asset would have to pass before it counts as usable clearing margin. The consultation does not propose changing the list of eligible collateral, though it asks for views on stablecoins, tokenised money market fund units and tokenised gold as possible future forms.

Go deeper

• Tokenized Stocks as Margin: Haircuts and Weekend Risk — how haircuts and off-hours pricing shape tokenized collateral.

• How Liquidations Work — what happens when margin falls below maintenance levels.

On LeverUp, perpetual futures trade through a protocol-managed virtual liquidity architecture.

Originally published on the LeverUp Blog.

Agentic trading on perps means a software agent, usually built on a language model, takes part in trading perpetual futures: it reads market data, forms a view, places or stages orders, and operates under permissions a human granted. The market does not change because the trader is software. Funding, margin and liquidation apply the same way.

What is an AI agent?

A chatbot answers a question. An agent is given a goal and a set of tools, and it takes several steps toward that goal on its own, checking in with you at points you define. The word covers a wide range, from a research helper that only reads and summarizes, to a program that can click, sign in and spend.

Grok Bot's launch post describes AI teammates you can give real work to, with their own computer and sign-ins to the tools you already use. Meta's Muse Wonder post describes a personal agent that takes actions on a user's behalf. Those are different products with a shared shape: a model, tools, some memory, and a permission boundary. For the difference between a rules-based bot and a model-driven agent, see AI trading agent vs trading bot; for whether bots deliver at all, see Do AI trading bots work?

Five jobs when an agent participates in perps

It helps to split "the agent trades" into five separate jobs. Each can be given to an agent, withheld from it, or put behind a human approval.

1. Read data. Prices, open interest, funding, positions and history. This is the lowest-risk job because nothing moves. LeverUp's developer docs describe a read-only REST API with no authentication required for prices, markets, positions and trade history. An agent that only reads can still produce a bad summary, but it cannot open a position.

2. Decide. Turn data into a view: long, short, size, exit. Model-generated decisions need checks on their assumptions, inputs and proposed exposure. A model can sound confident and be wrong, so a decision is a proposal until something checks it. One proposed way to separate the two is the decision-layer architecture, which is a proposed design, not a live LeverUp feature.

3. Place or stage orders. Staging means the agent prepares an order and a human confirms it. Placing means the agent submits it. The gap between those two verbs is the most important design choice in the whole stack.

4. Permissions and keys. Whatever places an order needs a credential. A key that can only express trading intent is a much smaller risk than a key that can also move funds. The full argument is in scoped permissions for AI trading agents.

5. Guardrails and holding costs. Position limits, leverage caps and loss limits belong in code that the model cannot talk its way past. Holding duration matters regardless of how often a person or agent checks the position. On LeverUp, holding fees accrue while a position is open, and funding may be paid or received.

Hook one: Grok Bot (xAI)

Grok Bot launched in beta on August 11, 2026. The post says Bots have their own computer, sign into tools you already use, work across apps, and "only come back when something needs your approval." The docs describe each Bot as running on a persistent cloud computer with a browser, filesystem and terminal.

On access, the security page says Bots generally act with the signed-in member's access, with an exception for team-managed connectors that may use team or service-account credentials. It also says credentials stay out of the model and approval prompts show the proposed operation. It also says its Auto Review feature does not review every side effect, so it is one control among several.

What the materials do not say: in the launch post, Grok Bot docs and security page reviewed here, none mentions trading, crypto, perpetual futures or LeverUp. The examples are sales, operations, engineering and similar work. Any link between a general agent and a perps venue is something a user builds, not something these pages document. For a plain-language overview, see what Grok Bot is.

Hook two: Meta Muse

Meta's Muse Wonder post, dated October 12, 2026, introduces models aimed at "personal and professional agentic tasks." It says Muse Wonder is available through the Meta Model API and Muse Code, and that it will soon power experiences in Meta's Muse app, rolling out first to subscribers.

On safety, Meta's post says a personal agent "takes actions on a user's behalf," that this level of access demands a model that "exercises discretion with private information and resists misuse," and that it "checks in before taking important actions." Finance appears only as an evaluation area, in the context of understanding financial information. The page does not mention trading, crypto or perpetual futures.

To be direct: nothing in Meta's post describes a connection between Meta Muse and LeverUp, and this series does not claim one. Meta Muse is here as a named hook beside the other two products, and because the behaviour its post describes — checking in before important actions — is the same pattern a perps setup needs.

Hook three: Manus Cue

Manus announced Cue as part of Manus 2.0 on September 28. The post calls Cue a standalone app for personal agents and says each agent has its own email, phone number, wallet and computer, and can pay within a budget you set. Cue was in early access with an invite code at launch.

Again, the official Manus announcement does not document crypto trading, perpetual futures or LeverUp. A wallet and a spending budget describe how an agent pays for things. They do not describe how much market risk an agent may take.

That distinction is the point of why a spending budget is not a leverage limit. As an illustration with assumed numbers (not from any product page): a 100 USDC budget could, at an assumed 20x leverage, control a 2,000 USDC notional position — the same margin-vs-notional split LeverUp's opening-a-position docs describe for leveraged perps in general. In this hypothetical, 100 USDC committed as margin supports 2,000 USDC of notional exposure; a spending budget alone does not establish a limit on leveraged exposure. For product details, see what Manus Cue is.

A research assistant is not an execution agent

Grok Bot's documentation describes research and summarization among its example tasks. In a hypothetical market-research setup, an assistant could summarize news, explain terms and compare scenarios. That covers reading data and some analysis. If configured without trading credentials or order-submission tools, it cannot submit trades.

An execution agent is different because it holds a credential that can change a position. The risks are different too. A research assistant that is wrong costs you a bad idea. An execution agent that is wrong can open, resize or close a leveraged position before you read the message. When a product page says "agent," ask which of the five jobs it is allowed to do.

What does not change on the venue

Whether a person or an agent submits the order, the venue's rules apply. Using LeverUp's docs as the reference:

• Funding. The funding docs say that when one side is crowded, that side pays funding to the other, and that the rate is 0 when long and short open interest are equal. Their worked example, with assumed market numbers, comes to roughly 3.51 USDC over 24 hours on a 10,000 USDC long.

• Holding fee. The holding-fee docs say the holding fee accrues per second on position notional and is charged when the position closes. An agent that keeps positions open for long stretches accrues it for the whole time.

• Liquidation. The liquidation docs say a position is liquidated when the market price reaches the liquidation price or when collateral cannot cover outstanding fees, with a loss rate of 85% of margin on most pairs and 80% on some.

LeverUp documents a hosted-agent integration mode for One-Click Trading. The developer docs say the signing key "can only express trading intent" and "cannot transfer tokens, cannot withdraw, and cannot act outside the permission bits the user granted." For the execution steps, see the Grok Bot trading walkthrough rather than repeating them here. The relevant point for this post is that the venue enforces margin and liquidation the same way, regardless of who or what holds the key.

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 official documentation on pricing and execution, VMMV-based settlement and protocol risk controls.

Series roadmap

This is post one of the Agentic Trading on Perps series. The rest are upcoming and not yet published:

• #2 AI Trading Bot vs AI Agent on Perps: What Changes When the Market Has Leverage

• #3 Scoped Keys and Delegated Access: What an Agent Can Actually Do to Your Perp Position

• #4 Risk Guardrails in Code: Pre-Trade Checks an Agent Cannot Skip

• (#5 cancelled — Cue wallet companion merged into this hub)

• #6 Funding and Holding Costs for a Round-the-Clock Agent

• #7 Liquidation and Fee Drift: What Happens When an Agent Holds Overnight

• #8 Meta Muse, Connectors and Human Approval: How Delegated Trading Differs From a Hosted Agent

• #9 Stock Perps Hours and Force-Close: Markets an Agent Shouldn't Enter Blindly

• #10 Pre-Deploy Checklist for an Agent Trading on LeverUp

If you are new to the underlying mechanics, start with the perpetual futures learning path.

Closing

Agentic trading on perps is the same market with a new kind of participant. The useful questions are the old ones, asked about software: what can it read, what can it decide, what can it submit, what key does it hold, and what stops it. Official materials for Grok Bot, Meta Muse and Manus Cue describe general-purpose agents and do not document perps trading; treat any claim beyond that as unverified.

This article is educational and is not financial advice. Perpetual futures use leverage and can result in the loss of your entire margin.

Originally published on the LeverUp Blog.

A grid bot and a language-model agent can both be sold as an "AI trading bot." On spot those differences already matter; leverage amplifies them. Turn on leverage and the gap changes shape: a small error in a decision is scaled by position size, costs keep accruing while the position is open, and the venue, not the bot or the agent, decides when a position is closed by force.

Agent products and models such as Grok Bot and Meta's Muse Wonder model series show how common agents have become for general tasks. Neither announcement page mentions trading, crypto or leverage. Nothing below claims either one connects to LeverUp. This post is the second in the Agentic Trading on Perps series and covers only what leverage adds.

A one-paragraph reminder: bot versus agent

A bot runs rules someone wrote in advance. An agent puts a language model in the loop to decide what to do next, often across several tools. The full comparison, including inputs, auditability and cost, lives in AI trading agent vs trading bot, and the question of whether bots make money is in Do AI trading bots work?. The rest of this post assumes you have that split in mind and asks one question: what changes when the account is leveraged?

What leverage changes for both

Leverage separates margin from exposure. LeverUp's opening-a-position docs describe traders choosing collateral, exposure size and leverage, with optional stop-loss and take-profit orders. Exposure is a multiple of the margin put up, so the same wrong call costs a larger share of the account.

Three things follow, and they apply to a bot and an agent alike:

• Errors scale. A bad entry, a misread price or a wrong size does proportionally more damage.

• Time costs money. A position that sits open pays fees for as long as it sits.

• Someone else holds the exit. Past a threshold, the venue closes the position whether or not the operator agrees.

What differs is how each kind of system produces the error in the first place.

How a rule-based bot fails under leverage

A rule-based bot does what its rules say, including when the rules no longer fit the market. These examples are hypotheticals, not observations of any real bot.

Range logic meets a breakout. Imagine a grid bot built for a range. Price leaves the range and keeps going. Without a stop condition, the bot keeps adding to the losing side. On spot, that is a large unrealized loss. With leverage, increasing exposure without proportionately increasing margin can reduce the position's buffer against further losses. On LeverUp, adding in the same direction on the same pair with the same margin token merges quantity and margin and updates the weighted entry, so the liquidation effect depends on those changes (opening-a-position docs).

No awareness of carrying costs. Many simple rule sets are written around price and nothing else. A bot with an entry rule, an exit rule and no clock can hold a position far longer than its designer pictured, and the cost of holding grows with that time.

Stale or wrong parameters. A leverage setting or position size that made sense in testing can be wrong on a different market, and a fixed rule repeats the same mistake consistently.

The common thread is that the bot is consistent. Its logic can be easier to debug, but it may keep an unsuitable strategy unless its rules detect the change.

How an LLM agent fails under leverage

An agent adds flexibility, and with it some failure modes a rule set does not have. Again, these are labelled hypotheticals.

A confident wrong number. A model asked for the current funding rate or price may answer from memory instead of fetching it. If that figure feeds a sizing decision, the leveraged position is sized on a guess. This is one reason the decision step should read live data from the source, a point made in AI trading agent vs trading bot.

Tool-call ordering mistakes. An agent that places an order, then adjusts margin, then sets a stop, can get the sequence wrong or stop partway through. A position that exists without its intended stop is a different risk from one that never opened.

Context drift overnight. An agent running for hours accumulates context. Earlier instructions can be diluted, summarized away or contradicted by later text. A limit that was clear at the start of a session may carry less weight many steps later.

Different answers to the same question. Outputs can vary between runs. Under leverage, a small variation in how the agent reads "reduce risk" can be the difference between trimming a position and closing it.

The pattern: a bot fails by being rigid, an agent fails by being inconsistent. Leverage makes both costly, in different ways.

Holding and funding: costs that accrue while a position is open

On LeverUp, two fees accrue while a position is open. Per the holding and funding docs, the holding fee accrues per second based on position notional and holding duration, with the rate locked at opening and the fee deducted when the position closes. The funding fee exists to keep long and short open interest balanced: when one side is crowded, that side pays the other, and the rate is 0 when the two are equal.

The relevant variable is duration, not how often anyone checks the position. A bot that polls once a second and an agent that wakes once an hour accrue the same fees on the same open position, because fee accrual depends on elapsed holding time. Checking more often does not cut them; closing does.

An assumed illustration, extending the docs' own worked example. The docs show a 10,000 USDC long paying about 3.51 USDC over 24 hours at an assumed 12.8% annualized funding rate. If the rate were held constant (assumed; the docs describe a rate that moves with open-interest skew), seven days would cost roughly 10,000 × 12.8% ÷ 365 × 7 ≈ 24.5 USDC, before the holding fee. Against margin of 1,000 USDC at an assumed 10x, that is about 2.5% of margin for a position that did nothing but stay open.

A rule-based bot with no funding input will not see that cost. An agent might see it, if it is given the data and asked, but that is only as reliable as the data it reads. Neither is protected by default.

Liquidation and fee drift

Liquidation is decided by the venue. The liquidation docs say a position is liquidated when the market price reaches the liquidation price or when collateral becomes insufficient to cover outstanding fees. For a long, the docs give the liquidation price as the entry price minus (collateral × liquidation loss rate − fees) ÷ position size, where fees include the close fee, holding fee and funding fee, and the loss rate is set per pair, 85% on most and 80% on some.

Fees sit inside that formula, so the liquidation price is not a fixed number. An assumed example using the docs' formula for a long: entry price 100, collateral 100 USDC at 10x, so position size is 10 units, and an 85% loss rate. With zero fees, the liquidation price is 100 − (85 ÷ 10) = 91.5. If 5 USDC of fees have accrued, it becomes 100 − (80 ÷ 10) = 92.0. The line has moved closer to the entry price although nobody changed the position. (The docs' simplified condition also nets funding received against costs, so the direction of drift depends on which side of funding the position is on.)

This is where a prompt-based agent can go wrong in a quiet way. If an agent calculated its liquidation price at entry and stored it, that number can be stale hours later. A stop placed "safely" above the entry-time figure may sit closer to the real threshold than the agent believes. The fix is to read the venue's current position data instead of trusting a stored calculation, and to leave room for fees. For the full mechanics, see how liquidations work on LeverUp.

A prompt is not a risk rule

One idea runs through the failure modes above. A line in a prompt such as "keep leverage low" is an instruction the model weighs. A code check that rejects any order above a set leverage holds regardless of what the model concludes. Under leverage, the gap between the two is the gap between a suggestion and a limit. The prompt can shape behavior, but it should not be the only thing standing between a model's output and a leveraged order. How to build those checks is the subject of upcoming posts in this series, and key permissions are covered in AI trading agents need scoped permissions.

A practical split: when a bot is enough, when an agent needs code-level limits

Neither is better by default. Some rough guidance, for education only:

• A bot can be enough when the job is narrow and the rules are tested: fixed size, fixed market, an explicit exit, and a hard stop on duration or loss. Its rigidity is an asset when the rules are right.

• An agent earns its place when the job needs interpretation, such as summarizing conditions or preparing a trade for a person to approve. The more authority it has over leveraged orders, the more its limits should live in code outside the model.

• Combined setups let an agent propose and deterministic code check, a pattern explored in the proposed decision-layer design, which is a proposed architecture and not a live LeverUp feature.

If an agent is connected to a venue at all, LeverUp's documented route is the One-Click Trading hosted-agent mode, walked through in the Grok Bot trading guide. That guide covers setup; this series covers what to put around it. Post #3 looks at scoped keys and post #4 at pre-trade checks in code. A spending budget is not a leverage limit either, as this Manus Cue explainer argues. For the underlying mechanics, the perpetual futures learning path is a good start.

Closing

Leverage does not make bots or agents good or bad. It makes their characteristic mistakes more expensive: a bot's rigidity, an agent's inconsistency, and for both, the cost of time and the venue's control over the exit.

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 pricing and order execution, VMMV settlement, protocol risk controls, and liquidation.

This article is educational and is not financial advice. Perpetual futures use leverage and can result in the loss of your margin.

Originally published on the LeverUp Blog.

Agent products such as Grok Bot run tasks from a cloud computer, which makes them a concrete place where a trading key could end up. Grok's launch page does not mention trading, crypto or leverage, and nothing here claims Grok Bot ships a LeverUp connector. LeverUp's official gasless documentation describes a hosted-agent mode for backend-held signing keys. Our tutorial, How to Build a Grok Bot Trading Agent on LeverUp, explores that setup.

This post is the third in the Agentic Trading on Perps series. The second, AI Trading Bot vs AI Agent on Perps, covered how leverage changes failure modes. Here the question is narrower: when you hand an agent a key, what can that key do to a leveraged perp position, and what can it not do?

For the general argument for why agent access should be narrow, see AI Trading Agents Need Scoped Permissions. This post does not repeat it. It stays on the permission layers and on LeverUp's documented boundaries.

Three layers of access

"The agent has access" can mean three different things. Treating them as one is a common source of confusion.

1. Read access. The agent can see prices, markets, positions, history and portfolio data. It cannot change anything.

2. Trade-intent access. The agent can submit instructions to open, close or adjust positions, but only inside the account's existing structure.

3. Collateral movement. The agent can transfer tokens out of a wallet or withdraw funds. This is the layer that turns a bad trading day into an empty account.

A well-scoped agent key sits on layer 1, layer 2, or both. It does not reach layer 3. Whether a given system actually enforces that split is a property of the venue, not of the agent, which is why the rest of this post reads the documentation instead of assuming.

What "scoped" means for a perp position

A perp position is a bundle of choices: direction, size, leverage, margin, and optional take-profit and stop-loss orders. A scoped key can be allowed to touch some of those and not others. In practice, the sensible questions are:

• Can the key open new positions, or only close existing ones?

• Can it adjust (add margin, change TP/SL), or is the position fixed once opened?

• Can it reduce collateral on a position?

• Is it limited to specific actions at all, or does it hold a wildcard?

The answers decide the worst case. A key that can only close positions can end exposure but cannot create it. A key that can open positions can create leveraged exposure using whatever collateral the account has made available. Those are very different risks, and a prompt asking the agent to "be careful" changes neither.

LeverUp's 1CT hosted-agent boundaries, as documented

LeverUp's gasless interface, One-Click Trading (1CT), lets a trader authorize a signing key once onchain. After that, each order is an offchain EIP-712 signature that the protocol relays and executes, according to the gasless overview. The same page lists a "hosted agent" mode: a key your backend holds, authorized with authorizeAgent(botAddress, …) and "optionally restricted per action."

The gasless overview states the boundary plainly: the signing key "can only express trading intent. It cannot transfer tokens, cannot withdraw, and cannot act outside the permission bits the user granted." The overview also says the main wallet key is not used after setup.

The permissions themselves are set in the authorization docs:

• authorizeAgent(agent, name, permissions) is a one-time transaction from the trader's main wallet.

• permissions is a bitmask where bit n grants action n. The docs' examples show MARKET_OPEN as bit 0 and MARKET_CLOSE as bit 1, so an open-and-close-only agent is a two-bit mask.

• type(uint256).max is a wildcard that skips per-bit checking and grants everything. Any other value is checked bit by bit.

• A trader can have several agents, each with its own name and permissions.

• The same call can update an agent's permissions later, and separate functions revoke one agent, an agent by name, or all agents.

Two details matter for scoping. First, an explicit mask is a snapshot: the authorization docs say an agent authorized before a new action existed does not hold that action's bit, while a wildcard agent picks up new actions automatically. A wildcard therefore grows with the protocol; a narrow mask does not. Second, the docs' own example of "everything except one action" is written as noWithdraw, excluding REMOVE_MARGIN. That is the docs' label for the mask. This post does not characterize where removed margin goes, because the pages reviewed do not say. The takeaway is simpler: margin removal is a separate bit, and an operator who wants an agent that cannot touch it has to leave it out explicitly.

The gasless overview lists fourteen operations the interface supports, including market and limit open, market, batch and partial close, add and remove margin, and several TP/SL create, update and cancel actions. The permissions page does not publish a separate, smaller "safe subset." Which of those fourteen an agent receives is the trader's call.

The step-by-step setup is in the Grok Bot guide, so it is not repeated here. One short pointer: the Agent Wallet Manager in the app lets a trader paste an agent address, name it, tick individual actions, and later update or revoke it. The docs say the app does not ask for the private key.

Authorization is also not the same as funding. The authorization page states that it "grants permission to trade, not to move tokens," and that the trader must still approve the Diamond contract for the collateral token and the execution fee token. Without those approvals, intents are accepted by the endpoint and then skipped onchain.

Read-only data needs no trading permission

Layer 1 is separate from layer 2. LeverUp's REST API at service.leverup.xyz is described as "read-only HTTP access to prices, markets, positions, trade history, portfolio analytics and leaderboards," with no authentication required. Open positions and portfolio data for an address are among its endpoints. The same page says placing trades goes through the onchain or gasless routes instead.

That gives an agent builder a clean split. A research or monitoring agent can read positions and prices with no trading key at all. A second component, with a narrow mask, can be given the ability to submit intents. Keeping those apart means a compromised reader holds nothing that can place an order. The REST API docs ask integrators to cache where permitted and poll no more than once per second per endpoint; that is a rate courtesy, not a security feature.

If a scoped key leaks: what an attacker can and cannot do

Take a hosted-agent key whose mask covers market open and market close only. Using the documentation, here is the bounded picture. Items marked assumption are reasoning from the docs, not statements in them.

Cannot, per the gasless overview: transfer tokens, withdraw, or take an action whose bit was not granted. Those are the stated limits of a signing key.

Can, within the granted bits: submit signed intents to open or close positions on that trader's behalf, as described in the authorization docs. For a leveraged account, that is the real exposure. An attacker with open permission can create positions in markets the interface supports, and market-close permission can end positions the trader meant to hold. The permitted actions expose the trader to trading losses and fees; the key has no direct token-transfer permission. Positions remain subject to LeverUp's documented liquidation conditions; how liquidations work on LeverUp explains the mechanics.

Bounded by approvals (assumption): because the authorization docs say intents are skipped without the collateral and fee-token approvals, the size of the Diamond's allowance on the trader's wallet plausibly caps how much collateral an intent can draw. The pages reviewed do not spell this out as a security control, so treat it as inference, and check the allowance you have set.

Stopped by revocation: the trader can call revokeAgent, revokeAgentByName or revokeAllAgents from the main wallet, as described in the authorization docs. The docs warn to revoke onchain and wait for the receipt before deleting local key material, because the reverse order leaves a live authorization on a key nobody holds. Revocation stops future intents. It does not undo intents that already executed (assumption, from how onchain execution works; the pages reviewed do not address it).

Not described in the gasless overview or authorization docs reviewed: an expiry on authorizations, per-key size or leverage limits, or alerting on unusual intents. Absence from the docs reviewed is not proof that nothing exists. It means this post makes no claim either way.

The practical reading is narrower than "the agent could drain me" and narrower than "scoped keys make this safe." Restricting a key to opening and closing positions narrows its permitted actions, but does not cap the trading losses or fees those actions can cause.

Prompts still are not risk rules

A scoped key answers what the agent may do. It does not answer how much, how often, or under what conditions. An instruction like "keep leverage low" lives in a prompt; the permission bit for market open does not know about it. Turning those judgments into rules enforced outside the model is its own topic, and a later post in this series takes it up. For now the point is that permissions and risk limits are separate layers, and a key can be perfectly scoped while the position it opens is far too large for the account.

If you are new to the series, start with the hub post, then the bot versus agent comparison.

Closing

Read, trade and withdraw are different permissions, and a perp position is exposed mainly through the middle one. LeverUp's gasless overview puts the signing key on the trade-intent side and states that it cannot transfer or withdraw, with the specific bits left to the trader. Read those pages directly before relying on any summary, including this one.

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 VMMV settlement, protocol risk controls, and gasless execution.

Originally published on the LeverUp Blog.

Most agent setups start with a system prompt: keep leverage modest, avoid oversized positions, stop trading after a bad day. That is a request, not a rule. A language model reads it as one more piece of text, weighs it against everything else in its context, and can be argued out of it by a tool result, a user message, or its own earlier reasoning.

This is the fourth post in the Agentic Trading on Perps series. The second, AI Trading Bot vs AI Agent on Perps, covered how leverage changes failure modes. The third, Scoped Keys and Delegated Access, covered what a key lets an agent do. This one covers the layer in between: how much, how often, and under what conditions, enforced by code the model does not control.

Four knobs that belong in code

A risk budget becomes a guardrail when it is a number in a config file that a plain function checks before any order leaves the system. Four are worth separating.

1. Max leverage. A hard ceiling on the leverage of any single order. If the requested leverage is above the cap, the order is rejected, not trimmed silently.

2. Max notional. A ceiling on position size, both per order and in total across open positions. Notional exposure equals margin multiplied by leverage, so a leverage cap alone does not bound exposure.

3. Max daily loss. A realized-plus-unrealized loss limit over a rolling window. When it is hit, the system stops opening new positions and flags a human.

4. Human-confirm gates. Conditions under which the code pauses and asks a person: an order above a notional threshold, a first trade in a new market, a change to any limit, a request that would reduce margin on an open position.

Where these numbers sit is your decision, and this post does not suggest values. All figures below are an assumed example to show arithmetic, not a recommendation.

The order of derivation matters. Start from the loss you can accept (the risk budget), derive the notional that fits it, and only then read off the leverage cap. Starting from a leverage number and hoping the rest works out reverses the logic, because leverage describes how thinly a position is margined, not how much you can lose.

Why the model must not own write access

The point of a guardrail is that it holds when the model is wrong, confused, or manipulated. That only works if the model cannot change it.

• Separate the config. Limits live in a file or service that the agent's tool set has no write path to. The model can read the limits to explain a rejection; it cannot edit them.

• Separate the check from the intent. The model proposes {market, side, size, leverage}. A deterministic function approves or rejects. The model does not call the order endpoint directly.

• Treat rejection as final within a run. If a rejection can be retried with a reworded request until it passes, the check is a suggestion. Rejections should be logged and should not feed back as "try a smaller number until it works."

• Put limit changes behind a human. Raising a cap is a human-confirm event, performed outside the agent's session.

This is the same principle as scoped permissions, applied to size instead of access. Scoped keys limit which actions exist. Guardrails limit how large those actions can be.

LeverUp margin and liquidation distance

The guardrails above need real mechanics to check against. These are the documented LeverUp ones that affect each knob, all taken from the docs.

Margin is per position. LeverUp's opening-a-position docs describe collateral type, exposure size and leverage as choices made per position, and say positions with different margin tokens are separate. Our comparison, Cross Margin vs Isolated Margin, explains why that behaves much like isolated margin. For guardrails, it means a notional cap should be computed per position and in aggregate, since the account-level picture is the sum of separate positions.

Positions on the same pair merge. The opening-a-position docs say that opening again in the same direction on the same pair with the same margin token adds to the existing position: quantity and margin are summed and the entry price becomes the quantity-weighted average. A check that only looks at the new order's size can pass an order that pushes the merged position over the cap. The check should evaluate the post-merge position.

Liquidation distance depends on leverage. The liquidation docs say a position is liquidated when the price reaches the liquidation price or when collateral cannot cover outstanding fees. They give the loss rate as set per pair: 85% on most pairs, 80% on the high-leverage pairs and a few others. The simplified condition is that total loss and fees reach the threshold times the position margin.

Assumed example: linear exposure, constant USD collateral price, and fees ignored. Adverse price moves are measured from entry. Take an 85% threshold from the liquidation docs. Margin is notional divided by leverage, so the loss that triggers liquidation is roughly 0.85 divided by leverage, as a fraction of notional:

The numbers only show the shape: the same price move that leaves a low-leverage position intact can liquidate a higher-leverage one. Close and holding fees reduce the liquidation buffer; funding paid reduces it further, while funding received can increase it. The liquidation formula accounts for these amounts. A guardrail can use that relationship to reject orders whose liquidation distance is narrower than a distance you chose in advance, which is a more direct control than a bare leverage number.

Fees accrue while a position is open. The holding and funding docs describe a holding fee that accrues per second on notional and is charged at close, and a funding fee paid by the crowded side. Both are part of the liquidation condition. An always-on agent that holds positions should have these counted in its loss limit; later posts in this series return to this.

Two edge cases for the confirm gate. The ADL docs say leverage-based checks apply only to positions opened on the current UTC day. For those positions, adding enough margin to bring effective leverage below 1x can trigger an automatic close. The opening-a-position docs also note a take-profit cap of 550% of PnL and open-interest caps that can temporarily suspend new positions in a direction. A pre-trade check should treat "order rejected by the venue" as a normal outcome rather than an error to retry blindly.

The protocol's own risk controls are a different layer. LeverUp's risk controls page describes protocol-side abuse detection and states that detection thresholds are not published. That is the protocol managing its own risk. It is not your risk budget, and nothing there caps a single trader's size or loss to a level you chose. Your limits are yours to write.

A minimal pre-trade check sequence

Pseudocode-level, not a bot. The shape is what matters: the model proposes, the gate disposes, and each branch is logged.

proposal = model.propose()                 # {market, side, size, leverage}

if proposal.market not in ALLOWED_MARKETS:       reject("market")
if proposal.leverage > MAX_LEVERAGE:             reject("leverage")

merged = merge_with_open_position(proposal)      # same pair, side, margin token
if merged.notional > MAX_NOTIONAL_PER_POSITION:  reject("position notional")
post_trade = replace_matched_position(open, merged)
if total_notional(post_trade) > MAX_TOTAL:        reject("total notional")

if liq_distance(merged) < MIN_LIQ_DISTANCE:      reject("liquidation distance")

if loss_over_rolling_window() >= MAX_DAILY_LOSS:  halt_and_alert()

if needs_human(merged, proposal):                queue_for_confirm()
else:                                            submit(proposal)

A few notes on this sequence:

• Order matters. Cheap structural checks first (market, leverage), then checks that need state (merge, totals), then the loss limit, then the human gate.

• halt_and_alert is a state, not a retry. After the daily limit is hit, the loop stops opening positions until a human resets it.

• needs_human covers anything unusual: a new market, a size above a review threshold, any request to remove margin, any proposal following several rejections.

• Fail closed. If the price feed, position read or loss calculation errors, the answer is "reject," not "assume zero."

Where E9's proposed decision layer fits

Our earlier post, AI Trading Agents Need a Decision Layer, describes a proposed architecture: a bounded model answering constrained questions, with code enforcing hard limits and a protocol that executes only authorized actions. It is a design discussion, not a live LeverUp feature or integration. The checks in this post are the "code for hard limits" part of that picture. Whatever sits upstream, whether a large model, a small decision model or a person, these gates sit downstream of it and apply the same way.

What comes next

Scoped keys decide what an agent may do. Guardrails decide how much of it can happen. The loss limit should include accrued fees; the next posts examine those costs and longer holding periods in more detail. Post six covers funding and holding costs for an always-on agent, and post seven covers what happens when positions are held overnight.

Closing

A guardrail is a number the model cannot change, checked by code the model does not run. The arithmetic in this post is assumed and the mechanics come from LeverUp's documentation, so read the liquidation and opening-a-position pages directly and confirm current parameters before encoding 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 VMMV settlement, protocol risk controls, and liquidation.

Originally published on the LeverUp Blog.

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.

Originally published on the LeverUp Blog.

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).

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.

Originally published on the LeverUp Blog.

Meta's assistant, Muse, supports connectors to apps and services. Public's MCP page documents connecting Muse to a Public account for trading; that is not a LeverUp integration. This post compares approval with pre-authorization. What they do show is a pattern worth understanding before any agent touches a leveraged position: how much of the decision stays with a human at the moment an order is placed.

Two clarifications up front. "Muse Wonder" is a model series, not a trading product. Meta's research post describes it as a model for personal and professional agents, and its examples are a running plan, custom merchandise and a seating chart. It does not describe trading. And nothing in this article says Meta Muse, or any other consumer assistant, connects to LeverUp. We are not aware of any such connector, partnership or endorsement, and none is implied.

This is the eighth post in the Agentic Trading on Perps series. Earlier posts covered what scoped keys can do to a perp position. Here the narrower question is about delegation models: approving each action versus authorizing a key in advance.

Two ways to delegate

Strip away the branding and there are two common designs.

Approve each order. The agent proposes, a human confirms, and only then does anything execute. The agent can research, draft and prepare, but every consequential action passes through a person at that moment. The human is a gate on each action.

Pre-authorize a scoped key. The human grants a signing key permission once, within limits. After that, the agent acts without a per-order prompt, inside whatever the grant allows. The human is a gate on the setup, and on whatever monitoring and revocation they do afterwards.

Neither is automatically safer. They fail differently.

An approval prompt is only as protective as the attention behind it. A scope is only as protective as the care taken when it was written. The rest of this post looks at where each model shows up.

Consumer assistants: a pattern of approval by default

Meta's Help Center page on Connectors says Muse can connect to services through Settings, and states that by default Muse "will not take many important actions, such as sending an email, without your approval." The page adds that this can be changed in Settings and that many connectors can be limited to retrieving data. It also says Meta does not review custom connectors or how they use your information, and that credentials for custom connectors are held in a secure credentials store. The page does not mention brokerage or trading, and we do not extrapolate from it.

Meta's research post says something similar at the model level: the Muse Wonder description says the model "asks for clarification when needed and checks in before taking important actions." That is a statement about a model's design intent, not a guarantee about any specific product setting.

So the pattern, in the generic sense, is: an assistant plus a connector to an outside service, with a human approval step for important actions that the user can loosen or tighten.

Brokerage connectors: one third-party example, with its own terms

The same pattern appears in brokerage. Public.com publishes an MCP trading page describing how outside AI assistants can connect to a Public brokerage account. This is a third-party brokerage connector, not LeverUp — an industry-pattern example only.

Its terms are worth reading closely, because they show the approval question is not settled by the word "connector." As of 2026-10-29, the Public.com MCP trading page says that by connecting an AI agent you authorize it to view your account data and place trades on your behalf, and that trades "may be executed by your AI agent without your direct input on each transaction." It also says Public does not supervise or audit third-party AI agents. The page includes setup text a user can send to an assistant that says "never place trades without my explicit confirmation," but that is an instruction the user chooses to give, not a requirement the page describes as built in. The page does not state a publication date.

The takeaway is not about Public in particular. It is that "human approval" can live in several places: in the assistant's defaults, in an instruction you type, or in the connector's own rules. If you cannot say which one applies, you do not yet know what approval means in your setup.

What LeverUp's hosted-agent model actually is

LeverUp's documented agent surface is different in kind. The gasless trading (1CT) overview describes One-Click Trading as letting a user authorize a signing key once, onchain, and then trade without wallet popups and without paying gas. After the authorization, "every subsequent order is an offchain EIP-712 signature that the protocol relays and executes."

That is the pre-authorized model from the table. Some details from the docs:

• One authorization, many orders. The authorization page describes a one-time onchain transaction from the trader's main wallet that grants a signing key permission to submit trade intents on their behalf.

• Scoped by permission bits. The authorization documentation describes a permissions bitmask, where each bit corresponds to an action. The docs show examples such as allowing only market opens, or market opens plus market closes, and note that the maximum value acts as a wildcard.

• Limited to trading intent. The 1CT overview says the signing key "can only express trading intent": it cannot transfer tokens, cannot withdraw, and cannot act outside the permission bits granted.

• Revocable. The authorization page lists functions to update permissions and to revoke an agent, and notes the app has an Agent Wallet Manager for inspecting and revoking authorizations.

• Hosted agent mode. The 1CT overview lists a "hosted agent" integration mode, a key held by a backend, with authorization that can be restricted per action.

The step-by-step setup is in our tutorial, How to Build a Grok Bot Trading Agent on LeverUp. This post does not repeat it, and it is not evidence that Grok Bot or any consumer assistant ships a LeverUp connector. It is a worked example of one developer pattern, in which you hold the key and the agent is code you control.

Two cautions from the authorization documentation. First, authorization grants permission to trade, not to move tokens; the trader still approves the protocol contract for the collateral and fee tokens. Second, the wildcard value is not "everything except what I forgot." An explicit mask is a snapshot, and the docs explain how new actions interact with older masks. Read the authorization page before choosing a scope.

What human approval still means after a key is authorized

Pre-authorization does not remove the human. It moves the human's job.

• Scope design. The permissions you pick are the approval you gave in advance. A key limited to opening and closing is a smaller decision than a wildcard.

• Capital design. LeverUp's authorization documentation separates agent action permissions from the trader's token approvals to the Diamond contract. Review permissions, token allowances and available collateral together. Neither action permissions nor initial funding set a cumulative-loss budget. Post #3 and our earlier piece on scoped permissions for trading agents go deeper.

• Monitoring. A position opened without a prompt still has to be watched. Nothing about a signing key tells you whether the agent's reasoning was sound.

• Revocation. The authorization documentation lists onchain revocation functions and warns to revoke and wait for the receipt before deleting local key material.

In the approve-each-order world, the human's job is attention. In the scoped-key world, it is engineering and housekeeping. Many people would find the second easier to get wrong, because nothing prompts them to revisit it.

Why the distinction matters under leverage

An unleveraged spot purchase and a leveraged position expose capital differently. Leverage creates notional larger than posted margin, so an adverse move can consume that margin faster. LeverUp's liquidation documentation describes liquidation when the market reaches the liquidation price or collateral becomes insufficient to cover outstanding fees. Its holding documentation explains ongoing holding and funding charges. Approving an opening order does not end the position's continuing risk.

That changes what an approval prompt is worth. A single "confirm" tap on an order tells you the size and direction, but it may not tell you how much margin buffer remains once fees accrue, what happens overnight, or how the position interacts with others. Our posts on funding and holding costs and liquidation and fee drift cover those pieces.

Likewise, a pre-authorized key under leverage can submit a series of orders without per-order approval. LeverUp's documented permission bits restrict action types; they do not specify a user-selected notional, leverage or cumulative-loss budget. Exposure controls need separate enforcement beside the protocol's market risk controls.

A few questions help in either model:

1. Where exactly does approval happen, and can I point to the setting or the instruction that enforces it?

2. If the agent is wrong, what is the largest thing it can do before a human notices?

3. Can I revoke quickly, and have I tested that?

4. Does anything outside the agent, such as a margin limit or a size limit, hold even if the agent misbehaves?

Closing

"Human in the loop" and "delegated key" describe two different designs, and an industry full of connectors uses both. Meta describes configurable approval defaults, while Public's MCP disclosure permits trades without direct input on each transaction. LeverUp's hosted-agent mode uses a backend-held signing key with onchain authorization, action permissions and revocation. None of this means one assistant or another works with LeverUp. Products and terms change; re-open the primary pages before relying on them.

For the series start, 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 VMMV-based settlement, oracle-referenced pricing, relayed execution and protocol risk controls.

Originally published on the LeverUp Blog.

Why It Matters

A signed index changes what a user is asked to trust. The product page says a value can be checked against a verifier contract on the chain, so a party does not have to rely on whoever relayed it. The same product page lists mark price, margin, liquidation and settlement among the uses of an index price, and says the applications it describes are illustrative. A reasonable reading is that signing shifts scrutiny from the relay path toward the index methodology itself. That is an interpretation, not a claim the page makes. For a perpetual venue it could matter because one value can sit behind mark price, margin and liquidation at once, so a question about a single number can spread to several outcomes.

The second change is the type of reference. CoinDesk reports that the provider's indices underpin BlackRock's Bitcoin ETF and CME Group crypto futures, and the company says its indices are used by products representing more than $120 billion in assets. If an onchain perpetual venue adopts such an index, its margin and liquidation inputs could match a reference already used in those products. Whether a venue does so depends on its own design and agreements. Matching those references would be a choice the venue makes about its inputs, not something the oracle itself decides on the venue's behalf.

The limits matter as much. The provider's Disclaimer and Disclosures says its parent group's crypto exchange is a source of input data for certain indices, so readers may want to look at how index inputs are chosen. CoinDesk adds that the oracle will not issue funds or handle trades itself and supplies reference prices. A signature shows where a value originated and that it was not altered along the way. It does not show that a price suits a fast market, and the venue still owns its own margin, liquidation and settlement rules, so basis, funding costs and margin rules continue to matter for traders. Anyone weighing a venue that adopts a signed index may want to ask which index it uses, how often values update, and what happens when a value is unavailable.

Go deeper

• Oracle Price Integrity and Permissioned Validators — how oracle design shapes the prices behind execution.

• What Is Oracle Pricing in DeFi? — the basics of how onchain markets obtain reference prices.

On LeverUp, perpetual futures trade through a protocol-managed virtual liquidity architecture.

Originally published on the LeverUp Blog.