Back to Details

dflow-platform-fees

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

DFlow Platform Fees

DFlow平台费用

Collect a fee on trades your app routes through the DFlow Trade API, paid to a builder-controlled token account on successful execution. This is the builder→user fee — builders monetizing their distribution.
通过DFlow Trade API在您的应用路由的交易中收取费用，交易成功执行后费用将支付至构建者控制的代币账户。这是构建者向用户收取的费用——构建者通过流量分发实现变现。

Prerequisites

前提条件

  • DFlow docs MCP (
    https://pond.dflow.net/mcp
    ) — install per the repo README. This skill is the recipe; the MCP is the reference. Exact parameter encoding, response shapes, and the full mode matrix live there — don't guess.
  • DFlow文档MCP（
    https://pond.dflow.net/mcp
    ）——按照仓库README进行安装。本技能是操作指南，MCP是参考资料。精确的参数编码、响应格式和完整的模式矩阵都在那里——请勿自行猜测。

Surface

使用方式

API only. Platform fees are 
/order
parameters on the Trade API. The 
dflow
CLI is for direct self-trading, not for monetizing a distribution product, so it doesn't expose platform-fee flags — don't hunt for a 
--platform-fee-bps
option.
Which host depends on API-key status, same as the other trading skills: prod 
https://quote-api.dflow.net
with 
x-api-key
, dev 
https://dev-quote-api.dflow.net
.
仅支持API。平台费用是Trade API的
/order
参数。
dflow
CLI用于直接自助交易，而非用于变现分发产品，因此它不暴露平台费用相关的标志——无需寻找
--platform-fee-bps
选项。
使用哪个主机取决于API密钥状态，与其他交易技能相同：生产环境使用
https://quote-api.dflow.net
并携带
x-api-key
，开发环境使用
https://dev-quote-api.dflow.net
。

Two fee models

两种费用模型

Pick based on what trades you're fee-ing.
根据您要收取费用的交易类型进行选择。

Fixed — 
platformFeeBps

固定费率——
platformFeeBps

Flat percentage of the trade in basis points (1 bps = 0.01%). 
platformFeeBps: 50
→ 0.5% fee. Works on spot and PM trades. The only option for spot.
以基点为单位的固定交易百分比（1个基点=0.01%）。
platformFeeBps: 50
→ 0.5%的费用。适用于**现货和预测市场（PM）**交易。这是现货交易的唯一可选模式。

Dynamic — 
platformFeeScale
(PM outcome tokens only)

动态费率——
platformFeeScale
（仅适用于预测市场结果代币）

Probability-weighted fee that scales with market uncertainty:
fee = k * p * (1 - p) * c
  • k
    = 
    platformFeeScale
    , 3-decimal precision (
    platformFeeScale: 50
    → k = 0.050).
  • p
    = the all-in price (includes all fees + filled price), 0–1.
  • c
    = contract size.
  • Paid in the settlement mint (USDC or CASH).
p * (1 - p)
peaks at 
p = 0.5
and is zero at 
p = 0
/ 
p = 1
— so you charge the most on coin-flip markets, scale down as markets approach certainty, and charge nothing at redemption (
p = 1
). If your revenue model assumes a take on redemption, rework it.
Example. 
platformFeeScale = 50
, user buys 100 YES contracts at 
p = 0.40
: 
fee = 0.050 * 0.40 * 0.60 * 100 = 1.20
→ $1.20 on a $40 buy.
Dynamic fees are not available on spot.
随市场不确定性变化的概率加权费用：
fee = k * p * (1 - p) * c
  • k
    = 
    platformFeeScale
    ，保留3位小数精度（
    platformFeeScale: 50
    → k = 0.050）。
  • p
    = 全价（包含所有费用+成交价格），范围0–1。
  • c
    = 合约规模。
  • 费用以结算代币（USDC或CASH）支付。
