RecoveryOS 帮助加密货币交易所避免沉睡客户余额落入州政府接管的灰区。

1. 沉睡余额的规模已经大到，靠人工处理例外情况根本撑不住。
2. 各州 escheat 逻辑正在和加密产品正面碰撞，而这些产品根本套不进传统银行或券商流程。
3. 买方现在已经看到，软件确实能在资产被州政府接管前明显减少流失，ROI 因而更好讲清楚。
4. 新一轮赛道融资意味着，合规负责人终于能为专门基础设施立预算，而不必继续把钱花在一次性的法务项目上。

催化因素。 Eisen 的融资以及其披露的 31% 预防率说明，沉睡资产预防正变成一个能单独预算的基础设施品类；与此同时，加密账户又把各州规则差异暴露得最尖锐。

RecoveryOS 打通交易所总账、CRM、触达渠道和合规策略引擎，持续维护一份接近沉睡门槛账户的实时清单。系统会按州别时钟、资产类型、联系方式可达性和文档缺口给账户打分，再在账户真正进入 escheat 前发起正确的通知节奏。对那些最终还是超期的账户，产品会产出可审计的决策轨迹，并编排获批的清算、汇缴、税表和客户追回流程，不再让运营团队手工把这些环节硬拼在一起。再配上一套白标追回门户，客户可以自行验身、查看可领余额并发起找回，不必制造大量定制化客服工作。

差异化。 通用的无人认领财产供应商，大多等到申报时点才介入，那时真正高风险的决定往往早就做完了。RecoveryOS 提前几个月进场，围绕加密场景的现实约束来设计：合并托管总账、代币清算政策，以及把合规、税务和客服揉在一起的客户追回流程。时间一长，它的护城河不只是规则库，而是州规则决策日志、沉睡账户基准数据，以及深度嵌进总账和消息系统的集成——这些都很难被平台轻易拆掉。

待完成任务

flowchart LR
  Buyer[Crypto compliance team] --> Pain[Inactive balances nearing dormancy]
  Pain --> Product[RecoveryOS orchestration layer]
  Product --> Outcome[Prevented losses and audit-ready filings]

高管要点

• 真正的切口存在，因为多数现有厂商都是到申报时点才开始介入；而加密货币交易所需要的是一套实时控制台，在余额落入 escheat 前就先管住不活跃检测、触达证据和资产处理决策。
• 买方紧迫感很集中，但一旦爆发就很重：美国少数几家大型交易所和托管方承受着多州沉睡余额敞口，做错不仅会导致资产流失、用户愤怒和审计问题，还可能触发应税的被迫清算。
• 通用无人认领财产软件里的竞争强度已经偏中高，但加密原生的沉睡账户预防仍然稀缺；这给了做专门工作流系统的空间，而不是非得做宽而泛的合规套件。
• 第一款产品就该坚持美国优先、托管优先，因为州别碎片化才是痛点根源，也是通用申报工具没法端到端解决问题的主因。

市场定义

面向美国托管型加密平台的软件和托管式工作流基础设施，负责尽早识别沉睡账户、编排合规的所有者触达，并为清算、汇缴或追回产出可审计路径。这个市场比通用无人认领财产申报更窄，也比宽泛的合规科技更窄；本质上是在交易所和钱包运营内部，把沉睡资产决策真正跑起来。

用户与买方

主要用户是美国加密货币交易所和托管钱包平台里的沉睡资产、合规运营、财务运营和客户运营团队。真正付钱的人通常是首席合规官、总法律顾问、运营副总裁，或其他对无人认领财产风险、审计敞口和高客服负担追回流程负责的高管。

购买触发点

• 年度持有人申报日历和尽调窗口，会把沉睡余额清理变成周期性的审计事件，而不是一次性的法务备忘录。 [6][24][25][27]
• 各州对数字资产的处理，正在从模糊走向明文规则，这迫使交易所重做策略、控制和客户沟通。 [17][26][28][29]
• 一旦交易所必须先把沉睡加密资产换成 USD 再汇缴，还可能触发应税事件，客户伤害就会瞬间变得具体。 [17][30]

支付意愿

公开定价很少，因为真正的替代方案大多按企业级或顾问式软件来卖：Sovos 主打定制定价的申报与尽调自动化，NAUPA 对小持有人仍主要指向基础申报工具，Simple Escheat 则更像轻量自助式申报产品。这说明多州持有人合规的预算确实存在，但加密原生平台若想卖出更高客单价，就必须证明自己能在申报前先把损失拦下来。 [6][19][20][46]

