> 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/ja/romenoapuri/bloom/compliance.md).

# コンプライアンスモデル

Bloom は Plume の Arc フレームワークを改変せずに実行します。コンプライアンスは **トークン契約自体によって** — オフチェーンの画面、シーケンサーのフィルター、取引所ポリシーによってではありません。これが可搬性を生む性質です。つまり、ルールはどの実行経路にもトークンとともに移動し、両方のウォレット経路で適用されます。

## 強制アーキテクチャ

```
ArcToken._update（すべての transfer/mint/burn）
   └─ RestrictionsRouter（チェーンごとに1つ、モジュール種別レジストリ）
        ├─ TRANSFER_RESTRICTION → WhitelistRestrictions（トークンごと）
        ├─ YIELD_RESTRICTION    → YieldBlacklistRestrictions（トークンごと）
        └─ GLOBAL_SANCTIONS     →（スロットは存在するが、グローバルモジュールは未デプロイ）
```

* **WhitelistRestrictions** — 許可リストです。 `transfersAllowed` が false（ゲート付きモード）の間は、どちらか一方でもリスト外の転送は、型付きエラー `TransferRestricted()` (`0xe827105e`でリバートします）。このチェックは、あらゆる残高移動のたびにトークン内部で実行されます。EVMウォレット間の転送、Solana署名付き転送、ストアフロントでの販売、初期流動性の移動のすべてが同じゲートを通過します。発行者自身の管理権限を除けば、これを迂回する経路はありません。
* **YieldBlacklistRestrictions** — 配当分配からアドレスを除外します。該当する比例分はトークン契約内に残ります。
* **GLOBAL\_SANCTIONS** — ルーターは、すべてのトークンに適用されるチェーン全体のモジュール（例: 制裁リスト）をサポートします。現時点では何もデプロイされていませんが、このスロットはチェーンレベルで運用するモジュールの自然な置き場です。

## 信頼モデルを率直に述べると

**許可リストフラグは、発行者によるオフチェーンの判断です。** KYC/AML は発行者側のプロセス（そのベンダー、そのルール）で行われ、チェーンはその *結果* — `isWhitelisted(addr)`. [オンボーディングと審査](/ja/romenoapuri/bloom.md) は、その判断を取り巻く仕組みです。つまり、投資家がどう申請し、発行者がどう判断し、どのような監査証跡が残るかということです。そしてこのモデルは変わりません。依然として発行者の判断であり、依然としてオンチェーンでは単なる真偽値であり、どこにも文書はありません。これは Plume で使われている Arc フレームワーク独自のモデルです。これは意図的に *ない* オンチェーンIDシステムです。IDクレームも、オンチェーンのアテステーションも、あるアドレスが誰に属するかを示す暗号学的証明もありません。検証可能なオンチェーンID（例: 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`             | アドレスの追加/削除、ゲート付きモードの切り替え                             |

知っておくべき結果: **失われた投資家ウォレット** は、発行者の対応によってのみ回復可能です（代替アドレスをホワイトリストに追加し、必要に応じて法的手続きに従って mint/burn/upgrade 権限を使用します。Arc に強制送金の組み込みプリミティブはありません）。したがって、発行者の鍵管理はコンプライアンス態勢の一部です。アプリのロールビューアは、各権限の保有者を可視化します。

## Rome が追加するもの — そして registerToken が保持するもの

Solanaウォレットのユーザーは **合成EVMアドレス** として表示されます（Solanaの公開鍵から導出）。コンプライアンス層から見ると、彼らは通常のアドレスです。発行者がホワイトリストに追加し、ゲートがチェックし、収益が届きます。1つの許可リストが両方のウォレット世界をまたぎます。カストディ上の含意は [LANES.md](/ja/romenoapuri/bloom/lanes.md).

にあります。 `Rome は1回のトランザクションあたりのアカウント数を制限するため、トークンは段階的にデプロイされ、単発の` ArcTokenFactoryV2.registerToken `の代わりに`createToken `ADMIN_ROLE`を使ってファクトリーステータスを取得します。ガードは上流のセキュリティモデルを正確に維持します。トークンは正規のプロキシ（codehash）でなければならず、その実装はファクトリーのホワイトリストに登録済み（codehash）でなければならず、呼び出し元はトークンの


---

# 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 by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.rome.builders/ja/romenoapuri/bloom/compliance.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

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.