密钥必须在线，能拦的是请求

托管型处理商手里有一把能动你余额的密钥。下面任何一条都改不了这件事。这些控制改的是：能造出多少种转账让这把密钥点头。每一道关掉一条路，把别的路留着。带边界写出来的控制比不带边界的值钱，边界正是要摆一个人的地方。

密钥在线的理由很平常。商户在某个时区凌晨两点点下发送，服务商那边没人醒着，转账照样要拼出来、签好、发出去。冷钱包的定义恰恰是它答不了这件事。所以真正的问题从来不是密钥在不在线，而是一次请求在见到它之前得先穿过什么。

最大的一笔失窃，密钥没坏在哪儿

因为那笔交易是由本该签它的人签的。

2025年2月21日前后，约 15 亿美元的虚拟资产离开 Bybit，五天后 FBI 把这起盗窃归到朝鲜身上。失窃一周后，Safe 生态基金会在声明里描述了这条路径：针对 Bybit 那个 Safe 的攻击「was achieved through a compromised Safe{Wallet} developer machine」，结果是「the proposal of a disguised malicious transaction」。

好几个人批准了它。多签在一笔错的交易上完成了本职工作，签名个数从头到尾不是变量。下面每一道控制都值得拿这句去量：请求送到跟前时看起来已经合规，它还剩什么？

「隔离签名」隔离掉的是什么

签名的那一步，和商户、付款方够得着的界面。

Paymos 的出账交易在公开 Web 路径之外签名，转出只能指向商户事先批准的目标地址。隔离说的是够不够得着：它缩短「能把一次请求摆到密钥面前」的清单。这是实打实的工作，不过没有这个词听上去那么多。一条从正门进来、签名有效的请求，它一点办法没有。

它也不切分签字的权力。这是受管托管：商户授权，服务商运营签名与广播。这笔交换合不合自己的生意，是托管模式的选择，该在读下面任何一道控制之前做完。

财务主管接下来那个问题答案很短：余额放着的时候不出借，也不给 Paymos 产生收益。商户余额在 Paymos 账本里分户记账，复式记账。

两把凭证，只有一把能动钱

两把里恰好一把。这条分界是执行出来的，不是写在文档里的。

商户每个环境各持一把 Payment 凭证和一把 Payout 凭证。Payment 密钥覆盖账单和支付通道；Payout 密钥覆盖转出，以及校验目的地要用的读取。两边互不伸手，从插件、日志或笔记本里漏出去的付款密钥造不出转出，它没有转出权限可用。

检查只在一个地方跑：每条命令都过请求管线里同一步授权，不够的凭证在那里就被拒。一条一条路由自己写的权限检查，总有人在下季度新加的那条上忘掉。

旁边还压着两个条件。Payout 密钥必须带 IP 白名单，认证这一步拒绝名单为空的那把，不把空读成不限制；Payment 密钥则根本带不了名单，付款流量本来就该从客户所在的地方打过来。也没有按站点、按服务分发的密钥可签：每个环境各一把在用的，合计四把，吊销是终态。这属于事故预案，不属于宣传册。一次泄漏没法靠吊销「漏的那个集成」收口，那个环境里每个集成拿的都是同一把。

白名单管住方向，管不住别的

钱能去哪儿。不管多少，不管谁开的口，也不管那个地址还是不是你的。

机制短到可以摆在一处读：

• 名单上什么都没有，就什么都出不去。空名单不读成「不限制」，它把转出关掉。
• 条目按地址加网络族建键。批准一个 EVM 地址，一次盖住 Ethereum、BSC、Polygon、Arbitrum、Optimism、Base、Avalanche 和 Plasma；Tron、TON、Solana 各自成族。
• 能进白名单的只有四族，所以 NEAR 和 Sui 收款，却收不了转出。
• 移除是吊销不是删除，谁在什么时候能收到钱，这条痕迹留着。
• 一次批准最多 1000 个地址，CSV 每份文件最多 1000 行，一个账户最多 5000 条在用条目。
• 这一整块没有 API 路由。名单住在控制台里，Payout 密钥读得到它去校验目的地，加不了。

最后那一行值得停一下。能动钱的那把凭证扩不了钱能去的地方，这条分界还扛得住一次配置失误：从 API 做这件事的路根本没造出来。

