Open a leveraged perp position on the best/selected venue (non-custodial).

side is "long" | "short". market e.g. SOL-PERP; size_usd is notional USD. venue optional -- defaults to the configured primary (Jupiter Perps), with health failover to the fallback for new orders. Returns an UNSIGNED tx (Tier A) or a signing payload (Tier B) for your wallet to sign + broadcast, plus venue_name / custody_tier / settlement_token. Tier B (venue-custodied) venues require acknowledge_tier_b=true after reviewing custody_disclosure. Fee charged on size_usd notional past the daily free tier (x402).

jurisdiction: your ISO-3166-1 alpha-2 country code, self-declared -- perps are geo-gated (no US persons, unknown jurisdiction DENIED). Declare once here (or via declare_jurisdiction/trade_equity) and it is remembered 90 days.

Workflow: EXECUTE step (leveraged directional leg) -- after get_venue_health / get_venue_risk_score clear the venue and get_risk_assessment caps the size. Monitor via perp_positions. See get_trading_workflow.

idempotency_key (optional): a client-generated UUID. Retrying with the same key + same args replays the original result instead of re-opening the order. Reuse the SAME key across the build call and its signed_transaction completion call -- the two legs dedupe independently, so this never raises IDEMPOTENCY_CONFLICT; a NEW key means a genuinely new order.

signed_transaction / verify (two-phase execution): re-call this tool with the SIGNED payload and Crank relays it by custody tier -- Tier A to Solana RPC, then awaits on-chain confirmation and re-reads the position on the executing venue; Tier B to the venue's own submit endpoint, which returns a venue order id (reported as venue-acknowledged, since it is not an on-chain signature). Gate follow-on decisions on verification.confirmed, never on tx_signature alone.

venue_action (optional, completion leg only): the value the BUILD leg recorded on extra['venue_action'] -- pass it back alongside signed_transaction so Crank relays the bytes under the venue action the venue itself named (e.g. Jupiter's create-limit-order, for a keeper-co-signed build that can only land via the venue's execute endpoint). Omit it and Crank reads the signed bytes' own message header: caller-completable bytes go to Solana RPC, but keeper-co-signed bytes need a venue action, which is then derived from order_type alone (limit -> create-limit-order, market -> increase-position). On the completion leg order_type is therefore load-bearing and is NEVER defaulted: omit both it and venue_action on keeper-co-signed bytes and the call is refused with a re-build instruction rather than relayed under a guessed action. Always round-trip the build response's extra['venue_action'].

order_type: "market" | "limit". Omitted on the BUILD leg it defaults to "market" (unchanged); omitted on the completion leg it stays unset (see venue_action above).

simulate (optional): true = rehearse this call. The full gate stack (capability, kill switch, session signer, wallet policy, permission mode, soft launch, venue / compliance / token checks, fee quote) is evaluated read-only and returned as verdicts + would_execute, with a paper fill where one applies. Nothing is built, signed, broadcast or charged. Omitted = your wallet's default_simulate setting; false = execute.