先定义“功能边界”
公账数字钱包的功能边界，是指该钱包能够执行哪些操作、由谁授权执行，以及哪些操作明确不在其权限范围内。判断边界时，应把“能查看”与“能控制”分开，也要把钱包作为操作界面、链上账户作为执行主体、智能合约作为规则载体分别识别。钱包本身通常是与账户交互的应用或接口，并不等同于账户，也不天然等同于资产所有权。
确认账户与控制方式
以太坊账户主要分为外部拥有账户和合约账户。外部拥有账户由私钥控制，可以发起交易；合约账户则由部署在链上的代码控制，通常在收到交易后按照代码逻辑执行操作。两类账户都可以接收、持有和发送以太币及代币，也可以与已部署的智能合约交互，但授权机制并不相同。
因此，确认公账数字钱包边界的第一步，是记录其实际连接的账户地址、账户类型和控制主体。若是外部拥有账户，私钥或签名设备决定谁能发起交易；若是合约账户，则应进一步检查合约代码中是否存在转账、冻结、铸造、角色管理或其他特殊逻辑。仅凭钱包名称、页面权限或地址标签，不能完整推断这些能力。
按操作类型拆分权限
可以将钱包功能拆成四类：资产查询、普通转账、合约交互和治理管理。资产查询通常只需要读取链上状态；普通转账需要生成并签署交易；合约交互可能触发代币转移或其他代码逻辑；治理管理则可能涉及授予或撤销角色、变更管理员、暂停功能等高影响操作。每一类都应单独列出允许主体、审批条件和禁止事项。
智能合约的访问控制通常有两种基本思路。单一所有者模式适合管理主体较少、权限结构简单的场景；基于角色的访问控制则可以把铸造、销毁、冻结或管理等操作分配给不同角色。角色并不自动代表所有管理能力，具体权限取决于合约对角色的检查，以及角色的授予、撤销和管理员设置方式。
用最小权限划定公账范围
适用的边界设计应遵循最小权限原则：每个账户、签名人或系统组件只获得完成职责所需的权限。例如，负责日常付款的账户不必同时拥有角色管理权限，负责查看余额的人员不应获得交易签名能力。若多个角色共享同一个管理员，管理员实际拥有的控制范围可能超过单个业务角色，应将这种继承关系一并记录。
对于高风险管理权限，还应确认是否存在多方签名、分步转移或延迟生效等约束。相关机制可以降低单一账户误操作或密钥失控带来的影响，但是否存在这些机制，必须以实际合约逻辑和已配置权限为依据，不能因为钱包支持某项功能就推定链上账户已经启用。
一份可执行的确认清单
确认时可以按以下顺序检查：第一，明确钱包对应的账户地址和账户类型；第二，列出可以发起交易或签名的主体；第三，按查询、转账、合约调用和管理操作建立权限表；第四，核对合约中的所有者、角色、角色管理员及授予撤销规则；第五，确认是否存在多签、延迟、暂停或其他限制；第六，记录权限变更事件和复核责任。
如果角色成员可能动态变化，不能只依赖初始配置或前端显示。相关信息可以结合角色授予和撤销事件进行链下追踪；如果业务要求直接在链上枚举角色成员，则需要确认合约是否实现了相应的可枚举机制。边界文档还应标注读取权限、签名权限和最终控制权限，避免把“能够发起请求”误认为“能够独立完成资产转移”。
常见问题
钱包能看到余额，是否就能支配资产？不能。查看链上状态与签署交易是不同权限，资产控制取决于账户密钥或合约授权逻辑。
拥有某个角色，是否就能授予别人同一角色？不一定。角色成员通常只能通过权限检查；能否授予或撤销角色，还要看该角色对应的管理员设置。
把管理员转给一个地址后，是否一定可以继续管理？不能仅凭地址完成判断。还要确认接收地址的账户类型、是否具备正确控制者，以及转移过程是否需要接受步骤或其他条件。
怎样判断边界是否清楚？如果每项操作都能对应到具体调用、授权主体、审批条件和撤销方式，并能说明哪些操作被明确禁止，通常才算形成了可审计的功能边界。