双通道

一次代币部署，两种钱包世界。两条路径都执行 相同的合约 并采用 相同的合规门控 ——它们唯一的区别在于由谁签名，以及交易如何到达链上。

EVM 路径

标准的以太坊工具链，保持不变：钱包签署一笔 EVM 交易，链的 JSON-RPC 端点接受它，代币合约执行允许名单限制。无需集成任何 Bloom 特定内容——受门控转账的实测成本约为 3.1M gas（Rome gas 以 USDC 计价；为便于对比，普通原生转账约为 1.48M gas）。

Solana 路径

Solana 钱包驱动相同的 EVM 合约 以原生方式——任何地方都不存在 EVM 密钥:

1. 身份。 用户在 EVM 侧的地址是 合成：按确定性方式派生为 keccak256(solana_pubkey)[12..32]。Rome EVM 程序会在链上根据交易的实际签名者派生它——它无法被伪造，而且不存在对应的 secp256k1 私钥，因此 只有 Solana 签名才能驱动这个地址.

2. 发现。 客户端向链的 RPC（rome_emulateCallAccounts）询问 EVM 调用将触及哪些 Solana 账户；仿真还会决定哪些账户可写（调用的 value 必须包含——接收方余额账户是否可写取决于它）。

3. 提交。 客户端构建一个 DoTxUnsigned 指令——一个 未签名的 由 Solana 签名授权的 EIP-1559 载荷——再加上计算预算指令（250KB 堆，1.35M CU），以及费用池账户发现所省略的内容。钱包只需签署一笔 Solana 交易；完成。

   在本次部署（2026-07-30）上测得的大小： 一次商店购买会展开为 22 个账户 并序列化为 1,061 字节 相对于 1232 字节的旧版上限——还剩 171 字节的余量，大约还能容纳 5 个账户。因此它今天并不需要查找表。若状态涉及更多内容——例如尚未创建的关联代币账户、首次持有者——仍可能超出该上限，而一旦超过 1232 字节，客户端就会回退为通过其为此目的创建的地址查找表来发送 v0 交易。

   这种回退对钱包来说代价很高： 每个 ALT 扩展分块以及 v0 重新提交，都是单独的一次 signTransaction，因此一次购买会变成三到四次提示。Hadrian 已经有一个持久化的 dApp 表保存着这些合约的账户——改为引用该表才是解决方案，而路径客户端目前还做不到。

4. 确认。 交易在 Solana 上确认；EVM 视图稍后片刻才跟上（工具会在发送下一次调用前轮询 nonce）。

仅限原子执行——该路径的硬边界

DoTxUnsigned 是 一笔在一笔 Solana 交易中执行的 EVM 交易 由 Rome 的原子 VM 执行。迭代 VM——即将一次 EVM 执行拆分到多笔 Solana 交易中分阶段完成的那种——目前还无法通过这条路径访问，因此 无法以原子方式容纳的调用根本不能走这条路径。 没有可用的回退方案，也不应新增；对于无法容纳的调用，解决办法就是把调用做得更小。

有两件事常被误认为是它，但两者都不是：

• v0 + 查找表回退 是一个更大的 封装，而不是不同的执行方式：它仍是同一条指令，只是装在一种可容纳更多账户密钥的交易格式中。今天测得的商店购买并不需要它（1,061/1232 字节），而即便需要，该调用也仍然是原子的。

• 多步骤旅程并不等同于多段执行。 Bloom 的 Run 将其步骤称为 legs ——先批准，再购买——而且每一步都是 一笔完整交易，分别签名，本身即原子。Rome 也把一次拆分执行中的各个片段称为 legs。这个应用只有前者，绝不能要求后者。术语会冲突；机制不会。

下表中的每一条流程都是一笔原子交易，其中最重的一条也只占每笔交易计算上限的略高于一半——因此，对 Bloom 目前所做的任何操作而言，这条边界都还很远。

在 Rome devnet 上测得，每项各需一次签名——以下为两条链上观察到的范围：

Solana 路径流程	CU
受门控的 RWA 转账	~339–381K
wUSDC 批准	~189–191K
商店购买（批准 + 购买 = 共 2 次签名）	~730–796K
现金腿清扫到钱包自身的代币账户	~42–54K
普通数值转账	~47K
TestApprover.approve ——允许名单准入， 由钱包签名	220,794

作为比较，Solana 的单笔交易计算上限为 1.4M CU——Bloom 最重的流程也只用了略高于一半。

托管：为何 RWA 保持在合成地址中

每一种受权限控制的资产都必须回答的设计问题： 代币会不会泄出合规边界？ 在 Solana 路径上，答案是结构性的，而非策略性的：

• RWA 驻留在 EVM 状态中。 其余额存储在 Rome EVM 程序的账户内部。这里没有 SPL 铸币 ，没有对应的代币账户表示，也没有任何 Solana 原生对象可供转移。（这正是刻意设计——若存在包装/镜像版本，那就成了逃逸通道。）

• Solana 侧的底层机制无法触及它。 该路径中用于资产转移的 legs（create_ata、SPL 转账、清扫）都作用于 SPL 代币账户；EVM 存储余额并没有这种账户。不存在任何可将 EVM 余额转移到 Solana 代币账户的指令。

• 只有所有者的 Solana 签名才能驱动该合成，而且它所能表达的每一种移动都是对代币合约的调用——而该合约会执行允许名单门控——因此，转账到未列入白名单的地址时，无论由 EVM 密钥还是 Solana 密钥签名，都会以相同方式回滚。

• 现金腿是刻意预留的例外。 wUSDC（收益、出售所得）由 SPL 支持，并且 应当 双向往返：退出腿（transfer_spl）将其从合成地址移至钱包自己的关联代币账户，并完成端到端验证。资产仍留在边界内；现金则可自由流动。

两项实际后果，直说如下：Solana 钱包 UI 不会显示 RWA 持仓（没有可列出的 SPL 代币）——Bloom 应用才是持仓展示界面；而丢失的 Solana 密钥则通过发行方流程恢复（COMPLIANCE.md），而不是通过带外转移资产——这正是受权限控制资产所需要的特性。