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

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.