四种费用都从买家出：Immutable 订单簿的费用表怎么读

在支持订单簿撮合的 NFT 平台里，成交后钱怎么被切分，往往比挂单价本身更难查。Immutable 的订单簿文档对这件事写得相当直白：系统支持协议费、版税、Maker 费、Taker 费四种费用，交易执行时自动从付款中扣除，并且一句话定调——所有费用由买方支付，卖方拿到的是售价减去被扣部分后的净额。

四种费用各有收款人和设定方。协议费归 Immutable，文档在费率表里写明主网与测试网均为百分之二，不可协商，覆盖订单簿上的全部交易；版税归 NFT 创作者，设定在 NFT 合约上，由订单簿强制执行；Maker 费归挂单方所在的市场，由创建订单的一方设定；Taker 费归吃单方所在的市场，由执行订单的一方设定。最后两项的存在，是因为同一本订单簿可以被多个前端市场接入：你在 A 站挂单、买家在 B 站下单，A 与 B 可以各自附加自己的市场费，互不干涉。

文档给了一个贯穿例子：一笔 1 单位代币的付款，协议费 0.02、版税 0.05、Maker 费 0.01、Taker 费 0.01，卖方到手 0.91。这个算式的重点不在具体数字，而在方向：挂单的人标多少，收到的就只会更少；买方以为“卖家收 1.00”的直觉在 Immutable 的费用模型里恰好相反。同一份文档还提醒，费用以代币最小单位记账而非百分比——例如 18 位小数的代币里，数值 0.01 个币要写成 1 后面跟 16 个零的整数，参数填错位就等于把费用放大一百倍。

部分成交是这套模型里最容易算错账的场景。文档说明费用是按名义金额（notional）填写的具体数值，订单部分成交时，订单簿会自动按比例折算各项费用。也就是说，你为一整单设置了固定数值的费用，成交一半时各方拿到的也是对应一半，不会出现“半单仍收全额协议费”的错配。对开发者，这意味着接入时不要把费用写成自己算好的百分比逻辑，交给订单簿折算即可；对普通用户，这意味着部分成交后的到账差额与成交比例应当一致，若不一致更可能哪里出了问题，值得去查订单明细。

对交易者还有一个常被忽略的核对动作：下单前看费用明细字段而不是只看总价。订单簿类接口通常把四类费用拆开展示，逐项确认收款地址归属（平台金库、创作者地址、两个市场地址）比只盯一个“预计支付”数字更能发现问题——仿冒前端常用手法就是悄悄替换其中一项的收款地址。四种费用对应四个收款方，这个结构本身就是防篡改的抓手：任何一个收款地址与官方文档说明不符，先停手再查。

把费用方向放到跨市场比较里还有另一层含义。有的平台让卖方承担主要费用，有的像这里一样由买方全额承担，两种设计对“挂单价”的含义完全不同：买方付费制下，卖家标价即毛收入，买家实付永远高于标价；卖家付费制下则相反。在多个市场之间比价时，先确认目标市场的费用方向，再把同一种“到手价”或“实付价”口径统一，数字才可比。这一步不做，两个市场报价的差值里混着费用结构的差值，比较本身就失去了意义。

最后核对费率本身要注意时效。协议费百分之二、测试网同费率，这些都是文档撰写时查阅到的数字，平台随时可能调整，接入前应回到官方文档页确认当前值；对交易者来说，同一平台不同时期挂单，费用字段也可能已变。费率之外，文档给出的框架相对稳定：谁收款、谁设定、从谁的份额里扣、部分成交怎么折算——四问的框架比任何具体数字更耐久，拿到任何市场的费率页，按这四问重写一遍，费用结构就没有秘密。

本文为机制说明，不构成任何投资建议。