# Injective Trading Frontend UX > Build, review, or debug Injective trading frontend UX for RFQ, orderbook, AuthZ/autosign, wallet-connected trading, USDC balances, trade buttons, search, and user-facing error states. Use this whenever implementing or reviewing a browser trading app on Injective, especially if the UI opens or closes positions, cashes out, uses max leverage, uses RFQ/AuthZ/autosign, displays USDC balances, or handles transaction failures. - Skill: `injectivelabs/injective-trading-frontend-ux` (Agent Skill, multi-file: 4 files) - Install (CLI): `npx skillmds@latest add injectivelabs/injective-trading-frontend-ux` - Raw SKILL.md: https://api.skillmd.com/api/skills/injectivelabs/injective-trading-frontend-ux/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Web & Frontend - License: MIT - Author: injectivelabs (https://skillmd.com/u/injectivelabs) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/injectivelabs/injective-trading-frontend-ux --- # Injective Trading Frontend UX Use this skill when building or reviewing a browser UI that lets users trade on Injective. Pair it with protocol-specific skills such as `injective-frontend-wallet`, `injective-rfq-integrations`, `injective-trading-autosign`, and `injective-usdc-integration` when the task touches those areas. ## Core Rule A trading UI should keep the protocol precise in code and logs, but keep the user flow simple, conservative, and impossible to double-submit accidentally. ## Pre-Ship Checklist ### Trade Submission - Use one in-flight trade lock per active wallet/session for all transaction-producing actions: open, close, cash out, cash out all, cancel, and emergency exits. - Disable every trade button while the lock is held. Release only after the tx is confirmed or the flow fails. - Do not rely on a per-card spinner or per-position loading state to prevent duplicate broadcasts. Two buttons can still race the same account sequence. - Treat `account sequence mismatch` as a likely frontend concurrency or stale-sequence bug before changing chain parameters. - Keep bulk close/cash-out flows sequential unless the signer and sequence manager are proven safe for parallel transactions. ### Wallet, AuthZ, And Autosign Readiness - Distinguish wallet connection from trading readiness. Connected wallet does not imply RFQ/AuthZ/autosign is ready. - Revalidate local session, grantee, or autosign state against the currently connected `inj1` address after connect, account swap, reload, and revoke. - Key local grantee/session storage by granter address. Never let a session from wallet A appear active for wallet B. - For revoke flows, broadcast and confirm the on-chain `MsgRevoke` before clearing local session state. If revoke fails or the user rejects signing, keep the session visible so they can retry. - Show actionable states such as `Authorize wallet`, `Order pending`, or `Order failed, please try again.` Avoid leaking raw message type or signer internals in the primary UI. ### RFQ And Order Errors - Do not expose RFQ IDs, taker addresses, CheckTx logs, account sequence numbers, or raw tx hashes as the main error copy. - Normalize RFQ no-quote timeouts like `no quotes received within wait time [rfqID: ... taker: ...]` to a generic failure message. Log the details for developers. - Prequote or warmup requests are useful for speed, but final click-time submission still needs quote freshness, slippage, maker allowlist, and prepared-input validation. - A matched RFQ is not the same as a confirmed trade. Keep controls locked until settlement is confirmed or failed. ### USDC And Amount Inputs - Default cash/trade amount fields blank. Do not prefill `$100` or any fixed amount; many wallets have less. - Let explicit controls such as Half and All-In fill from the current visible balance. - Truncate displayed USDC balances instead of rounding up, so the UI never implies spendable funds that may not exist. - After a bridge/CCTP/funding tx, a short-lived local balance floor can make the UI less confusing while indexer balances catch up. Clear it once the authoritative balance catches up or the floor expires. - Keep native USDC denoms explicit in code and logs. Injective EVM USDC is `0xa00C59fF5a080D2b954d0c75e46E22a0c371235a`; Cosmos bank denom is `erc20:0xa00C59fF5a080D2b954d0c75e46E22a0c371235a`. ### Market Search And Layout - Prefer search that scrolls to and highlights matching markets while keeping the full market grid rendered. - Avoid filtering to a single result if the grid layout stretches one card across the page. - Use stable card/grid dimensions so search, loading labels, error stamps, and button states do not reshape the trading form. - If search has no match, keep the grid stable and show a compact no-match state near the search control or below the grid. ### Copy Boundaries - User copy should describe what the user can do next, not how the protocol failed internally. - Developer logs can include RFQ ID, taker address, tx hash, rawLog, account number/sequence, and prepared quote diagnostics. - Primary UI copy should stay short: `Enter cash`, `Need cash`, `Order pending`, `Order failed, please try again.`, `Authorize wallet`. ## Good Defaults - Blank amount input with `Enter cash` CTA disabled. - Half / All-In buttons disabled until a positive USDC balance is known. - Global trade lock shared by open and close buttons. - Search shortcut `/` focuses search; results scroll and highlight rather than filtering away context. - Toasts and per-card errors use sanitized messages; raw errors go to console or telemetry. ## When To Use Other Skills - Wallet signing, Injective pubkey types, sequence, and browser wallet errors: use `injective-frontend-wallet`. - RFQ taker implementation details: use `injective-rfq-integrations`. - AuthZ/autosign grants and session trading: use `injective-trading-autosign`. - CCTP/native USDC bridge flows: use `injective-usdc-integration`.