> 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/reference/contract-addresses.md).

# Contract Addresses

Precompiles, program IDs, and per-chain deployed contract addresses.

Precompile addresses are built into the Rome EVM program and are identical on every chain. Per-chain deployed contracts are **canonical in the** [**Rome registry**](https://github.com/rome-protocol/rome-registry/tree/main/chains). The Hadrian table below lists the headline contracts that the registry (release v0.2.0) marks `live`; the registry is the single source of truth, and a contract can be redeployed after this page was written. See [Reading the contracts list](#reading-the-contracts-list) for how to pick the live address in code.

## Precompiles (all chains)

Standard Ethereum precompiles, with mainnet-equivalent semantics:

| Precompile    | Address                                      |
| ------------- | -------------------------------------------- |
| ecrecover     | `0x0000000000000000000000000000000000000001` |
| SHA-256       | `0x0000000000000000000000000000000000000002` |
| RIPEMD-160    | `0x0000000000000000000000000000000000000003` |
| identity      | `0x0000000000000000000000000000000000000004` |
| modexp        | `0x0000000000000000000000000000000000000005` |
| BN254 add     | `0x0000000000000000000000000000000000000006` |
| BN254 mul     | `0x0000000000000000000000000000000000000007` |
| BN254 pairing | `0x0000000000000000000000000000000000000008` |
| blake2f       | `0x0000000000000000000000000000000000000009` |

Rome non-EVM precompiles, for reaching into Solana (interfaces in [`rome-solidity/contracts/interface.sol`](https://github.com/rome-protocol/rome-solidity/blob/master/contracts/interface.sol)):

| Precompile     | Address                                      | Interface                 | Purpose                                       |
| -------------- | -------------------------------------------- | ------------------------- | --------------------------------------------- |
| System         | `0xFF00000000000000000000000000000000000007` | `ISystemProgram`          | PDA derivation, base58 conversion             |
| CpiProgram     | `0xFF00000000000000000000000000000000000008` | `ICrossProgramInvocation` | Arbitrary CPI + cross-state reads             |
| HelperProgram  | `0xFF00000000000000000000000000000000000009` | `IHelperProgram`          | ATA/PDA creation, SPL transfers, gas↔lamports |
| Withdraw       | `0x4200000000000000000000000000000000000016` | `IWithdraw`               | Withdraw SOL/SPL from EVM to Solana           |
| SystemCached   | `0xFF00000000000000000000000000000000000004` | `ISystemCached`           | Cached-track System helpers                   |
| SplCached      | `0xFF00000000000000000000000000000000000005` | `ISplCached`              | Cached-track SPL operations                   |
| ASplCached     | `0xFF00000000000000000000000000000000000006` | `IAssociatedSplCached`    | Cached-track ATA operations                   |
| WithdrawCached | `0xFF0000000000000000000000000000000000000b` | `IWithdrawCached`         | Cached-track withdraw                         |

A contract uses one track — legacy (`SplCached` off) or cached — consistently; the two are not mixed within a call.

## Program IDs

rome-evm programs (the Solana program that runs the EVM), per Rome network:

| Network           | Program ID                                    |
| ----------------- | --------------------------------------------- |
| Hadrian (testnet) | `RPTWwELXAY4KC9ZPHhaxp7Sq1hHtU3HNEgLbSegCcWf` |
| Rubicon (mainnet) | `RomePq9X3iAoTr813HR7uRarafFDUJty6GdiEceYpzX` |

Well-known Solana programs (same as anywhere on Solana):

| Program                 | ID                                             |
| ----------------------- | ---------------------------------------------- |
| SPL Token               | `TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA`  |
| SPL Token-2022          | `TokenzQdBNbLqP5VEhdkAS6EPFLC1PHnBqCXEpPxuEb`  |
| Associated Token        | `ATokenGPvbdGVxr1b2hvZbsiqW5xWH25efTNsLJA8knL` |
| System Program          | `11111111111111111111111111111111`             |
| Metaplex Token Metadata | `metaqbxxUerdq28cj1RbAWkYQm3ybzjb6a8bt518x1s`  |

## Rome ZK EVM on Solana devnet

These v0.3.0 programs are shared by operator-run ZK EVM chains on Solana devnet. The [tagged program list](https://github.com/rome-protocol/solana-zk-evm/blob/v0.3.0/deploy/rollup/programs.devnet.json) is the source for these IDs.

| Program       | ID                                             |
| ------------- | ---------------------------------------------- |
| zk-inbox      | `28948c2Qt1QtG2XJA823ytzCfj7U5cNNm3FuM2KoXsAa` |
| zk-settlement | `8anSjJZu5vgfNbESPLoKudVBNEraDZASwKJnkDLTCaGo` |
| veritas       | `2cLGd9FKC7TiZrEHCvpw291AwXNcGgP9nDT4W3PHLe5k` |
| zk-bridge     | `27TbMDUyVynpFpqeKygpUMcDzWKHfW4k9aRN5yCysLEQ` |

Node image: `ghcr.io/rome-protocol/rome-zk-evm:v0.3.0`.

## Deployed contracts — Hadrian (testnet, 200010)

Headline contracts, taken from the `live` entries of the [registry](https://github.com/rome-protocol/rome-registry/tree/main/chains/200010-hadrian) (v0.2.0). The full set (SPL wrappers, Uniswap V2/V3/V4, Aave, oracle feeds) is in the registry.

| Contract             | Address                                      |
| -------------------- | -------------------------------------------- |
| ERC20SPLFactory      | `0x37c13e4ff21fb914eb24014dcbd0f8dbeaa31078` |
| Multicall3           | `0xb7180d3c46632b582b99d9af3daae394fab9ae4c` |
| OracleAdapterFactory | `0x52b008771fc95b4674a4f3533570b3d223f27f68` |
| BatchReader          | `0x2869f0a96572e7fb15036656e9a32fd17346499b` |
| RomeBridgeWithdraw   | `0x6eeacb4e6006b7a29c8141f69b6c75346dedec73` |
| MeteoraDAMMv1Factory | `0xd68b355f62643de0ec40243cba8f699f959ea3c4` |
| UniswapV3Factory     | `0xD9E323088561D40267767b52252595ea9cF1D5bD` |
| UniswapV4PoolManager | `0x8a281Be9B5173B2F52328437eAa0d272791707f7` |

## Deployed contracts — Rubicon (mainnet, 7531)

Headline contracts (the public registry publishes the Hadrian set today; the Rubicon set is listed here). Wrappers: `wUSDC` `0x0952d233b0c254cd375f3bfb3e5869c1a906f9b3`, `wETH` `0x01e8b3573da1d4b7b4b1ce0932cf07c8af0c92e9`, `wSOL` `0xc4e29e0f726a906e93277cbbc37bf27a9848a113`.

| Contract                        | Address                                      |
| ------------------------------- | -------------------------------------------- |
| ERC20SPLFactory                 | `0x4068aa7482dc15e9f78e22fbe0f884531c83ae6e` |
| Multicall3                      | `0xd6e0b13ea70aea0d44db083544f01d8b7693a759` |
| OracleAdapterFactory            | `0x6a1340dd86c3951b6f13d9001b3951d56a2fe581` |
| BatchReader                     | `0x580dc0ecb226530ee8a90b57e0f0cd2555fb4f0f` |
| RomeBridgeWithdraw              | `0xceea191761cdba2fc589996d7dd096e57db29c84` |
| WETH9                           | `0x8dc8bf908efa4511f71a9e2ed95f46a70507f1ae` |
| UniswapV2Factory                | `0x23af4d2065d24b42a1a17f22b963c9216d0a1dc2` |
| UniswapV2Router                 | `0x445d7af7888db44a4904b63336cc43446dfb37f7` |
| UniswapV3Factory                | `0x02aed7762fdc8bae826e7ee0ac2d2e1f754ba025` |
| SwapRouter (V3)                 | `0x680b7645c63421e33584a02aca91be6642d3d034` |
| NonfungiblePositionManager (V3) | `0xfb132adf6b7d811408f3639e91c8f638bddd6123` |
| QuoterV2 (V3)                   | `0x1d68d09dcc3a8c1b9aa8f0e2b138205c04bad4a7` |

## Reading the contracts list

Each chain folder in the registry has a `contracts.json`. It is a list of contracts. Every entry has a `name` and a `versions[]` list, and each version has an `address`, a `version` and a `status` of `live`, `deprecated` or `retired`. A contract that was redeployed keeps its old versions in the list, so the first or the last item is not necessarily the one to use. Pick the version whose `status` is `"live"`. A few entries (Hadrian's Aave contracts) have more than one live version, so filter on `status` and choose on purpose rather than taking the first match.

```ts
import { getContracts } from "@rome-protocol/registry";
const factory = getContracts(200010).find((c) => c.name === "ERC20SPLFactory");
const address = factory.versions.find((v) => v.status === "live").address;
```

`getContracts(chainId)` returns the list for that chain, or `null` if the chain is not published. Some entries have no live version at all (Hadrian's `RomeswapMinimalRouter` is one), so check that the `find` found something before reading `.address`. The registry package is installed from GitHub, not npm: `npm install github:rome-protocol/rome-registry#v0.2.0`.

## Environments

| Environment       | Chain ID | RPC                                | Status |
| ----------------- | -------- | ---------------------------------- | ------ |
| Rubicon (mainnet) | `7531`   | `rubicon.mainnet.romeprotocol.xyz` | Live   |
| Hadrian (testnet) | `200010` | `hadrian.testnet.romeprotocol.xyz` | Live   |


---

# 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/reference/contract-addresses.md?ask=<question>&goal=<user_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.