> 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/de/apps-auf-rome/bloom/issuing.md). # Ausgabe Bloom ermöglicht es Ihnen, einen **berechtigten Real-World-Asset** als gewöhnlichen Solidity-Vertrag auf einer Rome-Chain auszugeben und ihn über eine asset-spezifische Konsole zu verwalten. Das Asset ist sowohl über EVM- als auch Solana-Wallets erreichbar, aber **die Ausgabe erfolgt nur über EVM** — eine Solana-Wallet hält Assets; sie erstellt sie nicht. Dieser Leitfaden behandelt die Ausgeber-Konsole, den Erstellungsassistenten, das Sign-in-Gate der Konsole und jeden der sechs Verwaltungstabs. > **Sie übergeben Bloom keine Dokumente oder personenbezogenen Daten, und Ihr Investor ebenfalls nicht.** Bloom erfasst das *Ergebnis* Ihrer Compliance-Entscheidung; die Chain speichert ein Boolean pro Adresse. Ihr KYC/AML-Prozess — Ihre Dienstleister, Ihre Dateien, Ihre Aufbewahrung — bleibt vollständig in Ihrem eigenen System. Das vollständige Modell steht in [COMPLIANCE.md](/de/apps-auf-rome/bloom/compliance.md); dieser Leitfaden verweist darauf, statt es hier zu wiederholen. *** ## Was Sie tun können Als Administrator eines Assets liegt alles Folgende in Ihrer Hand über die Konsole — und jeder dieser Schritte ist eine echte On-Chain-Transaktion, verlinkt auf der [Nachweise](/de/apps-auf-rome/bloom/evidence.md) Seite: * **Ein Asset ausgeben** — der Assistent deployt es als drei Verträge (unten). * **Anträge prüfen** — jeden einzelnen genehmigen oder ablehnen (eine Ablehnung enthält einen Grund, der dem Antragsteller zusteht) und eine genehmigte Adresse zur Allowlist hinzufügen. * **Die Allowlist verwalten** — eine Adresse hinzufügen, **eine Reihe von Adressen in einer einzigen Transaktion hinzufügen** (`batchAddToWhitelist`), oder eine Adresse entfernen; der Token erzwingt die Liste bei jeder Übertragung. * **Das Asset gaten** — Übertragungen auf die Allowlist beschränken (wodurch das Angebot endgültig wird) oder die Beschränkung aufheben. * **Das Angebot verwalten** — die Gesamtsumme lesen und prägen oder verbrennen, sobald Sie die Rolle haben. * **Den Verkauf durchführen** — einen Verkauf öffnen (Einheiten und Preis), ihn schließen, unverkaufte Bestände zurückrufen und den Erlös auszahlen. * **Ertrag festlegen und verteilen** — die Auszahlungswährung festlegen und dann eine Auszahlung verteilen, die die Halter eine Transaktion nach der anderen durchläuft; ausgeschlossene Halter werden übersprungen. * **Rollen verwalten** — einer Adresse eine Rolle gewähren, eine widerrufen oder die eigene aufgeben. Jeder ist unten im jeweiligen Tab mit den von der Chain durchgesetzten Regeln beschrieben. *** ## Die Ausgeber-Konsole ![Die Ausgeber-Konsole unter /issuer, die die Assets auflistet, die dieses Deployment kennt, und ihren Verkaufsstatus.](/files/a6772e155e9a22d9b63afeef844ac358650b915b) `/issuer` listet die Assets auf, die Sie auf dieser Chain ausgegeben haben, und lässt Sie ein neues starten. * Verbinden Sie eine **EVM-Wallet**. Ein nicht verbundener Besucher oder eine Solana-Wallet sieht die Aufforderung, den richtigen Wallet-Typ zu verbinden, statt einer leeren Konsole — eine Solana-Wallet kann nicht ausgeben, und das ist eine Produktgrenze, die die Chain als zweite, unabhängige Schutzmaßnahme durchsetzt. * Die Tabelle listet jedes Asset mit seinem **Namen und Symbol**, seiner Lebenszyklus- **Phase**, und seinem **Verkaufs-** status (einem *Open* -Badge oder *Closed*). Zwei Spalten — **Halter** und **Zu prüfen** — zeigen einen Gedankenstrich. Die Halteranzahl braucht die Auflistung der Allowlist, und die Prüfwarteschlange ist ein Off-Chain-Speicher, bei dem Sie sich pro Asset anmelden; ein Gedankenstrich sagt *nicht abgefragt* wo ein `0` ein Fakt behaupten würde, den die App nicht gelesen hat. Drücken Sie **Ein Asset ausgeben** um den Assistenten zu öffnen, oder wählen Sie eine Zeile aus, um die Konsole dieses Assets zu öffnen. *** ## Ein Asset erstellen: der Assistent ![Der Erstellungsassistent unter /create: die Asset-Felder, dann sechs Karten, die aufleuchten, sobald ihre Transaktionen gelandet sind.](/files/c7a17049183d67558e447572b09c76f83c024a19) `/create` erfasst vier Felder und deployt dann Ihr Asset. | Feld | Regel | | ------------------ | -------------------------------- | | **Name** | Erforderlich. | | **Symbol** | Erforderlich. | | **Angebot** | Eine ganze Zahl größer als null. | | **Dezimalstellen** | Eine ganze Zahl von 0 bis 18. | Drücken Sie **Start**. Wenn ein Feld ungültig ist, sagt der Assistent Ihnen, welches und warum, statt hinter einer deaktivierten Schaltfläche zu sitzen. Wenn der Entwurf gültig ist, wird Ihre Wallet gebeten, jeden Schritt nacheinander zu signieren. ### Warum es schrittweise deployt wird > **Ein Token wird als drei Verträge über mehrere Transaktionen deployt — niemals in einer einzigen.** Arcs Ein-Transaktions- `createToken` würde **77 Account-Locks**benötigen, und Rome begrenzt eine einzelne Transaktion auf **62 Locks**. Deshalb deployt der Assistent jedes Teil in einer eigenen Transaktion und erhält danach über `ArcTokenFactoryV2.registerToken`den Factory-Status. Dies ist eine sichtbar gemachte Rome-Beschränkung, keine optionale Optimierung — und die Schutzmechanismen bewahren Arcs Sicherheitsmodell aus dem Upstream exakt (kanonischer Proxy, auf der Whitelist stehende Implementierung, der Aufrufer hält die Admin-Rolle des Tokens, Registrierung nur einmal). Siehe [COMPLIANCE.md](/de/apps-auf-rome/bloom/compliance.md#what-rome-adds--and-what-registertoken-preserves). ### Die sechs Karten Der Assistent zeigt sechs Karten, die dem Fortschritt des Deployments folgen. Eine Karte wechselt von **Wartend** zu **Wird signiert…** zu **Fertig** (oder **Fehlgeschlagen**) sobald ihre Transaktion gelandet ist. | # | Karte | Was sie tut | | - | ------------------------------- | --------------------------------------------------------------------------------------------------------------------------------- | | 1 | **Implementierung** | Die gemeinsame Asset-Implementierung für diese Chain — aufgelöst, nichts zu signieren. (Erledigt, bevor irgendein Schritt läuft.) | | 2 | **Das Asset** | Deployt Ihr Asset und setzt Name, Symbol, Angebot und Dezimalstellen in einem Schritt. | | 3 | **Wer es halten darf** | Deployt das eigene Berechtigungsmodul dieses Assets, mit Ihnen als seinem Administrator. | | 4 | **Bei Übertragungen erzwingen** | Verweist das Asset auf dieses Modul, sodass jede Übertragung vom Asset selbst geprüft wird. | | 5 | **Yield-Regeln** | Deployt und verknüpft das Modul, das entscheidet, wer bezahlt wird. | | 6 | **Registrierung** | Registriert das Asset — dadurch wird der Verkauf geöffnet und spätere Upgrades werden möglich. | Die sechs Karten fassen acht zugrunde liegende Bereitstellungsschritte zusammen, sodass ein einzelner Lauf **Start** ergibt **acht Signaturen**. Ein Hinweis unter der Schaltfläche lautet *"Ihre Wallet wird Sie bitten, jeden Schritt zu signieren. Sie können jederzeit stoppen und später genau dort weitermachen, wo Sie aufgehört haben — nichts geht verloren."* Dass die Registrierung der letzte Schritt ist, ist der Grund, warum ein Stopp sicher ist: Das Asset ist in jeder Phase eine echte Bereitstellung und wird erst am Ende registriert. Wenn der Lauf abgeschlossen ist, liest der Assistent *"Ausgegeben. Ihr Asset ist live unter …"* mit einem Link zur Konsole des Assets unter `/token/[address]`. > **`initialize` gewährt Ihnen jede Rolle.** Der Assistent-Controller — Ihre EVM-Adresse — erhält die Admin-, Minter/Burner-, Yield-Manager/Distributer- und Upgrader-Rollen des Tokens sowie die Admin-Rolle des Allowlist-Moduls. Ihre Schlüsselverwahrung ist daher Teil der Compliance-Position des Assets: Eine verlorene Investor-Wallet ist nur durch Ihre Admin-Aktion wiederherstellbar, und der **Rechte** Tab macht jeden Träger einer Befugnis sichtbar. (`UPGRADER_ROLE` wird *nicht* automatisch der Factory gewährt — gewähren Sie sie explizit, wenn Sie Upgrades über die Factory wollen.) *** ## Die asset-spezifische Konsole und das Sign-in-Gate ![Das Sign-in-Gate der Konsole: Signieren Sie eine Nachricht mit Ihrer Wallet — es gibt kein Passwort.](/files/b96611af769912f6901edd80f9bc6329429c5f6f) Öffnen `/token/[address]` zeigt **nicht** die Konsole nicht sofort an. Es zeigt ein **Sign-in-Gate**: > *"Melden Sie sich an, um dieses Asset zu verwalten. Signieren Sie eine Nachricht mit Ihrer Wallet — es gibt kein Passwort. Ihre Autorität kommt vom Asset selbst und wird bei jeder Aktion erneut geprüft, sodass ein Widerruf sofort wirksam wird."* Drücken Sie **Mit Ihrer Wallet anmelden**. Genau Folgendes passiert: 1. Ihre Wallet wird gebeten, `personal_sign` eine kurze, menschenlesbare Erklärung zu signieren (überschrieben mit *"Bloom — belegen Sie, dass Sie dieses Asset verwalten"*), die die eine Aktion nennt, die sie autorisiert — das Lesen der Antragswarteschlange dieses Assets — zusammen mit der Asset-Adresse, der Chain-ID und einem Zeitstempel. 2. Die App sendet diese signierte Erklärung an `GET /api/applications`. 3. Der **Server** prüft sie: Er ermittelt Ihre Adresse aus der Signatur, bestätigt, dass die Erklärung für diese Chain bestimmt und noch frisch ist (sie autorisiert für ein Zwei-Minuten-Fenster, nicht für eine Sitzung), liest das **eigene Allowlist-Modul des Tokens** von der Chain und prüft, ob Ihre Adresse die Rolle hält, die das Schreiben auf die Allowlist tatsächlich erfordert — `MANAGER_ROLE` auf diesem Modul. 4. Wenn Sie sie besitzen, wird die Warteschlange zurückgegeben und die Konsole rendert. Wenn nicht, lehnt der Server mit `403` und einem Grund ab. ![Das Gate zeigt eine zitierte Ablehnung: Eine Wallet, die dieses Asset nicht verwaltet, wird abgewiesen.](/files/bd97429a12c27f8e092d25ffd703e716577d9f01) > **Das Asset entscheidet, wer es verwalten darf — nicht diese App.** Die Rolle wird auf dem Allowlist- **Modul**geprüft, nicht auf dem Token, und eine gleichnamige Rolle auf dem Token selbst *nicht* wird nicht übernommen — es sind unterschiedliche Zuständigkeiten. Es gibt kein Konto und keine Sitzung: Jede nachfolgende Anfrage trägt ihre eigene frische Signatur, und genau das bedeutet *"bei jeder Aktion erneut geprüft"* . Widerrufen Sie die Rolle einer Wallet auf der Chain, und sie kann sich sofort nicht mehr anmelden. Eine Ablehnung zeigt den Grund **in Anführungszeichen** — Bloom schreibt niemals einen Satz darüber, warum eine Wallet abgewiesen wurde. Wenn Sie die Signatur in Ihrer Wallet ablehnen, ist das Ihr *"Nein"*, nicht das des Assets, und es wird nicht als Ablehnung gemeldet. > **Das Gate entscheidet, wessen Konsole es ist, nicht, was geheim ist.** Angebot, Verkaufsstatus, die Allowlist-Liste und die Rollen sind öffentliche Chain-Lesewerte, die jeder Explorer beantworten kann. Was die Signatur bringt, ist die **Antragswarteschlange** — die Erklärungen anderer Leute — und das Recht, überhaupt die Konsole angezeigt zu bekommen. ### Die Konsolenüberschrift Nach dem Anmelden nennt die Überschrift das Asset und zeigt seine **Phase** — die folgenreichste Tatsache, die es hat: | Phase | Bedeutung | | ----------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Entwurf** | Es ist noch kein Berechtigungsmodul verknüpft, daher schränkt nichts ein, wer dies halten darf. | | **Open** | Übertragungen sind offen, und das Angebot kann sich noch ändern. Das Asset zu gaten macht sein Angebot endgültig, und das lässt sich nicht rückgängig machen. | | **Gegatet** | Nur auf der Allowlist stehende Adressen dürfen dies halten, **und sein Angebot ist endgültig** — es kann dauerhaft nichts mehr geprägt oder verbrannt werden. | Über den Tabs zeigt eine Zusammenfassung vier Kennzahlen — **Halter · Zu prüfen · Verkauft · Ausgezahlte Rendite**. Zwei werden von der Chain und dem Store gelesen (*Zu prüfen* sobald Sie angemeldet sind; *Verkauft* aus dem Storefront); *Halter* wartet auf die Halteranzahl der Rendite-Vorschau, und *Ausgezahlte Rendite* wartet auf den noch kommenden Cursor der Auszahlungshistorie. Jede wartende Zelle zeigt einen Gedankenstrich und erklärt, was sie braucht, statt `0` eine Tatsache zu behaupten, nach der niemand die Chain gefragt hat. *** ## Die sechs Tabs Die Konsole hat sechs Tabs, in dieser Reihenfolge: **Anträge · Wer es halten darf · Angebot · Verkauf · Rendite · Rechte.** Jede Schreibaktion in diesen Tabs verwendet eine gemeinsame Steuerung, die die **genannten Vorbedingungen** und ihre **Folgen** *vor* der Schaltfläche anzeigt und ihre Phase benennt, während sie läuft (*"Warten auf Ihre Wallet…"*, *"Wird auf der Chain gelandet…"*). Nichts sollte zurückrollen, nur um Ihnen zu zeigen, was vorher hätte geprüft werden können. ### Anträge — die Prüfwarteschlange ![Der Tab Anträge — die Prüfwarteschlange, mit einem ausstehenden Antrag zum Genehmigen oder Ablehnen und der Compliance-Schnittstelle.](/files/443c4955ec1243cf7a4723a3c9c9f4890814dbf0) Dieser Tab listet auf, wer sich beworben hat, das Asset zu halten. Jede Zeile zeigt die Adresse des Antragstellers, die Jurisdiktion, den Typ des Halters, eine **Prüfungen** Spalte (*Bestanden* wenn Ihr Anbieter ein Ergebnis aufgezeichnet hat, sonst *Erklärt*), und einen **Status** (*Zu prüfen*, *Genehmigt*, *Abgelehnt*). Erweitern Sie eine Zeile, um ihre Fakten und zwei Bedienelemente zu sehen: **Genehmigen — darf es halten** und **Ablehnen**. Eine Ablehnung erfordert einen Grund, der zur Antwort des Antragstellers wird. > **Genehmigen sind zwei getrennte Handlungen, und der Tab sorgt dafür, dass sie sauber bleiben.** Beim Drücken von **Genehmigen** *wird* Ihre Entscheidung im Antrags-Speicher aufgezeichnet. Die Adresse auf die Allowlist des Assets auf der Chain zu setzen ist eine **zweite Signatur** — `batchAddToWhitelist` — und bis sie gelandet ist, sagt die Zeile das auch. Wenn die aufgezeichnete Entscheidung und die Chain nicht übereinstimmen, benennt der Tab die Lücke und bietet die Schreibaktion an, die sie schließt: **Zulassen** um eine genehmigte Adresse zur Allowlist hinzuzufügen, oder (bei einer weiterhin gelisteten abgelehnten Adresse) das Steuerelement, um sie zu entfernen. Die Adresse kann das Asset nicht halten, bis der Schreibvorgang auf der Allowlist gelandet ist. Eine feste Notiz in diesem Tab — die **Compliance-Schnittstelle** — sagt, wo Ihr eigener Prozess eingesteckt wird: > *"Hier werden keine Dokumente angefordert oder aufbewahrt — die Prüfungen sind Ihre eigenen. Verbinden Sie Ihren Anbieter hinter der `Anträge` -Schnittstelle oder importieren Sie bereits getroffene Entscheidungen. Bloom erfasst das Ergebnis und die Chain speichert ein Ja oder Nein gegen die Adresse."* Das ist die Schnittstelle, die ein selbst gehosteter Ausgeber ersetzt: Tauschen Sie die Implementierung des Antrags-Speichers gegen Ihre eigene dauerhafte Implementierung aus, und kein Aufrufer ändert sich. Bloom führt keine Prüfungen durch und hält kein Dokument. ### Wer es halten darf — das Transfer-Gate ![Der Tab Wer-es-halten-darf — die Anzahl der Allowlist-Einträge und das Steuerelement für Übertragungen beschränken, mit den Folgen seiner Einbahnstraßenwirkung.](/files/e634a808eafa7e68856f1732bef3618175b6e5a1) Dieser Tab meldet, wie viele Adressen auf der Allowlist des Assets stehen, und lässt Sie umschalten, ob die Allowlist **durchgesetzt**: * Wenn Übertragungen **uneingeschränkt**sind, bietet er an, **Übertragungen auf die Allowlist zu beschränken**. Die Folgen der Schreibaktion sagen aus, dass dadurch das Angebot endgültig wird und dies für Nicht-Administratoren eine Einbahnstraße ist. * Wenn Übertragungen **eingeschränkt**sind, bietet er an, **die Beschränkung aufheben**. Seine Folgen sagen unmissverständlich, dass dies kein Undo ist. Bei einem *ungateteten* (Entwurfs-)Asset ohne verknüpftes Berechtigungsmodul sagt der Tab das auch — *"Es ist kein Berechtigungsmodul verknüpft, daher schränkt nichts ein, wer dies halten darf"* — und der Schalter wird nicht angezeigt. > **Der Token prüft beide Seiten jeder Übertragung.** Solange das Asset gegatet ist, führt eine Übertragung, bei der eine Partei nicht auf der Allowlist steht, auf der Chain zu einem typisierten Fehler und wird zurückgerollt. Dasselbe Gate greift bei einer Übertragung aus einer EVM-Wallet, einer von Solana signierten Übertragung, einem Storefront-Verkauf und dem ersten Liquiditätstransfer — es gibt keinen Weg daran vorbei außer Ihren eigenen Admin-Rechten. ### Angebot ![Der Supply-Tab — die Gesamtzahl der vorhandenen Einheiten.](/files/7fac9ac3be387f2038656abe81f5083192d17e8a) Dieser Tab meldet das gesamte vorhandene Angebot, in ganzen Einheiten. ### Verkauf — öffnen, schließen und Erlös entnehmen ![Der Verkauf-Tab — ein offener Verkauf, mit den Steuerelementen Verkauf schließen, unverkaufte Einheiten zurückrufen und Erlös auszahlen.](/files/34964f00aacde047686302cd51b9b025e29e82a8) Dieser Tab führt den Primärverkauf über den Storefront-Vertrag aus. * **Wenn kein Verkauf offen ist**, bietet er an, einen zu öffnen: Geben Sie **Zu verkaufende Einheiten** und **Preis pro Einheit** (in `wUSDC`) ein und drücken Sie dann **Verkauf öffnen**. Die Vorbedingungen der Schreibaktion werden zuerst angezeigt — der Token muss registriert sein, der Storefront muss den Verkaufsbestand halten, und der Storefront selbst muss auf dem Token, den er verkauft, auf der Allowlist stehen — damit ein noch nicht öffnbarer Verkauf genau sagt, was er benötigt. * **Wenn ein Verkauf offen ist**, zeigt er an, wie viele Einheiten des Angebots noch übrig sind, und bietet **Diesen Verkauf schließen**. * **Unverkaufte Einheiten zurückrufen** verschiebt unverkauften Bestand vom Storefront zurück an einen Empfänger (standardmäßig an Sie). Dies ist **nicht** ein Schließen — der Verkauf bleibt aktiviert, und die Folge der Schreibaktion sagt das auch, sodass ein Rückruf nicht als Rückabwicklung missverstanden werden kann. * **Erlös auszahlen** sendet die Einnahmen des Storefronts an eine Adresse (standardmäßig an Sie). Erlöse wachsen unabhängig vom Status des Verkaufs an, daher können sie sowohl bei offenem als auch geschlossenem Verkauf ausgezahlt werden. ### Yield — Halter bezahlen, einer pro Transaktion ![Der Yield-Tab — das Feld für den Auszahlungsbetrag, mit der Erinnerung, zuerst eine Auszahlungswährung festzulegen.](/files/2d707cede6808440f82c400185280bdfecdfef18) Dieser Tab verteilt eine Yield-Auszahlung an die Halter. > **Eine Verteilung ist ein Rundgang, kein Klick.** Auf Rome `distributeYieldWithLimit` zahlt **einen Halter pro Transaktion** (das Account-Limit), also ist eine Auszahlung eine Abfolge von Fenstern, jedes mit eigener Signatur. Sie geben den Betrag einmal ein, in ganzen Einheiten der Auszahlungswährung, und er wird gesperrt, sobald der Rundgang beginnt. Das **erste** Fenster zieht die gesamte Auszahlung von Ihnen ein und zahlt den ersten Halter; jedes spätere Fenster bewegt nur Geld, das bereits im Token-Vertrag liegt. Bloom liest den Cursor nach jedem Fenster erneut von der Chain — die Haltermenge ordnet sich neu, während sich Salden ändern, und das Senden eines veralteten Index würde wieder bei null starten und Ihr Geld ein zweites Mal einziehen. Der Tab zeigt den Fortschritt — *"Halter N von M wird bezahlt"* — und endet, wenn der Cursor wieder herumläuft. Wenn für das Asset keine Auszahlungswährung festgelegt ist, sagt der Tab das; die Festlegung der Auszahlungswährung ist das eine Feld einer Verteilung, das nur Sie wählen können. > **Anteile gesperrter Halter bleiben im Vertrag.** Eine von dem Yield-Blacklist-Modul ausgeschlossene Adresse wird übersprungen, und ihr anteiliger Anteil bleibt im Token-Vertrag, statt ausgezahlt zu werden. Vergangene Auszahlungen werden noch nicht angezeigt — sie zu lesen würde die Verteilungsereignisse bis zum ersten Block des Assets zurückverfolgen, wofür noch ein Verlaufscursor fehlt. Der Tab sagt das in sich selbst, statt einen `0`. ### Rechte — die Rollen ![Der Rechte-Tab — jede Rolle und ob sie gehalten wird, sowie das Gewähren/Widerrufen/Aufgeben-Steuerelement.](/files/8b146fcc108de9bf83c1a6f5a946f1eb7d615742) Dieser Tab listet jede Rolle auf, die der Token deklariert, und ob sie gehalten wird, jeweils gelesen mit einem einzelnen `hasRole` Auf dem Token ausführen. Eine Rolle, die **nicht** vorhanden ist, wird als solche angezeigt, statt ausgelassen zu werden — auf einer Rechtes-Registerkarte, eine fehlende Zeile und ein *"Nein"* sind unterschiedliche Fakten. Unter der Liste ändert ein Steuerelement die Rollen: | Aktion | Wirkt auf | Befugnis | | ------------------------- | ------------------------------------------------------------------------- | -------------------- | | **Einem Konto gewähren** | Eine Adresse, die Sie eingeben | `DEFAULT_ADMIN_ROLE` | | **Einem Konto entziehen** | Eine Adresse, die Sie eingeben | `DEFAULT_ADMIN_ROLE` | | **Ihre eigene aufgeben** | Sie selbst (OpenZeppelin verlangt, dass die Bestätigung der Aufrufer ist) | Sie | Die Rollenauswahl stammt vom Token selbst, sodass das Steuerelement niemals eine Rolle anbieten kann, die der Token nicht hat. Wie bei jeder Schreibaktion werden die Befugnis-Zeile und die Folge vor der Schaltfläche angezeigt, sodass die Tür und ihre Einweg-Natur vor Ihrer Unterschrift genannt werden. *** ## Was Bloom oder die Chain nie berührt Um eindeutig zu machen, wo die Compliance liegt: | Ding | Wo es liegt | | -------------------------------------------------- | --------------------------------------------------------------------------------------------------------------- | | KYC/AML-Dokumente und personenbezogene Daten (PII) | Ihr eigenes System, mit Ihren eigenen Anbietern und Aufbewahrungsfristen — **niemals** diese App oder die Chain | | Ihre Entscheidung, eine Adresse zuzulassen | Ein Datensatz außerhalb der Chain; Sie besitzen den Speicher | | Die Wirkung dieser Entscheidung auf der Chain | Ein boolescher Wert — `isWhitelisted(address)` — geschrieben von `batchAddToWhitelist` | | Durchsetzung der Regel | Der Asset-Contract, bei jeder Übertragung | | Wer das Asset verwalten darf | Die auf dem Allowlist-Modul des Assets gehaltene Rolle, die bei jeder Anfrage geprüft wird | Für das vollständige Compliance-Modell lesen Sie [COMPLIANCE.md](/de/apps-auf-rome/bloom/compliance.md); für die Zwei-Linien-Mechanik (EVM und Solana), die Ihre Inhaber verwenden, lesen Sie [LANES.md](/de/apps-auf-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 dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.rome.builders/de/apps-auf-rome/bloom/issuing.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. 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.