> 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/canton-zk-evm/trust-model.md). # Trust model and limits The checks, authorities, custody assumptions and limits of the Ostia early release. Ostia is an early release on a local test network. It has one builder, one operator and one confirmer. The code and ZisK 1.3.1-alpha have not been audited. tROME is a test coin with no value. Do not use this release for anything of value. This page describes commit `a84e84e439a5cc669c0ae61facf7c8c995d9d564`. Read the full [design](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/docs/DESIGN.md) and [security policy](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/SECURITY.md). ## Who checks what | Part | Check or authority | | ---------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Guest | Validates the EVM block and rejects a chain configuration other than Ostia's compiled rules. | | Sidecar `verify` | Checks the proof, pinned programVK and rootC, proven block hash, header and transaction list. | | Sidecar `legs` | Checks the gateway's account and storage proofs and compares the ordered attached legs with the proven gateway hash. | | Daml `Advance` | Checks the sidecar's answers, parent, next block number, gas cap and the contracts used by the legs. It settles the legs and creates the next head and block record. | | Canton | Orders blocks through the consumption of the chain's one state contract and commits the transaction's changes together. It rejects differing external-call answers. | | Builder | Selects transactions, checks the Canton contracts it can see, obtains a proof and submits the block. It cannot finalize a block itself. | One sidecar runs beside each confirming participant, including the operator's participant. Each sidecar computes its answers solely from the input sent in the external call. Daml compares their answers; it does not perform the cryptographic proof check itself. The [sidecar README](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/sidecar/README.md) and [Daml README](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/daml/README.md) give the checks and authority requirements. ## What the proof fixes The pinned program key identifies the guest and its chain rules. The proof commits to a block hash. Checking its header binds the state root and transaction root. Account and storage proofs then bind the gateway's recorded leg hash to that state root. The attached legs must have the same fields and order as those the gateway recorded. Removing a leg, adding one or changing a recipient, amount, token or id fails the hash comparison. A block with no legs must prove that absence too. The leg comparison also relies on Keccak-256's collision resistance. The chain record's genesis state root fixes the gateway code. The gateway contract has no owner, admin key, upgrade or pause. The Canton party still has custody authority over the tokens it holds. ## Operator, confirmer and gateway authority The operator and gateway propose the chain's genesis, pins, gas cap and builder. The confirmer accepts the proposal. It is expected to compare the pins and genesis gateway code with its own build. The supplied local scripts propose matching values and immediately accept the proposal on the confirmer's behalf. The operator, confirmer and gateway sign `ZkChain`. They are the chain's root of trust. Deposit and withdrawal settlement choices require all three. Payment settlement requires the operator and confirmer. `Advance` provides their joint authority under the Daml design. The builder alone cannot exercise the settlement choices. The gateway party holds the Canton tokens backing wrapped tokens on the EVM. It is hosted on the operator's participant. Whoever runs that participant can move the locked tokens outside the withdrawal rules. The gateway contract's lack of an admin key does not constrain that Canton party's ability to act through its participant. Token registration is another trust decision. The operator and gateway propose the mapping from a Canton instrument to an EVM wrapped token, and the confirmer accepts it. The gateway executes the registered token's Daml transfer code with its own authority. The [network README](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/network/README.md#the-canton-network) describes the participant hosting and registration checks. ## What can stop a block To include a leg, the builder needs read access to its requests, terms, acceptances, allocations, token registrations and gateway holdings. It leaves out a transaction whose Canton contracts it cannot see. An allocation can be taken back after the builder checks it or after proving. A token registry can also refuse settlement under its own rules. Canton then refuses the block and nothing commits. For a registry refusal the builder could not predict, the next run needs `--exclude`; the builder does not remember that refusal across runs. Each builder run handles one block; it does not loop over successive blocks. The builder does not cap execution steps before proving. If the prover cannot finish a block, the builder run stops. The [builder README](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/builder/README.md#not-here) records these limits. ## What this release does not provide The local network keeps no state between runs. It has no Ledger API authentication or TLS and is intended for one machine. The network uses pinned Canton 3.6 snapshots and a snapshot Daml compiler for the external call. Their versions and hashes are in [PINS](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/PINS). Multiple builders, forced inclusion, public Canton deployment, privacy and custody requiring more than the operator's participant are outside this release. There are no throughput or block-time targets. The recorded demo used the same sidecar implementation on both confirming participants, on the same machine as Canton. The reader can re-check block proofs, but `BlockRecord` does not carry the settled legs. The browser's Verify button checks the proof, header and transactions; it does not repeat the Canton leg settlement checks. ## Report a security problem Use GitHub's private vulnerability reporting for `canton-zk-evm`: open the repository's Security tab and choose **Report a vulnerability**. Do not open a public issue for a security problem. Include the affected component, commit, steps to reproduce and observed result. Attach the proof or block if it is part of the finding. The [security policy](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/SECURITY.md) defines the scope. There is no bug bounty. --- # 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/canton-zk-evm/trust-model.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.