p * (1 - p)
在
p = 0.5
时达到峰值，在
p = 0
/ 
p = 1
时为0——因此您在胜负难分的市场中收取最高费用，随着市场趋于确定而降低费用，并且在赎回时不收取任何费用（
p = 1
）。如果您的收入模型假设在赎回时抽成，请重新调整模型。
示例。
platformFeeScale = 50
，用户以
p = 0.40
的价格购买100份YES合约： 
fee = 0.050 * 0.40 * 0.60 * 100 = 1.20
→ 40美元的订单收取1.20美元费用。
动态费率不适用于现货交易。

Core 
/order
parameters

核心
/order
参数

Full param details and encoding → docs MCP, or read the pages directly: 
/build/trading/platform-fees
, 
/build/recipes/trading/platform-fees
.
  • platformFeeBps
    — fixed fee in bps. Works everywhere.
  • platformFeeScale
    — dynamic fee coefficient. PM outcome tokens only.
  • platformFeeMode
    — which side pays the fee: 
    outputMint
    (default) or 
    inputMint
    .
  • feeAccount
    — the SPL token account that receives the fee. Must already exist before the trade; DFlow won't create it.
完整的参数详情和编码请查看文档MCP，或直接访问以下页面：
/build/trading/platform-fees
、
/build/recipes/trading/platform-fees
。
  • platformFeeBps
    ——固定费率（基点）。适用于所有场景。
  • platformFeeScale
    ——动态费率系数。仅适用于预测市场结果代币。
  • platformFeeMode
    ——支付费用的一方：
    outputMint
    （默认）或
    inputMint
    。
  • feeAccount
    ——接收费用的SPL代币账户。必须在交易前已存在；DFlow不会为您创建该账户。

Mode matrix — who can pay the fee in which token

模式矩阵——哪些主体可以用哪种代币支付费用

Trade typeAllowed 
platformFeeMode
Imperative spot
inputMint
or 
outputMint
Declarative spot
outputMint
only
PM outcome-token tradesAlways settlement mint (USDC / CASH), regardless of what you pass
Easy trap when porting from imperative to declarative: 
inputMint
mode silently becomes invalid.
交易类型允许的
platformFeeMode
命令式现货
inputMint
或 
outputMint
声明式现货仅
outputMint
预测市场结果代币交易始终使用结算代币（USDC / CASH），与您传入的参数无关
从命令式迁移到声明式时容易犯的错误：
inputMint
模式会自动变为无效。

Fee accounts (ATAs)

费用账户（ATA）

You need one ATA per token you collect in. A builder collecting in USDC and SOL needs a USDC ATA and a SOL ATA, both already created, both controlled by the builder's wallet. Pass the relevant one as 
feeAccount
per request — DFlow reads it, validates it matches the mode's token, and transfers on success.
For PM: the fee ATA must be a settlement-mint ATA (USDC or CASH), since that's the only token PM fees can be paid in.
您需要每个收取费用的代币对应一个ATA。如果构建者同时收取USDC和SOL费用，则需要USDC ATA和SOL ATA，两者都必须预先创建，且都由构建者的钱包控制。在每个请求中传入对应的账户作为
feeAccount
——DFlow会读取该账户，验证其是否与模式指定的代币匹配，并在交易成功时进行转账。
对于预测市场：费用ATA必须是结算代币的ATA（USDC或CASH），因为预测市场费用只能以这些代币支付。

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

需要询问用户的问题（以及不应询问的问题）

Ask if missing:
  1. Which trade types do you want to collect fees on — spot, PM outcome tokens, or both? Scopes which fee model(s) are relevant: spot-only → 
    platformFeeBps
    only; PM → either; both → usually 
    platformFeeBps
    on spot + 
    platformFeeScale
    on PM (per-request choice).
  2. Rate — bps value for fixed; 
    k
    value for dynamic.
  3. Collection token(s) — which token(s) do you want the fee paid in, and do you already have a matching ATA owned by the builder wallet?
  4. Imperative or declarative? Only matters for spot and only matters for 
    platformFeeMode
    — declarative can only fee in 
    outputMint
    .
  5. DFlow API key. Platform fees are an HTTP-only feature (params on the user's own 
    /order
    call) — there's no CLI flag for them, so you're always plumbing the key into the script's HTTP client. 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 DFlow key everywhere — same 
    x-api-key
    unlocks Trade API + Metadata API, REST + WebSocket. Yes → prod 
    https://quote-api.dflow.net
    + 
    x-api-key
    . No → dev 
    https://dev-quote-api.dflow.net
    , rate-limited. Pointer: 
    https://pond.dflow.net/build/api-key
    .
