> 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/developer-guides/deploy-solidity.md). # Deploy Solidity Contracts Deploy Solidity smart contracts on Solana with Hardhat or Foundry — Rome network configuration, funded accounts, and step-by-step deployment. This guide covers deploying Solidity smart contracts on Rome EVM using Hardhat and Foundry. ## Prerequisites * Node.js v22.13+ (Hardhat) or Foundry installed * A funded Rome EVM address (see [Quickstart](/getting-started/quickstart.md)) * Your private key exported as an environment variable ```bash export PRIVATE_KEY="0xYOUR_PRIVATE_KEY" ``` ## Network Configuration | Network | RPC URL | Chain ID | Explorer | | --------------------- | ------------------------------------------- | -------- | -------------------------------------- | | Hadrian (testnet) | `https://hadrian.testnet.romeprotocol.xyz/` | `200010` | `via-hadrian.testnet.romeprotocol.xyz` | | **Rubicon (mainnet)** | `https://rubicon.mainnet.romeprotocol.xyz/` | `7531` | `via-rubicon.mainnet.romeprotocol.xyz` | Gas is USDC on every network. On Hadrian you get it by bridging test USDC or wrapping from a Solana devnet wallet ([Faucets](/resources/faucets.md)); on Rubicon by bridging USDC from Ethereum with the [Rome Bridge](https://bridge-api.mainnet.romeprotocol.xyz/). Deploy to Rubicon with the same artifacts you tested on Hadrian — only the chain id and the wrapper addresses differ. ## Hardhat ### Setup ```bash mkdir my-rome-project && cd my-rome-project npx hardhat --init ``` Accept the defaults (Hardhat 3, current directory, TypeScript + viem template); dependencies install automatically. ### hardhat.config.ts ```typescript import hardhatToolboxViemPlugin from "@nomicfoundation/hardhat-toolbox-viem"; import { configVariable, defineConfig } from "hardhat/config"; export default defineConfig({ plugins: [hardhatToolboxViemPlugin], solidity: { profiles: { default: { version: "0.8.28" }, production: { version: "0.8.28", settings: { optimizer: { enabled: true, runs: 200 } }, }, }, }, networks: { hadrian: { type: "http", chainType: "l1", chainId: 200010, url: "https://hadrian.testnet.romeprotocol.xyz/", accounts: [configVariable("PRIVATE_KEY")], }, rubicon: { type: "http", chainType: "l1", chainId: 7531, url: "https://rubicon.mainnet.romeprotocol.xyz/", accounts: [configVariable("PRIVATE_KEY")], }, }, }); ``` `configVariable("PRIVATE_KEY")` resolves from the environment (or the encrypted keystore — `npx hardhat keystore set PRIVATE_KEY`). ### Deploy ```bash npx hardhat run scripts/deploy.ts --network hadrian ``` ### Verify on Block Explorer ```bash npx hardhat verify --network hadrian 0xCONTRACT_ADDRESS ``` Needs the Sourcify verifier config from [Verify Contracts](/developer-guides/verify-contracts.md) in your `hardhat.config.ts`. ## Foundry ### Setup ```bash forge init my-rome-project cd my-rome-project ``` ### Deploy ```bash # Testnet forge create --rpc-url https://hadrian.testnet.romeprotocol.xyz/ \ --private-key $PRIVATE_KEY \ src/Counter.sol:Counter ``` ### Call Deployed Contract ```bash # Read cast call 0xCONTRACT_ADDRESS "number()" \ --rpc-url https://hadrian.testnet.romeprotocol.xyz/ # Write cast send 0xCONTRACT_ADDRESS "increment()" \ --rpc-url https://hadrian.testnet.romeprotocol.xyz/ \ --private-key $PRIVATE_KEY ``` ## Using the Rome Solidity SDK For contracts that interact with Solana programs, use the interfaces from the public [`rome-solidity`](https://github.com/rome-protocol/rome-solidity) repo. It is installed from GitHub, not from npm: ```bash # Hardhat / npm npm install github:rome-protocol/rome-solidity # Foundry forge install rome-protocol/rome-solidity # then in foundry.toml, under [profile.default]: # remappings = ["@rome-protocol/rome-solidity/=lib/rome-solidity/"] ``` Contracts beyond `interface.sol` and the oracle interfaces (the ERC-20 wrappers and factory, for example) import OpenZeppelin. With npm it comes along as a dependency. With Foundry, also run `forge install OpenZeppelin/openzeppelin-contracts` and add the remapping `@openzeppelin/contracts/=lib/openzeppelin-contracts/contracts/`. With npm, the package installs as `@rome-protocol/rome-solidity`, so the import below resolves from `node_modules`. With Foundry, the remapping makes the same import resolve from `lib/rome-solidity`. ```solidity // SPDX-License-Identifier: MIT pragma solidity ^0.8.28; import {ICrossProgramInvocation, IHelperProgram} from "@rome-protocol/rome-solidity/contracts/interface.sol"; contract MyRomeContract { IHelperProgram constant Helper = IHelperProgram(0xFF00000000000000000000000000000000000009); ICrossProgramInvocation constant Cpi = ICrossProgramInvocation(0xFF00000000000000000000000000000000000008); // Transfer an SPL token from the caller's PDA function moveSpl(address to, uint64 tokens, bytes32 mint) external { Helper.transfer_spl(to, tokens, mint); } // Invoke any Solana program via CPI function callSolanaProgram( bytes32 programId, ICrossProgramInvocation.AccountMeta[] calldata accounts, bytes calldata data ) external { Cpi.invoke(programId, accounts, data); } } ``` ## Bring an existing protocol Any Solidity contract deploys on Rome unmodified — a compliance contract, a DeFi protocol, or an existing hardened application. The one thing that is not in your contract is the **one-time wrapper grant**: a user who moves SPL-wrapper tokens (wUSDC and the like) through your contract has to grant that token's wrapper the right to move their tokens once, before the first `transferFrom`. Without it the transfer reverts with SPL error `0x4`. Check `isEnabled(user)` on the wrapper and see [One-time grant per wallet](/core-concepts/token-interop.md#one-time-grant-per-wallet); your front end sends the grant, your contract does not change. Two production examples you can fork and deploy with the same Hardhat / Foundry flow above: * [**compound-on-rome-comet**](https://github.com/rome-protocol/compound-on-rome-comet) — canonical Compound v3 (Comet), standard Foundry. * [**rome-aave-v3**](https://github.com/rome-protocol/rome-aave-v3) — canonical Aave v3. Both gain Solana execution and CPI composability with no contract changes; their users make the one-time wrapper grant described above before the first deposit. ## Gas Let your tooling estimate gas (`eth_estimateGas`; Hardhat, `forge create` and `cast` all do) and never hardcode `21000`. On Rome most of a write's cost is creating Solana accounts, such as a deployed contract, a new token account or a never-used recipient, and the estimate includes them. For a call that makes Solana CPIs the estimate can come out low, so keep a margin. Rome charges the gas actually used. Measured on Hadrian, deploying a 10-byte contract estimated and used 1,147,921 gas, and a native transfer to an existing address estimated 21,000 and used 10,001. A real contract costs more, so estimate your own deploy. The [JSON-RPC page](/reference/json-rpc.md#gas-is-solana-derived-estimate-dont-hardcode) has the measured table. ## Deployment Constraints | Constraint | Limit | Notes | | ---------------------- | ------------------ | ------------------------------------------------------------ | | Max contract size | 24 KB | Same as Ethereum (EIP-170, 24,576 bytes) | | Transaction size limit | 80 KB per holder | Large deploys are split across holder accounts transparently | | Compute budget | \~1.4M CU (atomic) | Use iterative mode for heavy contracts | | Solidity version | 0.8.28 recommended | Earlier versions work but 0.8.28 matches the SDK | ## Common Errors | Error | Cause | Fix | | -------------------------------------------------------------------- | ---------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `insufficient funds for gas` | EVM address has no gas token | Hadrian: bridge test USDC in with the [Rome Bridge](/apps-on-rome/bridge-api.md) (see [Quickstart](/getting-started/quickstart.md), step 2); Rubicon: bridge real USDC in with the [Rome Bridge on mainnet](https://bridge-api.mainnet.romeprotocol.xyz/) | | `nonce too low` | Stale nonce in wallet | Reset MetaMask account or specify nonce manually | | `execution reverted` | Contract logic failed | Debug with `eth_call` or `forge test --fork-url` | | `execution reverted` with SPL error `0x4` when moving wrapper tokens | The user has not made the one-time wrapper grant | Check `isEnabled(user)` on the wrapper and send `approve_spl` once ([details](/core-concepts/token-interop.md#one-time-grant-per-wallet)) | | `transaction underpriced` | Gas price below minimum | Increase gas price in transaction | | A transfer or deploy fails with a fixed gas limit | A hardcoded limit such as `21000` is below what creating the Solana accounts costs | Remove it and use `eth_estimateGas` | ## What's Next * [Open your contract to Solana users](/developer-guides/open-to-solana-users.md) — let Solana wallet users call what you just deployed * [Call Solana from EVM](/developer-guides/call-solana-from-evm.md) — use CPI precompiles to interact with Solana programs * [Verify Contracts](/developer-guides/verify-contracts.md) — publish your source to the block explorer --- # 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/developer-guides/deploy-solidity.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.