测试了一遍 Circle StableFX：关于链上外汇、技术架构和商业模式的一些思考

截图中的钱包地址、交易标识等个人信息已做遮挡处理。

最近因为工作原因，需要对 Circle StableFX 做一些测试。之前对 USDC、Arc、CPN 已经有一些了解，这次申请了 Sandbox 账号，主要想把换汇流程实际跑一遍，再看看它背后的技术和业务逻辑。

操作本身不算复杂，但做完之后，有几个地方挺值得琢磨：为什么用 Maker 报价，而不是 AMM？为什么锁定汇率以后还要签名、交付资金？为什么测试时交易的一侧必须是 USDC？以及，做市商还要向平台付费，只靠点差能不能赚钱？

这些问题其实连在一起。先从这次测试说起。

一、先说体验：一次 StableFX 交易经历了什么

进入 Trade 页面，选择卖出和买入的资产、金额，再选择 Settlement tenor，就可以请求报价。拿到报价以后，确认汇率和费用，连接钱包签名，然后进入资金交付与结算阶段。

图 1：Sandbox 测试中的交易输入页面。文中截图来自不同次 Sandbox 测试，金额和报价并非同一订单的连续记录。图片均可点击查看原图。

整个体验大致是：

选择交易对 → 获取报价 → 确认并锁定交易条件
          → 钱包签名 → 交付资金 → 双方完成结算

我最直接的感受，是“成交”和“到账”被分得很清楚。确认报价时能看到兑换数量、手续费和抵押额；锁价之后，资金还需要按照这笔交易的要求完成交付。页面显示汇率已锁定，并不代表兑换所得已经进入钱包。

图 2：Sandbox 测试中的报价确认页面。图中价格与费用为当时测试值。

Settlement tenor 也体现了这个区别。它约定的是结算窗口，不能简单把 instant 当成“点击后立即到账”。整理文章时，官方文档将 instant、hourly、daily 分别说明为交易创建后的 30 分钟、1 小时和 1 天窗口。技术指南

另一个很明显的角色是 Maker。我能测试 Trade，但进入 Fulfill 后，页面提示 Maker 账户还没有完成配置，所以这次并没有实际跑通 Maker 端履约。

图 3：测试时进入 Fulfill 页面，提示 Maker 账户尚未完成配置。

这让我开始关注它的市场组织方式：用户在一侧提出换汇需求，另一侧有人负责报价和交付资产。这个角色分工，是理解后面技术设计的起点。

二、从 AMM 到 RFQ：把报价交给做市商

稳定币兑换当然可以用 AMM。资产放进池子，按照池子的规则和流动性状态成交，是很成熟的一种做法。那 StableFX 为什么选择另一条路？

我的理解是，它希望让机构把已有的做市能力带进来。Maker 可以根据订单金额、库存、市场价格和交割期限，给出一笔具体交易的报价。Taker 接受之后，再按确定的条件交付。

Taker 发起询价 → Maker 提供报价 → 接受价格 → 链上交割

RFQ，也就是 Request for Quote，适合把这些交易条件交给专业机构定价。StableFX 用链下执行引擎组织询价和报价，把结算放在 Arc 上，官方也明确采用了这个分工。技术指南

这并不等于 AMM 天生不适合外汇，也不能说 RFQ 一定没有滑点、一定更便宜。AMM 的效果取决于池子设计和深度，RFQ 的效果取决于 Maker 的报价和履约能力。

但两者的流动性组织方式确实不同。StableFX 更依赖有人愿意持续为具体订单承担价格和库存风险。机构能够沿用自己的风险管理方式，这是它的吸引力；没有足够好的 Maker 报价，也是它绕不开的限制。

三、一次交易背后的链上流程

报价确定以后，剩下的问题就是：怎样把双方的承诺变成可以执行的资产交换？这次看签名数据和合约记录，主要涉及 EIP-712、Permit2、FxEscrow 和 PvP。

EIP-712 + Permit2：把交易条件放进签名

