> 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/explorer.md). # Explorer Read Ostia's EVM blocks beside their Canton records and check a proof in the browser. The explorer combines reth's EVM data with Canton block records that it reads using the reader party's identity. It has block, transaction and address pages, a tROME faucet and a Verify button for checking a block in the browser. This page describes commit `a84e84e439a5cc669c0ae61facf7c8c995d9d564`. Read the full [explorer README](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/explorer/README.md). ## Read a block The block page shows its EVM data beside its Canton update id, record time and the operator and confirmer that signed its record. It compares reth's block hash, the record's hash and the hash of the recorded header. It also displays the program key, ZisK release and block hash read from the proof beside the explorer's expected values. A block being proven is not yet on Canton. A transaction may be waiting, being proven or final. The explorer does not show the block's Daml legs: `BlockRecord` does not carry them. The explorer keeps its index in memory. It rebuilds that index from Canton's records at startup. The supplied network also keeps those records in memory and loses them on restart. ## Check the proof in your browser Reading values from the proof does not verify it. Pressing Verify downloads a WebAssembly build of the sidecar's `verify` function and runs it on the recorded proof, header and transactions. The check verifies the PLONK proof under the pinned program key and ZisK release. It checks that the header hashes to the proven block hash and that the transactions match the header's transaction root. The panel also requires that block hash to match reth's hash for the block. The expected pins come from the explorer's status response. Verify runs the sidecar's block check; it does not run the separate `legs` check. The button is disabled while the block is being proven. After a check, the panel shows its result, duration and the module's download size. The duration excludes the download. See the [browser verifier README](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/explorer/verify/README.md). ## Use the tROME faucet The default payout is 1 tROME. Each address can request a payout once per 24 hours, and the faucet sends payouts at least 2 seconds apart. These limits are held in memory and reset when the explorer restarts. tROME has no value. The faucet sends a transaction to reth. It arrives in the next proven block, so the builder must run for a payout to become final. Neither starting the network nor starting the explorer runs the builder. The faucet's funded genesis must be prepared before the network starts. `explorer/run.sh setup` creates that funding and a fresh key for the run. `explorer/run.sh start` starts the container, and `explorer/run.sh stop` stops it. With no faucet key, the faucet is off. The full explorer guide has the startup sequence; the [demo guide](https://github.com/rome-protocol/canton-zk-evm/blob/a84e84e439a5cc669c0ae61facf7c8c995d9d564/demo/README.md#running-it) has the sequence that includes both the demo and faucet funding. ## Local access The container runs beside the chain on the same Linux machine with Docker and listens locally. The network has no Ledger API authentication. The explorer's code restricts its reads to the reader party, but anyone who can reach that participant can also read records for its other parties. The explorer README says not to give it a public address under these conditions. --- # 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/explorer.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.