dflow-kalshi-trading

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

DFlow Kalshi Trading

DFlow Kalshi交易

Buy, sell, and redeem YES/NO outcome tokens on Kalshi prediction markets. PM trades are imperative and asynchronous — submit, then poll until terminal.

在Kalshi预测市场中买入、卖出和赎回YES/NO结果代币。PM交易是命令式且异步的——提交订单后，需轮询直至进入终端状态。

Prerequisites

前置条件

DFlow docs MCP (
```
https://pond.dflow.net/mcp
```
) — install per the repo README. This skill is the recipe; the MCP is the reference. Look up endpoint shapes, parameter details, error codes, and anything else field-level via
```
search_d_flow
```
/
```
query_docs_filesystem_d_flow
```
— don't guess.
dflow
CLI (optional, for command-line/agent use) — install per the repo README.

DFlow文档MCP（
```
https://pond.dflow.net/mcp
```
）——按照仓库README进行安装。本技能是操作指南，MCP是参考资料。通过
```
search_d_flow
```
/
```
query_docs_filesystem_d_flow
```
查找端点结构、参数细节、错误代码及其他字段级信息——请勿猜测。
dflow
CLI（可选，适用于命令行/代理场景）——按照仓库README进行安装。

Choose your surface

选择操作方式

CLI — command line, scripts, local agents. Manages keys, signs, submits, polls.
API — web/mobile apps with a browser wallet (Phantom, Privy, Turnkey, etc.). Wallet handles signing + RPC; app must proxy HTTP through its backend (the Trading API serves no CORS).

If unclear, ask once: "From the command line, or wired into an app?"

CLI——命令行、脚本、本地代理。管理密钥、签名、提交订单、轮询状态。
API——搭配浏览器钱包（Phantom、Privy、Turnkey等）的网页/移动应用。钱包负责签名+RPC；应用必须通过后端代理HTTP请求（Trading API不支持CORS）。

若不确定，可询问一次：“是通过命令行操作，还是集成到应用中？”

Workflows

工作流程

All three workflows assume the user already has a market ledger mint (CLI; the

marketLedger

field on the Metadata API market object) or an outcome mint (API;

yesMint

noMint

) in hand. If they only have a ticker / event name, defer to

dflow-kalshi-market-scanner

One market, two settlement rails. Every initialized Kalshi market on DFlow exposes both a USDC rail and a CASH rail in

market.accounts

— each with its own

marketLedger

yesMint

, and

noMint

. They share an orderbook (the top-level

yesBid

yesAsk

volume24hFp

are market-wide), but trades and holdings are rail-scoped: USDC-rail YES tokens are a different SPL mint from CASH-rail YES tokens and aren't fungible. Default to the USDC rail unless the user holds CASH, explicitly asks for CASH, or the active DFlow vault only has CASH. Don't write defensive "fall back to CASH if USDC rail missing" code — it never fires, and it hides the rail choice from the user. State the default at the top of the script instead.

Settlement mint constants (Solana, Token-2022 for CASH and the classic SPL token program for USDC):

USDC:

EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v

CASH:

CASHx9KJUStyftLFWGvEVf59SGeG9sh5FfcnZMVPCASH

Use these as the keys into

market.accounts[mint]

when picking a rail. There is no top-level
market.settlementMint
field on the

/markets

response (despite what some recipe snippets might suggest with

market.accounts?.[market.settlementMint]

— that pattern shows up in position-side code, where the rail is already known from the held outcome mint, not in market-discovery code). Key by the mint directly.

所有三个工作流程均假设用户已获取市场账本铸造地址（CLI场景；Metadata API市场对象的

marketLedger

字段）或结果铸造地址（API场景；

yesMint

noMint

）。若用户仅提供代码/事件名称，请转至

dflow-kalshi-market-scanner

处理。

一个市场，两种结算通道。 DFlow上每个已初始化的Kalshi市场在

market.accounts

中都会暴露USDC通道和CASH通道——每个通道都有自己的

marketLedger

、

yesMint

和

noMint

。它们共享同一个订单簿（顶层的

yesBid

yesAsk

volume24hFp

