> 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/vi/ung-dung-tren-rome/bloom/compliance.md).

# Mô hình tuân thủ

Bloom chạy khung Arc của Plume ở trạng thái không sửa đổi. Việc tuân thủ là **được cưỡng chế bởi chính hợp đồng token** — không phải bởi bất kỳ màn hình ngoài chuỗi, bộ lọc sequencer hay chính sách của địa điểm nào. Đó là thuộc tính làm cho nó có tính di động: các quy tắc đi cùng token tới bất kỳ đường thực thi nào, trên cả hai làn ví.

## Kiến trúc thực thi

```
ArcToken._update (mọi lần chuyển/mint/burn)
   └─ RestrictionsRouter (mỗi chuỗi một cái, sổ đăng ký loại mô-đun)
        ├─ TRANSFER_RESTRICTION → WhitelistRestrictions (mỗi token)
        ├─ YIELD_RESTRICTION    → YieldBlacklistRestrictions (mỗi token)
        └─ GLOBAL_SANCTIONS     → (slot tồn tại; chưa triển khai mô-đun toàn cục)
```

* **WhitelistRestrictions** — danh sách cho phép. Trong khi `transfersAllowed` là false (chế độ có rào cản), một giao dịch mà bất kỳ bên nào không nằm trong danh sách sẽ hoàn nguyên với lỗi có kiểu `TransferRestricted()` (`0xe827105e`). Kiểm tra chạy ngay trong token trên mọi di chuyển số dư — một chuyển khoản ví EVM, một chuyển khoản được ký trên Solana, một giao dịch bán tại cửa hàng, và lần di chuyển thanh khoản ban đầu đều đi qua cùng một cổng. Không có đường vòng nào ngoài quyền quản trị của chính nhà phát hành.
* **YieldBlacklistRestrictions** — loại trừ các địa chỉ khỏi phân phối lợi suất; phần chia theo tỷ lệ của họ vẫn ở lại trong hợp đồng token.
* **GLOBAL\_SANCTIONS** — bộ định tuyến hỗ trợ các mô-đun áp dụng trên toàn chuỗi cho mọi token (ví dụ: danh sách trừng phạt). Hiện chưa triển khai mô-đun nào; slot này là nơi tự nhiên cho một mô-đun được vận hành ở cấp chuỗi.

## Mô hình tin cậy, được nói thẳng thắn

**Cờ danh sách cho phép là quyết định ngoài chuỗi của nhà phát hành.** KYC/AML diễn ra trong quy trình của nhà phát hành (các nhà cung cấp của họ, quy tắc của họ); chuỗi ghi nhận và thực thi *kết quả* — `isWhitelisted(addr)`. [Quy trình onboarding và xem xét](/vi/ung-dung-tren-rome/bloom.md) là cơ chế xoay quanh quyết định đó — cách một nhà đầu tư nộp đơn, cách nhà phát hành quyết định, và dấu vết kiểm toán mà nó để lại — và nó không thay đổi mô hình này: vẫn là quyết định của nhà phát hành, vẫn chỉ là một giá trị boolean on-chain, và không có tài liệu nào ở bất kỳ đâu. Đây là mô hình riêng của khung Arc như được dùng trên Plume. Nó có chủ đích là *không phải* một hệ thống danh tính on-chain: không có tuyên bố danh tính, không có xác nhận on-chain, không có bằng chứng mật mã về việc một địa chỉ thuộc về ai. Các tiêu chuẩn mang danh tính on-chain có thể xác minh (ví dụ ERC-3643) đổi lấy việc chuyển khoản nặng nề hơn đáng kể để có thuộc tính đó; Arc đánh đổi cơ chế nhẹ hơn để lấy niềm tin do nhà phát hành nắm giữ. Bloom nêu điều này một cách trung thực thay vì ám chỉ nhiều hơn.

## Quyền của nhà phát hành (mang dáng dấp đại lý chuyển nhượng)

`ArcToken.initialize` cấp cho trình điều khiển wizard mọi vai trò:

| Vai trò                                         | Quyền lực                                                                                               |
| ----------------------------------------------- | ------------------------------------------------------------------------------------------------------- |
| `ADMIN_ROLE` / `DEFAULT_ADMIN_ROLE`             | liên kết/thay thế các mô-đun hạn chế, quản lý vai trò                                                   |
| `MINTER_ROLE` / `BURNER_ROLE`                   | quản lý nguồn cung                                                                                      |
| `YIELD_MANAGER_ROLE` / `YIELD_DISTRIBUTOR_ROLE` | đặt token lợi suất, chạy phân phối                                                                      |
| `UPGRADER_ROLE`                                 | nâng cấp token theo UUPS (do nhà phát hành nắm giữ; cấp cho factory để nâng cấp qua trung gian factory) |
| Mô-đun whitelist `WHITELIST_ADMIN_ROLE`         | thêm/xóa địa chỉ, chuyển đổi chế độ có rào cản                                                          |

Hậu quả đáng biết: một **ví nhà đầu tư bị mất** chỉ có thể khôi phục thông qua hành động của nhà phát hành (đưa địa chỉ thay thế vào whitelist và, nếu cần, dùng quyền mint/burn/upgrade theo quy trình pháp lý của họ — Arc không có primitive cưỡng bức chuyển khoản tích hợp sẵn). Vì vậy, việc nhà phát hành quản lý khóa là một phần của tư thế tuân thủ; trình xem vai trò của ứng dụng hiển thị những người nắm giữ từng quyền.

## Rome thêm gì — và những gì registerToken bảo toàn

Người dùng ví Solana xuất hiện như **địa chỉ EVM tổng hợp** (được suy ra từ khóa công khai Solana của họ). Với lớp tuân thủ, họ là các địa chỉ bình thường: nhà phát hành đưa họ vào whitelist, cổng kiểm tra họ, lợi suất đến được với họ — một danh sách cho phép bao trùm cả hai thế giới ví. Hệ quả về lưu ký nằm trong [LANES.md](/vi/ung-dung-tren-rome/bloom/lanes.md).

Vì Rome giới hạn số tài khoản mỗi giao dịch, token được triển khai theo từng phần và có trạng thái factory thông qua `ArcTokenFactoryV2.registerToken` thay vì `createToken`. Các cơ chế bảo vệ giữ nguyên chính xác mô hình bảo mật gốc: token phải là một proxy chuẩn (codehash), implementation của nó phải được whitelist bởi factory (codehash), bên gọi phải nắm giữ `ADMIN_ROLE`, và việc đăng ký chỉ được phép một lần. Không có gì trên bề mặt tuân thủ bị suy yếu bởi đường đi theo từng phần.


---

# 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/vi/ung-dung-tren-rome/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.