> For the complete documentation index, see [llms.txt](https://docs.jaawle.xyz/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.jaawle.xyz/product/one-click-trading.md). # One-click trading With one-click trading the wallet signs twice, ever. After that every trade is a signature from a key that lives in the browser, the relayer submits it, and the fee is paid in USDC. No transaction popups, no ETH. ## Enabling it 1. Open the wallet menu and choose **Enable one-click trading**. 2. The terminal generates a **subaccount**: a fresh key that never leaves the browser. It is encrypted with a non-extractable WebCrypto key kept in IndexedDB; the ciphertext lives in local storage for this site only. 3. The wallet is asked for two typed-data signatures (EIP-712), neither of which is a transaction: * a **grant**: which subaccount may act for this account, until when, for how many actions, up to what size per action; * a **USDC permit** (EIP-2612): lets the router pull collateral and deposits from the account. 4. The terminal posts the grant to the relayer, which submits it for free. One-click trading is on. Both signatures work with any wallet: a browser extension (discovered through EIP-6963) or a mobile wallet through WalletConnect. See [Eligibility and identity](/legal/eligibility-and-identity.md). ## What happens on a trade ```mermaid sequenceDiagram participant B as Browser (subaccount key) participant R as Relayer (backend) participant TR as TradeRouter participant P as Protocol B->>B: build the action, sign it with the subaccount B->>R: POST /api/v1/relay (action, signature, optional permit) R->>TR: eth_estimateGas (the contract's own checks) R->>TR: execute(action, signature, permit, fee) [relayer key pays ETH] TR->>TR: deadline · nonce · KYC(account) · fee ≤ cap · grant alive · signature TR->>B: pull the fee in USDC from the account to the relayer TR->>P: increasePositionFor(account, …) / …For(account, …) P-->>B: position keyed to the account; payouts to the account ``` The ticket shows the fee before signing (`fee ≈ $0.25 + network`, in USDC). The action carries the maximum fee the signer accepts; the relayer charges `gas × gas price × ETH/USD × (1 + 20 %)`, never more than that cap, between 0.05 and 5 USDC. Rejections come back as the contract's own error name (for example an expired grant or a notional above the budget) before any gas is spent. The transaction hash appears in the terminal log like any other. ## Budgets The grant is the limit on what a subaccount can ever do. Defaults proposed by the terminal: | Budget | Default | Meaning | | ---------------- | ------- | ------------------------------------------------------------------------------------------------------------------------------ | | `expiresAt` | 7 days | after this, actions are refused until renewed | | `maxActions` | 500 | one is consumed per action, whatever its size | | `maxNotionalUsd` | $50 000 | per action: opens, USDC and stock deposits and index deposits are measured against it; closes, redemptions and cancels are not | Renewal is one signature when the expiry nears or the actions run out (the wallet menu shows both). A new grant replaces the old one. ## Revocation * **Disable** in the wallet menu signs a zero-budget grant, which the relayer submits for free, and forgets the local key. No transaction. * From any wallet, without the terminal: `removeSubaccount(sub)` on the router is a transaction that does the same. * Clearing the site's storage removes the key but not the grant; the grant still expires on its own. ## What the subaccount can and cannot do It can sign these actions for the account: open and close positions (`Increase`, `Decrease`), queue and cancel pool deposits and redemptions (`RequestLiquidity`, `CancelRequest`), queue and cancel index deposits and redemptions (`IndexDeposit`, `IndexRedeem`, `IndexCancel`), and set a take-profit or stop-loss (`SetTrigger`). It can never: * **be a payee.** Every close, redemption and cancel pays the account. The router's `…For(account)` entry points on the PositionManager, the pools and the index vault key positions to the account and pay out to the account; the subaccount address appears nowhere in accounting. * change grants, approvals or KYC. * act past `expiresAt`, past `maxActions`, or above `maxNotionalUsd` per action. * replay: each action carries a sequential nonce and a deadline. * act on an unknown pool. A stolen session key can therefore only churn within the budget until it is revoked; it cannot move funds out. The relayer, for its part, cannot forge or alter an action (the subaccount signed it) or overcharge (the fee is capped by the signature); it can only withhold, and the plain wallet path is always available, which is also the censorship escape hatch. ## Take-profit and stop-loss `SetTrigger(pool, isLong, takeProfit, stopLoss, closeBps)` is a one-click action like the others: the router forwards it to the TriggerBook for the account. The keeper checks triggers against every price it publishes. ## Details * One-click trading needs the account to be on the KYC allowlist; the router checks it on the account, not the subaccount. * The USDC permit is optional on later actions; if the allowance is already in place (or someone front-ran the permit) the router ignores it. * dShare deposits through the router still need a one-time approval of the router by the wallet; the issuer's dShares are not confirmed to support EIP-2612. * `GET /api/v1/relay/state/{account}` gives the terminal the router's domain, nonces, the current grant and fee quotes; `GET /api/v1/relay/history/{account}` lists relayed actions. Every submission is a `job_runs` row of kind `relay`. * Local chains use a mock USDC with permit, like Base's native USDC. --- # 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://docs.jaawle.xyz/product/one-click-trading.md?ask=&goal= ``` `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.