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

# Compliance-Modell

Bloom betreibt Plumes Arc-Framework unverändert. Die Compliance wird **vom Token-Contract selbst durchgesetzt** — nicht durch einen Off-Chain-Screen, einen Sequencer-Filter oder eine Venue-Policy. Das ist die Eigenschaft, die es portabel macht: Die Regeln reisen mit dem Token zu jedem Ausführungspfad, auf beiden Wallet-Lanes.

## Durchsetzungsarchitektur

```
ArcToken._update (bei jedem Transfer/Mint/Burn)
   └─ RestrictionsRouter (einer pro Chain, Registry nach Modultyp)
        ├─ TRANSFER_RESTRICTION → WhitelistRestrictions (pro Token)
        ├─ YIELD_RESTRICTION    → YieldBlacklistRestrictions (pro Token)
        └─ GLOBAL_SANCTIONS     → (Slot vorhanden; kein globales Modul bereitgestellt)
```

* **WhitelistRestrictions** — die Allowlist. Solange `transfersAllowed` false ist (Gated Mode), revertiert ein Transfer, bei dem eine der beiden Seiten nicht auf der Liste steht, mit dem typisierten Fehler `TransferRestricted()` (`0xe827105e`"). Die Prüfung läuft im Token bei jeder Kontobewegung — ein EVM-Wallet-Transfer, ein von Solana signierter Transfer, ein Verkauf im Storefront und die anfängliche Liquiditätsbewegung passieren alle dasselbe Gate. Es gibt keinen Weg daran vorbei, außer über die eigenen Admin-Rechte des Emittenten.
* **YieldBlacklistRestrictions** — schließt Adressen von Yield-Ausschüttungen aus; ihr proportionaler Anteil bleibt im Token-Contract.
* **GLOBAL\_SANCTIONS** — der Router unterstützt chain-weite Module, die auf jeden Token angewendet werden (z. B. eine Sanktionsliste). Heute ist keines bereitgestellt; der Slot ist der natürliche Platz für eines, das auf Chain-Ebene betrieben wird.

## Das Vertrauensmodell, offen gesagt

**Das Allowlist-Flag ist die Off-Chain-Entscheidung des Emittenten.** KYC/AML findet im Prozess des Emittenten statt (dessen Dienstleister, dessen Regeln); die Chain erfasst und erzwingt das *Ergebnis* — `isWhitelisted(addr)`. [Onboarding und Prüfung](/de/apps-auf-rome/bloom.md) ist der Mechanismus rund um diese Entscheidung — wie ein Investor sich bewirbt, wie der Emittent entscheidet und welche Prüfspuren er hinterlässt — und er ändert dieses Modell nicht: weiterhin die Entscheidung des Emittenten, weiterhin nur ein Boolescher Wert on-chain, und nirgendwo Dokumente. Das ist das eigene Modell des Arc-Frameworks, wie es auf Plume verwendet wird. Es ist absichtlich *nicht* ein On-Chain-Identitätssystem: Es gibt keine Identitätsansprüche, keine On-Chain-Attestierungen und keinen kryptografischen Nachweis, wem eine Adresse gehört. Standards, die verifizierbare On-Chain-Identität tragen (z. B. ERC-3643), tauschen für diese Eigenschaft deutlich schwergewichtigere Transfers ein; Arc tauscht leichtere Mechanik gegen beim Emittenten liegendes Vertrauen. Bloom stellt dies offen dar, statt mehr zu implizieren.

## Emittentenbefugnisse (wie ein Transfer-Agent gestaltet)

`ArcToken.initialize` weist dem Wizard-Driver jede Rolle zu:

| Rolle                                           | Befugnis                                                                                                        |
| ----------------------------------------------- | --------------------------------------------------------------------------------------------------------------- |
| `ADMIN_ROLE` / `DEFAULT_ADMIN_ROLE`             | Restriktionsmodule verknüpfen/ersetzen, Rollen verwalten                                                        |
| `MINTER_ROLE` / `BURNER_ROLE`                   | Supply-Verwaltung                                                                                               |
| `YIELD_MANAGER_ROLE` / `YIELD_DISTRIBUTOR_ROLE` | Yield-Token festlegen, Ausschüttungen ausführen                                                                 |
| `UPGRADER_ROLE`                                 | das Token per UUPS upgraden (vom Emittenten gehalten; an die Factory für Factory-vermittelte Upgrades vergeben) |
| Whitelist-Modul `WHITELIST_ADMIN_ROLE`          | Adressen hinzufügen/entfernen, Gated Mode umschalten                                                            |

Wissenswerte Konsequenzen: Ein **verlorenes Anleger-Wallet** ist nur durch eine Aktion des Emittenten wiederherstellbar (eine Ersatzadresse whitelisten und, falls nötig, die Mint-/Burn-/Upgrade-Befugnisse gemäß ihrem rechtlichen Prozess verwenden — Arc hat keine eingebaute Zwangstransfer-Primitivfunktion). Die Schlüsselhoheit des Emittenten ist daher Teil der Compliance-Position; der Rollen-Viewer der App macht die Inhaber jeder Befugnis sichtbar.

## Was Rome hinzufügt — und was registerToken bewahrt

Solana-Wallet-Nutzer erscheinen als **synthetische EVM-Adressen** (abgeleitet aus ihrem Solana-Public-Key). Für die Compliance-Schicht sind sie gewöhnliche Adressen: Der Emittent whitelisted sie, das Gate prüft sie, Yield erreicht sie — eine einzige Allowlist umfasst beide Wallet-Welten. Verwahrungsimplikationen stehen in [LANES.md](/de/apps-auf-rome/bloom/lanes.md).

Da Rome die Konten pro Transaktion begrenzt, werden Tokens schrittweise bereitgestellt und erhalten den Factory-Status über `ArcTokenFactoryV2.registerToken` statt des einmaligen `createToken`. Die Guards bewahren das Upstream-Sicherheitsmodell exakt: Das Token muss ein kanonischer Proxy sein (Codehash), seine Implementierung muss factory-whitelisted sein (Codehash), der Aufrufer muss das Token's `ADMIN_ROLE`, und die Registrierung ist nur einmalig. Nichts an der Compliance-Oberfläche wird durch den schrittweisen Weg geschwächt.


---

# 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/compliance.md?ask=<question>&goal=<endgoal>
```

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