托管资金台运营：合并净值、出账前 simulation 拦 revert、mass payout 与 KYT 审计
资金台的运营既要看得全，也要走得稳。看得全是指把散在 BTC/ETH/TRON 上的头寸合并成一个可信的 net-worth；走得稳是指每一笔出账在进入 MPC/multisig 审批流之前就要确认它不会失败，并且整个资金动向要留下可审计的合规轨迹。1st Node 把净值合并、出账前 simulation、mass payout 与 KYT 监控放在一把 key、一个 credit 余额上，节点自有，签名始终在客户端。
面临的挑战
托管场景对错误的容忍度极低。一笔会 revert 的出账如果直接进了 MPC/multisig 审批流，审批人会浪费签名、时间和 gas，甚至在协调多签时造成流程混乱。所以理想的做法是在交易到达审批人之前就先 simulation 一遍，把会失败的挡在门外。与此同时，资金动向必须持续过 KYT，并为每一次 allow/review/block 留下可复现的审计记录，以备内控和监管核查。而最硬的红线是密钥：托管方绝不能把签名权交给外部服务。这些诉求叠在一起，要求一个既能读、能模拟、能出款、能监控，又完全不碰私钥的后端。
- Balances / portfolio / net-worthC2
- Simulate tx (preview)C3
- Mass payout / settlementC2
- Transaction screening / KYTC3
一次读取合并 BTC/ETH/TRON 的 net-worth
资金台首页需要一个跨链合并的净值视图。通过一次 net-worth 读取，把 BTC/ETH/TRON 的头寸合并成统一口径的总额，运营和财务看到的是同一个数。数据来自自有归档节点，历史与当前状态同源，便于对账与回溯。
出账前 simulation 在到达 MPC/multisig 前捕获 revert
每一笔出账在进入 MPC/multisig 审批流之前先跑 simulation：如果这笔交易会 revert，在审批人签名之前就被捕获并拦下，不浪费审批人的签名与 gas。关键是签名完全在客户端，平台不持有 key——simulation 只是预演执行结果，不接触私钥，密钥红线不被触碰。
mass payout 出款，KYT 留下 allow/review/block 审计
批量出款走 mass payout，从统一的 credit 余额出账。资金动向由 KYT 持续监控，每一次判定形成 allow/review/block 的记录，供内控和监管审计。读净值、模拟、出款、监控挂在同一把 key 下，审计链路完整且口径一致。
该架构交付什么
- BTC/ETH/TRON 的净值一次读取合并为统一口径，运营与财务共用同一个总额视图。
- 出账前的 simulation 在到达 MPC/multisig 审批人之前捕获 revert，避免浪费签名与 gas，且签名全在客户端、平台不持有 key。
- mass payout 出款配合 KYT 的 allow/review/block 记录，形成可审计的资金动向轨迹，全部挂在一把 key、一个 credit 余额下。
常见问题
你们要模拟出账、又要读余额，会不会因此拿到我们的签名权或私钥？
不会。simulation 只是预演交易的执行结果，签名完全在客户端完成，平台不持有 key。读净值、模拟、出款都不接触私钥，密钥始终留在你自己的 MPC/multisig 一侧。
怎么在审批人签名之前就知道一笔交易会失败？
在交易进入 MPC/multisig 审批流之前先对它做 simulation，如果会 revert 就在这一步被捕获并拦下，审批人不必为一笔注定失败的交易浪费签名和 gas。
充值、拿密钥、上线。
自助开通。支持加密货币或银行卡。按额度计费——重型原语更贵，简单调用很便宜。
获取 API 密钥