> 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/issuing.md).

# 발행

Bloom을 사용하면 다음을 발행할 수 있습니다 **권한이 부여된 실물 자산** Rome 체인에서 일반 Solidity 계약으로 배포하고, 자산별 콘솔에서 관리합니다. 이 자산은 EVM 지갑과 Solana 지갑 모두에서 접근할 수 있지만, **발행은 EVM 전용입니다** — Solana 지갑은 자산을 보유할 뿐, 생성하지는 않습니다. 이 가이드는 발행자 콘솔, 생성 마법사, 콘솔 로그인 게이트, 그리고 6개의 관리 탭 각각을 다룹니다.

> **Bloom에 어떤 문서나 개인정보도 제출하지 않으며, 투자자도 마찬가지입니다.** Bloom은 다음을 기록합니다 *결과* 귀하의 컴플라이언스 결정에 대한 내용을; 체인은 주소당 하나의 불리언을 기록합니다. 귀하의 KYC/AML 프로세스 — 공급업체, 파일, 보관 정책 — 는 전적으로 귀하의 시스템에만 남습니다. 전체 모델은 다음에 있습니다 [COMPLIANCE.md](/ko/rome/bloom/compliance.md); 이 가이드는 이를 다시 설명하지 않고 해당 문서를 가리킵니다.

***

## 할 수 있는 작업

자산의 관리자로서, 아래의 모든 작업은 콘솔에서 직접 수행할 수 있으며 — 이 모든 것은 실제 온체인 트랜잭션으로, 다음에서 연결됩니다 [증거](/ko/rome/bloom/evidence.md) 페이지:

* **자산 발행** — 마법사가 이를 아래의 세 개 계약으로 배포합니다.
* **신청 검토** — 각 신청을 승인하거나 거절하며(거절에는 신청자에게 제공되어야 할 사유가 포함됩니다), 승인된 주소를 허용 목록에 추가합니다.
* **허용 목록 관리** — 한 주소를 추가하거나, 추가 **단일 트랜잭션으로 주소 묶음을** (`batchAddToWhitelist`)를 추가하거나, 주소를 제거합니다. 토큰은 모든 전송마다 이 목록을 강제합니다.
* **자산 게이팅** — 전송을 허용 목록으로 제한하거나(이렇게 하면 공급이 확정됩니다), 제한을 해제합니다.
* **공급 관리** — 총량을 확인하고, 역할을 보유하면 발행하거나 소각합니다.
* **판매 운영** — 판매를 열고(수량과 가격), 닫고, 미판매 재고를 회수하고, 수익금을 인출합니다.
* **수익 설정 및 분배** — 지급 통화를 설정한 다음 지급을 분배합니다. 이는 보유자들을 한 번에 하나의 트랜잭션씩 순회하며, 제외된 보유자는 건너뜁니다.
* **역할 관리** — 주소에 역할을 부여하거나, 회수하거나, 자신의 역할을 포기합니다.

각 항목은 아래에서, 체인이 강제하는 내용과 함께 해당 탭에서 자세히 설명합니다.

***

## 발행자 콘솔

