> For the complete documentation index, see [llms.txt](https://docs.anchored.finance/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.anchored.finance/trading-api/trading/one-click-security-ux.md).

# One Click Security and API Semantics

One Click reduces repeated wallet prompts by letting a delegated service submit router transactions for a user. It does **not** change the underlying trading contracts: orders, deposits, withdrawals, and cancels still go through `StockRouter`.

## Mental Model

```mermaid
flowchart LR
    U[User wallet] -->|signs EIP-712 Delegate| API[Trading API]
    API -->|enable| OCR[OneClickRouter]
    D[Delegatee service] -->|execute as user| OCR
    OCR -->|ERC-2771 forward| R[StockRouter]
    R --> S[Cashier and Stock]
```

The user signs a typed delegation message. The delegatee service can then forward allowed router calls through `OneClickRouter`. The downstream router resolves the original user through ERC-2771 forwarding.

## Authorization Scope

Before enabling One Click, the integration should treat the delegation as a scoped transaction authorization:

* The delegatee can submit supported RWA trading router calls.
* The delegatee can place orders, cancel orders, deposit, and withdraw through allowed `/send` flows.
* The authorization is tied to the chain, OneClickRouter, delegatee, nonce, and deadline in the EIP-712 payload.
* Delegation can be disabled.

## API Flow

```mermaid
sequenceDiagram
    participant Client
    participant API as Trading API
    participant User
    participant OCR as OneClickRouter

    Client->>API: GET /1ct/status
    API-->>Client: status and delegatee
    Client->>API: POST /1ct/prepare
    API-->>Client: EIP-712 signPayload
    Client->>User: Request typed-data signature
    User-->>Client: signature
    Client->>API: POST /1ct/enable
    API->>OCR: delegateBySig
    API-->>Client: enabled
```

## Implementation Rules

| Rule                                            | Why                                                                      |
| ----------------------------------------------- | ------------------------------------------------------------------------ |
| Verify signer equals `signPayload.message.user` | Prevent enabling delegation for the wrong wallet                         |
| Use the returned `deadline` exactly             | It is part of the signed payload                                         |
| Treat nonce as single-use                       | Reusing old signatures should fail                                       |
| Check `/1ct/status` before `/send`              | Avoid avoidable send failures                                            |
| Keep `userAddress` binding explicit             | `/send` uses the API key bound user, not arbitrary request `userAddress` |
| Always support disable                          | Users need a clear recovery path                                         |

## API States

Treat One Click as a small API state machine: not enabled, preparing, signature requested, enabled, and disable pending. The only state that should allow `/send` endpoints is `Enabled`.

State mapping:

| State               | Integration handling                                       |
| ------------------- | ---------------------------------------------------------- |
| Not enabled         | Do not call `/send`; use `/calldata` or prepare delegation |
| Preparing           | Call `/1ct/prepare` and request typed-data signature       |
| Signature requested | Wait for a valid user signature                            |
| Enabled             | `/send` endpoints can be used                              |
| Disable pending     | Do not assume future `/send` requests will succeed         |

## Deposit Caveat

One Click does not remove ERC-20 approval requirements. For `/cash/deposits/send`, the API key bound `userAddress` must still approve the cash token spender.

## Risk Boundaries

One Click should be treated as a powerful trading authorization:

* Do not hide the delegatee address.
* Do not reuse signatures across chains or routers.
* Do not submit `/send` for a different user than the bound `userAddress`.
* Log `uuid`, `txHash`, and operation/order IDs for audit.

## Related Docs

| Need                   | Doc                                                                          |
| ---------------------- | ---------------------------------------------------------------------------- |
| Endpoint details       | [one-click-delegated.md](/trading-api/trading/one-click-delegated.md)        |
| End-to-end flow        | [../guides/one-click-flow.md](/trading-api/guides/one-click-flow.md)         |
| viem typed-data sample | [../guides/demo-code.md](/trading-api/guides/demo-code.md)                   |
| Troubleshooting        | [../reference/troubleshooting.md](/trading-api/reference/troubleshooting.md) |