Onboard, fund, place immediate orders, withdraw, proxy signed Lighter transactions, and deploy Lighter Nautilus strategies through Superior Trade.
npx skills add https://github.com/Superior-Trade/superior-skills --skill lighter
Use this skill for Lighter account onboarding, direct CCTP funding, immediate market orders, signed transaction proxy submission, fast withdrawals, and v3 Nautilus deployments on Superior Trade.
Base URL: https://api.superior.trade
Auth: x-api-key: $SUPERIOR_TRADE_API_KEY
Venue config: { "venue": "lighter", "instrument_id": "<SYMBOL>.LIGHTER" }
SUPERIOR_TRADE_API_KEY.sendTx proxy payload without explicit user confirmation of market, side, size, order type, and risk.sendTx payloads as real trading actions. The proxy forwards the signed transaction; it does not simulate or validate the trading intent.owner_address. An external deposit wallet is only the payer; it does not become the Lighter owner.Lighter does not reuse the Hyperliquid funding flow.
Deposit:
External wallet -> native USDC transfer to Lighter CCTP intent -> Lighter
Ownership and signing:
Superior-managed Privy wallet -> Lighter L1 owner -> Lighter API key index 4
Withdrawal:
Lighter -> fast withdrawal -> external EVM wallet
The Lighter account index is created only after the first credited deposit. Readiness can move through:
needs_deposit -> deposit_pending -> account_created
-> api_key_approving -> ready
-> key_provisioning_unknown
Proceed with live deployment only when the account status is ready.
/v3/account/{address}/lighterOnboard or repair a Lighter account for an owned Superior-managed wallet. After the first credited deposit, this endpoint records the Lighter account index and approves Superior-managed Lighter API key index 4 when needed.
curl -sS -X POST "https://api.superior.trade/v3/account/${OWNER_ADDRESS}/lighter" \
-H "x-api-key: ${SUPERIOR_TRADE_API_KEY}" \
-H "content-type: application/json"
Use this after the first deposit is credited, or when status shows account_ready: true and api_key_ready: false.
Response fields:
account_ready: Lighter account exists and collateral can be read.api_key_ready: Superior-managed Lighter API key is approved and stored.ready: both account_ready and api_key_ready.api_key_approval_tx_hash: Lighter transaction hash for approving API key index 4.If the response status is api_key_approving, poll GET /v3/account/{address}/status/lighter until ready: true or manual review is required.
/v3/account/{address}/status/lighterCheck account and API-key readiness before deposits, signed proxy submissions, withdrawals, or live deployment.
curl -sS "https://api.superior.trade/v3/account/${OWNER_ADDRESS}/status/lighter" \
-H "x-api-key: ${SUPERIOR_TRADE_API_KEY}"
Expected statuses include needs_deposit, deposit_pending, account_created, api_key_approving, key_provisioning_unknown, and ready.
If the status is key_provisioning_unknown, stop and report that manual review is required. Do not rotate keys or retry blindly.
If account_ready: true and api_key_ready: false, call POST /v3/account/{address}/lighter only after the user confirms they want to onboard the account for trading/API-key use.
/v3/portfolio/lighter/balancecurl -sS "https://api.superior.trade/v3/portfolio/lighter/balance?owner_address=${OWNER_ADDRESS}" \
-H "x-api-key: ${SUPERIOR_TRADE_API_KEY}"
Returns the Lighter account balance associated with owner_address. Before the first credited deposit, the API can return zero balance with needs_deposit.
/v3/authorize-and-send/lighterUse placeOrder when the user asks for one immediate Lighter market order, such as "buy $10 ETH". The Superior API resolves the user's owned wallet, loads the stored Lighter API key, signs the Lighter order server-side, and submits it to Lighter. Agents only send SUPERIOR_TRADE_API_KEY; never ask for or handle Lighter API private keys.
Before calling this endpoint, verify:
GET /v3/account/{address}/status/lighter reports ready.GET /v3/portfolio/lighter/balance?owner_address=... shows enough collateral.Show this confirmation before submitting:
Lighter Order Summary:
* Market: [symbol / market_id]
* Side: [buy | sell]
* Quote amount: [amount] USDC
* Max slippage: [fraction, e.g. 0.005 = 0.5%]
* Owner wallet: [owner_address]
This will place a REAL market order on Lighter. Proceed? (yes/no)
Request:
curl -sS -X POST "https://api.superior.trade/v3/authorize-and-send/lighter" \
-H "x-api-key: ${SUPERIOR_TRADE_API_KEY}" \
-H "content-type: application/json" \
-d '{
"action": {
"type": "placeOrder",
"from": "0xSuperiorManagedWallet",
"market_id": 0,
"side": "buy",
"quote_amount": "10",
"max_slippage": "0.005",
"reduce_only": false,
"price_protection": true
}
}'
Notes:
market_id: 0 is ETH perp on Lighter mainnet. Query market metadata before using other ids.quote_amount is USDC notional, not base size.sendTx action remains available only for already-signed Lighter payloads./v3/portfolio/lighter/depositCreates a Lighter intent address for an external wallet to fund directly with native USDC. Funds do not pass through a Superior balance.
Supported source chains: arbitrum, base, avalanche.
Minimum amount: 5 USDC.
Required header: Idempotency-Key with a stable unique value for this deposit attempt.
Before calling this endpoint, show the user:
Lighter Deposit Summary:
* Source chain: [arbitrum | base | avalanche]
* Asset: native USDC
* Amount: [amount] USDC
* Payer wallet: [source_address or user's external wallet]
* Lighter owner: [owner_address]
* Destination: Lighter CCTP intent address returned by the API
This will move REAL USDC from the payer wallet to Lighter. Proceed? (yes/no)
Request:
curl -sS -X POST "https://api.superior.trade/v3/portfolio/lighter/deposit" \
-H "x-api-key: ${SUPERIOR_TRADE_API_KEY}" \
-H "content-type: application/json" \
-H "Idempotency-Key: ${IDEMPOTENCY_KEY}" \
-d '{
"owner_address": "0xSuperiorManagedWallet",
"source_address": "0xOptionalExternalPayer",
"source_chain": "arbitrum",
"amount": "5"
}'
The response includes the chain, native USDC contract, transfer destination, beneficiary owner, and operation id. The user or browser wallet signs the USDC transfer; the API never exports the Superior-managed key for deposits.
/v3/portfolio/lighter/deposit/{depositId}Poll deposit status and reconcile the persisted operation.
curl -sS "https://api.superior.trade/v3/portfolio/lighter/deposit/${DEPOSIT_ID}?owner_address=${OWNER_ADDRESS}" \
-H "x-api-key: ${SUPERIOR_TRADE_API_KEY}"
Reconciliation is read-only and never submits funds.
/v3/portfolio/lighter/withdrawWithdraws Lighter USDC to an external EVM wallet. The API signs with the Superior-managed owner and its encrypted Lighter API key.
Minimum amount: 4 USDC.
Required header: Idempotency-Key with a stable unique value for this withdrawal attempt.
Before calling this endpoint, show the user:
Lighter Withdrawal Summary:
* Asset: USDC
* Amount: [amount] USDC
* Lighter owner: [owner_address]
* Destination: [to_address]
This will move REAL USDC out of Lighter. Ambiguous submissions are recorded as unknown and must be reconciled by polling status. Proceed? (yes/no)
Request:
curl -sS -X POST "https://api.superior.trade/v3/portfolio/lighter/withdraw" \
-H "x-api-key: ${SUPERIOR_TRADE_API_KEY}" \
-H "content-type: application/json" \
-H "Idempotency-Key: ${IDEMPOTENCY_KEY}" \
-d '{
"owner_address": "0xSuperiorManagedWallet",
"to_address": "0xExternalDestination",
"amount": "4"
}'
The API returns 202 when the withdrawal is submitted, replayed, or recorded as unknown for reconciliation. If the response or status is unknown, do not resubmit with a new idempotency key. Poll the withdrawal id.
/v3/portfolio/lighter/withdraw/{withdrawalId}curl -sS "https://api.superior.trade/v3/portfolio/lighter/withdraw/${WITHDRAWAL_ID}?owner_address=${OWNER_ADDRESS}" \
-H "x-api-key: ${SUPERIOR_TRADE_API_KEY}"
Use this to reconcile withdrawal state. Reconciliation never resubmits a withdrawal.
/v3/authorize-and-send/lighterSubmits one pre-signed Lighter transaction payload through Superior Trade's Lighter proxy. This is the next step for placing an order when another component has already produced a signed Lighter tx_type and tx_info.
The proxy:
from wallet is owned by the authenticated user;action.type: "sendTx";tx_type, tx_info, and price_protection to Lighter /api/v1/sendTx;Before submitting an order payload, show the user:
Lighter Order Proxy Summary:
* Owner wallet: [from or default Superior-managed wallet]
* Market: [market/instrument from the order builder]
* Side: [buy/sell or long/short]
* Size: [quantity/notional]
* Order type: [market/limit/etc.]
* Price / limit: [price or N/A]
* Price protection: [true/false]
This will submit a REAL signed Lighter transaction. Proceed? (yes/no)
Request:
curl -sS -X POST "https://api.superior.trade/v3/authorize-and-send/lighter" \
-H "x-api-key: ${SUPERIOR_TRADE_API_KEY}" \
-H "content-type: application/json" \
-d '{
"action": {
"type": "sendTx",
"from": "0xOptionalSuperiorManagedWallet",
"tx_type": 14,
"tx_info": "{\"AccountIndex\":123,\"MarketIndex\":0}",
"price_protection": true
}
}'
Rules:
tx_type or tx_info. They must come from a trusted Lighter order builder/signer.price_protection enabled unless the user explicitly asks to disable it and understands the risk.lighter_error, do not resubmit blindly. Report the error and inspect whether the signed payload, market, price, or account readiness is invalid.GET /v3/account/{address}/status/lighter should report ready: true.Lighter strategy deployment uses the v3 Nautilus deployment API. It is separate from Hyperliquid Freqtrade deployments.
curl -sS -X POST "https://api.superior.trade/v3/deployments" \
-H "x-api-key: ${SUPERIOR_TRADE_API_KEY}" \
-H "content-type: application/json" \
-d '{
"region": "tokyo",
"deployment": {
"code": "class LighterStrategy: pass\n",
"config": {
"venue": "lighter",
"instrument_id": "BTC-PERP.LIGHTER"
}
}
}'
Rules:
config.venue must be exactly lighter.config.instrument_id must be formatted as <symbol>.LIGHTER, for example BTC-PERP.LIGHTER.lighter-tokyo venue profile.curl -sS -X POST "https://api.superior.trade/v3/deployments/${DEPLOYMENT_ID}/credentials" \
-H "x-api-key: ${SUPERIOR_TRADE_API_KEY}" \
-H "content-type: application/json" \
-d '{ "wallet_address": "0xSuperiorManagedWallet" }'
The wallet address must be owned by the authenticated user. The response reports credentials_status: "stored" and exchange: "lighter". It does not return private keys.
Before starting, verify:
GET /v3/account/{address}/status/lighter reports ready.GET /v3/portfolio/lighter/balance?owner_address=... shows enough USDC for the strategy.credentials_status: "stored".Show this confirmation before starting:
Deployment Summary:
* Strategy: [name]
* Exchange: lighter
* Runtime: Nautilus
* Instrument: [instrument_id]
* Owner wallet: [owner_address]
* Lighter balance: [balance] USDC
This will trade with REAL funds on Lighter. Proceed? (yes/no)
Start:
curl -sS -X PATCH "https://api.superior.trade/v3/deployments/${DEPLOYMENT_ID}/status" \
-H "x-api-key: ${SUPERIOR_TRADE_API_KEY}" \
-H "content-type: application/json" \
-d '{ "action": "start" }'
Stop:
curl -sS -X PATCH "https://api.superior.trade/v3/deployments/${DEPLOYMENT_ID}/status" \
-H "x-api-key: ${SUPERIOR_TRADE_API_KEY}" \
-H "content-type: application/json" \
-d '{ "action": "stop" }'
curl -sS "https://api.superior.trade/v3/deployments/${DEPLOYMENT_ID}" \
-H "x-api-key: ${SUPERIOR_TRADE_API_KEY}"
curl -sS "https://api.superior.trade/v3/deployments/${DEPLOYMENT_ID}/logs?pageSize=100" \
-H "x-api-key: ${SUPERIOR_TRADE_API_KEY}"
Use logs and status responses to verify runtime health. Do not infer that a deployment is trading from a successful start response alone.
400 validation_failed: Fix request shape, especially venue, instrument_id, wallet addresses, amount precision, or idempotency input.401 or 403: Check that SUPERIOR_TRADE_API_KEY is present and sent as x-api-key.404 not_found: The Lighter feature can be disabled or the resource does not belong to the user.409: A deposit is already active, a Lighter account is not ready, or the idempotency key was reused with different input.502: Upstream Lighter lookup, intent creation, key provisioning, or withdrawal submission failed.superior-trade-auth first when the user needs an API key.trade-thesis before deploying a new live strategy idea.hyperliquid for Hyperliquid Freqtrade deployments. Lighter uses v3 Nautilus deployment APIs instead.Assess Kubernetes workloads and cluster configuration for AKS Automatic compatibility. Identifies incompatibilities, generates fixes, and guides migration from AKS Standard to AKS Automatic. WHEN: migrate to AKS Automatic, check AKS Automatic readiness, validate manifests for Automatic, assess cluster for Automatic compatibility, fix deployment for Automatic compatibility, identify AKS Automatic migration blockers, is my cluster ready for AKS Automatic.
Discovers available Azure OpenAI model capacity across regions and projects. Analyzes quota limits, compares availability, and recommends optimal deployment locations based on capacity requirements. USE FOR: find capacity, check quota, where can I deploy, capacity discovery, best region for capacity, multi-project capacity search, quota analysis, model availability, region comparison, check TPM availability. DO NOT USE FOR: actual deployment (hand off to preset or customize after discovery), quota increase requests (direct user to Azure Portal), listing existing deployments.
Interactive guided deployment flow for Azure OpenAI models with full customization control. Step-by-step selection of model version, SKU (GlobalStandard/Standard/ProvisionedManaged), capacity, RAI policy (content filter), and advanced options (dynamic quota, priority processing, spillover). USE FOR: custom deployment, customize model deployment, choose version, select SKU, set capacity, configure content filter, RAI policy, deployment options, detailed deployment, advanced deployment, PTU deployment, provisioned throughput. DO NOT USE FOR: quick deployment to optimal region (use preset).
Unified Azure OpenAI model deployment skill with intelligent intent-based routing. Handles quick preset deployments, fully customized deployments (version/SKU/capacity/RAI policy), and capacity discovery across regions and projects. USE FOR: deploy model, deploy gpt, create deployment, model deployment, deploy openai model, set up model, provision model, find capacity, check model availability, where can I deploy, best region for model, capacity analysis. DO NOT USE FOR: listing existing deployments (use foundry_models_deployments_list MCP tool), deleting deployments, agent creation (use agent/create), project creation (use project/create).
Intelligently deploys Azure OpenAI models to optimal regions by analyzing capacity across all available regions. Automatically checks current region first and shows alternatives if needed. USE FOR: quick deployment, optimal region, best region, automatic region selection, fast setup, multi-region capacity check, high availability deployment, deploy to best location. DO NOT USE FOR: custom SKU selection (use customize), specific version selection (use customize), custom capacity configuration (use customize), PTU deployments (use customize).
This skill should be used when working with LaminDB, an open-source data framework for biology that makes data queryable, traceable, reproducible, and FAIR. Use when managing biological datasets (scRNA-seq, spatial, flow cytometry, etc.), tracking computational workflows, curating and validating data with biological ontologies, building data lakehouses, or ensuring data lineage and reproducibility in biological research. Covers data management, annotation, ontologies (genes, cell types, diseases, tissues), schema validation, integrations with workflow managers (Nextflow, Snakemake) and MLOps platforms (W&B, MLflow), and deployment strategies.
Latch platform for bioinformatics workflows. Build pipelines with Latch SDK, @workflow/@task decorators, deploy serverless workflows, LatchFile/LatchDir, Nextflow/Snakemake integration.
Run Python code in the cloud with serverless containers, GPUs, and autoscaling. Use when deploying ML models, running batch processing jobs, scheduling compute-intensive tasks, or serving APIs that require GPU acceleration or dynamic scaling.
Take superior-trade/lighter from the repository into ~/.claude/skills for personal
use, or into .claude/skills inside a project.
The agent identifies a skill by the name field in its header. Two skills with the
same name cannot sit side by side — one of them will be ignored.