> 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/issuing.md). # Phát hành Bloom cho phép bạn phát hành một **tài sản thực ngoài đời có quyền hạn** như một hợp đồng Solidity thông thường trên một chuỗi Rome, và quản trị nó từ một bảng điều khiển theo từng tài sản. Tài sản này có thể được truy cập từ cả ví EVM và Solana, nhưng **việc phát hành chỉ dành cho EVM** — ví Solana chỉ nắm giữ tài sản; nó không tạo ra chúng. Hướng dẫn này bao gồm bảng điều khiển của bên phát hành, trình hướng dẫn tạo, cổng đăng nhập của bảng điều khiển, và từng tab trong sáu tab quản trị. > **Bạn không đưa cho Bloom bất kỳ tài liệu hay dữ liệu cá nhân nào, và nhà đầu tư của bạn cũng vậy.** Bloom ghi nhận *kết quả* của quyết định tuân thủ của bạn; chuỗi ghi một giá trị boolean cho mỗi địa chỉ. Quy trình KYC/AML của bạn — các nhà cung cấp, tệp, thời hạn lưu giữ — hoàn toàn nằm trong hệ thống của riêng bạn. Mô hình đầy đủ nằm trong [COMPLIANCE.md](/vi/ung-dung-tren-rome/bloom/compliance.md); hướng dẫn này dẫn tới nó thay vì nhắc lại nó. *** ## Những gì bạn có thể làm Với tư cách là quản trị viên của một tài sản, mọi thứ bên dưới đều là việc bạn có thể làm từ bảng điều khiển — và tất cả đều là các giao dịch thực trên chuỗi, được liên kết trên [Bằng chứng](/vi/ung-dung-tren-rome/bloom/evidence.md) trang: * **Phát hành một tài sản** — trình hướng dẫn triển khai nó thành ba hợp đồng (bên dưới). * **Xem xét các đơn đăng ký** — phê duyệt hoặc từ chối từng đơn (một lần từ chối kèm theo lý do mà người nộp đơn được biết), và thêm một địa chỉ đã được phê duyệt vào danh sách cho phép. * **Quản lý danh sách cho phép** — thêm một địa chỉ, thêm **một loạt địa chỉ trong một giao dịch duy nhất** (`batchAddToWhitelist`), hoặc xóa một địa chỉ; token thực thi danh sách này trong mọi lần chuyển. * **Khóa tài sản** — hạn chế chuyển nhượng chỉ trong danh sách cho phép (điều này khiến nguồn cung trở nên cố định), hoặc gỡ bỏ hạn chế. * **Quản lý nguồn cung** — xem tổng số, và mint hoặc burn khi bạn nắm giữ vai trò. * **Vận hành đợt bán** — mở một đợt bán (số lượng và giá), đóng nó, thu hồi hàng tồn chưa bán, và rút tiền thu được. * **Thiết lập và phân phối lợi tức** — đặt loại tiền thanh toán, rồi phân phối khoản chi trả, theo đó đi qua từng người nắm giữ một giao dịch tại một thời điểm; các người nắm giữ bị loại trừ sẽ bị bỏ qua. * **Quản lý vai trò** — cấp một vai trò cho một địa chỉ, thu hồi một vai trò, hoặc từ bỏ vai trò của chính bạn. Mỗi mục được trình bày chi tiết bên dưới, cùng với những gì chuỗi thực thi, trong tab tương ứng của nó. *** ## Bảng điều khiển của bên phát hành ![Bảng điều khiển của bên phát hành tại /issuer, liệt kê các tài sản mà bản triển khai này biết đến và trạng thái bán của chúng.](https://4233397286-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F671PKS8ZQSNqtoC8PGvz%2Fuploads%2Fgit-blob-c94de7c7a94a287a4d9b90a92b2b16022213b702%2Fissuer-console.png?alt=media) `/issuer` liệt kê các tài sản bạn đã phát hành trên chuỗi này và cho phép bạn bắt đầu một tài sản mới. * Kết nối một **ví EVM**. Một khách truy cập chưa kết nối, hoặc một ví Solana, sẽ thấy lời nhắc kết nối đúng loại ví thay vì một bảng điều khiển trống — ví Solana không thể phát hành, và đó là ranh giới sản phẩm mà chuỗi thực thi như một lớp bảo vệ thứ hai, độc lập. * Bảng này liệt kê từng tài sản cùng với **tên và ký hiệu**, vòng đời của nó **giai đoạn**, và **Bán** trạng thái (một *Mở* huy hiệu hoặc *Đã đóng*). Hai cột — **Người nắm giữ** và **Cần xem xét** — hiển thị dấu gạch ngang. Số lượng người nắm giữ cần phép liệt kê của allowlist và hàng đợi xem xét là một kho lưu trữ ngoài chuỗi mà bạn đăng nhập theo từng tài sản; dấu gạch ngang có nghĩa là *không hỏi* nơi mà một `0` sẽ khẳng định một sự thật mà ứng dụng chưa đọc. Nhấn **Phát hành một tài sản** để mở trình hướng dẫn, hoặc chọn một hàng để mở bảng điều khiển của tài sản đó. *** ## Tạo một tài sản: trình hướng dẫn ![Trình hướng dẫn tạo tại /create: các trường của tài sản, rồi sáu thẻ sẽ sáng lên khi các giao dịch của chúng được xác nhận trên chuỗi.](https://4233397286-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F671PKS8ZQSNqtoC8PGvz%2Fuploads%2Fgit-blob-94683a3a49ac2418aed8cc66dbf47fad940814f7%2Fcreate-wizard.png?alt=media) `/create` thu thập bốn trường rồi triển khai tài sản của bạn. | Trường | Quy tắc | | ----------------------- | -------------------------- | | **Tên** | Bắt buộc. | | **Ký hiệu** | Bắt buộc. | | **Nguồn cung** | Một số nguyên lớn hơn 0. | | **Số chữ số thập phân** | Một số nguyên từ 0 đến 18. | Nhấn **Bắt đầu**. Nếu một trường không hợp lệ, trình hướng dẫn sẽ cho bạn biết trường nào và vì sao thay vì chỉ nằm sau một nút bị vô hiệu hóa. Khi bản nháp hợp lệ, ví của bạn sẽ được yêu cầu ký từng bước một. ### Vì sao nó triển khai theo từng phần > **Một token được triển khai thành ba hợp đồng qua nhiều giao dịch — không bao giờ chỉ một giao dịch.** của Arc trong một giao dịch `createToken` sẽ cần **77 khóa tài khoản**, và Rome giới hạn một giao dịch đơn ở mức **62 khóa**. Vì vậy trình hướng dẫn triển khai từng phần trong giao dịch riêng của nó và sau đó giành trạng thái factory thông qua `ArcTokenFactoryV2.registerToken`. Đây là một ràng buộc của Rome được hiển thị ra, không phải một tối ưu hóa tùy chọn — và các cơ chế bảo vệ giữ nguyên chính xác mô hình bảo mật gốc của Arc (proxy chuẩn, triển khai nằm trong danh sách trắng, bên gọi nắm vai trò quản trị của token, đăng ký chỉ một lần). Xem [COMPLIANCE.md](/vi/ung-dung-tren-rome/bloom/compliance.md#what-rome-adds-and-what-registertoken-preserves). ### Sáu thẻ Trình hướng dẫn hiển thị sáu thẻ, theo dõi tiến trình triển khai. Một thẻ chuyển từ **Đang chờ** vào **Đang ký…** vào **Hoàn tất** (hoặc **Thất bại**) khi giao dịch của nó được xác nhận. | # | Thẻ | Nó làm gì | | - | ------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------- | | 1 | **Triển khai** | Việc triển khai tài sản dùng chung cho chuỗi này — đã được xác định, không cần ký gì. (Hoàn tất trước khi bất kỳ bước nào chạy.) | | 2 | **Tài sản** | Triển khai tài sản của bạn và đặt tên, ký hiệu, nguồn cung và số chữ số thập phân trong một bước. | | 3 | **Ai có thể nắm giữ nó** | Triển khai mô-đun quyền riêng của tài sản này, với bạn làm quản trị viên. | | 4 | **Áp dụng nó cho việc chuyển nhượng** | Trỏ tài sản tới mô-đun đó, để mọi lần chuyển đều được chính tài sản kiểm tra. | | 5 | **Quy tắc lợi tức** | Triển khai và liên kết mô-đun quyết định ai được chi trả. | | 6 | **Đăng ký** | Đăng ký tài sản — đây là bước mở bán và cho phép bạn nâng cấp nó sau này. | Sáu thẻ này gói lại tám bước triển khai bên dưới, nên một lần **Bắt đầu** sẽ dẫn đến **tám chữ ký**. Một ghi chú bên dưới nút ghi *"Ví của bạn sẽ yêu cầu bạn ký từng bước. Bạn có thể dừng ở bất kỳ điểm nào và tiếp tục từ chỗ đã dừng — không mất gì cả."* Việc đăng ký là bước cuối cùng là lý do việc dừng lại vẫn an toàn: tài sản là một bản triển khai thực sự ở mỗi giai đoạn, và được đăng ký ở cuối. Khi quá trình hoàn tất, trình hướng dẫn hiển thị *"Đã phát hành. Tài sản của bạn đang hoạt động tại …"* kèm liên kết tới bảng điều khiển của tài sản tại `/token/[address]`. > **`initialize` cấp cho bạn mọi vai trò.** Người điều khiển trình hướng dẫn — địa chỉ EVM của bạn — nhận các vai trò quản trị, đúc/đốt, quản lý/phân phối lợi tức và nâng cấp của token, cùng với vai trò quản trị của mô-đun allowlist. Vì vậy việc bạn nắm giữ khóa là một phần trong tư thế tuân thủ của tài sản: ví của nhà đầu tư bị mất chỉ có thể khôi phục thông qua hành động quản trị của bạn, và tab **Quyền** làm cho người nắm giữ của mọi quyền lực hiển thị rõ. (`UPGRADER_ROLE` là *không phải* được cấp tự động cho factory — hãy cấp rõ ràng nếu bạn muốn các nâng cấp đi qua factory.) *** ## Bảng điều khiển theo từng tài sản, và cổng đăng nhập ![Cổng đăng nhập của bảng điều khiển: ký một thông điệp bằng ví của bạn — không có mật khẩu.](https://4233397286-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F671PKS8ZQSNqtoC8PGvz%2Fuploads%2Fgit-blob-a9377e3cad8460af1d9bb4eb3cf6f2a6a8f28b22%2Fconsole-signin.png?alt=media) Mở `/token/[address]` không **không phải** hiển thị ngay bảng điều khiển. Nó hiển thị một **cổng đăng nhập**: > *"Đăng nhập để quản lý tài sản này. Ký một thông điệp bằng ví của bạn — không có mật khẩu. Thẩm quyền của bạn đến từ chính tài sản, và nó được kiểm tra lại trong mọi hành động, nên việc thu hồi có hiệu lực ngay lập tức."* Nhấn **Đăng nhập bằng ví của bạn**. Đây chính xác là những gì xảy ra: 1. Ví của bạn được yêu cầu `personal_sign` một tuyên bố ngắn, dễ đọc cho con người (bắt đầu bằng *"Bloom — chứng minh bạn quản lý tài sản này"*) nêu rõ hành động duy nhất mà nó cho phép — đọc hàng đợi đơn đăng ký của tài sản này — cùng với địa chỉ tài sản, mã định danh chuỗi, và dấu thời gian. 2. Ứng dụng gửi tuyên bố đã ký đó tới `GET /api/applications`. 3. Các **máy chủ** xác minh nó: nó khôi phục địa chỉ của bạn từ chữ ký, xác nhận tuyên bố là cho chuỗi này và vẫn còn mới (nó chỉ cấp quyền trong một cửa sổ hai phút, không phải một phiên), đọc **mô-đun allowlist của chính token** từ chuỗi, và kiểm tra rằng địa chỉ của bạn nắm giữ vai trò mà thao tác ghi allowlist thực sự yêu cầu — `MANAGER_ROLE` trên mô-đun đó. 4. Nếu bạn nắm giữ nó, hàng đợi sẽ được trả về và bảng điều khiển hiển thị. Nếu không, máy chủ từ chối với `403` và một lý do. ![Cổng hiển thị một lời từ chối được trích dẫn: một ví không quản lý tài sản này sẽ bị từ chối.](https://4233397286-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F671PKS8ZQSNqtoC8PGvz%2Fuploads%2Fgit-blob-99040b8d3c752f0f84615b913d6b75fb0d36f81b%2Fconsole-refusal.png?alt=media) > **Chính tài sản quyết định ai có thể quản trị nó — không phải ứng dụng này.** Vai trò được kiểm tra trên allowlist **mô-đun**, không phải trên token, và việc nắm giữ một vai trò cùng tên trên token thì không *không phải* được chuyển sang — chúng là các thẩm quyền khác nhau. Không có tài khoản và không có phiên: mọi yêu cầu tiếp theo đều mang chữ ký mới riêng của nó, đó chính là điều *"được kiểm tra lại trong mọi hành động"* có nghĩa. Thu hồi vai trò của một ví trên chuỗi và nó sẽ không thể đăng nhập ngay lập tức. Một lần từ chối hiển thị lý do **được trích dẫn** — Bloom không bao giờ viết một câu về lý do ví bị từ chối. Nếu bạn từ chối chữ ký trong ví của mình, đó là lời *"không"*, không phải của tài sản, và nó không được báo cáo là một lần từ chối. > **Cổng này là để xác định bảng điều khiển thuộc về ai, chứ không phải cái gì là bí mật.** Nguồn cung, trạng thái bán, danh sách allowlist và các vai trò đều là dữ liệu công khai trên chuỗi mà bất kỳ trình khám phá nào cũng có thể trả lời. Điều mà chữ ký mang lại là **hàng đợi đơn đăng ký** — các khai báo của người khác — và quyền được thấy bảng điều khiển ngay từ đầu. ### Phần đầu bảng điều khiển Sau khi đăng nhập, phần đầu gọi tên tài sản và hiển thị **giai đoạn** — thông tin quan trọng nhất mà nó có: | Giai đoạn | Ý nghĩa | | ------------ | --------------------------------------------------------------------------------------------------------------------------------------------------- | | **Bản nháp** | Chưa có mô-đun quyền nào được liên kết, nên không có gì hạn chế ai có thể nắm giữ nó. | | **Mở** | Việc chuyển nhượng đang mở và nguồn cung vẫn có thể thay đổi. Khóa tài sản sẽ làm nguồn cung của nó trở nên cố định, và điều đó không thể hoàn tác. | | **Đã khóa** | Chỉ các địa chỉ trong allowlist mới có thể nắm giữ nó, **và nguồn cung của nó là cố định** — không thể đúc thêm hay đốt thêm nữa, vĩnh viễn. | Phía trên các tab, phần tóm tắt hiển thị bốn chỉ số — **Người nắm giữ · Cần xem xét · Đã bán · Lợi tức đã chi trả**. Hai chỉ số được đọc từ chuỗi và kho lưu trữ (*Cần xem xét* sau khi bạn đã đăng nhập; *Đã bán* từ storefront); *Người nắm giữ* phụ thuộc vào số lượng người nắm giữ trong bản xem trước lợi tức, và *Lợi tức đã chi trả* phụ thuộc vào con trỏ lịch sử chi trả còn chưa có. Mỗi ô đang chờ hiển thị một dấu gạch ngang và giải thích nó cần gì, thay vì một `0` sẽ khẳng định một sự thật mà chẳng ai hỏi chuỗi về. *** ## Sáu tab Bảng điều khiển có sáu tab theo thứ tự sau: **Đơn đăng ký · Ai có thể nắm giữ nó · Nguồn cung · Bán · Lợi tức · Quyền.** Mọi thao tác ghi trên các tab này đều dùng chung một điều khiển hiển thị **các điều kiện tiên quyết có tên** và các **hệ quả** *trước* nút, và nêu tên giai đoạn của nó khi chạy (*"Đang chờ ví của bạn…"*, *"Đang được ghi lên chuỗi…"*). Không có gì nên bị revert chỉ để dạy bạn điều gì lẽ ra có thể được kiểm tra trước. ### Đơn đăng ký — hàng đợi xem xét ![Tab Đơn đăng ký — hàng đợi xem xét, với một đơn đang chờ phê duyệt hoặc từ chối, và đường nối tuân thủ.](https://4233397286-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F671PKS8ZQSNqtoC8PGvz%2Fuploads%2Fgit-blob-8249de8b76f757101cc945ca4a2687103428839c%2Ftab-applications.png?alt=media) Tab này liệt kê những ai đã nộp đơn để nắm giữ tài sản. Mỗi hàng hiển thị địa chỉ của người nộp đơn, khu vực pháp lý, loại người nắm giữ, một **Kiểm tra** cột (*Đạt* nếu nhà cung cấp của bạn đã ghi nhận một kết quả, nếu không thì *Đã khai báo*), và một **Trạng thái** (*Cần xem xét*, *Đã phê duyệt*, *Bị từ chối*). Mở rộng một hàng để xem các dữ kiện và hai điều khiển của nó: **Phê duyệt — có thể nắm giữ nó** và **Từ chối**. Một lần từ chối cần có lý do, và lý do đó trở thành phản hồi của người nộp đơn. > **Phê duyệt gồm hai hành động riêng biệt, và tab này giữ cho chúng minh bạch.** Nhấn **Phê duyệt** *ghi nhận* quyết định của bạn vào kho lưu trữ đơn đăng ký. Đưa địa chỉ vào allowlist của tài sản trên chuỗi là một **chữ ký thứ hai** — `batchAddToWhitelist` — và cho đến khi nó được xác nhận, hàng đó sẽ nói rõ như vậy. Khi quyết định đã ghi và chuỗi không khớp nhau, tab sẽ nêu ra khoảng lệch và đưa ra thao tác ghi để khép lại nó: **Chấp nhận** để thêm một địa chỉ đã được phê duyệt vào allowlist, hoặc (đối với một địa chỉ bị từ chối nhưng vẫn còn trong danh sách) điều khiển để xóa nó. Địa chỉ đó không thể nắm giữ tài sản cho đến khi thao tác ghi allowlist được xác nhận. Một ghi chú cố định trên tab này — đường **nối tuân thủ** — nêu rõ quy trình của chính bạn gắn vào đâu: > *"Không có tài liệu nào được yêu cầu hay lưu giữ ở đây — các kiểm tra là của riêng bạn. Kết nối nhà cung cấp của bạn phía sau `Đơn đăng ký` giao diện, hoặc nhập các quyết định bạn đã đưa ra trước đó. Bloom ghi nhận kết quả và chuỗi ghi một giá trị có hoặc không đối với địa chỉ đó."* Đó là giao diện mà một bên phát hành tự lưu trữ thay thế: thay việc triển khai của kho lưu trữ đơn đăng ký bằng bản bền vững của riêng bạn và không cần thay đổi gì ở phía bên gọi. Bloom không thực hiện kiểm tra nào và không giữ tài liệu nào. ### Ai có thể nắm giữ nó — cổng chuyển nhượng ![Tab Ai-có-thể-nắm-giữ-nó — số lượng allowlist và điều khiển hạn chế chuyển nhượng, hiển thị các hệ quả một chiều của nó.](https://4233397286-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F671PKS8ZQSNqtoC8PGvz%2Fuploads%2Fgit-blob-d32c410e3b5798d86dc5b914bce2f927eb4b1620%2Ftab-holders.png?alt=media) Tab này báo cáo có bao nhiêu địa chỉ nằm trong allowlist của tài sản, và cho phép bạn chuyển đổi việc allowlist có được **thực thi**: * Khi việc chuyển nhượng **không bị hạn chế**, nó đưa ra tùy chọn **hạn chế chuyển nhượng chỉ trong allowlist**. Hệ quả của thao tác ghi nêu rõ rằng làm như vậy sẽ khiến nguồn cung trở nên cố định và là cánh cửa một chiều đối với những người không phải quản trị viên. * Khi việc chuyển nhượng **bị hạn chế**, nó đưa ra tùy chọn **gỡ bỏ hạn chế**. Hệ quả của nó nói rõ rằng đây không phải là hoàn tác. Trên một *chưa bị khóa* (bản nháp) tài sản chưa liên kết mô-đun quyền nào, tab sẽ nói rõ như vậy — *"Chưa có mô-đun quyền nào được liên kết, nên không có gì hạn chế ai có thể nắm giữ tài sản này"* — và công tắc sẽ không hiển thị. > **Token kiểm tra cả hai phía của mọi lần chuyển.** Trong khi tài sản bị khóa, một lần chuyển mà bất kỳ bên nào không nằm trong allowlist sẽ bị revert trên chuỗi với một lỗi có kiểu. Cùng một cổng này áp dụng cho chuyển từ ví EVM, chuyển đã ký bằng Solana, bán qua storefront, và bước di chuyển thanh khoản ban đầu — không có đường nào vượt qua nó ngoài các quyền quản trị của chính bạn. ### Nguồn cung ![Tab Nguồn cung — tổng số đơn vị đang tồn tại.](https://4233397286-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F671PKS8ZQSNqtoC8PGvz%2Fuploads%2Fgit-blob-29eb2d741e5193eef3ea94a214a199f2eb404fe7%2Ftab-supply.png?alt=media) Tab này báo cáo tổng nguồn cung đang tồn tại, theo đơn vị nguyên. ### Bán — mở, đóng, và nhận tiền thu được ![Tab Bán — một đợt bán đang mở, với các điều khiển đóng bán, thu hồi hàng chưa bán và rút tiền thu được.](https://4233397286-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F671PKS8ZQSNqtoC8PGvz%2Fuploads%2Fgit-blob-573a99f9028a984b038162dc885a16b715673293%2Ftab-sale.png?alt=media) Tab này vận hành đợt bán chính thông qua hợp đồng storefront. * **Khi không có đợt bán nào đang mở**, nó đưa ra tùy chọn mở một đợt: nhập **Số đơn vị bán** và **Giá mỗi đơn vị** (trong `wUSDC`), rồi nhấn **Mở bán**. Các điều kiện tiên quyết của thao tác ghi được hiển thị trước — token phải được đăng ký, storefront phải nắm giữ hàng tồn để bán, và chính storefront phải nằm trong allowlist của token mà nó bán — nên một đợt bán chưa mở được sẽ nói chính xác điều nó cần. * **Khi một đợt bán đang mở**, nó hiển thị còn lại bao nhiêu đơn vị trong đề nghị và đưa ra **Đóng đợt bán này**. * **Thu hồi các đơn vị chưa bán** chuyển hàng tồn chưa bán từ storefront trở lại cho một người nhận (mặc định là bạn). Đây là **không phải** việc thu hồi — đợt bán vẫn được bật, và hệ quả của thao tác ghi cũng nói rõ như vậy, nên việc thu hồi không thể bị hiểu nhầm là hoàn tác. * **Rút tiền thu được** gửi tiền thu của storefront tới một địa chỉ (mặc định là bạn). Tiền thu được tích lũy độc lập với trạng thái của đợt bán, nên có thể rút dù đợt bán đang mở hay đã đóng. ### Lợi tức — chi trả cho người nắm giữ, một người mỗi giao dịch ![Tab Lợi tức — trường số tiền phân phối, kèm nhắc nhở phải đặt loại tiền chi trả trước.](https://4233397286-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F671PKS8ZQSNqtoC8PGvz%2Fuploads%2Fgit-blob-cc8150ea6fee72d99bd5a2254073779cbd896c11%2Ftab-yield.png?alt=media) Tab này phân phối khoản chi trả lợi tức cho những người nắm giữ. > **Một lần phân phối là một lượt đi qua, không phải một cú nhấp.** Trên Rome, `distributeYieldWithLimit` chi trả **một người nắm giữ mỗi giao dịch** (giới hạn tài khoản), nên một khoản chi trả là một chuỗi các cửa sổ, mỗi cửa sổ có chữ ký riêng. Bạn nhập số tiền một lần, theo đơn vị nguyên của loại tiền chi trả, và nó sẽ bị khóa khi lượt đi qua bắt đầu. **đầu tiên** cửa sổ sẽ lấy toàn bộ khoản chi trả từ bạn và trả cho người nắm giữ đầu tiên; mỗi cửa sổ sau đó chỉ chuyển tiền đã nằm trong hợp đồng token. Bloom đọc lại con trỏ từ chuỗi sau mỗi cửa sổ — tập người nắm giữ được sắp xếp lại khi số dư thay đổi, và nếu gửi một chỉ mục cũ thì sẽ khởi động lại từ số 0 và rút tiền của bạn lần thứ hai. Tab hiển thị tiến độ — *"Đang chi trả cho người nắm giữ N trên M"* — và hoàn tất khi con trỏ quay vòng. Nếu tài sản chưa đặt loại tiền chi trả, tab sẽ nói rõ; việc đặt loại tiền chi trả là trường duy nhất của một lần phân phối mà chỉ bạn có thể chọn. > **Phần của những người nắm giữ bị hạn chế sẽ ở lại trong hợp đồng.** Một địa chỉ bị mô-đun danh sách đen lợi tức loại trừ sẽ bị bỏ qua, và phần chia theo tỷ lệ của nó sẽ nằm lại trong hợp đồng token thay vì được chi trả. Các khoản chi trả trước đó chưa được hiển thị — để đọc chúng phải lần ngược các sự kiện phân phối về đến khối đầu tiên của tài sản, điều này cần một con trỏ lịch sử vẫn chưa có. Tab này nói điều đó ngay trong nó thay vì hiển thị một `0`. ### Quyền — các vai trò ![Tab Quyền — mọi vai trò và việc nó có được nắm giữ hay không, cùng điều khiển cấp / thu hồi / từ bỏ.](https://4233397286-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F671PKS8ZQSNqtoC8PGvz%2Fuploads%2Fgit-blob-fb54f6c73c2d194dd5b6321bc3cb0af825f6f637%2Ftab-rights.png?alt=media) Tab này liệt kê mọi vai trò mà token khai báo và việc nó có được nắm giữ hay không, mỗi vai trò được đọc bằng một lệnh `hasRole` gọi tới token. Một vai trò mà **không phải** được nắm giữ sẽ hiển thị như vậy thay vì bị bỏ qua — trên tab quyền, một hàng bị thiếu và một *"không"* là hai sự thật khác nhau. Bên dưới danh sách, một điều khiển thay đổi các vai trò: | Hành động | Tác động lên | Thẩm quyền | | ---------------------------- | --------------------------------------------------------------- | -------------------- | | **Cấp cho một tài khoản** | Một địa chỉ bạn nhập | `DEFAULT_ADMIN_ROLE` | | **Thu hồi từ một tài khoản** | Một địa chỉ bạn nhập | `DEFAULT_ADMIN_ROLE` | | **Từ bỏ của chính bạn** | Chính bạn (OpenZeppelin yêu cầu bên xác nhận phải là người gọi) | Bạn | Các lựa chọn vai trò là của chính token, nên điều khiển không bao giờ có thể đưa ra một vai trò mà token không có. Như với mọi thao tác ghi, hàng thẩm quyền và hệ quả được hiển thị trước nút, nên cánh cửa và tính một chiều của nó được nêu rõ trước khi bạn ký. *** ## Điều không bao giờ chạm tới Bloom hay chuỗi Để nói rõ ràng nơi tuân thủ tồn tại: | Điều | Nơi nó tồn tại | | ------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------- | | Tài liệu KYC/AML và PII | Hệ thống của riêng bạn, với các nhà cung cấp và thời hạn lưu giữ của riêng bạn — **không bao giờ** ứng dụng này hoặc chuỗi | | Quyết định của bạn để chấp nhận một địa chỉ | Một bản ghi ngoài chuỗi; bạn sở hữu kho lưu trữ | | Hiệu ứng trên chuỗi của quyết định đó | Một giá trị boolean — `isWhitelisted(address)` — được ghi bởi `batchAddToWhitelist` | | Việc thực thi quy tắc | Hợp đồng tài sản, trong mọi lần chuyển | | Ai có thể quản trị tài sản | Vai trò được nắm giữ trên mô-đun allowlist của tài sản, được kiểm tra trong mọi yêu cầu | Để xem đầy đủ mô hình tuân thủ, hãy đọc [COMPLIANCE.md](/vi/ung-dung-tren-rome/bloom/compliance.md); còn về cơ chế hai luồng (EVM và Solana) mà những người nắm giữ của bạn sử dụng, hãy đọc [LANES.md](/vi/ung-dung-tren-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/vi/ung-dung-tren-rome/bloom/issuing.md?ask=&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.