测试中的结构化签名包含 Consideration，里面有报价标识、两种代币地址、双方金额以及到期时间。比如这次测试中的一笔交易，对价是 4 USDC 和 3.587765 EURC；这个 EURC 数量是扣除相应费用前的金额。

这些数据让签名与具体交易条件绑定起来。汇率可以由两侧金额体现，不一定另外存在一个叫“汇率”的字段。

EIP-712 规定结构化数据如何签名，Permit2 则参与按授权划转代币。交易确认和后续资金交付有各自的签名用途，不能把钱包弹出的几次请求都理解成同一个授权。

另外，Permit2 仍需要首次代币授权，不能理解成完全不需要 approve。已有适当授权之后，再利用签名完成后续转移，这是首次交易教程中说明的流程。

图 4：测试中的资金交付页面，再次确认 Delivering、Receiving 和 Due。

FxEscrow：把资金放进有条件的交割流程

用户交付的资金进入 FxEscrow 托管合约，合约记录订单和注资状态，按条件处理双方资产。

这一层很有必要。假如用户直接把 USDC 转给 Maker，就需要相信对方会随后支付 EURC。通过托管，资金的释放与另一侧的交付联系起来，双方按照同一套规则完成交易。

以这次测试中 Taker 先注资的路径看，takerDeliver 先把用户资产转入托管，makerDeliver 再完成 Maker 的交付。当两边都满足条件，合约触发结算。报价和签名在链下组织，最终资金流转可以在链上追踪。

PvP：两侧付款相互依赖

PvP 是 Payment versus Payment，可以理解成一手交钱、一手交资产。它要求最终两侧交割相互依赖，避免一方已经付出本金、另一方却没有支付的情况。

图 5：根据本次测试整理的交互时序。图中接口名称作了简化，用于说明签名、资金交付和结算之间的关系；具体接入以官方文档为准。

这里说的原子结算，是最终交换在同一笔链上交易中完成，不是把询价、签名和双方注资全部压进一笔交易。本次测试中，那笔 4 USDC 交易的结算结果是：用户收到 3.567765 EURC，Maker 收到 3.99 USDC，另有 0.02 EURC 和 0.01 USDC 进入手续费钱包。

这也解释了为什么报价金额和最终到账量需要分别看。上述数字是测试记录，不能外推为生产费率。

我觉得这套设计的价值在于，把交易承诺、资金托管和交割条件串了起来。它降低的是特定的结算风险，资金等待、到期违约、合约和资产风险仍需要管理。未按期完成交付的交易，会按相应规则进入违约与退款处理。结算说明

四、以 USDC 为中心，首先是流动性怎么组织

测试时还有一个限制：交易必须有一侧是 USDC，不能直接把 EURC 换成 GBPA。这是当时环境里观察到的限制，不代表技术上永远不能支持其他交易对。

我倾向于从流动性组织去理解它。如果一开始就支持所有非美元资产互换，需要持续维护的报价组合会迅速增加。即使能通过交叉汇率定价，也要解决相应资产的获取、对冲和交付。

先围绕 USDC 建立报价关系，可以让市场集中一些。对 Maker 来说，核心库存、对冲路径和结算安排也更容易标准化。这和外汇市场中围绕美元组织大量交易的思路相近。

当然，集中也有代价。用户原本只想完成欧元和英镑之间的兑换，如果要通过 USDC 做两笔，就可能增加费用和中间敞口。单笔 PvP 不会自动把两笔兑换变成一个原子过程。

所以我更愿意把它看成一种发展阶段的取舍：先让有限的交易对形成足够深的流动性，再看跨币种需求是否值得单独建立市场。

五、Maker 的商业模式：点差之外还要算什么

Maker 提供报价、准备资产，平台又会收取费用，最后剩下的利润从哪里来？这是比交易按钮更值得算的一笔账。

点差可以赚钱，但不是净利润

假设 Maker 获得资产的综合成本低于卖给客户的价格，差额就是毛收益。但拿到客户订单以后，它还要对冲、补库存、安排资金，有时还要承担价格变化带来的损失。

Maker 净收益
≈ 交易量 × 实现的毛点差
－ 平台费用－对冲成本－资金成本
－ 运营成本－预期风险损失

