带加密余额的新银行后端：一把 key 打通读余额、合规筛查与出款
面向 C 端的加密新银行，本质上要同时做三件事：把用户在 BTC/ETH/TRON 上的资产读成一个可展示的 net-worth；在钱进钱出的边界上做合规判断；再把出款可靠地发出去。多数团队走到这一步会发现自己签了三份合同、管着三把 key、对着三张账单——余额数据一家、筛查供应商一家、出款通道又一家。1st Node 把这三件事收到同一把 key、同一个预付费 credit 余额上，节点是我们自己的归档节点，不设人为的 rps 限制。
面临的挑战
新银行的钱流是双向的。用户从法币 on-ramp 进来、把加密 off-ramp 换出去，每一次跨边界都要做 risk-score 和 KYT 判断——放行前拦住高风险地址，放行后持续监控资金动向。同时前端要展示一个准确的多链 net-worth，出款要从同一个可用余额扣款。如果读余额、筛查、出款分属三家供应商，你就要自己缝合三套数据模型、三套鉴权、三套计费，任何一家的口径漂移都会变成对账事故。核心诉求很朴素：把整合成本降下来，把 key 和余额收成一个。
- Balances / portfolio / net-worthC2
- Address risk-score / exposureC3
- Transaction screening / KYTC3
- Mass payout / settlementC2
一次读取合并 BTC/ETH/TRON 的 net-worth
账户页需要的是一个跨链合并后的净值，而不是让客户端分别去问三条链再自己加总。通过 balances 与 net-worth 读取，一次调用返回用户在 BTC/ETH/TRON 上的持仓与估值，前端直接渲染。因为节点是自有归档节点，历史与当前状态都在同一套数据里，不需要为对齐口径再接第二个数据源。
在 ramp 边界做 risk-score，入账后持续 KYT
on-ramp/off-ramp 的每一笔都在放行前跑 risk-score，把风险决策卡在资金入账或放款之前；通过筛查的才继续。放行之后由 KYT 接管，持续监控对手方和资金流向，风险升高时进入复核。sanctions 筛查同样在这条边界上完成——筛查逻辑和余额读取共用同一把 key，不再需要单独对接一家合规供应商。
mass payout 与余额共用同一个 credit 余额
批量代付走 mass payout，一次提交多笔出款。关键在于出款扣的和展示用的是同一个预付费 credit 余额，不存在“余额 API 说有、出款通道说没有”的错位。整个链路——读净值、做筛查、发出款——挂在一把 key 下，一份账单，一套鉴权。
该架构交付什么
- 读余额、合规筛查、出款从三份合同三把 key 收敛为一把 key、一个 credit 余额，整合与对账成本显著下降。
- 风险决策卡在 on-ramp/off-ramp 边界的放行前，配合入账后的 KYT 持续监控，形成放行前后闭环。
- 自有归档节点、不设人为 rps 限制，高频读取账户净值与频繁出款都不必为限流做额外工程妥协。
常见问题
读余额、KYT 筛查、mass payout 真的能只用一把 key 吗？会不会各能力其实是不同套餐？
都在同一把 key、同一个预付费 credit 余额下调用，按用量从同一个余额扣 credit，不需要为筛查或出款单独签约、单独发 key。net-worth 读取、risk-score、KYT、sanctions 筛查、mass payout 是同一个平台的能力，计费口径统一。
出款要签名，你们会不会拿到我的私钥？
签名留在客户端，我们不持有 key。出款是 build/sign/broadcast 的模式——由平台构造交易、你在自己一侧签名、再广播出去，私钥始终不离开你的环境。
充值、拿密钥、上线。
自助开通。支持加密货币或银行卡。按额度计费——重型原语更贵，简单调用很便宜。
获取 API 密钥