品类动态

增长信号 增长更受政策推动；本轮没有抓到经过验证、可单独代表“加密沉睡资产软件”市场的 CAGR 数据

验证信号

• Eisen 称，其监控的资产接近 $16B、覆盖近 50 家机构，并在 2025 年让超过 31% 的高风险资产避免流入州政府托管。
• Binance.US 在公开帮助中心里直接提醒用户，沉睡加密资产可能会被换成 USD，而且这种转换可能触发应税事件。
• 特拉华、亚利桑那和弗吉尼亚都已有官方立法材料，说明数字资产正从理论边角问题变成明确的无人认领财产议题。

监管与技术约束

• 持有人必须识别沉睡财产、尝试联系所有者，并按正确的州别流程和格式完成申报；这不是可做可不做的后台杂务。
• 各州对数字资产的处理在“先清算再汇缴”还是“实物划转”之间仍然分化，沉睡期和申报日历也不同。
• 托管型加密工作流比现金账户更难，因为活跃信号、钱包控制、估值和代币处理都更模糊。

市场大致分成 4 类：加密原生的沉睡资产专家、横向无人认领财产申报套件、州项目或审计服务导向的现有厂商，以及轻量级申报工具。拟议中的创业公司只有在拿下加密运营里的预防工作流层时，才有赢面。通用申报供应商已经证明预算存在，但它们并不天然拥有总账原生的不活跃检测、加密特有的清算决策，或客户追回体验。

为什么现有厂商不会默认胜出

• 横向申报套件. Sovos 已经证明，企业会为尽调、沉睡计算和多州申报买软件；但它的重心在横向申报广度，而不是加密原生、申报前就介入的预防编排。
• 州项目与审计型现有厂商. Kelmar 在无人认领财产领域的公信力和州项目存在感都很强，但它的姿态仍更像项目管理和合规服务，而不是深嵌交易所工作流的软件。
• 自助式申报软件. 低端工具能帮持有人把报告报上去，但它们解决不了总账集成、联系方式可达性评分，以及在财产变成可申报前的加密特定处理决策。
• 内部团队与外部律师. 手工管理日历加法律备忘录，仍是默认替代方案；但各州截止日、所有者通知要求和资产处理边角情况叠在一起，流程重到不是表格能扛住的。

RecoveryOS 应该先以只做美国市场的沉睡资产控制台切入，服务托管型加密平台，而不是一上来就做宽泛的合规科技套件，也不是只管申报的工具。第一批客户应当是历史入金账户超过 1 million、即将迎来沉睡财产审查、合规检查或赞助银行要求的零售加密货币交易所或托管钱包平台。研究显示，这个切口站得住：各州沉睡规则不同、所有者触达义务分散、加密资产处理决定又复杂，表格、外部律师和申报优先的软件都解决不好。产品 v1 应聚焦识别高风险账户、编排通知、沉淀审计证据，并管理获批的清算、汇缴和索赔追回流程；对州规则或代币处理仍有歧义的情形，保留人工复核。GTM 应由创始人主导，围绕下一次申报周期卖出付费试点，再把这套工作流转成年度平台合同，定价方式是按受管沉睡账户数加工作流按量收费。研究给出的滩头市场 SAM 为 $20.0M，第 3 年 SOM 为 $2.5M，足够支撑一个聚焦的 pre-seed 切口，但还不够支撑过早横向扩张。护城河也不只是规则内容本身，而是总账集成、州规则决策日志以及触达结果数据的组合，时间越久，预防效果和可审计性越强。最大的不确定性仍是：到底有没有足够多的交易所愿意购买一套独立的预防控制台，而不是继续沿用律师主导流程或横向申报工具。所以，这份计划把渠道伙伴分发和试点转化都列成了明确的验证项。

问题

• 面向美国用户的加密货币交易所会累积大量不活跃客户余额；一旦各州沉睡时钟、通知规则和资产处理义务开始分州分化，问题就会迅速变得法律上很难处理。
• 多数运营方仍靠表格、SQL 抽数、外部律师和申报时点才介入的供应商硬撑，结果是漏触达、被迫清算、审计风险暴露，以及本可避免的客服升级。

解决方案

