合规模型

Bloom 直接运行 Plume 的 Arc 框架，未作修改。合规性由 代币合约本身强制执行 ——而不是由任何链下筛选、排序器过滤器或场所政策强制执行。这正是其可移植性的特性：规则会随代币进入任何执行路径，在两种钱包通道上都适用。

强制执行架构

ArcToken._update（每次转账/铸造/销毁）
   └─ RestrictionsRouter（每条链一个，模块类型注册表）
        ├─ TRANSFER_RESTRICTION → WhitelistRestrictions（每个代币）
        ├─ YIELD_RESTRICTION    → YieldBlacklistRestrictions（每个代币）
        └─ GLOBAL_SANCTIONS     →（槽位存在；尚未部署全局模块）

• WhitelistRestrictions ——允许名单。只要 transfersAllowed 为 false（门控模式）时，任一方不在名单上的转账会以类型化错误回退 TransferRestricted() (0xe827105e）。该检查在代币内部对每一次余额变动执行——EVM 钱包转账、Solana 签名转账、店面销售以及初始流动性转移都会经过同一道门禁。除非动用发行方自身的管理权限，否则没有绕行路径。

• YieldBlacklistRestrictions ——将地址排除在收益分配之外；其按比例应得份额保留在代币合约中。

• GLOBAL_SANCTIONS ——该路由器支持适用于每个代币的全链模块（例如制裁名单）。当前尚未部署任何模块；该槽位是由链级运营的此类模块的自然归宿。

坦诚说明的信任模型

允许名单标志是发行方的链下决定。 KYC/AML 发生在发行方的流程中（其供应商、其规则）；链上记录并强制执行 结果 — isWhitelisted(addr). 入驻与审核 是围绕该决定的机制——投资者如何申请、发行方如何决定，以及它留下的审计轨迹——并不会改变这一模型：仍然是发行方的决定，链上仍然只是一个布尔值，且任何地方都没有文档。这就是 Plume 上使用的 Arc 框架自身模型。它刻意 并非 一个链上身份系统：没有身份声明、没有链上证明，也没有关于某个地址属于谁的加密证明。承载可验证链上身份的标准（例如 ERC-3643）会为此属性付出明显更重的转账开销；Arc 则以更轻量的机制换取由发行方持有的信任。Bloom 如实呈现这一点，而不是暗示更多。

发行方权限（类似过户代理的结构）

ArcToken.initialize 会向向导驱动程序授予所有角色：

角色	权限
ADMIN_ROLE / DEFAULT_ADMIN_ROLE	链接/替换限制模块，管理角色
MINTER_ROLE / BURNER_ROLE	供应管理
YIELD_MANAGER_ROLE / YIELD_DISTRIBUTOR_ROLE	设置收益代币，执行分配
UPGRADER_ROLE	对代币进行 UUPS 升级（由发行方持有；如需通过工厂中介升级，则授予工厂）
白名单模块 WHITELIST_ADMIN_ROLE	添加/移除地址，切换门控模式

值得注意的后果：一个 丢失的投资者钱包 只能通过发行方操作恢复（将替代地址列入白名单，如有需要，再依据其法律流程使用铸造/销毁/升级权限——Arc 没有内置的强制转移原语）。因此，发行方的密钥托管本身就是合规姿态的一部分；应用的角色查看器会显示每项权限的持有者。

Rome 带来了什么——以及 registerToken 保留了什么

Solana 钱包用户显示为 合成的 EVM 地址 （由其 Solana 公钥派生）。对于合规层而言，它们是普通地址：发行方将其列入白名单，门禁对其进行检查，收益也会发放给它们——一份允许名单覆盖两种钱包世界。托管影响详见 LANES.md.

由于 Rome 对每笔交易的账户数量设有上限，代币会分段部署，并通过 ArcTokenFactoryV2.registerToken 而不是通过一次性 createToken。这些防护措施原样保留了上游安全模型：代币必须是规范代理（codehash），其实现必须已被工厂列入白名单（codehash），调用方必须持有该代币的 ADMIN_ROLE，