![/issuer의 발행자 콘솔로, 이 배포가 알고 있는 자산과 그 판매 상태를 나열합니다.](https://1350471780-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F671PKS8ZQSNqtoC8PGvz%2Fuploads%2Fgit-blob-c94de7c7a94a287a4d9b90a92b2b16022213b702%2Fissuer-console.png?alt=media)

`/issuer` 이 체인에서 발행한 자산을 나열하고 새 자산 발행을 시작할 수 있게 합니다.

* 다음을 연결하세요 **EVM 지갑**. 연결되지 않은 방문자나 Solana 지갑에는 빈 콘솔 대신 올바른 종류의 지갑을 연결하라는 안내가 표시됩니다 — Solana 지갑은 발행할 수 없으며, 이는 체인이 두 번째 독립적 가드로 강제하는 제품 경계입니다.
* 표에는 각 자산의 다음 항목이 함께 표시됩니다: **이름과 심볼**, 그리고 생애주기 **단계**, 그리고 **판매** 상태( *열기* 배지 또는 *종료됨*).

두 열 — **보유자** 및 **검토 대기** — 는 대시로 표시됩니다. 보유자 수는 허용 목록의 열거가 필요하고, 검토 대기열은 자산별로 로그인하는 오프체인 저장소이므로, 대시는 *요청되지 않음* 어디서 `0` 앱이 읽지 않은 사실을 주장하려 하기 때문입니다.

누르세요 **자산 발행** 마법사를 열려면, 또는 해당 자산의 콘솔을 열려면 행을 선택하세요.

***

## 자산 생성: 마법사

![/create의 생성 마법사: 자산 필드와, 해당 트랜잭션이 반영되면 켜지는 6개의 카드.](https://1350471780-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F671PKS8ZQSNqtoC8PGvz%2Fuploads%2Fgit-blob-94683a3a49ac2418aed8cc66dbf47fad940814f7%2Fcreate-wizard.png?alt=media)

`/create` 4개의 필드를 수집한 뒤 자산을 배포합니다.

| 필드         | 규칙            |
| ---------- | ------------- |
| **이름**     | 필수.           |
| **심볼**     | 필수.           |
| **공급량**    | 0보다 큰 정수.     |
| **소수 자릿수** | 0부터 18까지의 정수. |

누르세요 **시작**. 필드가 유효하지 않으면 마법사는 비활성화된 버튼 뒤에 머무르지 않고 어떤 필드가 왜 잘못됐는지 알려줍니다. 초안이 유효하면 지갑에 각 단계를 순서대로 서명하라고 요청합니다.

### 왜 부분별로 배포하는가

> **토큰은 여러 트랜잭션에 걸쳐 3개의 계약으로 배포됩니다 — 한 번에 하나로 배포하지 않습니다.** Arc의 단일 트랜잭션 `createToken` 에는 필요할 **77개의 계정 잠금**, 그리고 Rome은 단일 트랜잭션을 다음으로 제한합니다 **62개 잠금**. 그래서 마법사는 각 부분을 별도의 트랜잭션으로 배포하고, 이후 다음을 통해 팩토리 상태를 획득합니다 `ArcTokenFactoryV2.registerToken`. 이는 Rome의 제약을 가시화한 것이지 선택적 최적화가 아니며 — 가드들은 Arc의 상위 보안 모델을 정확히 보존합니다(정식 프록시, 화이트리스트된 구현, 호출자가 토큰의 관리자 역할을 보유, 등록은 한 번만). 다음을 참조하세요 [COMPLIANCE.md](/ko/rome/bloom/compliance.md#what-rome-adds-and-what-registertoken-preserves).

### 6개의 카드

마법사는 배포 진행 상황을 따라가는 6개의 카드를 보여줍니다. 카드는 다음에서 바뀝니다 **대기 중** 다음에 **서명 중…** 다음에 **완료** (또는 **실패**) 트랜잭션이 반영되면.

| # | 카드               | 하는 일                                                    |
| - | ---------------- | ------------------------------------------------------- |
| 1 | **구현체**          | 이 체인의 공통 자산 구현체 — 해결됨, 서명할 내용 없음. (어떤 단계가 실행되기 전에 완료됨.) |
| 2 | **자산**           | 자산을 배포하고 이름, 심볼, 공급량, 소수 자릿수를 한 단계에서 설정합니다.             |
| 3 | **누가 보유할 수 있는가** | 이 자산 전용 권한 모듈을 배포하며, 귀하가 관리자가 됩니다.                      |
| 4 | **전송 시 적용**      | 자산이 해당 모듈을 가리키게 하여 모든 전송을 자산 자체가 검사하게 합니다.              |
| 5 | **수익 규칙**        | 누가 지급받는지 결정하는 모듈을 배포하고 연결합니다.                           |
| 6 | **등록**           | 자산을 등록합니다 — 이것이 판매를 열고 나중에 업그레이드할 수 있게 합니다.             |

6개의 카드는 내부적으로 8개의 배포 단계를 접어 보여주므로, 하나의 **시작** 는 다음을 초래합니다 **8개의 서명**. 버튼 아래의 메모에는 다음이 적혀 있습니다 *"지갑이 각 단계를 서명하라고 요청할 것입니다. 언제든 중단하고 중단한 지점에서 다시 시작하세요 — 아무것도 잃지 않습니다."* 등록이 마지막 단계인 이유가, 중단해도 안전한 이유입니다. 자산은 각 단계에서 실제로 배포되며, 마지막에 등록됩니다.

실행이 완료되면 마법사는 다음을 표시합니다 *"발행 완료. 귀하의 자산은 다음에서 활성화되었습니다 …"* 자산의 콘솔 링크와 함께 `/token/[address]`.

> **`초기화` 가 귀하에게 모든 역할을 부여합니다.** 마법사 실행 주체 — 귀하의 EVM 주소 — 는 토큰의 관리자, 발행/소각, 수익 관리/분배, 업그레이더 역할과 허용 목록 모듈의 관리자 역할을 받습니다. 따라서 키 보관은 자산의 컴플라이언스 상태의 일부입니다. 분실된 투자자 지갑은 귀하의 관리자 조치를 통해서만 복구할 수 있으며, 콘솔의 **권한** 탭은 각 권한의 보유자를 모두 표시합니다. (`UPGRADER_ROLE` 인 것을 선택하세요 *가 아닌* 팩토리에는 자동으로 부여됩니다 — 팩토리 매개 업그레이드를 원하면 명시적으로 부여하세요.)

***

## 자산별 콘솔, 그리고 로그인 게이트

![콘솔 로그인 게이트: 지갑으로 메시지에 서명하세요 — 비밀번호는 없습니다.](https://1350471780-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F671PKS8ZQSNqtoC8PGvz%2Fuploads%2Fgit-blob-a9377e3cad8460af1d9bb4eb3cf6f2a6a8f28b22%2Fconsole-signin.png?alt=media)

열기 `/token/[address]` 은 **가 아닌** 콘솔을 바로 표시합니다. 그것은 **로그인 게이트**:

> *"이 자산을 관리하려면 로그인하세요. 지갑으로 메시지에 서명하세요 — 비밀번호는 없습니다. 귀하의 권한은 자산 자체에서 나오며, 모든 작업마다 다시 확인되므로, 철회하면 즉시 적용됩니다."*

누르세요 **지갑으로 로그인**. 정확히 어떤 일이 일어나는지 보겠습니다:

1. 지갑에 요청하여 `personal_sign` 짧고 사람이 읽을 수 있는 문구에 서명합니다(머리글 *"Bloom — 이 자산을 관리함을 증명하세요"*)에 서명합니다. 이 문구는 승인하는 단 하나의 작업 — 이 자산의 신청 대기열 읽기 — 과 함께 자산 주소, 체인 ID, 타임스탬프를 명시합니다.
2. 앱은 그 서명된 문구를 다음으로 보냅니다 `GET /api/applications`.
3. 위의 **서버** 가 이를 검증합니다: 서명에서 귀하의 주소를 복원하고, 문구가 이 체인을 위한 것이며 여전히 최신인지 확인하고(세션이 아니라 2분 동안만 승인됨), 다음을 읽습니다 **토큰 자체의 허용 목록 모듈** 을 체인에서 읽고, 귀하의 주소가 허용 목록 쓰기에 실제로 필요한 역할을 보유하는지 확인합니다 — `MANAGER_ROLE` 해당 모듈에서.
4. 보유하고 있으면 대기열이 반환되고 콘솔이 렌더링됩니다. 보유하지 않았다면 서버는 다음으로 거부합니다 `403` 그리고 사유를 함께 제공합니다.

![인용된 거부 메시지를 보여주는 게이트: 이 자산을 관리하지 않는 지갑은 차단됩니다.](https://1350471780-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F671PKS8ZQSNqtoC8PGvz%2Fuploads%2Fgit-blob-99040b8d3c752f0f84615b913d6b75fb0d36f81b%2Fconsole-refusal.png?alt=media)

> **누가 이 자산을 관리할 수 있는지는 이 앱이 아니라 자산이 결정합니다.** 역할은 허용 목록에서 확인됩니다 **모듈**, 토큰이 아니라서, 토큰에서 같은 이름의 역할을 보유해도 *가 아닌* 승계되지 않습니다 — 서로 다른 권한입니다. 계정도 세션도 없습니다: 이후의 모든 요청은 각각 고유한 새 서명을 동반하며, 이것이 *"모든 작업마다 다시 확인된다"* 의 의미입니다. 체인에서 지갑의 역할을 회수하면 즉시 로그인할 수 없게 됩니다.

거절 시 사유가 표시됩니다 **인용된** — Bloom은 지갑이 왜 거부되었는지에 대한 문장을 쓰지 않습니다. 지갑에서 서명을 거부했다면 그것은 귀하의 *"아니오"*이지, 자산의 것이 아니며, 거절로 보고되지도 않습니다.

> **게이트는 무엇이 비밀인지가 아니라 누구의 콘솔인지에 관한 것입니다.** 공급량, 판매 상태, 허용 목록 명단, 역할은 공개 체인 조회로 어떤 익스플로러든 확인할 수 있습니다. 서명이 제공하는 것은 **신청 대기열** — 다른 사람들의 선언 — 그리고 콘솔을 볼 권리 자체입니다.

### 콘솔 헤더

로그인하면 헤더에 자산 이름이 표시되고 다음을 보여줍니다 **단계** — 이 자산이 가진 가장 중요한 사실:

| 단계       | 의미                                                                              |
| -------- | ------------------------------------------------------------------------------- |
| **초안**   | 아직 권한 모듈이 연결되지 않아, 누가 이것을 보유할 수 있는지 제한하는 요소가 없습니다.                              |
| **열기**   | 전송은 열려 있고 공급은 여전히 변경될 수 있습니다. 자산을 게이팅하면 공급이 확정되며, 이는 되돌릴 수 없습니다.                |
| **게이팅됨** | 허용 목록에 있는 주소만 이것을 보유할 수 있습니다, **그리고 공급은 확정됩니다** — 더 이상 발행하거나 소각할 수 없으며, 영구적입니다. |

탭 위에는 4개의 수치를 보여주는 요약이 있습니다 — **보유자 · 검토 대기 · 판매됨 · 지급된 수익**. 두 개는 체인과 저장소에서 읽습니다(*검토 대기* 로그인한 후에; *판매됨* 은 매장 계약에서 가져옵니다); *보유자* 는 수익 미리보기의 보유자 수를 기다리고, 그리고 *지급된 수익* 는 아직 오지 않은 지급 기록 커서를 기다립니다. 각 대기 셀은 대시를 표시하고 무엇이 필요한지 설명하며, 다음과 같은 `0` 체인에 아무도 요청하지 않은 사실을 주장하는 문구는 표시하지 않습니다.

***

## 6개의 탭

콘솔에는 다음 순서의 6개 탭이 있습니다: **신청 · 누가 보유할 수 있는가 · 공급 · 판매 · 수익 · 권한.**

이 탭들의 모든 쓰기 작업은 단일 공유 컨트롤을 사용하며, 이 컨트롤은 쓰기의 **명명된 선행 조건** 과 그 **결과** *를* 버튼 앞에 표시하고, 실행 중에는 단계를 이름 붙입니다(*"지갑을 기다리는 중…"*, *"체인에 반영 중…"*). 먼저 확인할 수 있었던 것을 알려주기 위해 아무것도 되돌려져서는 안 됩니다.

### 신청 — 검토 대기열

![신청 탭 — 승인 또는 거절할 대기 중인 신청과 컴플라이언스 접점이 있는 검토 대기열입니다.](https://1350471780-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F671PKS8ZQSNqtoC8PGvz%2Fuploads%2Fgit-blob-8249de8b76f757101cc945ca4a2687103428839c%2Ftab-applications.png?alt=media)

이 탭에는 자산 보유를 신청한 사람이 나열됩니다. 각 행에는 신청자의 주소, 관할권, 보유자 유형, 그리고 **검사** 열(*통과* 공급자가 결과를 기록했다면, 그렇지 않으면 *선언됨*), 그리고 **상태** (*검토 대기*, *승인됨*, *거절됨*)가 표시됩니다. 행을 펼치면 해당 사실과 두 개의 컨트롤을 볼 수 있습니다: **승인 — 보유 가능** 및 **거절**. 거절에는 사유가 필요하며, 그 사유가 신청자의 답변이 됩니다.

> **승인은 두 개의 별도 행위이며, 이 탭은 이를 분명히 구분합니다.** 누르면 **승인** *기록합니다* 신청 저장소에 귀하의 결정을 기록합니다. 주소를 온체인에서 자산의 허용 목록에 올리는 것은 **두 번째 서명** — `batchAddToWhitelist` — 그리고 반영될 때까지 행에 그렇게 표시됩니다. 기록된 결정과 체인이 일치하지 않으면, 탭은 그 차이를 표시하고 이를 메우는 쓰기를 제공합니다: **허용** 승인된 주소를 허용 목록에 추가하거나, (아직 목록에 남아 있는 거절된 주소의 경우) 이를 제거하는 컨트롤입니다. 허용 목록 쓰기가 반영되기 전에는 해당 주소가 자산을 보유할 수 없습니다.

이 탭의 고정 메모 — **컴플라이언스 접점** — 에서는 귀하의 자체 프로세스가 어디에 연결되는지 설명합니다:

> *"여기서는 어떤 문서도 요구하거나 보관하지 않습니다 — 검사는 귀하의 것입니다. 다음 뒤에 귀하의 공급자를 연결하세요 `신청` 인터페이스를 사용하거나, 이미 내린 결정을 가져오세요. Bloom은 결과를 기록하고 체인은 해당 주소에 대해 하나의 예/아니오를 기록합니다."*

이것이 자체 호스팅 발행자가 대체하는 인터페이스입니다: 신청 저장소의 구현을 귀하의 지속성 있는 구현으로 바꾸면 호출자는 변경할 필요가 없습니다. Bloom은 어떤 검사도 수행하지 않으며 문서도 보유하지 않습니다.

### 누가 보유할 수 있는가 — 전송 게이트

![누가 보유할 수 있는가 탭 — 허용 목록 수와 전송 제한 컨트롤, 그리고 일방통행성 결과를 보여줍니다.](https://1350471780-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F671PKS8ZQSNqtoC8PGvz%2Fuploads%2Fgit-blob-d32c410e3b5798d86dc5b914bce2f927eb4b1620%2Ftab-holders.png?alt=media)

이 탭은 자산에 허용 목록으로 등록된 주소 수를 보고하고, 허용 목록이 **강제되는지**:

* 전송이 **제한되지 않을 때**, 다음을 제안합니다 **전송을 허용 목록으로 제한**. 쓰기의 결과는 그렇게 하면 공급이 확정되며 비관리자에게는 일방통행임을 명시합니다.
* 전송이 **제한됨**, 다음을 제안합니다 **제한 해제**. 그 결과는 이것이 되돌리기가 아님을 분명히 명시합니다.

다음과 같은 *게이팅되지 않은* (초안) 자산에서 권한 모듈이 연결되지 않았다면 탭이 그렇게 표시합니다 — *"권한 모듈이 연결되지 않았으므로, 누가 이것을 보유할 수 있는지 제한하는 요소가 없습니다"* — 그리고 토글은 표시되지 않습니다.

> **토큰은 모든 전송의 양쪽을 모두 검사합니다.** 자산이 게이팅된 동안, 어느 쪽 당사자라도 허용 목록에 없으면 전송은 체인에서 유형화된 오류와 함께 되돌려집니다. 동일한 게이트는 EVM 지갑 전송, Solana 서명 전송, 매장 판매, 초기 유동성 이동에도 적용되며 — 귀하의 관리자 권한 외에는 우회 경로가 없습니다.

### 공급량

![공급 탭 — 존재하는 총 단위 수.](https://1350471780-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F671PKS8ZQSNqtoC8PGvz%2Fuploads%2Fgit-blob-29eb2d741e5193eef3ea94a214a199f2eb404fe7%2Ftab-supply.png?alt=media)

이 탭은 존재하는 총 공급량을 정수 단위로 보고합니다.

### 판매 — 열기, 닫기, 수익 받기

![판매 탭 — 열린 판매와, 판매 종료, 미판매 회수, 수익 인출 컨트롤이 있습니다.](https://1350471780-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F671PKS8ZQSNqtoC8PGvz%2Fuploads%2Fgit-blob-573a99f9028a984b038162dc885a16b715673293%2Ftab-sale.png?alt=media)

이 탭은 매장 계약을 통해 주요 판매를 운영합니다.

* **판매가 열려 있지 않을 때**, 판매를 열 수 있도록 제안합니다: 입력 **판매할 수량** 및 **단위당 가격** (in `wUSDC`), 그런 다음 누르세요 **판매 시작**. 쓰기의 선행 조건이 먼저 표시됩니다 — 토큰은 등록되어 있어야 하고, 매장 계약이 판매 재고를 보유해야 하며, 매장 계약 자체가 판매하는 토큰의 허용 목록에 있어야 합니다 — 그래서 아직 열 수 없는 판매는 필요한 사항을 정확히 알려줍니다.
* **판매가 열려 있으면**, 제안에 남은 수량을 보여주고 다음을 제공합니다 **이 판매 종료**.
* **미판매 수량 회수** 미판매 재고를 매장 계약에서 수신자에게 다시 이동시킵니다(기본값은 귀하입니다). 이것은 **가 아닌** 종료가 아닙니다 — 판매는 계속 활성화되어 있고, 쓰기의 결과도 그렇게 말하므로 회수를 되돌림으로 오해할 수 없습니다.
* **수익 인출** 매장 계약의 수익을 주소로 보냅니다(기본값은 귀하입니다). 수익은 판매 상태와 별개로 누적되므로 판매가 열려 있든 닫혀 있든 인출할 수 있습니다.

### 수익 — 보유자에게 지급, 한 거래당 하나씩

![수익 탭 — 분배 금액 필드와, 먼저 지급 통화를 설정하라는 알림이 있습니다.](https://1350471780-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F671PKS8ZQSNqtoC8PGvz%2Fuploads%2Fgit-blob-cc8150ea6fee72d99bd5a2254073779cbd896c11%2Ftab-yield.png?alt=media)

이 탭은 수익 지급을 보유자에게 분배합니다.

> **분배는 클릭이 아니라 순회입니다.** Rome에서는 `distributeYieldWithLimit` 이 지급합니다 **한 거래당 한 명의 보유자에게** (계정 한도) 이므로, 지급은 여러 창의 연속이며 각 창마다 고유한 서명이 필요합니다. 금액은 지급 통화의 정수 단위로 한 번만 입력하며, 순회가 시작되면 고정됩니다. 다음 **먼저** 창은 귀하로부터 전체 지급액을 가져와 첫 번째 보유자에게 지급합니다. 이후 각 창은 토큰 계약 안에 이미 들어 있는 돈만 이동합니다. Bloom은 매 창마다 체인에서 커서를 다시 읽습니다 — 잔액이 변하면 보유자 집합의 순서가 바뀌고, 오래된 인덱스를 보내면 0부터 다시 시작하여 귀하의 돈을 두 번째로 가져가게 됩니다.

탭에는 진행 상황이 표시됩니다 — *"M명 중 N번째 보유자에게 지급 중"* — 그리고 커서가 순환하면 완료됩니다. 자산에 지급 통화가 설정되어 있지 않으면 탭이 그렇게 알려줍니다; 지급 통화 설정은 분배에서 오직 귀하만 선택할 수 있는 유일한 필드입니다.

> **제한된 보유자의 몫은 계약에 남습니다.** 수익 블랙리스트 모듈에 의해 제외된 주소는 건너뛰며, 그 비례 몫은 지급되지 않고 토큰 계약에 남습니다.

과거 지급 내역은 아직 표시되지 않습니다 — 이를 읽으려면 분배 이벤트를 자산의 첫 블록까지 거슬러 올라가야 하며, 이를 위해서는 아직 오지 않은 기록 커서가 필요합니다. 탭은 이를 다음과 같은 `0`.

### 권한 — 역할

![권한 탭 — 모든 역할과 그것이 보유되었는지 여부, 그리고 부여 / 회수 / 포기 컨트롤.](https://1350471780-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F671PKS8ZQSNqtoC8PGvz%2Fuploads%2Fgit-blob-fb54f6c73c2d194dd5b6321bc3cb0af825f6f637%2Ftab-rights.png?alt=media)

이 탭은 토큰이 선언한 모든 역할과 그것이 보유되었는지 여부를 나열하며, 각 항목은 단일 `hasRole` 호출로 토큰에서 읽습니다. 다음 역할은 **가 아닌** 보유됨으로 표시되며 생략되지 않습니다 — 권한 탭에서는 누락된 행과 *"아니오"* 는 서로 다른 사실입니다.

목록 아래에는 역할을 변경하는 컨트롤이 있습니다:

| 작업            | 대상                               | 권한                   |
| ------------- | -------------------------------- | -------------------- |
| **계정에 부여**    | 입력한 주소                           | `DEFAULT_ADMIN_ROLE` |
| **계정에서 회수**   | 입력한 주소                           | `DEFAULT_ADMIN_ROLE` |
| **자신의 역할 포기** | 본인(OpenZeppelin은 확인자가 호출자여야 합니다) | 귀하                   |

역할 선택지는 토큰 자체의 것이므로, 컨트롤이 토큰에 없는 역할을 제안할 수는 없습니다. 모든 쓰기와 마찬가지로, 권한 행과 결과가 버튼 앞에 표시되므로, 문과 그 일방통행성은 서명 전에 명시됩니다.

***

## Bloom이나 체인에 절대 닿지 않는 것

컴플라이언스가 어디에 존재하는지 명확히 하자면:

| 항목               | 존재 위치                                                              |
| ---------------- | ------------------------------------------------------------------ |
| KYC/AML 문서와 PII  | 귀하의 자체 시스템, 귀하의 공급업체와 보관 정책을 사용하여 — **절대** 이 앱 또는 체인               |
| 주소를 허용할 귀하의 결정   | 오프체인 기록; 저장소는 귀하의 소유입니다                                            |
| 그 결정의 온체인 결과     | 불리언 하나 — `isWhitelisted(address)` — 에 의해 기록됨 `batchAddToWhitelist` |
| 규칙의 강제           | 자산 계약이 모든 전송마다                                                     |
| 누가 자산을 관리할 수 있는가 | 자산의 허용 목록 모듈에서 보유한 역할, 모든 요청마다 확인됨                                 |

컴플라이언스 모델 전체는 다음을 읽으세요 [COMPLIANCE.md](/ko/rome/bloom/compliance.md); 보유자가 사용하는 2개 경로(EVM 및 Solana) 메커니즘은 다음을 읽으세요 [LANES.md](/ko/rome/bloom/lanes.md).


---

# 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/issuing.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.