Gasless Trading (1CT)

One-Click Trading lets a user authorize a signing key once, onchain, and then trade without wallet popups and without paying gas. Every subsequent order is an offchain EIP-712 signature that the protocol relays and executes.

	Direct onchain	1CT
Wallet popup per trade	Yes	None
Gas per trade	Trader pays	Protocol pays
Time to submit	Wallet confirmation + broadcast	Sub-second
Oracle payload	You fetch and attach it	Relayer handles it
Main wallet key	Signs every transaction	Never used after setup

How it works

main wallet                 1CT signing key              LeverUp relayer            Diamond
    │                            │                             │                       │
    │ ① authorizeAgent(...)  ────┼─────────────────────────────┼──────────────────────►│
    │    one transaction, once   │                             │                       │
    │                            │                             │                       │
    │ ② click "Long" ───────────►│ EIP-712 sign (silent)       │                       │
    │                            │ POST /v2/trading/submit-intent                      │
    │                            ├────────────────────────────►│                       │
    │                            │                             │ batch + oracle prices │
    │                            │                             ├──────────────────────►│
    │                            │                             │        verify + execute
    │◄────────────── status ─────┴─────────────────────────────┴───────────────────────│

The signing key can only express trading intent. It cannot transfer tokens, cannot withdraw, and cannot act outside the permission bits the user granted. See Security Model.

Integration modes

Mode	Who signs	Authorization	Typical use
Browser key	A key generated and stored in the user's browser	authorizeAgent(localKey, …)	Frontends, wallets
Hosted agent	A key your backend holds	authorizeAgent(botAddress, …), optionally restricted per action	Trading bots, copy trading, managed strategies
Self-signing	The trader's own key	None needed — signer == trader is accepted directly	Backend scripts, CLIs, integrators holding their own key

Self-signing is the fastest way to try 1CT: no authorization transaction, and you still get gas covered and oracle handling done for you.

What you can do

Fourteen operations, covering everything the onchain path supports:

market open · limit open · market close · batch close · partial close · cancel limit order · update limit order TP/SL · add margin · remove margin · update position TP/SL · create TP/SL orders · update TP/SL orders · cancel TP/SL order · cancel all TP/SL orders on a position

Full list with parameters: Actions Reference.

Endpoints

Base URL: https://oneclick-01-keeper.leverup.xyz

Method	Path	Purpose
GET	/v2/trading/anti-ddos-config	Per-action execution fee configuration
POST	/v2/trading/submit-intent?blockchain=MONAD	Submit a signed intent, returns intentHash
GET	/v2/trading/{intent_hash}/status	Poll execution status

Integration steps

Step	What	How often
1	Prepare config — Diamond address, chain id, service URL	once
2	Prepare a signing key	once per user
3	Authorize the agent onchain	once per user (skip when self-signing)
4	Cache the execution fee config	on start, refresh every 60s
5	Build actionData	per trade
6	Sign the intent	per trade
7	Submit and poll	per trade

A working implementation of steps 4–7 is on the Reference Client page.

Prerequisites

• ERC-20 collateral only. Native MON is not supported through 1CT — wrap it to WMON first.
• Approve the Diamond for both your collateral token and the execution fee token, before the first trade. If they are the same token, the allowance must cover amountIn + extraFee + antiDdosFee.
• Referrals work here too. broker and extraFee are carried on every fee-charging action — see Brokers & Referrals.
• Trade parameters (qty at 1e10, prices at 1e18, tokenIn/lvToken pairing) are identical to the onchain path. Read Precision & Units and Core Concepts first.

What is different from onchain

1. You never send oracle data. The relayer fetches it. Intents carry no oracle payload.
2. Execution is batched. Your intent is bundled with others and executed in one transaction.
3. Failures are reported, not reverted. A rejected intent is skipped with a reason string rather than reverting a transaction you sent. See Submit & Track.
4. Closes, margin changes and TP/SL creation require the position to be indexed. The relayer looks the position up to resolve its oracle feeds, so doing one of these immediately after opening can fail with 404 Position not found. Opens are unaffected, and so is cancelling or updating orders — including CANCEL_ALL_DECREASE_ORDERS, which takes a positionHash but needs no lookup. See Actions Reference.

Next: Security Model.