举个纯假设的例子：100 万美元成交量，实现 10 个基点的毛点差，毛收入是 1,000 美元。如果各项成本合计 8 个基点，剩下 200 美元；成本升到 12 个基点，就亏 200 美元。这里没有采用 StableFX 的实际费率。

所以只靠点差的模式可以成立，但交易量并不是越大越好。每单扣完成本仍有正收益，扩大规模才有意义。客户长期只往一个方向换币，Maker 就要不断补充另一种库存，经营结果也会和双向订单平衡时很不一样。

StableFX 要给 Maker 带来什么

首先是订单流。Maker 已经有资金和定价能力，如果平台能带来原本接触不到的客户，它就有理由参与。更稳定、方向更平衡的订单，也有助于安排库存。

其次是减少重复建设。统一的交易接口和结算流程，可以降低逐个接入交易对手的成本。不过 Maker 仍然需要自己的定价、风控和资金管理系统，平台不会替它完成所有做市工作。

第三是结算与资金效率。PvP 改善本金交割风险，批量注资减少操作次数，符合条件的净额处理有机会减少资金需求。Batch fund 不是向公共流动性池充值，批量操作和净额处理也不是同一个概念。Maker 操作说明

平台的收费最后要由这些价值支撑。Maker 愿不愿意长期留下来，取决于得到的订单和节省的成本，能否覆盖平台费用与自身风险。只有页面更方便，还不够。

六、哪些业务真的需要这样的换汇方式

跨境支付：把换汇接进付款流程

例如企业已经持有 USDC，要支付欧洲供应商，可以先换成 EURC。如果供应商接受 EURC，链上换汇就能和后续付款连起来。

如果供应商只收银行欧元，则还需要赎回和当地支付通道。StableFX 覆盖其中的换汇与链上交割，完整到账时间仍要把后面的环节算进去。这个场景的价值，应当用最终成本和到账速度衡量。

金融机构结算：处理持续的双向资金需求

支付公司、交易平台可能每天都有不同币种的流入和流出。对它们来说，报价、交割和对账如果能统一起来，会比逐笔人工协调方便得多。

这类业务也更容易用到批量和净额安排。不过能节省多少资金，要看真实订单方向与结算条件，不能只看“支持批量”这个功能名称。

企业财资：让不同币种的余额可以调配

一家企业有美元收入、欧元支出，就可能需要把一部分余额换成接下来要支付的币种。金额、用款时间和可接受价格都比较明确，和 RFQ 的订单方式比较契合。

前提是企业真的愿意持有并使用这些稳定币。如果收款、工资和采购最终全部在银行账户里完成，稳定币换汇还要证明自己能减少整条链路的成本。

七、我的判断：挑战在流动性、合规和资产生态

测试之后，我对这套技术分工是认可的。但 Sandbox 能说明流程怎么走，无法证明真实市场里有多少人愿意来交易。

流动性是第一个问题。足够好的报价吸引订单，订单又吸引 Maker，网络才有机会成长。初期如果交易量不够，Maker 不愿投入太多库存，报价和额度就可能反过来限制用户增长。合约运行顺畅，并不能自动解决这个循环。

合规和机构接入也必须放进商业模型。账户配置、交易对手准入、本地业务安排，都会影响谁能参与、成本有多高。对于需要连接当地银行和支付渠道的业务，仅有链上可兑换的资产还不够。

再往下是非美元稳定币生态。Maker 得能方便地获取和赎回资产，客户换到以后也得有地方使用。发行、流通、兑换和支出之间少一环，资金就很难持续周转，换汇网络也难形成稳定需求。

这次最大的收获，是把几个看似独立的设计看成了一件事：RFQ 让机构负责定价，USDC 集中早期流动性，Permit2 和 FxEscrow 把交易条件接到资金交付，PvP 约束最终交换。

我更关心它接下来能否形成一门持续运转的生意：用户拿到合适的价格，Maker 扣完成本还有利润，换到的资产又能进入真实业务。技术已经给出了组织交易的方式，剩下的要靠真实订单来回答。