再看边界。白名单说的是方向，不说归属：商户完全可以有意批准客户或者玩家的地址，给终端用户转账就是这么做的。三月份为某个外包同事的钱包批下来的地址，九月还是已批准地址。

它也不说大小。转出压着两条账户限额：单笔转出的价值上限，和在途转出的并发上限；还剩几个在途名额，在转出表单里还没输入就显示出来。这两条框的是一次移动，白名单框的是方向。一笔转出可以舒服地待在两条限额里，同时去到今天早上你不会挑的地方。

谁可以往名单里加地址

能往那儿打钱的人多，能加地址的人少，这是故意的。

管理白名单默认落在账户所有者手里。财务角色可以往所有者批准过的目的地发转出，批不了新的；管理员角色默认没有转出权限。NIST 的术语表用工资单说完了这个原则：任何用户都不该拿到足以独自滥用系统的权限，批准一张工资支票的人，不该同时是能把它做出来的人。

默认值只是起点，权限还能单独授给某个成员。这条分离撑得住的前提是没人把它授出去又忘了，权限页面也就是这道控制的一部分。

那一刻的第二层是升级认证，而它不是无条件的。既没有 TOTP 也没有通行密钥的商户用户永远不会被问，因为它加强的是已经存在的因素，不存在的要不来。当成账号已经有的防护来读，它不是。两边都成立的是名单本身：转出只能指名单上的地址，加一个地址是单独记录在案的动作，名单为空就没有转出。

真的触发的时候，它绑在自己批准的那个动作上，用掉即失效。注意它站的位置：转出这一步不带验证，改名单这一步带。守的是门，不是每一次出门，而这正是把名单留短的全部理由。

已经在动的转出，还能拦下什么

越往后越少，这个形状提前知道有用。

取消是开头的一小段窗口，不是召回。转出还在 created 且没开始执行时收得回，往后就晚了；同一笔取消两遍也不出错，响应里还是那一笔转出。过了这一段，转账归链所有，而请求和不可逆交易之间，原来只站着白名单。

冻结工作在单笔转出之上。有一个全局出账冻结，还有一个针对单个资产加网络组合的，后者会自己抬起来：账本和钱包对不上，超过设定容差，这一对就停下，不等谁发现。记账上出了分歧，先停住分歧对准的那件事，再弄清哪边错了。安全机制本来就该这么工作。

另外，一条资产加网络的转出路线可能暂时不可用。这一对不出现在转出选择器里，指名它的请求在创建时被拒，余额分文未动，不进队列。这里的拒绝天生便宜。创建转出会把金额连同网络费一起移进冻结，没上链就结束的，冻结全额回来，网络费一起回来。重跑也便宜：external_order_id 在一个商户内唯一，重复创建返回已有的那笔转出，不再发一笔，保的是半路死掉的结算任务，保不了真的不一样的请求。

转出失败为什么只说一句话

因为另一个选项是把内部异常文本摆到商户屏幕上。

转出失败的原因不给商户看。给商户的那句从状态推出来：这笔转出没有发出去、冻结已经释放，以及去哪儿问。后面那个字段里躺着签名器和 RPC 的原始异常、内部数字和运营方备注，展示的那一端永远用封闭状态。

代价落在商户身上，缺的不只是那个原因。转出没发出去，不发邮件，控制台铃铛里也不放东西，一次失败只在 webhook 里出现，别处没有。转出剩下那段要多久，是另一页的事。

挑托管服务商该问哪几个问题

先问那笔什么都没干的余额，再问人。

它放着的时候，会不会被出借、质押，或者替服务商生息？再问：哪个角色批准目的地，这个角色能不能同时往那儿打钱，以及在没人登记第二因素的账户上，改名单那道验证做了什么？好的回答说得出一个角色和一道验证，不是报一支团队。最后问，转出没发出去时你们怎么告诉我、走哪条渠道。

有一道控制比其余的都重，就是那份已批准地址的名单。它有多短就有多管用，而值得守的时刻是它发生变化的那一刻——所以在 Paymos 这边，这次变化默认只有所有者能做、会记录在案、没有 API 路由，也是唯一会要第二因素的动作，而它后来授权的转出什么都不要。