> 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/lanes.md). # Die zwei Lanes Ein Token-Deployment, zwei Wallet-Welten. Beide Pfade führen die **gleichen Verträge** mit dem **gleichen Compliance-Gate** — sie unterscheiden sich nur darin, wer signiert und wie die Transaktion die Chain erreicht. ## EVM-Pfad Standard-Ethereum-Tooling, unverändert: Die Wallet signiert eine EVM-Transaktion, der JSON-RPC-Endpunkt der Chain akzeptiert sie, der Token-Contract erzwingt die Allowlist. Nichts Bloom-Spezifisches zu integrieren — die gemessenen Kosten eines Gate-Transfers liegen bei \~3,1 Mio. Gas (Rome-Gas ist in USDC denominiert; ein einfacher nativer Transfer liegt zum Vergleich bei \~1,48 Mio.). ## Solana-Pfad Eine Solana-Wallet steuert dieselben EVM-Verträge **nativ — es existiert nirgendwo ein EVM-Schlüssel**: 1. **Identität.** Die EVM-seitige Adresse des Nutzers ist *synthetisch*: deterministisch abgeleitet als `keccak256(solana_pubkey)[12..32]`. Das Rome-EVM-Programm leitet sie on-chain aus dem tatsächlichen Signierer der Transaktion ab — sie kann nicht vorgetäuscht werden, und es existiert kein secp256k1-Privatschlüssel dafür, daher **ist die Solana-Signatur das Einzige, was diese Adresse jemals ansteuern kann**. 2. **Entdeckung.** Der Client fragt die RPC der Chain (`rome_emulateCallAccounts`) ab, welche Solana-Konten der EVM-Call berühren wird; die Emulation entscheidet auch, welche beschreibbar sind (der `Wert` des Calls muss enthalten sein — die Beschreibbarkeit des Balance-Kontos des Empfängers hängt davon ab). 3. **Einreichen.** Der Client erstellt eine `DoTxUnsigned` -Instruktion — eine *unsignierte* EIP-1559-Payload, autorisiert durch die Solana-Signatur — plus Compute-Budget-Instruktionen (250 KB Heap, 1,35 Mio. CU) und die Gebührenpool-Kontoerkennung, die ausgelassen wird. Die Wallet signiert eine einzelne Solana-Transaktion; fertig. **Größe, gemessen bei diesem Deployment am 2026-07-30:** ein Storefront-Kauf entspricht **22 Konten** und serialisiert sich zu **1.061 Bytes** gegenüber dem Legacy-Limit von 1232 Bytes — 171 Bytes Puffer, also etwa fünf weitere Konten. Es braucht heute also KEINE Lookup-Tabelle. Ein Zustand, der mehr berührt — ein noch zu erstellendes Associated Token Account, ein Erstanleger — könnte es dennoch überschreiten, und über 1232 Bytes fällt der Client auf eine v0-Transaktion über eine Address Lookup Table zurück, die er zu diesem Zweck ERSTELLT. **Dieser Fallback ist für eine Wallet teuer:** jeder ALT-Extend-Chunk und die v0-Neueinreichung sind eine separate `signTransaction`, sodass aus einem Kauf drei oder vier Prompts werden. Hadrian verfügt bereits über eine persistente dApp-Tabelle, die die Konten dieser Verträge enthält — stattdessen darauf zu verweisen, ist die Lösung, was der Lane-Client bisher noch nicht kann. 4. **Bestätigen.** Die Transaktion bestätigt sich auf Solana; die EVM-Ansicht zieht kurz danach nach (das Tooling prüft den Nonce, bevor der nächste Call gesendet wird). ### NUR ATOMAR — die harte Grenze des Pfads `DoTxUnsigned` ist **eine EVM-Transaktion, die innerhalb einer Solana-Transaktion ausgeführt wird** durch Rome's atomare VM. Die iterative VM — diejenige, die eine einzelne EVM-Ausführung über mehrere Solana-Transaktionen hinweg staget — ist über diesen Pfad noch nicht erreichbar, daher **kann ein Call, der nicht atomar hineinpasst, diesen Pfad überhaupt nicht nehmen.** Es gibt keinen Fallback, auf den man ausweichen könnte, und es sollte auch keiner hinzugefügt werden; die Lösung für einen Call, der nicht passt, ist ein kleinerer Call. Zwei Dinge werden häufig dafür gehalten, und keines davon ist es: * **Der v0+-Lookup-Table-Fallback** ist eine größere *Hülle*, nicht eine andere Ausführung: dieselbe einzelne Instruktion, verpackt in ein Transaktionsformat mit Platz für weitaus mehr Account-Keys. Gemessen heute braucht der Storefront-Kauf das nicht (1.061 von 1232 Bytes), und ein Call, der es täte, wäre dennoch atomar. * **Eine mehrstufige Reise ist keine mehrgliedrige Ausführung.** Blooms `Run` nennt seine Schritte *Legs* — erst genehmigen, dann kaufen — und jeder ist eine **vollständige Transaktion, separat signiert, für sich genommen atomar**. Rome nennt die Stücke EINER aufgeteilten Ausführung ebenfalls Legs. Diese App hat das erste und darf niemals nach dem zweiten fragen. Das Wort kollidiert; die Mechanismen nicht. Jeder Ablauf in der Tabelle unten ist eine atomare Transaktion, und der schwerste nutzt nur etwas mehr als die Hälfte des Compute-Limits pro Transaktion — die Grenze ist also für alles, was Bloom heute tut, nicht nahe. Gemessen auf dem Rome-Devnet, je eine Signatur — beobachtete Spannen über zwei Chains: | Solana-Pfad-Ablauf | CU | | ---------------------------------------------------------------- | ---------- | | Gated-RWA-Transfer | \~339–381K | | wUSDC approve | \~189–191K | | Storefront-Kauf (approve + buy = 2 Sig. insgesamt) | \~730–796K | | Cash-Leg-Sweep zum eigenen Token-Konto der Wallet | \~42–54K | | Einfacher Value-Transfer | \~47K | | `TestApprover.approve` — Allowlist-Aufnahme, **wallet-signiert** | 220,794 | Zum Vergleich: Solanas Compute-Limit pro Transaktion beträgt 1,4 Mio. CU — der schwerste Bloom-Ablauf nutzt nur etwas mehr als die Hälfte davon. ## Verwahrung: warum die RWA beim synthetischen bleibt Die Designfrage, die jedes genehmigungspflichtige Asset beantworten muss: *kann das Token aus dem Compliance-Perimeter entweichen?* Auf dem Solana-Pfad ist die Antwort strukturell, nicht politisch: * **Die RWA ist im EVM-State verankert.** Ihre Salden sind Speicher in den Accounts des Rome-EVM-Programms. Es gibt **kein SPL-Mint** dafür, keine Token-Account-Repräsentation, nichts Solana-Natives, das verschoben werden könnte. (Das ist absichtlich — eine gewrappte/gespiegelte Version wäre die Hintertür.) * **Die Solana-seitige Infrastruktur kann es nicht anfassen.** Die assetverschiebenden Legs des Pfads (`create_ata`, SPL-Transfers, Sweeps) operieren auf SPL-Token-Accounts; EVM-Speichersalden haben keinen solchen Account. Es gibt keine Instruktion, die einen EVM-Saldo in ein Solana-Token-Konto verschiebt. * **Nur die Solana-Signatur des Eigentümers steuert den synthetischen**, und jede Bewegung, die sie ausdrücken kann, ist ein Aufruf an den Token-Contract — der das Allowlist-Gate durchsetzt — sodass ein Transfer an eine nicht auf der Whitelist stehende Adresse identisch revertiert, egal ob er mit einem EVM-Schlüssel oder einem Solana-Schlüssel signiert wurde. * **Das Cash-Leg ist die bewusste Ausnahme.** wUSDC (Erträge, Verkaufserlöse) ist SPL-gestützt und *sollte* den Rundlauf machen: Das Exit-Leg (`transfer_spl`) verschiebt es vom synthetischen in das eigene zugehörige Token-Konto der Wallet, End-to-End verifiziert. Asset bleibt im Perimeter; Cash fließt frei. Zwei praktische Konsequenzen, klar gesagt: Eine Solana-Wallet-Oberfläche wird den RWA-Bestand nicht anzeigen (es gibt kein SPL-Token zum Auflisten) — die Bloom-App ist die Positionsoberfläche; und ein verlorener Solana-Schlüssel wird über den Prozess des Emittenten wiederhergestellt ([COMPLIANCE.md](/de/apps-auf-rome/bloom/compliance.md#issuer-powers-transfer-agent-shaped)), nicht indem das Asset außerhalb des normalen Pfads verschoben wird — genau das ist die Eigenschaft, die ein genehmigungspflichtiges Asset will. --- # 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/lanes.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.