> 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/resources/glossary.md).

# Glossary

Definitions of Rome and Solana terms used across these docs — ATA, CPI, PDA, VmAt/VmIt, holder accounts, SPL tokens, and more.

Rome-specific and Solana terms used throughout this documentation.

## A

**Allocation** — A Canton token set aside for a receiver and executor. In Ostia, `Advance` executes the allocation for a deposit or payment. The sender can take it back before settlement. See [Deposits, withdrawals and payments](/canton-zk-evm/deposits-withdrawals-payments.md).

**ATA (Associated Token Account)** — A deterministic token account for a given wallet + mint pair on Solana. Derived from the wallet pubkey, token mint, and ATA program.

**Atomic Execution (VmAt)** — EVM transaction mode where the entire execution completes within a single Solana transaction. Default mode for most operations.

## B

**Batch guest** — The ZisK program built for a chain's genesis. It checks a batch's inbox data and execution, then commits the public values that Solana settlement checks.

**BN254** — An elliptic curve used for ZK proof verification. Rome supports ecAdd (0x06), ecMul (0x07), and ecPairing (0x08) precompiles.

**Borsh** — Binary Object Representation Serializer for Hashing. Solana's standard serialization format. Little-endian byte ordering.

## C

**Canton** — Orders Ostia's blocks and commits each proven EVM block with its Canton actions in one transaction. See [Canton ZK EVM](/canton-zk-evm/canton-zk-evm.md).

**Chain ID** — A unique identifier for each EVM environment on Rome. Each application gets its own chain ID.

**CPI (Cross-Program Invocation)** — One Solana program calling another within the same transaction. How Rome EVM contracts interact with Solana programs.

**Compute Units (CU)** — Solana's equivalent of Ethereum gas. Each transaction has a compute budget; operations consume CU.

**Confirmer** — A signer of Ostia's chain record. Its participant runs a sidecar that checks block proofs and gateway legs through Canton's external call. See [Trust model and limits](/canton-zk-evm/trust-model.md).

## D

**Daml** — Used for Ostia's contracts on Canton: the chain's head, block records and the contracts that settle deposits, withdrawals and payments. See [How it works](/canton-zk-evm/how-it-works.md).

## E

**ERC20SPL** — An ERC-20 wrapper contract that reads balances from the underlying SPL token account on Solana. For a wallet the ERC-20 balance is the SPL balance; tokens held by a contract sit in the wrapper's escrow account and are tracked in its storage.

**ERC20SPLFactory** — A factory contract that deploys ERC20SPL wrappers for any SPL token mint.

**Exit prover** — The service that proves a withdrawal against a final root on Solana, then sends its vault payout.

**External call** — The Canton extension through which Daml calls each confirming participant's sidecar. Ostia uses it for the `verify` and `legs` checks. See [How it works](/canton-zk-evm/how-it-works.md).

## G

**Gateway** — In Ostia, the EVM contract that records a block's Canton legs and creates wrapped tokens. The separate gateway party on Canton holds the tokens that back the wrapped tokens on the EVM. See [Deposits, withdrawals and payments](/canton-zk-evm/deposits-withdrawals-payments.md).

## H

**Hercules** — The block indexer service. Monitors Rome EVM events on Solana and produces Ethereum-compatible block data.

**Holder Account** — An on-chain buffer (max 80 KB) that stores large EVM transactions exceeding the 4 KB Solana (v1) transaction limit.

## I

**Iterative Execution (VmIt)** — EVM transaction mode that splits execution across multiple Solana transactions, each step packing as many opcodes as fit in its compute budget (adaptive step size). Used for compute-intensive operations.

## L

**Lamports** — Smallest unit of SOL. 1 SOL = 10^9 lamports.

**Leg** — A Canton action recorded by Ostia's EVM gateway: a deposit, withdrawal or payment. The proven block and its legs settle together in `Advance`. See [Deposits, withdrawals and payments](/canton-zk-evm/deposits-withdrawals-payments.md).

## M

**Mollusk SVM** — Off-chain Solana VM emulator used by Rome Proxy for `eth_call` and gas estimation. Can execute arbitrary BPF programs.

## O

**Oracle Gateway** — Adapter contracts exposing Pyth and Switchboard price feeds through Chainlink's AggregatorV3Interface.

## P

**Participant** — A Canton node that hosts parties. In Ostia's local network, the operator and confirmer participants each run a sidecar, while the users participant hosts the test parties and reader. See [Run it locally](/canton-zk-evm/run-it-locally.md).

**Party** — A Canton identity hosted on a participant. Ostia's contracts name parties as signers, controllers or observers; the gateway party holds the locked Canton tokens. See [Trust model and limits](/canton-zk-evm/trust-model.md).

**Payer** — A Solana keypair that signs and pays for Solana transactions on behalf of EVM users. Managed by the Proxy.

**PDA (Program Derived Address)** — A deterministic Solana address derived from seeds and a program ID. No private key — the program "owns" the PDA.

**Proved root** — A state root posted with a ZisK proof checked by Solana settlement. For a permissionless Rome ZK EVM chain, it is final when posted.

**Proxy** — The Rome JSON-RPC server (port 9090) that translates Ethereum API calls into Solana transactions.

## R

**RheaTx** — A single EVM transaction on one rollup.

**RemusTx** — Multiple EVM transactions across rollups, executed atomically.

**RomulusTx** — EVM transactions + native Solana instructions, executed atomically.

**ResourceFactory** — SDK component that pools Solana keypairs and holder account indices for parallel transaction submission.

## S

**Sidecar** — The service beside each confirming participant that checks Ostia's proof, block data and gateway legs when Canton calls it. See [How it works](/canton-zk-evm/how-it-works.md).

**SPL Token** — Solana's standard token program. All fungible tokens on Solana (USDC, SOL, etc.) are SPL tokens.

**StateHolder** — An on-chain account that stores serialized VM state between iterative execution steps.

**Synchronizer** — Ostia's local Canton network has one synchronizer, made up of a sequencer and a mediator. All three participants connect to it. See [Run it locally](/canton-zk-evm/run-it-locally.md).

## T

**Token-2022** — Next-generation SPL token program with extensions (Transfer Hooks, Confidential Transfers, Permanent Delegates).

**Transfer Hook** — Token-2022 extension that invokes a program on every `transfer_checked` call.

**TxBuilder** — SDK component that builds Solana instructions from EVM transactions.

## V

**Verification key (programVK)** — The chain-specific guest identifier registered on Solana. Settlement accepts a proof only when its programVK matches an active entry for that chain.

## Z

**ZisK** — The proving system that runs a chain's batch guest and produces the proof checked by Rome ZK EVM settlement.


---

# 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/resources/glossary.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.