> 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/apps-on-rome/bloom/evidence-investor.md).

# Evidence — an investor

The [Investing](/apps-on-rome/bloom/investing.md) screenshots are a real buyer, twice over — **once from an EVM wallet and once from a Solana wallet, buying the same Solidity asset** (Mineral Vault I, `ARCV`) on Hadrian (chain `200010`). Every action is a transaction you can open. The link is the claim.

* **Asset:** [`0x2b13ba16a429bf630f94882e477fe775d34b7c74`](https://via-hadrian.testnet.romeprotocol.xyz/address/0x2b13ba16a429bf630f94882e477fe775d34b7c74)
* **Storefront:** [`0x9326a00dd1cd4f3f1800fc849c3c58715fc5061a`](https://via-hadrian.testnet.romeprotocol.xyz/address/0x9326a00dd1cd4f3f1800fc849c3c58715fc5061a)
* **Paid in:** wUSDC [`0xd4cc34b67c805d472b5a709a22a1037f6b16ef28`](https://via-hadrian.testnet.romeprotocol.xyz/address/0xd4cc34b67c805d472b5a709a22a1037f6b16ef28)

## The EVM lane — a wallet buys at its own address

An EVM wallet holds the asset at its own address, and a buy is the ordinary two-step approve-then-buy. The eligibility gate is checked on the token first — the buyer is allowlisted, then buys.

Buyer: [`0x5667b3700b4a021Cc475157cbf3dE2d756Fae597`](https://via-hadrian.testnet.romeprotocol.xyz/address/0x5667b3700b4a021Cc475157cbf3dE2d756Fae597)

| # | What it did                                                              | Transaction                                                                                                                                 |
| - | ------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------- |
| 1 | Allowlist the buyer (the test-wiring stand-in for the issuer's approval) | [`0xf8180aef…5c29c86d`](https://via-hadrian.testnet.romeprotocol.xyz/tx/0xf8180aef8ba3203750a4ae63eea215c9e5891cd147f7272a359f512c5c29c86d) |
| 2 | Approve wUSDC to the storefront                                          | [`0x0f7229ea…7c2669e5`](https://via-hadrian.testnet.romeprotocol.xyz/tx/0x0f7229eab17d8d28907a3bc9239f62367abed528fde09bd7cc0ad10f7c2669e5) |
| 3 | Buy the asset                                                            | [`0xe099d892…3792f6de`](https://via-hadrian.testnet.romeprotocol.xyz/tx/0xe099d8921225563cf0fbf0e4fd1e97037f50bcbebf41f2acea21696f3792f6de) |

After the buy, the eligibility card reads **Permitted** and the holding shows in Positions — the `invest-permitted` and `positions` screenshots in the guide are this buyer, after these transactions.

## The Solana lane — a wallet buys at its derived address

This is the one that carries the whole thesis: **a Solana wallet buys the same Solidity asset, with no bridge and no second token.** There is no EVM key anywhere — the buyer signs with their Solana key, and the asset is held at the EVM address *derived* from it.

* **Solana signer:** `55R41dbRU13QhLpAgha1841wR5M6sAcZhXd4S1LGupBn`
* **Derived holding address:** [`0xd868eec27e47376e739d0a3555f81b7657faa322`](https://via-hadrian.testnet.romeprotocol.xyz/address/0xd868eec27e47376e739d0a3555f81b7657faa322) — `keccak256(pubkey)[12..32]`

Each step is a `DoTxUnsigned`: an EVM transaction executed inside **one Solana transaction**, authorised by the Solana signature. The buy is the same two legs, each its own Solana transaction:

| # | What it did                                                | Solana transaction                                                                                                                                         | Compute   |
| - | ---------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- | --------- |
| 1 | Approve wUSDC to the storefront (from the derived address) | [`3ohASbQc…3ad5p`](https://explorer.solana.com/tx/3ohASbQcv3L7qPbJfccoZQeN1KX1yPBy4nycdSU6PVWD8DxrpfGgHVymbHHfkLWC5727xE3XJTzf1Fyf5ct3ad5p?cluster=devnet) | \~191K CU |
| 2 | Buy the asset                                              | [`5CdSWWh3…3UkJ`](https://explorer.solana.com/tx/5CdSWWh3A72jy2M843F3udYjiHr2UUM82FrfxjcNJja8RZrj6AQH7mHCMmZafgMFBUGBCMriXQiS7jM36rQZ3UkJ?cluster=devnet)  | \~737K CU |

The buyer paid the transaction fee in **lamports from their own Solana wallet**; the derived address never held SOL. The `positions-solana` screenshot in the guide — *"Held for your Solana key"*, the custody chain, and the ARCV holding — is this signer, after these transactions.

> **The same asset, the same allowlist, either wallet world.** The EVM buyer and the Solana buyer bought the identical Solidity token, gated by the identical on-chain allowlist, priced in the identical wUSDC. The only difference is which key signed and which address holds — which is the entire point of the two lanes, proven here rather than asserted. The mechanics are in [LANES.md](/apps-on-rome/bloom/lanes.md); the compliance model is in [COMPLIANCE.md](/apps-on-rome/bloom/compliance.md).


---

# 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/apps-on-rome/bloom/evidence-investor.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.
