> 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/ko/rome/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)`. [온보딩 및 심사](/ko/rome/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`                 | 주소 추가/삭제, 게이트 모드 전환                               |

알아둘 만한 결과:  **분실된 투자자 지갑** 은 발행자의 조치를 통해서만 복구할 수 있습니다(대체 주소를 허용 목록에 추가하고, 필요하다면 그들의 법적 절차에 따라 mint/burn/upgrade 권한을 사용 — Arc에는 강제 전송 기본 기능이 내장되어 있지 않습니다). 따라서 발행자의 키 보관은 준수 태세의 일부이며, 앱의 역할 뷰어는 각 권한의 보유자를 표시합니다.

## Rome가 추가하는 것 — 그리고 registerToken이 보존하는 것

Solana 지갑 사용자는 다음과 같이 표시됩니다 **합성 EVM 주소** (해당 Solana 공개 키에서 파생됨). 준수 레이어에는 이들이 일반 주소로 보입니다. 발행자가 이를 허용 목록에 추가하고, 게이트가 검사하며, 수익이 이들에게 도달합니다. 하나의 허용 목록이 두 지갑 세계를 모두 포괄합니다. 보관상의 함의는 [LANES.md](/ko/rome/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 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/ko/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.