Roadmap
Off-chain venues (roadmap)
A sketch for letting an agent trade a perp venue whose order book lives off-chain, without the strategy contract ever holding a hot key to the vault itself.
No contract exists for this yet. This page describes a direction, not a shipped feature or a commitment to a specific venue or date. Nothing here should be read as a live integration.
Why an on-chain strategy is not enough
PortfolioStrategy covers venues where a swap settles on-chain in the same
transaction — the contract can see the fill, so it can also bound the slippage. Order-book
perps on venues like Lighter do not work that way: matching happens off-chain in the venue's own
sequencer, and the strategy contract never sees a trade. It cannot cap position size, leverage,
or trade rate the way it caps a swap.
The custody problem changes shape as a result. On PortfolioStrategy the contract
is the trader. Here the agent has to be the trader, because the venue speaks to whoever holds the
account's key — which means the question is no longer "can the contract validate the trade"
but "what can the key that trades actually do."
The custody boundary this would need
The shape most worth building toward: the strategy clone opens and owns the venue account itself. It deposits vault capital as margin, then registers a scoped, trade-only key for the agent — one that can place and cancel orders and nothing else. It cannot withdraw, cannot transfer, cannot register a different key. Every one of those stays authenticated to the clone, not the agent.
| Holds | Can | Cannot |
|---|---|---|
| Agent's key | Place and cancel orders | Withdraw, transfer, rotate keys |
| Strategy clone | Cancel orders, force-close, rotate/revoke the key, queue withdrawal | Skip the vault on the way back — exits only ever land there |
That bounds how long capital can be exposed to a bad key — the clone can always cancel, close, and pull funds out without the agent's cooperation. It does not bound how much a live position can lose while it's open, because nothing on-chain is watching the trade happen. The real risk limit is how much a proposal is allowed to deposit in the first place, not anything the contract enforces mid-trade.
Why settlement would have to be async
Secure withdrawals from an off-chain order book don't clear instantly — they queue and mature, sometimes well after the position is flat. A fund running this can't price that position for a mid-proposal deposit or redemption the way it prices an on-chain swap; both would have to wait behind the same queue the strategy itself is waiting on. That's a real cost to communicate to depositors before it ships, not after.
None of this is scheduled. It's here because the gap between "agent trades an AMM" and "agent trades an order book" is a custody-model problem, not a feature-flag, and it's worth thinking through in the open before it's a live contract instead of after.