Ostia on Canton DevNet. Public introduction: November 9. Source.
Rome Protocol has introduced Ostia to Canton’s developer community, inviting builders to try an Ethereum-compatible environment that settles its blocks on Canton. Developers can deploy Solidity contracts and test transfers between the two environments using familiar browser wallets and development tools.
Ostia has been running on Canton DevNet since October 22. The November 9 introduction brings together its public access, documentation and recent tools. DevNet is a network for development and testing, so this is not a launch for assets with real financial value.
Why Ethereum developers might care
Ethereum applications are commonly written in Solidity and run in an Ethereum Virtual Machine, or EVM. The EVM is the software environment that executes those contracts.
Canton applications use a different contract model, commonly written in Daml. Ostia’s aim is to give Solidity developers a way to build applications whose execution can be coordinated with Canton activity, without first rewriting every contract in Daml.
The team supports tools such as Foundry and Hardhat for deploying contracts. Its code is open source under Apache-2.0, so developers can inspect the implementation and run their own setup.
What the proof does
The “ZK” in ZK EVM refers to zero-knowledge proof technology. In Ostia, the important role of the proof is to establish that an EVM block follows the defined execution rules. The label alone does not mean every transaction is confidential.
The process has three steps:
- Build a block. Ostia collects EVM transactions and the Canton actions they request.
- Prove and check it. ZisK, the proof system used by Ostia, produces a proof. Software beside a confirming Canton participant checks that proof and the associated actions.
- Commit together. The block and its attached Canton actions settle in one Canton transaction, or none of those changes commits.
Ostia’s settlement flow. Source: Rome documentation.
That last step is called atomic settlement. Think of two linked actions that must either both succeed or both fail. Keeping them in one commit avoids leaving one completed while the other is still waiting.
What builders can try
- Deploy contracts: use Solidity tools against Ostia’s public development endpoint.
- Move test assets: use the Bridge page to transfer between Ostia and Canton, including representations of Canton Coin and Ethereum-format tokens.
- Create a Canton account: the browser flow uses a wallet signature to open an account hosted on Rome’s validator.
- Inspect settlement: the explorer shows the Canton transaction associated with each block.
The bridge’s account design keeps signing under the user’s key. Rome hosts the account on its validator, while its documentation says the host cannot move that account’s holdings without the user’s authority.
A test environment with clear limits
Rome’s trust-model documentation says it currently runs every Ostia service, including the block builder, prover, public endpoint and the single confirming sidecar. Canton DevNet’s synchronizer is operated by the network, separately from Rome.
This is an early implementation, with a more concentrated operating setup than a mature production service. Test balances can be reset, and the documentation explicitly says not to use it for anything of value.
Ostia adds another approach to Ethereum-compatible development on Canton alongside the existing Zenith testnet. The useful question for builders is how each implementation coordinates their application with Canton assets and what trust assumptions come with that design.
Builder links: Documentation · Network and test-token details · Source code · Rome on X.