是市场全局数据），但交易和持仓是通道专属的：USDC通道的YES代币与CASH通道的YES代币是不同的SPL铸造地址，不可互换。默认使用USDC通道，除非用户持有CASH、明确要求使用CASH，或当前DFlow金库仅存有CASH。请勿编写“若USDC通道缺失则 fallback 到CASH”的防御性代码——这种情况绝不会发生，且会向用户隐藏通道选择。请在脚本开头明确说明默认通道。

结算铸造地址常量（Solana网络，CASH使用Token-2022标准，USDC使用经典SPL代币程序）：

USDC:

EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v

CASH:

CASHx9KJUStyftLFWGvEVf59SGeG9sh5FfcnZMVPCASH

选择通道时，使用这些地址作为

market.accounts[mint]

的键。

/markets

响应中没有顶层的
market.settlementMint
字段（尽管某些示例代码片段中出现了

market.accounts?.[market.settlementMint]

——这种模式出现在头寸端代码中，其中通道已从持有的结果铸造地址得知，而非市场发现代码）。直接使用铸造地址作为键。

Buy (open or increase a YES/NO position)

买入（开仓或加仓YES/NO头寸）

Confirm the buy gates (KYC + geo + maintenance window) are passable for this user — see Gotchas.
Submit the order with the settlement mint as input (USDC or CASH) and the outcome mint as output.
Poll status until terminal (
```
closed
```
/
```
expired
```
/
```
failed
```
).

CLI:
```
dflow trade <atomic-amount> USDC --market <marketLedger> --side yes|no
```
— auto-polls for up to 120s.
```
<FROM>
```
accepts either the base58 mint or the shorthand
```
USDC
```
/
```
CASH
```
(CLI resolves a small symbol set, same as spot).
```
--market
```
takes the
```
marketLedger
```
for the settlement track matching the
```
<from>
```
arg — i.e.
```
market.accounts[<USDC-or-CASH-mint>].marketLedger
```
on the Metadata API response. The CLI derives the YES/NO outcome mint from
```
--side
```
+
```
<from>
```
, so the same
marketLedger
value is used for both
--side yes
and
--side no
. Don't pass a
```
yesMint
```
/
```
noMint
```
here — those are inputs to the API surface, not the CLI. The docs' "market mint" and "market ledger mint" phrasing both refer to this one field.

"Buy N whole contracts" from a scan snapshot. Kalshi buys submit a USDC amount and get back as many whole contracts as it covers, refunding leftovers. When you're executing N contracts off a snapshotted

yesAsk

, compute

Math.ceil(N * yesAsk * 1e6)

atomic USDC and optionally add a small buffer (≤ ~1%, a few basis points is typically enough) so a tick-up in the ask between scan and submit doesn't leave you with N-1. Leftover stablecoin is refunded by the CLP, so over-funding slightly is cheap insurance. Don't over-fund by more than a percent or two — at some point it's no longer insurance, it's a different order size.

API:
```
GET /order?userPublicKey=&inputMint=<settlement>&outputMint=<yesMint|noMint>&amount=<atomic>
```
, then sign + submit + poll
```
/order-status
```
. The API takes the outcome mint directly (no
```
--market
```
indirection). Field details via the docs MCP.

确认该用户可通过买入限制（KYC + 地域 + 维护窗口）——参见注意事项。
提交订单，输入结算铸造地址（USDC或CASH），输出结果铸造地址。
轮询状态直至进入终端状态（
```
closed
```
/
```
expired
```
/
```
failed
```
）。

CLI：
```
dflow trade <atomic-amount> USDC --market <marketLedger> --side yes|no
```
——自动轮询最长120秒。
```
<FROM>
```
接受base58格式的铸造地址或简写
```
USDC
```
/
```
CASH
```
（CLI会解析一组小型符号集，与现货交易相同）。
```
--market
```
参数需传入与
```
<from>
```
参数匹配的结算通道的
```
marketLedger
```
——即Metadata API响应中
```
market.accounts[<USDC或CASH铸造地址>].marketLedger
```
的值。CLI会根据
```
--side
```
+
```
<from>
```
自动推导YES/NO结果铸造地址，因此**
```
--side yes
```
和
```
--side no
```
使用相同的
```
marketLedger
```
值**。请勿在此处传入
```
yesMint
```
/
```
noMint
```
——这些是API场景的输入，而非CLI场景。文档中的“市场铸造地址”和“市场账本铸造地址”均指该字段。

