如果你是一家 brokerage、媒体运营者或决定上线预测市场场所的金融科技公司,下一步要做的决定就是:自己构建基础设施,还是授权使用别人的基础设施。大多数团队带着粗略的估算来面对这个问题,最终都会被实际的数字吓一跳。这正是我们当初希望拥有的那份拆解。
本文面向已经理解机会所在的运营者(如果还没有,请先阅读我们的市场分析)。这里的问题纯粹是执行层面的:以美元和月数衡量,要交付一个能够承载真实交易量的可信场所,到底需要多少成本?
“自建”到底意味着什么
在讨论成本之前,先具体说明一个完整的预测市场平台究竟需要哪些组成部分会很有帮助。运营者一致地低估了这份清单,因为其中一些部分要等到深入实施阶段才会显现出来。
一个生产级场所至少需要:
- 结果合约。 定义条件性 payoff、接受抵押品并在 resolution 时进行支付的 Smart Contract(或其链下等价物)。它们必须能够处理 YES/NO 合约、多结果市场以及条件依赖关系,而且必须经过审计。
- 一个 matching engine。 一个中心化的限价订单簿,通常运行在 relayer 架构之上,让用户不必为每一笔订单支付 gas。这是非平凡的软件——亚毫秒级的撮合排序、公平性保证、部分成交机制、cancel-replace 语义。
- 结算基础设施。 一种确定结果并对市场进行结算的方式。要么是中心化的市场完整性团队,要么是乐观 Oracle 集成(UMA),要么是自建的 Oracle 网络。每一条路径都有各自持续的运营负担。
- Wallet 与托管。 如果你是 crypto-native,那就意味着 wallet 集成加上链上托管。如果你是受监管机构,那就是法币出入金通道、隔离客户资金以及为这种隔离辩护所需的审计轨迹。
- KYC、AML 与合规流水线。 按司法辖区划分。每个司法辖区都有自己的供应商体系、身份证件要求和报告义务。
- 前端与移动应用。 交易 UX、出入金流程、市场发现、图表、仓位管理、通知。这是用户体验的大部分。
- 流动性供给。 要么是做市机器人,要么是合约式做市商关系,要么是与另一家场所达成共享流动性安排。没有这一项,你就没有场所。
- 运营。 7×24 监控、事件响应、客户支持、争议处理、市场创建流水线,以及处理边缘情况的人工 override 能力。
八根支柱。每一根本身都是一项严肃的工程项目。
从零自建的现实成本
下面是我们在审阅过的运营者自建计划中持续出现的成本结构。这些是 2026 年的数字,针对的是一个清楚自己在做什么的团队,并不是最便宜的构建路径。
| 组件 | 初始成本 | 时间 | 持续费用 |
|---|---|---|---|
| Smart Contract + 审计(OpenZeppelin 或 Trail of Bits) | $280k – $520k | 4–6 个月 | $30k / 年 |
| Matching engine + relayer 架构 | $520k – $980k | 5–8 个月 | $140k / 年 |
| 结算 / Oracle 集成 | $180k – $360k | 3–5 个月 | $60k / 年 |
| Wallet + 托管(受监管司法辖区) | $420k – $800k | 5–9 个月 | $220k / 年 |
| KYC / AML 流水线(1 个司法辖区) | $140k – $260k | 2–4 个月 | $80k / 年 |
| 前端 + 移动端 + 设计系统 | $580k – $1.1M | 5–7 个月 | $280k / 年 |
| 流动性(初始做市) | $1.0M – $2.5M | 持续 | 差异极大 |
| 运营 / 支持 / 监控基础设施 | $320k – $640k | 2–3 个月 | $340k / 年 |
合计是 340 万到 720 万美元的前期成本,每年 115 万美元以上的持续运营开销,以及大约 8 至 14 个月的关键路径时间表——单条最长的工作流是 matching engine,但实践中真正的约束是审计,因为 matching engine 依赖稳定的合约接口,而这些接口要等到审计完成第二轮之后才会交付。
上述数字假设是一个司法辖区、一种语言、单一资产类别。每增加一个司法辖区,前期成本约增加 $200k,时间增加 6 至 10 周。多资产支持(例如体育 + 宏观 + crypto)会在市场创建和结算自动化方面再增加一层复杂性。
没人会算进去的隐性成本
上面列出的是明显的部分。另外还有六项是运营者一贯低估的。
审计周期是复数,不是单数。 第一轮审计会带回若干 finding。你修复它们、重构、再审计。然后是第三轮。每一轮 6 至 10 周、$90k–$160k。大多数团队按一次审计来做预算,最后发现自己需要三次。
流动性不是一次性成本。 做市商安排要么是为提供 spread 而支付的合约费用,要么是必须充值资本的内部账本。无论哪一种,成本都将无限期地持续,并随交易量扩大而增长,不会随时间下降。
监管参与是双向的。 你拿不到一张许可证;你是在数月或数年间与监管机构建立一种关系。这种关系有软成本(高管时间、法律顾问、定期书面陈述、面对面会议),它们不会出现在任何成本表上。
Resolution 运营。 像 Polymarket 当前的状态那样,每周拥有 9,800 个活跃市场的平台,每天会有几十个边缘情况下的 resolution——市场底层数据存在歧义、信息源发生变化、重大事件重新框定了结果问题。每一个都需要人为判断、有据可查的推理过程以及对外可辩护的结论。运营者一贯没有为这种 resolution-ops 编制相应的人头预算。
基础设施的攻击面。 你构建的每一个组件都是你必须捍卫的组件。抢先交易、Oracle 操纵、MEV 提取、前端钓鱼、密钥管理失败——威胁模型很广,后果是公开的。生产环境中的运营者在上线后会把 20% 至 30% 的工程产能花在加固上。
晚上线的机会成本。 在 2026 年塑造受众期待的运营者品牌将持续累积优势。延后 12 个月上线,损失的不只是 12 个月的收入——它是把 12 个月的领先优势拱手让给最先在你目标受众中上线的对手。
授权到底解锁了什么
授权基础设施并不是一个折中的答案。干净地走授权路径的运营者,所运营的产品表面与自建运营者相同——同样的合约、同样的深度、同样精细的 UX——但成本结构不同。
| 维度 | 自建 | 授权 (Kuest) |
|---|---|---|
| 首笔实盘交易的时间 | 8–14 个月 | 数天 |
| 前期资本 | $3.4M – $7.2M | ≈ $0 |
| 上线时的流动性 | 冷启动 | 由现有场所共享 |
| 审计归属 | 运营者 | 继承(OpenZeppelin) |
| Resolution 通路 | 自建 / 集成 | 托管 |
| 每个司法辖区的叠加成本 | 每个 +$200k | 配置 |
| 工程团队规模 | 5–8 名 FTE | 0 |
| 每笔交易的运营者费用 | 是 | 是 |
运营者费用是关键的经济点。授权不会以任何实质性的方式稀释你每笔交易的收入——大多数基础设施协议把平台费定价为运营者费用的一小部分,而不是按收入分成。你保留 brokerage 利润;你把工程构建外包出去。
对大多数运营者来说,相关的问题不是“授权能让我节省多少?”——而是“能让我多早锁定受众归因?”。在构建上节省下来的成本是真实的,但它只是提前 9 至 12 个月上线所带来价值的一小部分。
自建什么时候确实有意义
确实有三种场景下自建是真正有意义的,值得对它们坦诚相待。
你就是场所,而不是运营者。 如果你的战略定位是成为全球性的场所(例如 Polymarket 或 Kalshi),那么你必须拥有基础设施,因为这就是护城河。你不会授权。你会自建,募集机构资本来支撑构建,并接受两年的时间表。
你拥有协议无法支持的独特合约设计。 如果你的价值主张是某种异乎寻常的东西——一种新型的多抵押合约、一种永续预测产品、一种 contract-as-derivative 包装——协议层面的抽象可能不适合。大多数运营者并不属于这一类,但确实有少数属于。
你是主权或准主权行为者。 一些机构出于非商业原因必须自有基础设施——主权财富基金、与中央银行相关的场所、大型国有交易所。它们会自建,因为授权会带来一种它们无法接受的非经济依赖关系。
对于其他所有人——每一家零售 brokerage、每一家面向消费者的金融科技公司、每一家拥有受众的媒体运营者——自建的路径是一种分心。
自建路径上没人预料到的失败
即便是对成本与时间表抱有清醒认识的团队,也会被某一类不会出现在任何路线图中的问题伏击。在我们观察过(以及在某些情况下在抢救阶段接手的)从零自建尝试中,有三种模式反复出现。
构建中期的工程师流失。 一位资深 Smart Contract 工程师在第七个月离职。他的接替者要等到第九个月才入职。知识转移又额外吞掉两个月。审计推迟了一个季度,因为合约表面在交接过程中持续变化。这并非假设——这就是自建项目典型的失败模式,因为有资格写这些合约的人很稀缺,而且他们有的是选择。
流动性提供方在上线途中改变经济条款。 运营者在第四个月签下了看起来还不错的做市商协议。到第十个月,做市商在竞争性账本上的机会已经变得更优。重新谈判会让运营者拿到更差的条款,或被迫切换到内部做市,从而新增一条原本预算中不存在、超过 100 万美元的资本线。
构建期间的监管漂移。 你在第一个月对照着构建的框架,并不是你在第十四个月准备申请 no-action letter 时所存在的那个框架。运营者一贯低估一年以上的构建周期内监管漂移所带来的返工量。我们看到过一些项目交付了、技术上也能运行,却无法申请它们当初设计目标的那张许可证,因为规则已经变了。
这三者共同的结构性属性是“持续时间风险”。在你处于构建阶段的每一个月里,你计划所依赖的假设都必须继续成立。但这些假设不会可靠地成立。授权把构建阶段压缩成几天,从而把持续时间风险压缩到接近于零——你是在面对当前的条件运营,而不是在赌一年后才会出现的条件。
一个快速的决策框架
按顺序问下面三个问题,可以把你引向正确的答案:
- 你的竞争护城河是场所,还是受众? 如果是受众,那就授权场所。如果场所本身就是护城河,那就自建。
- 你能在 12 个月以内交付一个可用的产品吗? 如果可以,自建是可以摆上桌面的选项。如果不能,你就是把受众交给那些做得到的人。
- 你的产品是否要求任何协议都不存在的合约设计? 如果是,自建。如果你的需求落在标准的二元 / 多结果 / scalar 合约空间内,那就授权。
大多数诚实地走完这套问题的运营者最终会回答:“是受众,12 个月内不太可能,合约需求是标准的。”那就是一个授权的决定。
授权在实践中是什么样子
一次干净的 Kuest 授权部署,在时间和顺序上看起来是这样的:
- 第 0 天。 通过 launch wizard 提交品牌素材、费率模型、受众定义、目标司法辖区。
- 第 0 – 1 天。 在你的运营者身份下部署 Smart Contract。配置自定义市场类型。选择 resolution 数据源。
- 第 1 – 3 天。 前端按你的品牌风格定制。按司法辖区配置合规流程。
- 第 3 – 5 天。 面向封闭受众进行 soft launch,做行为验证。流动性已经从共享订单流中到位。
- 第 5 – 14 天。 公开上线。运营者费用对每一笔交易开始收取。工程团队规模为零。
同样的范围,从零自建,需要一年半。
