返回博客operators

自建还是授权预测市场:2026 年的成本与时间分析

从零开始构建预测市场究竟需要多少成本——工程、审计、Oracle、合规、流动性——与授权基础设施的对比。真实数字,真实时间表。

自建还是授权预测市场:2026 年的成本与时间分析

如果你是一家 brokerage、媒体运营者或决定上线预测市场场所的金融科技公司,下一步要做的决定就是:自己构建基础设施,还是授权使用别人的基础设施。大多数团队带着粗略的估算来面对这个问题,最终都会被实际的数字吓一跳。这正是我们当初希望拥有的那份拆解。

本文面向已经理解机会所在的运营者(如果还没有,请先阅读我们的市场分析)。这里的问题纯粹是执行层面的:以美元和月数衡量,要交付一个能够承载真实交易量的可信场所,到底需要多少成本?

$3.8M – $7.2M
构建一个生产级预测市场平台的现实成本区间,包含经过审计的合约、自有的 matching engine 以及基础的 resolution 通路
Kuest 运营者调研,2026 年第一季度

“自建”到底意味着什么

在讨论成本之前,先具体说明一个完整的预测市场平台究竟需要哪些组成部分会很有帮助。运营者一致地低估了这份清单,因为其中一些部分要等到深入实施阶段才会显现出来。

一个生产级场所至少需要:

八根支柱。每一根本身都是一项严肃的工程项目。

从零自建的现实成本

下面是我们在审阅过的运营者自建计划中持续出现的成本结构。这些是 2026 年的数字,针对的是一个清楚自己在做什么的团队,并不是最便宜的构建路径。

组件初始成本时间持续费用
Smart Contract + 审计(OpenZeppelin 或 Trail of Bits)$280k – $520k4–6 个月$30k / 年
Matching engine + relayer 架构$520k – $980k5–8 个月$140k / 年
结算 / Oracle 集成$180k – $360k3–5 个月$60k / 年
Wallet + 托管(受监管司法辖区)$420k – $800k5–9 个月$220k / 年
KYC / AML 流水线(1 个司法辖区)$140k – $260k2–4 个月$80k / 年
前端 + 移动端 + 设计系统$580k – $1.1M5–7 个月$280k / 年
流动性(初始做市)$1.0M – $2.5M持续差异极大
运营 / 支持 / 监控基础设施$320k – $640k2–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 名 FTE0
每笔交易的运营者费用

运营者费用是关键的经济点。授权不会以任何实质性的方式稀释你每笔交易的收入——大多数基础设施协议把平台费定价为运营者费用的一小部分,而不是按收入分成。你保留 brokerage 利润;你把工程构建外包出去。

对大多数运营者来说,相关的问题不是“授权能让我节省多少?”——而是“能让我多早锁定受众归因?”。在构建上节省下来的成本是真实的,但它只是提前 9 至 12 个月上线所带来价值的一小部分。

自建什么时候确实有意义

确实有三种场景下自建是真正有意义的,值得对它们坦诚相待。

你就是场所,而不是运营者。 如果你的战略定位是成为全球性的场所(例如 Polymarket 或 Kalshi),那么你必须拥有基础设施,因为这就是护城河。你不会授权。你会自建,募集机构资本来支撑构建,并接受两年的时间表。

你拥有协议无法支持的独特合约设计。 如果你的价值主张是某种异乎寻常的东西——一种新型的多抵押合约、一种永续预测产品、一种 contract-as-derivative 包装——协议层面的抽象可能不适合。大多数运营者并不属于这一类,但确实有少数属于。

你是主权或准主权行为者。 一些机构出于非商业原因必须自有基础设施——主权财富基金、与中央银行相关的场所、大型国有交易所。它们会自建,因为授权会带来一种它们无法接受的非经济依赖关系。

对于其他所有人——每一家零售 brokerage、每一家面向消费者的金融科技公司、每一家拥有受众的媒体运营者——自建的路径是一种分心。

自建路径上没人预料到的失败

即便是对成本与时间表抱有清醒认识的团队,也会被某一类不会出现在任何路线图中的问题伏击。在我们观察过(以及在某些情况下在抢救阶段接手的)从零自建尝试中,有三种模式反复出现。

构建中期的工程师流失。 一位资深 Smart Contract 工程师在第七个月离职。他的接替者要等到第九个月才入职。知识转移又额外吞掉两个月。审计推迟了一个季度,因为合约表面在交接过程中持续变化。这并非假设——这就是自建项目典型的失败模式,因为有资格写这些合约的人很稀缺,而且他们有的是选择。

流动性提供方在上线途中改变经济条款。 运营者在第四个月签下了看起来还不错的做市商协议。到第十个月,做市商在竞争性账本上的机会已经变得更优。重新谈判会让运营者拿到更差的条款,或被迫切换到内部做市,从而新增一条原本预算中不存在、超过 100 万美元的资本线。

构建期间的监管漂移。 你在第一个月对照着构建的框架,并不是你在第十四个月准备申请 no-action letter 时所存在的那个框架。运营者一贯低估一年以上的构建周期内监管漂移所带来的返工量。我们看到过一些项目交付了、技术上也能运行,却无法申请它们当初设计目标的那张许可证,因为规则已经变了。

这三者共同的结构性属性是“持续时间风险”。在你处于构建阶段的每一个月里,你计划所依赖的假设都必须继续成立。但这些假设不会可靠地成立。授权把构建阶段压缩成几天,从而把持续时间风险压缩到接近于零——你是在面对当前的条件运营,而不是在赌一年后才会出现的条件。

一个快速的决策框架

按顺序问下面三个问题,可以把你引向正确的答案:

  1. 你的竞争护城河是场所,还是受众? 如果是受众,那就授权场所。如果场所本身就是护城河,那就自建。
  2. 你能在 12 个月以内交付一个可用的产品吗? 如果可以,自建是可以摆上桌面的选项。如果不能,你就是把受众交给那些做得到的人。
  3. 你的产品是否要求任何协议都不存在的合约设计? 如果是,自建。如果你的需求落在标准的二元 / 多结果 / scalar 合约空间内,那就授权。

大多数诚实地走完这套问题的运营者最终会回答:“是受众,12 个月内不太可能,合约需求是标准的。”那就是一个授权的决定。

授权在实践中是什么样子

一次干净的 Kuest 授权部署,在时间和顺序上看起来是这样的:

同样的范围,从零自建,需要一年半。