Do NOT ask about:
  • RPC, signing, slippage — orthogonal to fees; the base trading skill handles them.
  • Anything about who the user is — platform fees are a per-request parameter, not a wallet-level setting.
如果缺少以下信息，请询问：
  1. 您要对哪些交易类型收取费用——现货、预测市场结果代币，还是两者都要？ 这决定了适用的费用模型：仅现货→仅
    platformFeeBps
    ；仅预测市场→两种模型均可；两者都要→通常现货使用
    platformFeeBps
    + 预测市场使用
    platformFeeScale
    （可按请求选择）。
  2. 费率——固定费率的基点值；动态费率的
    k
    值。
  3. 收取费用的代币——您希望以哪种代币收取费用，并且您是否已经拥有由构建者钱包控制的对应ATA？
  4. 命令式还是声明式？ 仅对现货交易有影响，且仅影响
    platformFeeMode
    ——声明式仅支持
    outputMint
    模式收取费用。
  5. DFlow API密钥。平台费用是仅HTTP支持的功能（作为用户自行调用
    /order
    时的参数）——没有对应的CLI标志，因此您需要将密钥配置到脚本的HTTP客户端中。请用清晰中立的问题询问：“您是否拥有DFlow API密钥？” 不要预设密钥的存储位置——类似“您是否将其存放在环境变量中？”或“
    DFLOW_API_KEY
    是否已设置？”的表述会引导用户使用他们未要求的环境变量默认设置。提供选择；不要自动回退到环境变量或开发环境。所有场景使用同一个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
    。
请勿询问：
  • RPC、签名、滑点——这些与费用无关；基础交易技能会处理这些内容。
  • 关于用户身份的任何问题——平台费用是每个请求的参数，而非钱包级别的设置。

