> For the complete documentation index, see [llms.txt](https://nytshift.gitbook.io/nytshift-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://nytshift.gitbook.io/nytshift-docs/design-decisions-and-proposals/arcus-lighter-offline-execution-contracts-v1.md).

# Arcus and Lighter offline execution contracts v1

Status: offline implementation only. No route, signer, credential, account, wallet, testnet, order, leverage or production capability is enabled.

## Reviewed source pins

The contracts fail closed when the supplied official-document digest differs from the reviewed value.

| Venue/source                | SHA-256 observed 2026-08-05                                        |
| --------------------------- | ------------------------------------------------------------------ |
| Arcus place-order Markdown  | `f45b312147273d5bfa3811fb2e7dc6821f290557ce9174f34d2d5ab54740a20e` |
| Arcus set-leverage Markdown | `ecfa195b9bc7a967df545b552cac6b10cbe8a4b1efd39734baf48a5de99531a1` |
| Lighter trading Markdown    | `83317049946f3d7a0f071d39670db3cd527f855355d0dce9ed49be191b1bf776` |
| Lighter API-key Markdown    | `bab2550edb0d8c254c07c938116787c3685771cd441a73320f161e6dc4e7863d` |
| Lighter WebSocket Markdown  | `2918ab407dd03ff3a5f314458b6b1baa7f3c51a38426353101882ad027b69504` |

Sources:

* <https://docs.arcus.xyz/api-reference/exchange/place-order.md>
* <https://docs.arcus.xyz/api-reference/exchange/set-leverage-for-a-market.md>
* <https://apidocs.lighter.xyz/docs/trading.md>
* <https://apidocs.lighter.xyz/docs/api-keys.md>
* <https://apidocs.lighter.xyz/docs/websocket-reference.md>

## Arcus delivered no-send boundary

`apps/web/app/lib/arcus-native-risk-plan.ts` adds pure validation for native TP/SL and leverage planning. It is deliberately not imported by a route or signer.

TP/SL validation requires:

* a fresh online exact market and the pinned place-order document;
* an exact live position, reducing side and reduce-only semantics;
* supported `STOP_LOSS` / `TAKE_PROFIT` purpose separated from `LIMIT` / `MARKET` execution style;
* MARKET+IOC or LIMIT+GTT compatibility;
* trigger on the non-immediate side of the oracle;
* MARKET protective price within the documented 10% of the trigger;
* step-aligned partial quantity no larger than the position, or zero quantity for a position-level engine-sized TP/SL;
* exclusive position/entry grouping and at most one position-level trigger per class.

Even a ready plan retains `executionCapability: none`. Single-order TP/SL is explicitly unsupported by Arcus; a future implementation needs batch `placeUntriggered` typed signing (`op=4`), grouping and orders/user-fills reconciliation.

Leverage planning requires the pinned set-leverage document, fresh exact market/account scope, integer leverage within the venue maximum and the current NYTSHIFT 2x cap. Lowering leverage with an open position requires a proved margin-sufficient result. HTTP 202/`ACK` is never final; a future signer must reconcile `accountAttributes` until the effective value is `APPLIED` or the request is definitively rejected.

## Lighter delivered deny-by-default boundary

`apps/web/app/lib/lighter-offline-execution-plan.ts` validates a non-secret order shape while always returning `state: blocked`, `executionCapability: none` and `approvedForExecution: false`.

The shape enforces:

* all three pinned documents;
* a user API-key index outside the four reserved UI indexes;
* one exact sequential uint48 nonce with `SkipNonce` disabled;
* uint48 client-order identity and nonnegative account/market indexes;
* integer-native positive size/price, current minimum-base evidence and an explicit minimum-quote attestation;
* conditional trigger presence, reduce-only direction and size bounded by the exact current position;
* expiry between five minutes and thirty days; and
* current NYTSHIFT leverage no higher than 2x and no higher than venue maximum.

The implementation intentionally does not generate a signature, auth token or transaction payload. Lighter API keys can authorize writes and secure withdrawals, each key owns a nonce, API code 200 is syntax acceptance rather than sequencer finality, and authenticated order streams are required for final state. A future testnet implementation therefore needs a dedicated security review, isolated signer, exclusive durable nonce store, narrowly permitted key, authenticated lifecycle reconciliation, emergency cancellation, recovery and action-time owner authorization.

## Promotion gates

1. The two new pure test files passed locally on 2026-08-05.
2. Repeat them in the accepted immutable CI run for the reviewed release.
3. Arcus: implement batch typed signing and leverage as separate reviewed signer methods; add durable unknown-outcome reconciliation and account-bound testnet evidence before enabling any route.
4. Lighter: complete the key-permission/signer dependency review before adding any private credential or mutation code. Read-only production behavior stays unchanged.
5. No venue moves above the existing 2x policy or receives real-money authority without later legal, risk, operational and owner approval.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://nytshift.gitbook.io/nytshift-docs/design-decisions-and-proposals/arcus-lighter-offline-execution-contracts-v1.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
