> 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/getting-started-1/one-market.md).
# One market
Rome makes EVM and Solana one market. EVM apps for Solana wallets, Solana programs for EVM users, assets moving both ways, and your own market.
Rome makes EVM and Solana one market.
Rome runs EVM chains inside Solana. Solidity apps sit next to Solana programs and share Solana's state. Four capabilities follow.
## 1. EVM apps, Solana wallets
A Solana wallet gets an EVM address derived from its own key and signs with that key, so one deployment of a Solidity app serves both kinds of wallet.
Example: A Solana user connects on a lending protocol's own website and borrows, with no separate version of the app.
## 2. Solana programs, EVM users
A Solidity contract calls any Solana program in one atomic Solana transaction, and ports reach EVM users on other chains.
Example: With Portus, a user on Base or Polygon lends USDC into Kamino on Solana and withdraws to the same wallet, signing at home.
## 3. Assets both ways
On testnet, [Solgate](/apps-on-rome/solgate.md) connects Solana assets to AggLayer EVM chains in both directions. SPL token registration is permissionless, and EVM tokens arrive in Solana wallets as real SPL tokens. USDC uses CCTP.
Example: A token issued on Solana is held by an EVM user, and a token issued on an EVM chain is held by a Solana key.
## 4. Your own market
Any team launches its own Rome chain with its own token as gas and its own fee policy, sharing Solana's state.
Example: A team opens a chain where users pay gas in its token, use its apps and reach Solana programs and liquidity.
## Where this goes
We are building toward every EVM chain connected to Solana.
We are building toward every token usable on both sides, with permissionless and trustless movement.
We are building toward every app open to both worlds, with one signature per action.
We are building toward EVM and Solana order flow in shared pools, and protocols that compose in one atomic action.
We are building toward every team running its own market, with proved EVM rollups settling on Solana.
We are building toward Canton in the same market.
We are building toward one asset that carries its access rules across EVM and Solana holders.
## Live now
Live on mainnet: the Rome EVM, Rubicon, the Rome Bridge, Portus, the Oracle Gateway (Pyth prices for EVM contracts), Civitas, Arena.
On testnet: Solgate, Rome DEX, Teller, Aave, Uniswap, Aerarium (Compound), Cardo, Bloom.
Ostia runs on Canton DevNet.
## Start here
For users: connect the wallet you already have and use Rome apps. Solana wallets work as they are.
For builders: read [What is Rome?](/getting-started-1/what-is-rome.md) and the [Quickstart](/getting-started-1/quickstart.md), deploy your Solidity app on Rome, and join [Arena](https://arena.mainnet.romeprotocol.xyz) to build with the program.
---
# 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 by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://docs.rome.builders/getting-started-1/one-market.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
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.
