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; 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 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.

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

/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-Locksbenö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.registerTokenden 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.

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.

Ö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.

Das Asset entscheidet, wer es verwalten darf — nicht diese App. Die Rolle wird auf dem Allowlist- Modulgeprü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.

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.

Dieser Tab meldet, wie viele Adressen auf der Allowlist des Assets stehen, und lässt Sie umschalten, ob die Allowlist durchgesetzt:

• Wenn Übertragungen uneingeschränktsind, 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änktsind, 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.

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.

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.

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.

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; für die Zwei-Linien-Mechanik (EVM und Solana), die Ihre Inhaber verwenden, lesen Sie LANES.md.