从扫描快照中“买入N份完整合约”。Kalshi买入操作提交USDC金额，系统会买入该金额可覆盖的所有完整合约，剩余金额将退回。若要根据快照中的

yesAsk

执行N份合约，请计算

Math.ceil(N * yesAsk * 1e6)

个最小单位的USDC，可选择性添加少量缓冲（≤约1%，通常几个基点足够），避免扫描与提交期间卖价上涨导致最终仅买入N-1份合约。剩余稳定币将由CLP退回，因此略微超额支付是低成本的保障措施。请勿超额支付超过1%-2%——超过这个比例就不再是保障，而是改变了订单规模。

API：
```
GET /order?userPublicKey=&inputMint=<settlement>&outputMint=<yesMint|noMint>&amount=<atomic>
```
，然后签名+提交+轮询
```
/order-status
```
。API直接接收结果铸造地址（无需通过
```
--market
```
间接传递）。字段细节请查阅文档MCP。

Sell (decrease or close)

卖出（减仓或平仓）

Flip the mints — outcome in, settlement out. No KYC required. No

--market

--side

on the CLI; pass the outcome mint as the FROM positional and the CLI auto-resolves the settlement mint.

CLI:

dflow trade <atomic-outcome> <outcome-mint>

API: same
```
/order
```
call as buy, with input/output mints flipped.

交换铸造地址——输入结果铸造地址，输出结算铸造地址。无需KYC。CLI无需

--market

--side

参数；将结果铸造地址作为FROM参数传入，CLI会自动解析结算铸造地址。

CLI：

dflow trade <atomic-outcome> <outcome-mint>

API：与买入操作使用相同的
```
/order
```
调用，仅需交换输入/输出铸造地址。

Redeem (post-settlement)

赎回（结算后）

Once the market is

determined

finalized

and

redemptionStatus: "open"

, redemption is just a regular sell of the winning side back to the settlement mint. No special flag, no KYC.

一旦市场状态变为

determined

finalized

且

redemptionStatus: "open"

，赎回操作就是将获胜方代币卖回结算铸造地址的常规卖出操作。无需特殊标记，无需KYC。

What to ASK the user (and what NOT to ask)

需要询问用户的内容（以及无需询问的内容）

Trade shape — infer if unambiguous, confirm if not:

Operation — buy / sell / redeem. Infer from intent ("bet on X" → buy YES; "cash out" → sell; "my YES tokens just won" → redeem). Don't make the user pick a mode.
Market + side — for CLI: the
```
marketLedger
```
(from
```
market.accounts[<settlement-mint>].marketLedger
```
) plus
```
--side yes|no
```
. For API: the YES or NO outcome mint directly as
```
outputMint
```
.
Settlement rail — USDC or CASH. Both exist on every initialized market; default to USDC unless the user says otherwise. This determines which
```
marketLedger
```
(CLI) or
```
yesMint
```
/
```
noMint
```
(API) you use.
Amount in atomic units — every Kalshi mint is 6 decimals (
```
8_000_000
```
= $8 of USDC;
```
10_000_000
```
= 10 outcome tokens). Buys submit settlement-mint amounts (USDC/CASH); sells/redeems submit outcome-token amounts.

Infra — always ask, never infer:

API only — wallet pubkey (base58). Required for every
```
/order
```
call.
API only — DFlow API key (only when the script is making direct HTTP calls to
```
/order
```
or other Trade API endpoints; pure CLI scripts don't need one — see the "two auth paths" gotcha). Ask with a clean, neutral question: "Do you have a DFlow API key?" Don't presuppose where the key lives — phrasings like "do you have it in env?" or "is
DFLOW_API_KEY
set?" nudge the user toward env-var defaults they didn't ask for. Surface the choice; don't silently fall back to env or to dev. It's one key for everything DFlow — same
```
x-api-key
```
unlocks the Trade API and the Metadata API, REST and WebSocket. If yes → prod host
```
https://quote-api.dflow.net
```
with
```
x-api-key
```
on every request. If no → dev host
```
https://dev-quote-api.dflow.net
```
(same features, rate-limited). Point them at
```
https://pond.dflow.net/build/api-key
```
for a prod key. When you generate a script that does its own HTTP, log the resolved host + key-presence at startup so the user can see which rails they're on.
Priority fee (both surfaces) — "Any priority-fee preference, or just use DFlow's default?" Default on both surfaces = DFlow-auto, capped at 0.005 SOL (documented default on
```
/order
```
). Surface this explicitly so the user knows the lever exists for congested periods or cost-sensitive flows. Don't editorialize about what percentage of trades this covers — DFlow doesn't publish one and you don't know.
- API — pass
```
prioritizationFeeLamports
```
  on
```
/order
```
  :
```
auto
```
  |
```
medium
```
  |
```
high
```
  |
```
veryHigh
```
  |
```
disabled
```
  | integer lamports. Live estimates for tuning:
```
GET /priority-fees
```
  (snapshot),
```
/priority-fees/stream
```
  (WebSocket). (
```
/intent
```
  doesn't apply to Kalshi — PM is imperative-only.)
- CLI — no tuning flag;
```
dflow trade
```
  always uses the server-side default. If the user needs finer control (an exact lamport value, or
```
disabled
```
  ), they'll have to drop to the API.
Sponsored / gasless (API only — skip for CLI) — "Does the user need to hold SOL for this trade, or is your app covering fees?" Default = user pays everything. Two levers on
```
/order
```
, depending on what you want to cover:
- ```
sponsor=<sponsor-wallet-base58>
```
  — sponsor pays tx fee + ATA creation + market-init. Tx must be co-signed by both user and sponsor. Optional
```
sponsorExec=true|false
```
  picks sponsor-executes (default) vs. user-executes.
- ```
predictionMarketInitPayer=<wallet>
```
  — covers only the one-time market-init rent; user still signs and pays their own tx fee and ATA creation. Useful when you only want to eat the init cost. Markets can also be pre-initialized out-of-band via
```
GET /prediction-market-init
```
  .
- The CLI doesn't support either sponsorship lever.

Do NOT ask about:

RPC — CLI users set it during
```
dflow setup
```
. API users on a browser wallet never need their own RPC (the wallet handles it). Only ask if signing server-side. When one is needed, suggest Helius.
Slippage — both surfaces default to
```
"auto"
```
, which is right for CLP-sourced fills. Override only on explicit user request (
```
--slippage
```
CLI;
```
predictionMarketSlippageBps
```
API).
Platform fee — defer to
```
dflow-platform-fees
```
if the user pivots there.

交易形态——若明确则推断，若不明确则确认：

操作类型——买入/卖出/赎回。根据用户意图推断（“对X下注”→买入YES；“套现”→卖出；“我的YES代币赢了”→赎回）。无需让用户选择模式。
市场+方向——CLI场景：
```
marketLedger
```
（来自
```
market.accounts[<结算铸造地址>].marketLedger
```
）加上
```
--side yes|no
```
。API场景：直接将YES或NO结果铸造地址作为
```
outputMint
```
。
结算通道——USDC或CASH。每个已初始化的市场都同时存在这两个通道；默认使用USDC，除非用户另有说明。这将决定使用哪个
```
marketLedger
```
（CLI）或
```
yesMint
```
/
```
noMint
```
（API）。
最小单位金额——每个Kalshi铸造地址均为6位小数（
```
8_000_000
```
= 8美元USDC；
```
10_000_000
```
= 10个结果代币）。买入操作提交结算铸造地址的金额（USDC/CASH）；卖出/赎回操作提交结果代币的金额。

基础设施——始终询问，绝不推断：

仅API场景——钱包公钥（base58格式）。每个
```
/order
```
调用都需要此参数。
仅API场景——DFlow API密钥（仅当脚本直接调用
```
/order
```
或其他Trade API端点的HTTP请求时需要；纯CLI脚本无需此密钥——参见“两种认证路径”注意事项）。请用清晰中立的问题询问：“你是否拥有DFlow API密钥？” 不要预设密钥存储位置——诸如“你是否将其存放在环境变量中？”或“
```
DFLOW_API_KEY
```
是否已设置？”的表述会引导用户使用他们未要求的环境变量默认值。请给出选择；不要静默 fallback 到环境变量或开发环境。这是适用于所有DFlow场景的单一密钥——相同的
```
x-api-key
```
可解锁Trade API 和 Metadata API，REST 和 WebSocket。若用户拥有密钥→使用生产环境地址
```
https://quote-api.dflow.net
```
，并在每个请求中添加
```
x-api-key
```
。若用户没有→使用开发环境地址
```
https://dev-quote-api.dflow.net
```
（功能相同，有速率限制）。引导用户访问
```
https://pond.dflow.net/build/api-key
```
获取生产环境密钥。当生成自行发起HTTP请求的脚本时，请在启动时记录解析后的地址+密钥状态，以便用户了解当前使用的通道。
优先级费用（两种操作方式均适用）——“是否有优先级费用偏好，还是直接使用DFlow的默认值？”两种操作方式的默认值均为DFlow自动设置，上限为0.005 SOL（
```
/order
```
文档中记录的默认值）。请明确告知用户此选项，以便在网络拥堵或对成本敏感的场景中进行调整。不要评论此选项覆盖的交易比例——DFlow未公布相关数据，且你无法得知。
- API——在
```
/order
```
  请求中传递
```
prioritizationFeeLamports
```
  参数：
```
auto
```
  |
```
medium
```
  |
```
high
```
  |
```
veryHigh
```
  |
```
disabled
```
  | 整数lamports。调整时可参考实时估算：
```
GET /priority-fees
```
  （快照）、
```
/priority-fees/stream
```
  （WebSocket）。（
```
/intent
```
  不适用于Kalshi——PM仅支持命令式操作。）
- CLI——无调整标记；
```
dflow trade
```
  始终使用服务器端默认值。若用户需要更精细的控制（精确的lamport值或
```
disabled
```
  ），则需切换到API场景。
赞助式/无Gas（仅API场景——CLI场景跳过）——“用户是否需要持有SOL来进行此交易，还是由你的应用支付费用？”默认值为用户支付所有费用。
```
/order
```
有两个控制选项，取决于你想要覆盖的费用：
- ```
sponsor=<sponsor-wallet-base58>
```
  ——赞助方支付交易费用+ATA创建费用+市场初始化费用。交易需由用户和赞助方共同签名。可选参数
```
sponsorExec=true|false
```
  选择赞助方执行（默认）还是用户执行。
- ```
predictionMarketInitPayer=<wallet>
```
  ——仅覆盖一次性市场初始化租金；用户仍需签名并支付自己的交易费用和ATA创建费用。适用于仅想承担初始化成本的场景。也可通过
```
GET /prediction-market-init
```
  提前在外部初始化市场。
- CLI不支持任何赞助选项。

无需询问的内容：

RPC——CLI用户在
```
dflow setup
```
期间设置RPC。使用浏览器钱包的API用户永远不需要自己的RPC（钱包会处理）。仅当在服务器端签名时才需要询问。若需要RPC，建议使用Helius。
滑点——两种操作方式均默认使用
```
"auto"
```
，这适用于CLP提供的成交。仅当用户明确要求时才覆盖此设置（CLI使用
```
--slippage
```
；API使用
```
predictionMarketSlippageBps
```
）。
平台费用——若用户提及此内容，请转至
```
dflow-platform-fees
```
处理。

Gotchas (the docs MCP won't volunteer these)

注意事项（文档MCP不会主动提及）

Token-2022 outcome mints. Kalshi outcome mints use the Token-2022 program. Declarative trades (
```
/intent
```
) don't support Token-2022 — that's why Kalshi is imperative-only.
All Kalshi mints are 6 decimals. USDC, CASH, every outcome token. Always pass atomic units to the API.
Buys are whole-contract only — no fractional contracts. Submit a USDC/CASH amount; the system buys as many whole contracts as that amount covers and refunds any leftover stablecoin. Per-order floor is 0.01 USDC, but the practical floor in any given market is one contract at the current YES/NO price (e.g. if YES is trading at 0.43, you need ≥
```
430_000
```
atomic = $0.43). Quote first if the user is anywhere near the floor.
Async fills, no exceptions. PM
```
/order
```
returns
```
executionMode: "async"
```
. The transaction landing onchain is not the fill — the order can still expire or fail in the CLP. Always poll
```
/order-status
```
to a terminal state. CLI auto-polls for 120s; on timeout, follow up with
```
dflow status <orderAddress> --poll
```
.
Buy gates exist; check once per session, not per call.
- Proof KYC — required to buy (not sell, not redeem). Hit
```
GET https://proof.dflow.net/verify/{address}
```
  (public, no auth) once at session start, cache
```
{ verified: boolean }
```
  , gate the buy UI off the cache.
```
/order
```
  is still authoritative; on the rare miss, fall back on
```
unverified_wallet_not_allowed
```
  (API) /
```
PROOF_NOT_VERIFIED
```
  (CLI) using
```
details.deepLink
```
  .
- Geoblock — restricted in some jurisdictions. API builders enforce in their own UI (cache the user's country once per session). The CLI handles this internally and returns
```
category: "geoblock"
```
  . Policy:
```
https://pond.dflow.net/legal/prediction-market-compliance
```
  .
Maintenance window. Kalshi is offline Thursdays 3:00–5:00 AM ET, every week. CLPs stop serving routes;
```
/order
```
returns
```
route_not_found
```
(the CLI annotates with a maintenance note). Block PM submissions for the whole window.
route_not_found
is a catch-all. Wrong mint, amount below the contract-price floor, no liquidity right now, or the maintenance window. Verify mint, atomic units, and that the amount covers ≥ 1 contract before assuming illiquidity.
Browser apps must proxy. The Trading API serves no CORS — call it from a backend (Next.js API route or equivalent), never directly from the browser.
CLI shell-outs authenticate themselves; direct HTTP calls don't. If your script or backend shells out to
```
dflow trade
```
, that leg uses the CLI's stored config from
```
dflow setup
```
(key, wallet, RPC) — you plumb nothing for CLI invocations. If the same script also hits the Trade API or Metadata API directly over HTTP (e.g. scanner-style discovery, your own
```
/order
```
call,
```
/quote
```
, sibling HTTP tools), that HTTP client needs the key handed in explicitly (env var,
```
.env
```
,
```
--api-key
```
flag, header). The CLI's stored key is not reusable by a sibling HTTP client, and an env-var key is not injected into the CLI either — they're independent plumbing sites for the same DFlow key. Only ask about an API key for the HTTP portion; pure CLI scripts don't need one.

Token-2022结果铸造地址。Kalshi结果铸造地址使用Token-2022程序。声明式交易（
```
/intent
```
）不支持Token-2022——这就是Kalshi仅支持命令式操作的原因。
所有Kalshi铸造地址均为6位小数。USDC、CASH、所有结果代币均是如此。请始终向API传递最小单位金额。
买入仅支持完整合约——不支持部分合约。提交USDC/CASH金额；系统会买入该金额可覆盖的所有完整合约，并退回剩余稳定币。每笔订单的最低金额为0.01 USDC，但在特定市场中实际最低金额为当前YES/NO价格对应的一份合约（例如，若YES卖价为0.43，则需要≥
```
430_000
```
个最小单位=0.43美元）。若用户的金额接近最低限额，请先报价。
异步成交，无例外。PM的
```
/order
```
返回
```
executionMode: "async"
```
。交易上链并不意味着成交——订单仍可能在CLP中过期或失败。请始终轮询
```
/order-status
```
直至进入终端状态。CLI自动轮询120秒；若超时，请使用
```
dflow status <orderAddress> --poll
```
跟进。
买入限制存在；每个会话检查一次，而非每次调用。
- Proof KYC——买入需要（卖出、赎回不需要）。在会话开始时调用一次
```
GET https://proof.dflow.net/verify/{address}
```
  （公开接口，无需认证），缓存
```
{ verified: boolean }
```
  ，根据缓存结果限制买入UI。
```
/order
```
  仍是权威来源；若罕见出现缓存错误，请根据
```
unverified_wallet_not_allowed
```
  （API）/
```
PROOF_NOT_VERIFIED
```
  （CLI）错误中的
```
details.deepLink
```
  处理。
- 地域限制——部分司法管辖区受限。API开发者需在自己的UI中实施限制（每个会话缓存一次用户所在国家）。CLI会内部处理此问题，并返回
```
category: "geoblock"
```
  。政策详情：
```
https://pond.dflow.net/legal/prediction-market-compliance
```
  。
维护窗口。Kalshi每周四美国东部时间3:00–5:00处于离线状态。CLP停止提供路由；
```
/order
```
返回
```
route_not_found
```
（CLI会标注维护提示）。请在整个维护窗口内禁止提交PM订单。
route_not_found
是通用错误。可能是铸造地址错误、金额低于合约价格最低限额、当前无流动性，或处于维护窗口。在假设流动性不足之前，请先验证铸造地址、最小单位金额，以及金额是否≥一份合约。
浏览器应用必须使用代理。Trading API不支持CORS——请从后端（如Next.js API路由）调用，切勿直接从浏览器调用。
CLI shell调用会自行认证；直接HTTP调用不会。若你的脚本或后端调用
```
dflow trade
```
，该环节会使用
```
dflow setup
```
存储的CLI配置（密钥、钱包、RPC）——你无需传递任何参数用于CLI调用。若同一脚本同时通过HTTP直接调用Trade API或Metadata API（例如扫描式发现、自行调用
```
/order
```
、
```
/quote
```
、其他HTTP工具），则该HTTP客户端需要显式传入密钥（环境变量、
```
.env
```
、
```
--api-key
```
标记、请求头）。CLI存储的密钥不可用于同级HTTP客户端，环境变量中的密钥也不会注入到CLI中——它们是同一DFlow密钥的独立配置位置。仅在HTTP部分需要询问API密钥；纯CLI脚本无需此密钥。

When something doesn't fit

超出范围的内容

For anything not covered above — full parameter lists, full error tables, response schemas, partial-fill handling, rare flags, new features — query the docs MCP (

search_d_flow

query_docs_filesystem_d_flow

). Don't guess.

For runnable code, point the user at the DFlow docs recipes (each links to the DFlow Cookbook Repo for clone-and-go):

/build/recipes/prediction-markets/increase-position

/build/recipes/prediction-markets/decrease-position

/build/recipes/prediction-markets/redeem-outcome-tokens

对于上述未涵盖的内容——完整参数列表、完整错误表、响应 schema、部分成交处理、罕见标记、新功能——请查询文档MCP（

search_d_flow

、

query_docs_filesystem_d_flow

）。请勿猜测。

如需可运行代码，请引导用户查看DFlow文档示例（每个示例均链接到DFlow Cookbook仓库，可直接克隆使用）：

/build/recipes/prediction-markets/increase-position

、

/build/recipes/prediction-markets/decrease-position

、

/build/recipes/prediction-markets/redeem-outcome-tokens

。

Sibling skills

关联技能

Defer if the user pivots to:

```
dflow-kalshi-market-scanner
```
— discover markets, filter by event/category
```
dflow-kalshi-market-data
```
— live prices, orderbooks, streams
```
dflow-kalshi-portfolio
```
— view positions, unrealized P&L
```
dflow-proof-kyc
```
— set up Proof verification on a wallet
```
dflow-platform-fees
```
— charge a builder fee on PM trades
```
dflow-spot-trading
```
— non-Kalshi token swaps

若用户转向以下内容，请转至对应技能处理：

```
dflow-kalshi-market-scanner
```
——发现市场、按事件/类别筛选
```
dflow-kalshi-market-data
```
——实时价格、订单簿、数据流
```
dflow-kalshi-portfolio
```
——查看头寸、未实现盈亏
```
dflow-proof-kyc
```
——在钱包上设置Proof验证
```
dflow-platform-fees
```
——对PM交易收取开发者费用
```
dflow-spot-trading
```
——非Kalshi代币兑换",