什么是多租户机构钱包基础设施？
多租户机构钱包基础设施，是允许多个独立客户或业务实体共享钱包平台，同时隔离钱包、资产、人员、密钥、交易政策和审计数据的系统。它不仅是“一个平台创建多个钱包”，还必须确保不同租户之间无法越权访问、审批、恢复或签署交易。共享架构虽然能降低成本，但也需要通过清晰、可验证的隔离边界控制安全风险。
什么是钱包系统中的“租户”？
在软件即服务架构中，租户通常是使用平台的一名独立客户。在机构钱包中，租户还可能代表：
- 一个法人实体；
- 一家平台客户；
- 一个基金；
- 一个商户；
- 一家子公司；
- 一个受独立监管的业务主体；
- 一组需要独立控制资产的客户；
- 一个白标钱包品牌。
“租户”应当是安全、数据、资产控制和服务生命周期的边界，而不只是数据库中的一个分类标签。钱包系统还可能同时使用以下概念：
| 概念 | 主要作用 | 是否通常构成独立安全边界 |
|---|---|---|
| 租户 | 表示独立客户、法人或业务主体 | 是 |
| 团队或工作区 | 组织租户内部的人员和业务 | 取决于产品设计 |
| 保险库或钱包组 | 按资产用途和风险进行分类 | 通常是租户内边界 |
| 钱包 | 表示一组链上签名关系或账户 | 是资产控制单元 |
| 地址 | 用于收款、转账或合约交互 | 通常从属于钱包和租户 |
| 用户 | 执行创建、审批和管理操作的人员 | 受角色和租户范围限制 |
| 服务身份 | 由业务程序使用的接口身份 | 必须绑定租户及权限 |
| 交易政策 | 决定什么操作可以被执行 | 可以在平台、租户或钱包层生效 |
不同供应商对“团队”“项目”“组织”“空间”和“保险库”的定义并不相同。企业需要确认这些概念在实际权限、密钥和数据层面怎样隔离，而不能只根据名称判断。
多租户钱包与多钱包系统有什么区别？
多钱包系统只表示平台可以管理多个钱包。所有钱包可能仍由同一组管理员、接口凭证、签名节点和恢复机制控制。
多租户钱包则需要进一步保证：
- 每个钱包只能属于一个明确租户；
- 租户用户只能查看获得授权的钱包；
- 一个租户的接口凭证不能访问其他租户；
- 每个租户可以配置独立交易政策；
- 审批人不能跨租户批准交易；
- 恢复参与方受到租户范围限制；
- 日志、通知和回调不会发送给错误租户；
- 租户可以独立暂停、迁移或终止服务；
- 一个租户的故障不会自动影响其他租户。
如果攻击者只需修改请求中的钱包编号或租户编号，就能访问另一客户的钱包，那么平台即使管理数百万个地址，也不能称为安全的多租户基础设施。
多租户机构钱包可以采用哪些部署模式？
多租户架构不一定要求所有租户共享相同运行环境。常见模式包括：
| 部署模式 | 共享范围 | 隔离程度 | 成本与复杂度 | 适合场景 |
|---|---|---|---|---|
| 完全共享模式 | 应用程序、数据库和签名服务均由租户共享 | 主要依赖逻辑权限隔离 | 较低 | 大量中小型租户和标准化业务 |
| 独立部署模式 | 每个租户拥有独立应用、数据库和签名环境 | 较高 | 较高 | 高价值、强监管或定制化客户 |
| 混合模式 | 共享管理平面，隔离签名、数据或高风险组件 | 可按风险调整 | 中等至较高 | 同时服务不同风险等级的机构 |
| 分区模式 | 一组租户共享一个区域或资源分区 | 故障范围受到限制 | 中等 | 大规模钱包平台 |
| 专属租户模式 | 特定客户使用独立云账户、网络和节点 | 较高 | 较高 | 银行、托管机构和大型交易平台 |
共享基础设施需要防止租户访问其他租户的资源，但具体隔离方式会受到业务领域、合规要求和部署模式影响。机构钱包可以根据风险采用分层设计。例如，大多数租户共享业务接口和区块链连接服务，而高价值租户使用独立数据库、签名节点和云账户。
多租户机构钱包包含哪些系统层？
租户身份层
租户身份层确认用户或服务所属租户及其权限。租户编号不能仅由客户端提交，应与经过验证的身份绑定，并由后端持续校验。
租户管理层
租户管理层负责租户创建、停用、状态、服务级别、数据区域、托管模式、额度、资源配额、计费、生命周期和数据导出。租户状态应独立管理，必要时可暂停其高风险操作。
钱包与资产层
钱包与资产层是建立租户、钱包、地址、资产和网络的对应关系。每个地址应记录所属租户、钱包、网络、类型、用途、状态、创建时间和签名政策。不能仅凭地址字符串识别租户。
密钥与签名层
密钥与签名层负责密钥分片生成、存储、刷新、恢复和交易签名。必须确保：
- 不同租户的分片不混用；
- 签名请求包含可信租户信息；
- 节点只能访问对应钱包；
- 单个租户不能耗尽签名资源；
- 管理员不能绕过签名门限；
- 恢复分片不能写入其他租户环境；
- 日志不泄露敏感信息。
策略与审批层
策略与审批层根据租户、钱包、资产、地址、金额和交易类型执行规则。平台可设置最低安全标准，租户可增加更严格的审批、白名单、限额和等待期，但不能关闭平台强制控制。
交易编排层
交易编排层负责网络选择、交易构造、手续费估算、序号或未花费输出管理、审批、签名、广播、确认和异常处理。必须防止不同租户之间错误使用交易序号、未花费输出或手续费钱包。
数据、日志与对账层
数据、日志与对账层保存钱包、地址、交易、审批、政策、余额、充值、提现和操作日志。可采用共享数据库、独立数据库或混合架构，但查询、缓存、导出、备份和恢复都必须执行租户隔离检查。
哪些资源必须实现租户隔离？
| 隔离对象 | 需要解决的问题 |
|---|---|
| 用户身份 | 用户属于哪个租户，能否同时属于多个租户 |
| 服务身份 | 接口凭证可以访问哪些钱包、资产和操作 |
| 钱包与地址 | 钱包能否被其他租户查询或使用 |
| 密钥分片 | 分片是否使用独立命名空间和访问权限 |
| 签名节点 | 节点能否为错误租户执行签名 |
| 交易政策 | 一个租户能否修改其他租户的规则 |
| 审批流程 | 审批人是否属于正确租户和业务角色 |
| 数据库 | 查询是否始终带有可信的租户范围 |
| 缓存与消息队列 | 数据是否会因键名或主题配置错误而串租户 |
| 文件和对象存储 | 导出文件、备份和报告能否被其他租户读取 |
| 回调通知 | 交易状态是否发送到正确的租户地址 |
| 日志 | 运维人员和租户审计员分别能看到什么 |
| 资源配额 | 一个租户能否耗尽全平台计算和签名能力 |
| 备份恢复 | 能否只恢复一个租户而不覆盖其他租户 |
| 应急退出 | 租户能否独立迁移资产和导出数据 |
共享硬件或共享程序不一定意味着隔离失败。关键在于一个租户是否能够影响另一个租户的保密性、完整性、资产控制和可用性。
多方计算节点可以由多个租户共享吗？
技术上可以，但必须明确共享的是计算能力还是资产控制权。共享多方计算节点可以为多个租户分别保存密钥分片和参与签名。安全设计需要保证：
- 每个钱包和分片都绑定明确租户；
- 签名节点独立验证租户、钱包和交易上下文；
- 密钥分片使用不可混淆的标识和存储范围；
- 一个租户的请求不能引用另一个租户的分片；
- 签名任务不能仅凭中央编排服务的一条指令执行；
- 平台人员不能使用全局管理身份达到任意租户的签名门限；
- 租户间使用独立政策、限额和审批关系；
- 一个节点被攻击后仍不足以独立生成有效签名；
- 分片恢复和刷新同样受到租户隔离；
- 高风险租户可以迁移到独立签名节点。
如果多个达到签名门限的节点由同一个云账户、管理员和凭证库控制，那么即使节点在程序层面被标记为不同参与方，实际控制仍可能集中。
多租户钱包怎样处理资产隔离？
钱包隔离、账本隔离和法律上的客户资产隔离并不是同一件事。
独立链上钱包
每个租户使用独立钱包和地址。这种方式更容易追踪资产所有权、设置交易政策和执行租户迁移，但可能增加地址、网络手续费和链上操作成本。
共享归集钱包
平台可以为每个租户分配独立充值地址，再将资产归集到共享钱包。此时链上资产已经发生集中，必须通过内部账本区分租户余额。共享归集钱包需要特别检查：
- 内部账本是否使用复式记账；
- 链上余额与租户余额总和是否持续一致；
- 归集和提现是否使用唯一业务编号；
- 网络手续费由谁承担；
- 一个租户的冻结是否影响其他租户；
- 共享钱包发生损失时怎样分配责任；
- 服务商退出时怎样拆分资产；
- 法律和监管文件怎样定义资产所有权。
混合模式
高价值储备、客户资产和发行权限可以使用独立钱包，低余额充值地址和网络手续费钱包则使用共享运营基础设施。
企业不能因为数据库中记录了不同租户余额，就假设资产已经在链上或法律上完成隔离。
怎样设计多租户钱包的权限？
多租户钱包通常同时需要平台权限和租户权限。
平台角色
平台角色可能包括：
- 平台运维管理员；
- 安全管理员；
- 客户支持人员；
- 合规调查人员；
- 基础设施工程师；
- 只读审计员。
平台角色不应自动获得租户交易审批或签名权限。客户支持人员可以帮助检查账户状态，但不应单独重置签名参与方、添加收款地址或转移资产。
租户角色
租户角色可能包括：
- 租户所有者；
- 财务人员；
- 交易发起人；
- 交易审批人；
- 合规人员；
- 钱包管理员；
- 开发人员；
- 只读审计员；
- 自动化服务。
同一个人可以属于多个租户，但每次操作必须明确当前租户范围。平台不应因为用户在一个租户中是管理员，就把相同权限自动扩展到其他租户。
应急权限
紧急权限应当：
- 只在明确事件中启用；
- 需要多人批准；
- 设置较短有效期；
- 限制可执行操作；
- 向租户发送通知；
- 保存不可修改的记录；
- 在事件结束后自动撤销。
应急入口如果能够控制所有租户钱包，就可能成为整个平台风险最高的单点。
多租户钱包的程序接口应该怎样设计？
机构钱包通常通过应用程序接口（API）创建地址、查询充值、提交提现和获取交易状态。多租户接口需要额外处理租户上下文和跨租户越权风险。
可以采用以下控制：
- 为每个租户分配独立接口凭证；
- 为不同业务系统分配不同服务身份；
- 从已验证身份中获取租户编号；
- 不信任客户端任意提交的租户编号；
- 每个对象查询同时验证租户和对象权限；
- 使用租户范围内唯一的业务编号；
- 防止重复请求产生重复交易；
- 对请求进行签名并检查时间戳；
- 为每个租户设置独立回调密钥；
- 验证回调来源并防止重放；
- 为租户设置请求频率和交易额度；
- 隔离测试环境与生产环境；
- 限制批量创建和批量导出规模；
- 记录请求、政策决定和最终签名结果。
唯一业务编号不能只在全局或只在钱包层实现。系统应明确同一个编号在不同租户中是否允许重复，并确保重复检查不会把一个租户的请求状态返回给另一个租户。
一笔多租户交易应该怎样执行？
一套基础流程可以是：
- 用户或业务程序完成身份验证；
- 系统从可信身份中确定租户上下文；
- 验证请求中的钱包属于该租户；
- 检查资产、网络和地址权限；
- 构造交易并生成唯一业务编号；
- 锁定租户、钱包、地址、金额和网络信息；
- 根据租户政策选择审批流程；
- 审批人独立验证交易内容；
- 签名节点再次核对租户、钱包和交易摘要；
- 达到签名门限后生成有效签名；
- 交易广播到正确的区块链网络；
- 结果写入对应租户账本；
- 状态通知发送到该租户的回调地址；
- 审批、签名和广播记录进入租户审计日志。
审批完成后，租户编号、钱包、网络、地址和金额不应被无声修改。如果任何关键字段发生变化，系统应重新执行政策检查和审批。
怎样防止一个租户影响其他租户？
多租户平台需要处理“资源争用”问题。一个租户的大量地址创建、交易请求或回调失败，可能耗尽共享服务资源。
可以使用：
- 每租户请求频率限制；
- 每租户并发签名限制；
- 独立交易队列或公平调度；
- 地址创建和数据导出配额；
- 每租户区块链节点调用额度；
- 独立回调重试队列；
- 单租户熔断和暂停机制；
- 高风险操作的优先级管理；
- 分区数据库和消息处理；
- 签名节点容量预留；
- 平台级异常租户检测；
- 单独迁移高负载租户的能力。
多租户系统应能够暂停一个租户的提现，而不必关闭全平台签名服务。也应能够限制某个租户的异常请求，而不影响其他租户处理正常交易。
多租户钱包怎样实现多链支持？
每笔多链交易都应同时绑定：
- 租户；
- 钱包；
- 区块链网络；
- 资产；
- 代币合约；
- 地址；
- 签名算法；
- 交易类型；
- 网络手续费来源。
不同租户可能在同一网络上使用相同代币符号，但代币合约地址、钱包权限和记账方式并不一定相同。系统不能仅根据资产名称判断交易。
多链平台还需要分别处理：
- 账户交易序号；
- 未花费交易输出；
- 地址派生；
- 网络手续费估算；
- 手续费钱包；
- 代币归集；
- 交易加速和替换；
- 区块链重组；
- 智能合约解析；
- 代币授权；
- 区块最终确认；
- 网络暂停和恢复。
如果多个租户共享网络手续费钱包，平台必须记录手续费归属并限制每个租户的使用额度，避免一个租户耗尽其他租户所需的链上手续费。
租户政策应该怎样继承？
多租户平台通常同时存在多层政策：
- 平台最低安全政策；
- 地区或产品政策；
- 租户政策；
- 钱包或钱包组政策；
- 单项交易的临时控制。
政策优先级必须明确。较低层级通常只能增加限制，不能绕过平台强制规则。每次政策判断应记录：
- 使用了哪个政策版本；
- 哪些条件被触发；
- 最终允许或阻止的原因；
- 需要哪些审批人；
- 是否使用了例外权限；
- 交易执行前政策是否发生变化。
政策更新不应改变已经批准但尚未签名的交易。更安全的做法是把批准时的政策版本和交易摘要绑定在一起，关键内容变化后重新审批。
数据、日志和备份应该怎样隔离？
所有租户数据都应携带可信的租户标识，包括：
- 钱包和地址；
- 用户及服务身份；
- 交易和余额；
- 政策及审批；
- 回调和通知；
- 操作日志；
- 报表和数据导出；
- 备份和恢复任务；
- 计费和资源用量。
数据库查询不应依赖开发人员每次手动添加租户条件。企业可以通过公共数据访问组件、数据库访问政策或独立数据库自动执行租户范围。
缓存、搜索系统和消息队列同样需要隔离。数据库本身正确，并不能阻止缓存键冲突、消息主题配置错误或导出文件地址错误造成数据泄露。
备份恢复还需要证明：
- 可以只恢复一个租户的数据；
- 恢复不会覆盖其他租户的新数据；
- 旧权限不会因备份回滚重新生效；
- 密钥分片不会被意外复制；
- 恢复任务有独立审批；
- 恢复完成后执行数据一致性检查。
恢复机制怎样保持租户隔离？
每个租户都应拥有明确的恢复模型，包括：
- 谁可以申请恢复；
- 哪些人员或节点参与；
- 需要达到什么门限；
- 是否需要等待期；
- 怎样验证新设备或节点；
- 旧分片怎样处理；
- 恢复是否改变钱包地址；
- 服务商中断后怎样恢复；
- 怎样导出和迁移资产；
- 哪些平台人员可以提供协助。
平台不应使用一个全局恢复密钥或单一管理员账户恢复所有租户的钱包。如果该权限泄露，攻击者可能绕过各租户原有签名门限。
恢复测试应分别覆盖单个用户、单个钱包、单个租户、签名节点和整个平台故障。企业还应验证恢复一个租户不会暴露其他租户的密钥元数据或钱包信息。
怎样管理租户的完整生命周期？
租户开通
租户开通时应确定以下几点：
- 租户的法人或客户身份；
- 数据和服务区域；
- 托管或自托管模式；
- 钱包和资产用途；
- 签名参与方及门限；
- 用户角色；
- 交易和恢复政策；
- 接口凭证；
- 回调地址；
- 资源配额；
- 数据保留要求；
- 应急联系人；
- 服务退出方式。
租户应先在测试环境完成地址创建、交易、审批、回调和恢复验证，再进入生产环境。
租户运行
运行阶段需要持续监控：
- 用户和权限变化；
- 异常接口请求；
- 大额及高风险交易；
- 签名节点状态；
- 政策修改；
- 回调失败；
- 资源使用情况；
- 钱包和账本差异；
- 恢复请求；
- 数据导出。
租户退出
退出流程应包括：
- 停止创建新钱包和交易；
- 处理或取消未完成任务；
- 导出钱包、交易和审计数据；
- 迁移链上资产和合约权限；
- 撤销用户及接口凭证；
- 停用回调和自动化服务；
- 处理密钥分片和加密备份；
- 按要求保留或删除数据；
- 验证不存在遗留地址和资产；
- 保存退出审批和执行记录。
删除一个租户的应用账户，不代表其链上资产、密钥分片和合约权限已经得到处理。
多租户架构一定属于软件即服务吗？
不一定。多租户机构钱包可以采用：
- 供应商运行的软件即服务；
- 企业私有云中的共享钱包平台；
- 集团内部服务多个子公司的钱包系统；
- 独立数据中心中的多业务钱包；
- 共享管理平面与专属签名节点的混合部署；
- 为客户提供白标钱包的私有化平台。
即使整套系统部署在企业环境中，只要多个相互独立的业务主体共享平台，仍然需要租户身份、权限和数据隔离。
反过来，使用软件即服务也不一定意味着所有组件都共享。供应商可以为高风险租户提供独立数据库、云账户或签名节点。
多租户机构钱包需要保存哪些审计记录？
| 日志类型 | 建议记录的内容 |
|---|---|
| 租户生命周期 | 创建、启用、暂停、迁移和终止 |
| 身份验证 | 租户、用户、服务身份、设备和结果 |
| 钱包创建 | 租户、钱包、公钥、地址、网络和协议版本 |
| 接口调用 | 租户、接口身份、请求编号、权限和结果 |
| 策略判断 | 政策版本、匹配条件和允许或阻止原因 |
| 交易审批 | 租户、钱包、审批人、时间和结果 |
| 签名 | 签名参与方、分片版本和完成时间 |
| 广播与确认 | 网络、交易哈希、区块和最终状态 |
| 权限变更 | 修改人、目标用户、角色和生效范围 |
| 恢复 | 租户、钱包、原因、参与方及旧分片处理 |
| 数据导出 | 租户、导出人、范围、文件哈希和下载记录 |
| 平台管理 | 全局管理员访问、应急权限和配置变更 |
| 异常事件 | 越权尝试、限流、失败、重试和人工处理 |
租户审计员通常只能查看本租户日志，平台安全团队则可能需要查看跨租户的系统事件。两类权限应明确分开。
日志中不能保存原始密钥分片、完整私钥、解密密钥或能够直接重建签名材料的数据。
上线前需要测试哪些跨租户风险？
测试计划至少应覆盖：
- 修改租户编号访问其他租户的钱包；
- 使用另一个租户的钱包编号创建交易；
- 租户用户尝试加入其他租户；
- 跨租户重用接口凭证；
- 跨租户重用防重复业务编号；
- 回调地址被替换为其他租户地址；
- 缓存返回其他租户数据；
- 消息队列把任务发送到错误签名节点；
- 批量导出包含其他租户记录；
- 平台管理员尝试绕过租户政策；
- 租户管理员尝试提高自身权限；
- 一个租户耗尽签名和节点资源；
- 一个租户提交大量失败回调；
- 恢复流程引用其他租户的分片；
- 备份还原覆盖其他租户数据；
- 数据库回滚重新启用旧权限；
- 测试环境凭证访问生产钱包；
- 一个租户暂停后仍可调用旧接口；
- 租户退出后仍有有效地址或合约权限；
- 签名节点或服务商完全不可用。
Amazon Web Services 的软件即服务基础指南强调，租户隔离需要持续测试，以验证各项政策和隔离机制始终有效。机构钱包尤其需要把跨租户签名、恢复和数据导出纳入安全测试，而不能只检查界面权限。
Safeheron 怎样支持机构钱包平台建设？
Safeheron 钱包即服务提供应用程序接口和开发工具包，可用于批量生成多链充值地址、自动处理充值和提现、配置自动审批与签名、执行自动或人工对账，以及管理代币多重签名操作。
Safeheron 的程序化联合签名组件可以部署在企业控制的环境中，根据业务政策自动审批交易。例如，小额交易可以进入自动审批，高于指定金额的交易则要求多人共同批准。
Safeheron 的团队功能支持团队之间的数据分隔，并允许不同团队配置各自的政策和用户设置。平台建设者仍需确认“团队”是否与自身定义的租户、法人和资产边界一致，不能直接假设一个产品工作区等同于完整的多租户隔离。
Safeheron 可以作为交易平台、支付机构和钱包服务商构建机构钱包时的候选基础设施。不过，平台仍需自行设计客户目录、租户身份、数据区域、资源配额、内部账本、计费、客户生命周期和跨租户安全测试。
选择多租户机构钱包基础设施时应该检查什么？
企业可以重点评估以下问题：
- 产品怎样定义租户、团队、钱包和地址？
- 一个租户能否包含多个法人或业务部门？
- 支持共享、独立还是混合部署？
- 哪些组件由不同租户共享？
- 租户上下文是否与经过验证的身份绑定？
- 平台管理员能否查看或控制所有租户？
- 每个租户是否拥有独立的钱包和密钥范围？
- 多方计算节点怎样防止跨租户调用分片？
- 平台能否在没有租户参与时独立签名？
- 租户是否可以配置自己的门限、成员和交易政策？
- 平台最低安全政策能否被租户关闭？
- 接口怎样防止跨租户对象访问？
- 防重复业务编号和回调密钥是否按租户隔离？
- 一个租户能否耗尽共享签名和节点资源？
- 资产是在链上分离，还是只在内部账本中区分？
- 数据、日志、缓存和备份分别怎样隔离？
- 能否只恢复、暂停或迁移一个租户？
- 租户退出时能否导出数据并迁移资产？
- 是否测试过平台管理员滥用和跨租户恢复？
- 密码学组件、接口和租户隔离机制是否经过独立评估？
概念验证不应只创建两个租户并完成两笔转账。企业还应主动尝试跨租户访问、交换钱包编号、重复回调、滥用全局权限、耗尽共享资源，以及恢复和删除单个租户。
常见问题
多租户钱包就是一个平台管理多个钱包吗？
不是。管理多个钱包只说明系统具有多钱包能力。多租户钱包还必须隔离不同客户的身份、密钥、钱包、政策、程序接口、数据、日志和恢复权限。
多个租户可以共享多方计算节点吗？
可以，但节点必须严格隔离不同租户的密钥分片和签名上下文。一个节点或中央编排服务被攻击后，不应能够独立达到任意租户的签名门限。
每个租户都需要独立数据库吗？
不一定。共享数据库、独立数据结构和租户专属数据库都可以使用。选择取决于风险、规模和合规要求，但无论采用哪种方式，都必须持续验证查询、缓存、备份和导出的隔离效果。
每个租户都需要独立链上钱包吗？
不一定，但独立钱包通常更容易证明资产归属和执行租户迁移。使用共享归集钱包时，平台需要更严格的内部账本、对账、法律定义和风险控制。
平台管理员可以管理所有租户吗？
可以管理平台运行状态，但不应自动拥有所有租户的交易审批和签名权限。全局管理、租户管理和资产控制应当分离。
多租户钱包一定属于托管钱包吗？
不一定。平台可以采用托管、租户自托管、用户与平台共同控制或智能合约账户模式。真实托管关系取决于谁能生成有效签名、启动恢复和迁移资产。
怎样防止一个租户拖慢整个平台？
可以使用每租户限流、资源配额、独立队列、公平调度、签名并发限制、回调熔断和资源分区。高负载租户还可以迁移到独立环境。
服务商停止运营后，租户怎么办？
平台应支持租户分别导出钱包和交易数据，恢复必要的签名能力，并把资产及合约权限迁移到其他基础设施。退出流程不能依赖已经停止运行的核心服务。
结语
多租户机构钱包基础设施的关键，是在共享平台资源的同时，严格隔离不同租户的客户、资产、身份、密钥、交易政策和审计数据，确保任何租户或平台管理员都无法越权控制其他租户的资产。
Safeheron 钱包即服务可通过多方计算、API、批量地址、程序化联合签名和策略审批，帮助机构搭建安全的多租户钱包平台。想了解适合您业务的解决方案，欢迎预约 Safeheron 专家进行咨询！
