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

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

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.