• 提供一套理解托管场景的工作流系统，持续监控沉睡账户风险，按州别和资产类型判断允许的处理路径，并在余额变成可申报财产前先发起合规触达。
• 对最终仍然超期的余额，系统会生成覆盖清算、汇缴、税务文件和索赔追回的可审计链路；同时提供白标追回门户，减少定制化客服工作。

为什么我们会赢

• 公司盯住的是交易所工作流里的预防操作层——这里恰恰是现有申报套件和律师主导流程最薄弱的地方，也是 ROI 在申报日前就能看见的地方。
• 只要创业公司能拿下总账标准化、触达历史和州别决策日志，它就能在沉睡加密余额场景里累积出切换成本和绩效数据，这是只做申报的供应商拿不到的。

里程碑

flowchart LR
  Wedge[Crypto dormant-account wedge] --> MVP[Dormant control plane MVP]
  MVP --> Proof[Prevention and audit proof points]
  Proof --> Expansion[Adjacent digital-balance expansion]

创始团队

实验路线图

风险评估

必须成立的条件

• 至少有 10-15 家面向美国用户的大型托管型加密平台，其沉睡余额敞口严重到足以支撑六位数年度软件预算。
• 一个试点能在单个合规周期内接上核心总账、CRM 和通知数据，而不是拖成跨多个季度的企业服务项目。
• 使用产品的客户，相比原先“表格加律师”的流程，至少能多拦下 15-20% 即将转入州政府托管的高风险余额。
• 即便下游继续沿用申报、税务或法律供应商，交易所也愿意为一层预防型操作系统买单。
• 在横向现有厂商补齐功能前，加密原生工作流数据和集成会先积累成更好的预防和审计效果。

待尽调问题

• 目标 ICP 里到底有多少交易所，痛感真的高到愿意付六位数年费？
• 哪些州和资产类别构成第一条必须先做的工作流？又有哪些地方仍因法律歧义必须人工复核？
• 接入交易所总账和通信系统，到底要付出多少实施和安全审查成本？
• 预算实际掌握在谁手里：合规、运营、财务，还是由赞助银行推动的整改项目？
• 买方为什么会选这套系统，而不是 Eisen、Sovos、律师主导流程，或内部自建申报工作台？

模型合理性

• 收入引擎. 基准情景通过让 5 家滩头交易所上线，并把每家 ACV 逐步拉向约 $500K，刚好做到研究里的 Y3 SOM $2.5M。
• 必须做对的事. 付费试点必须在 1 个申报周期内转正，因为模型在 Y3 前只配了 1 个专职 GTM 岗位。
• 模型失效条件. 如果转化拖到接近 12 个月，同时毛利率卡在 68% 左右，现金就会转负——这正是核心下行情景。
• 下一轮融资证明点. 到了 Q4Y2，只要能同时看到 5 家正式生产客户、1 个完整申报周期证明点，以及没有服务化失控的伙伴来源销售线索，seed 轮故事就立得住。

情景

敏感性

flowchart LR
  Leads[Target exchanges] --> Pilots[Paid pilots]
  Pilots --> Customers[Production customers]
  Customers --> Revenue[Platform + usage revenue]
  Revenue --> GrossProfit[Gross profit after workflow ops]
  GrossProfit --> Cash[Cash runway]

警示项: 市场高度集中，所以哪怕只丢 1 家目标交易所，结果都会明显改写。 · 模型默认交易所会在现有申报供应商把类似工作流打包进去之前，先买一套独立控制台。 · 只有人工策略例外下降得够快、避免交付变成重服务模式，毛利率才能真正超过 BP 目标。

• 监管口径仍有歧义. 一些州对特定数字资产的处理方式可能并不一致，默认清算或汇缴政策因此很难标准化。 缓解措施: 先从托管现金和稳定币流程切入，把策略逻辑按州做成可配置，并与专门的无人认领财产律师合作。
• 紧迫感高度集中. 较小的平台未必觉得沉睡资产问题严重到值得购买，除非等到检查或申报失败逼着它们出手。 缓解措施: 初期销售只盯拥有百万级历史账户的交易所，并把定价锚定在减少资产损失和节省申报人工上。
• 现有厂商向上游扩张. 一旦赛道足够有吸引力，通用无人认领财产软件供应商可能会把能力从申报时点一路往前延伸到预防环节。 缓解措施: 趁横向厂商还没适配前，先在加密原生总账集成、客户追回工作流和证据系统上拉开差距。