Gotchas (the docs MCP won't volunteer these)

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

  • Don't set 
    platformFeeBps
    if you're not collecting.     The API factors a declared fee into slippage tolerance; if the fee isn't actually taken onchain, the slippage budget gets "spent" on nothing and user pricing worsens. Only pass a nonzero value when there's a real 
    feeAccount
    at the other end.
  • Redemption is fee-exempt under dynamic fees. 
    platformFeeScale
    returns 0 at 
    p = 1
    . There's no "take a cut on redemption" knob.
  • Dynamic fees are outcome-token trades only. 
    platformFeeScale
    is not supported on spot. Use 
    platformFeeBps
    there.
  • Declarative spot fees can only be in 
    outputMint
    .     Imperative has both modes; declarative narrows. Easy regression.
  • PM fees are always in the settlement mint. Passing 
    platformFeeMode: "inputMint"
    on a PM buy doesn't mean "collect in USDC because USDC is the input" — it's silently invalid. The fee settles in USDC/CASH regardless because that's the settlement mint.
  • feeAccount
    must exist before the trade.     DFlow doesn't create it for you. If it's missing, the trade fails.
  • One ATA per collected token. USDC fee account ≠ SOL fee account ≠ CASH fee account. Create what you need upfront.
  • Fees only apply on successful trades. Failed / cancelled / reverted trades → no fee charged, no transfer. Don't count failures as fee-bearing volume.
  • 如果不收取费用，请不要设置
    platformFeeBps
    。API会将声明的费用纳入滑点容忍度计算；如果费用并未实际链上收取，滑点预算会被“浪费”在无意义的地方，导致用户的定价变差。仅当另一端存在真实的
    feeAccount
    时，才传入非零值。
  • 动态费率下赎回交易免费用。当
    p = 1
    时，
    platformFeeScale
    返回0。没有“在赎回时抽成”的设置选项。
  • 动态费率仅适用于结果代币交易。
    platformFeeScale
    不支持现货交易。请在此场景使用
    platformFeeBps
    。
  • 声明式现货交易仅能以
    outputMint
    模式收取费用    。命令式支持两种模式；声明式仅支持一种。容易出现回归问题。
  • 预测市场费用始终以结算代币支付。在预测市场买入时传入
    platformFeeMode: "inputMint"
    并不意味着“因为USDC是输入代币，所以以USDC收取费用”——这是无效的，会被自动忽略。费用无论如何都会以USDC/CASH结算，因为这是结算代币。
  • feeAccount
    必须在交易前存在    。DFlow不会为您创建该账户。如果账户缺失，交易将失败。
  • 每个收取费用的代币对应一个ATA。USDC费用账户≠SOL费用账户≠CASH费用账户。请预先创建所需的账户。
  • 仅在交易成功时收取费用。失败/取消/回滚的交易→不收取费用，不进行转账。不要将失败交易计入收费交易量。

Platform fees vs DFlow's PM trading fees

平台费用与DFlow预测市场交易费的区别

Two different things that both use the word "fee":
  • Platform fees (this skill) — builder→user. Defined by the builder via 
    /order
    params, transferred to the builder's 
    feeAccount
    on success. Applies to any trade type.
  • DFlow PM trading fees + rebates — builder→DFlow, with a partial VIP rebate flow back from DFlow→builder. Charged on prediction-market outcome-token trades only (formula 
    roundup(0.07 × c × p × (1 − p)) + (0.01 × c × p × (1 − p))
    ), tiered by rolling 30-day PM volume (Frost / Glacier / Steel / Obsidian). Builders above $100k/30D volume may additionally qualify for the VIP rebate schedule. Details: 
    /build/prediction-markets/prediction-market-fees
    .
Don't mix them up when calculating net economics. Platform fees on a spot trade are just a line item between user and builder — DFlow isn't in that loop.
这是两个都使用“费用”一词的不同概念：
  • 平台费用（本技能）——构建者向用户收取。由构建者通过
    /order
    参数定义，交易成功后转入构建者的
    feeAccount
    。适用于所有交易类型。
  • DFlow预测市场交易费+返佣——构建者向DFlow支付，部分VIP返佣会从DFlow返还给构建者。仅对预测市场结果代币交易收取（公式为
    roundup(0.07 × c × p × (1 − p)) + (0.01 × c × p × (1 − p))
    ），根据过去30天的预测市场交易量分为不同等级（Frost / Glacier / Steel / Obsidian）。过去30天交易量超过10万美元的构建者可能有资格获得VIP返佣计划。详情请查看：
    /build/prediction-markets/prediction-market-fees
    。
计算净收益时请勿混淆两者。现货交易的平台费用仅存在于用户和构建者之间——DFlow不参与该流程。

When something doesn't fit

当遇到不符合预期的情况时

Defer to the docs MCP for exact parameter encoding, the code recipe at 
/build/recipes/trading/platform-fees
 (runnable, covers both 
platformFeeBps
and 
platformFeeScale
), and the FAQ entries on slippage interaction.
请参考文档MCP获取精确的参数编码，参考
/build/recipes/trading/platform-fees
中的代码示例（可运行，涵盖
platformFeeBps
和
platformFeeScale
），以及关于滑点交互的FAQ条目。

Sibling skills

相关技能

  • dflow-spot-trading
    — build the base spot 
    /order
    call; layer these params on top. Also covers priority fees and sponsored / gasless flows.
  • dflow-kalshi-trading
    — build the base PM 
    /order
    call; layer these params on top. Also covers priority fees and sponsored / gasless flows (including 
    predictionMarketInitPayer
    ).
  • dflow-spot-trading
    ——构建基础的现货
    /order
    调用；在此基础上添加本技能的参数。该技能也涵盖优先费用和赞助/无gas流程。
  • dflow-kalshi-trading
    ——构建基础的预测市场
    /order
    调用；在此基础上添加本技能的参数。该技能也涵盖优先费用和赞助/无gas流程（包括
    predictionMarketInitPayer
    ）。