Hats Protocol 的权限管理，核心是一个角色树结构。每个"Hat"代表一个链上角色，角色之间通过"管理员（admin）"关系连成树状层级：上层 Hat 的管理员可以创建、修改、撤销下层 Hat。权限本身不存储在 Hat 里，而是通过代币门控或外部集成，把 Hat 和具体的链上/链下权限绑定起来。撤销一个角色的权限，最直接的动作就是由该 Hat 的管理员把 Hat 从持有者地址上 burn 掉（或让持有者不再满足 eligibility 条件，触发自动撤销）。
角色树：从上到下的管理关系
Hats 树从"Top Hat"开始。Top Hat 是整个组织的最高治理权限，它自己管理自己，也是树中其他所有 Hat 的最终管理员。创建一棵树的第一步就是 mint Top Hat 到一个地址（通常先放在自己控制的钱包，之后再转给组织的多签或治理合约）。
Top Hat 之下，官方推荐先创建一个 Autonomous Admin 角色，作为后续所有角色的父级。这个角色可以交给智能合约或自动化模块，用于处理"让某些角色可被合格地址 claim"之类的操作。再往下是工作流/团队角色（Level 2），然后是个体角色和具体的离散权限角色。
这个树状结构的关键规则是：一个 Hat 的管理员是它正上方那个 Hat 的持有者（除非该 Hat 被设为 immutable）。管理员可以修改 Hat 的属性、mint 给新持有者、从旧持有者转移，以及撤销（burn）。持有者自己不能把 Hat 转给别人，Hat 是不可转让的 ERC1155 类代币。
接入：先建角色，再绑权限
接入 Hats 的流程可以分两步走，官方也允许从单角色起步，不必一开始就画整棵树。
第一步是创建角色。 在 Hats App 里创建一棵树或一个 Hat，设定名称、描述、图片、管理员关系。创建时可以选择 mutable（可修改） 或 immutable（不可修改）。mutable 的 Hat 之后可以由管理员修改属性；immutable 的 Hat 一旦创建就不能再改，适合那些需要给持有者最大确定性的场景。如果拿不准，保持 mutable，后续再调整。
第二步是把权限绑到角色上。 Hats 本身不执行权限逻辑，它做的是"角色验证"。你在自己的合约或应用里检查某个地址是否持有特定的 Hat ID，如果持有就放行对应的操作。官方描述的方式是通过 token gates 和集成库，把 Hat 连接到链上权限（如 Safe 签名、投票）或链下权限（如工作区访问、通讯频道）。对于开发者，Hats 提供 SDK 和合约接口，可以在应用里直接做 RBAC 检查。
一个实际的设计判断：不要把所有权限都塞进一个 Hat。Hats 的粒度设计允许你把"工作流成员"和"金库签名权"分成两个不同的 Hat。这样撤销一个人的金库权限时，不需要动他的成员身份。粒度越细，撤销时越精准，但管理成本也越高。官方在"What Hats Do I Need"里也是按这个思路建议分层级的。
撤销：手动 burn 与自动失效
撤销一个地址的权限，取决于这个 Hat 的 eligibility（资格）和 toggle 设置。
最直接的方式是管理员手动撤销。 管理员（即父 Hat 的持有者）调用 burn 或从持有者地址移除该 Hat。持有者本人不能拒绝，也不能自己转走。这适合人员离职、角色调整这类需要人工判断的场景。
更自动化的是设置 eligibility 模块。 Eligibility 模块是一个地址（可以是 EOA、多签，也可以是智能合约），它决定哪些地址有资格持有该 Hat，并且可以在持有者不再满足条件时自动撤销。官方给出的条件示例包括：持有特定数量的 ERC20/ERC721 代币、赢得 Snapshot 或 Tally 的选举、持有其他角色、完成质押等。比如，你可以把某个 Hat 的 eligibility 设为"必须持有至少 100 个某代币"，当持有者卖出代币导致余额不足时，Hat 被自动撤销。
Toggle 模块是另一层控制。 Toggle 决定一个 Hat 本身是 active 还是 inactive。当 Hat 被 toggle 为 inactive 时，所有持有者的余额瞬间变为 0，不需要逐个撤销。这适合"整个角色暂停"的场景，比如某个工作流临时解散。Toggle 可以是人工触发的（EOA 或多签调用 toggleHatStatus），也可以是逻辑合约根据时间戳等条件自动触发。
设置 eligibility 和 toggle 的入口在 Hats App 的 "Edit Tree" 模式下，选中目标 Hat，打开 "Revocation & Eligibility" 面板，选择 "Manually" 或 "Automatically" 来配置。
一个需要留意的边界
Hats 的撤销是链上动作，但绑定的权限是否真的失效，取决于你的集成侧有没有正确检查 Hat 状态。如果你在自己的合约里缓存了"某地址是管理员"的布尔值，而没有在每次操作时实时查询 Hats.balanceOf，那么即使 Hat 被撤销，你的合约仍然会放行。Hats 的自动撤销只有在读取方主动检查时才生效。设计接入时，权限判断应该落在每次关键操作时查询 Hat 余额，而不是在 onboarding 时写死。
另外，嵌套多棵树时要注意深度。官方文档警告，如果嵌套层级过深，高层管理员对最底层 Hat 的操作可能因为 gas 成本变得不切实际甚至超出区块限制。建议不要在超过约 10 层嵌套的树上挂外部权限。
参考资料
- Hats Protocol Docs·Getting Started with Hats，2026-10-22
- Hats Protocol Docs·Revocation & Eligibility: Requirements for Wearers，2026-10-22
- Hats Protocol Docs·What Hats Do I Need?，2026-10-22
- Hats Protocol Docs·Creating My First Hat，2026-10-22
- Hats Protocol Docs·Essentials For Hat Wearers，2026-10-22
- Hats Protocol Docs·Linking Hats Trees，2026-10-22
- Hats Protocol·How It Works，2026-10-22
- GitHub·Hats-Protocol/hats-protocol（Toggle 与 mutability 说明），2026-10-22
