> For the complete documentation index, see [llms.txt](https://docs.rome.builders/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.rome.builders/zh/rome-shang-de-ying-yong/bloom/compliance.md).

# 合规模型

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)`. [入驻与审核](/zh/rome-shang-de-ying-yong/bloom.md) 是围绕该决定的机制——投资者如何申请、发行方如何决定，以及它留下的审计轨迹——并不会改变这一模型：仍然是发行方的决定，链上仍然只是一个布尔值，且任何地方都没有文档。这就是 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](/zh/rome-shang-de-ying-yong/bloom/lanes.md).

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


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.rome.builders/zh/rome-shang-de-ying-yong/bloom/compliance.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.