This is Rome Protocol’s first post here. Ostia is an EVM chain that settles on Canton. ZisK, a zero-knowledge virtual machine, proves each block. One Canton transaction carries the block, its proof and the Canton actions the block asked for. The confirming participant’s external call checks the proof. The block and the Canton actions settle together, or nothing commits.
Ostia is live on Canton DevNet. It is open to everyone, and the code is open source under Apache-2.0.
What you can do now:
Deploy Solidity contracts with Foundry or Hardhat, as on Ethereum. The chain id is 770101 and the test coin is tROME.
Move tokens between Ostia and Canton on the Bridge page. Canton Coin arrives on Ostia as the CC ERC-20. ERC-20s such as WtROME stand on Canton as CIP-0056 twins. Both move back. A move takes about 1 to 2 minutes.
Send Canton Coin and twins to other Canton addresses from the same page. Incoming transfers have an Accept button, and you can take back a send that was not accepted.
Open a Canton account by signing one message in your wallet if you have no Canton wallet yet. No gas, no Canton software. Only your key can move what the account holds, and Rome’s validator hosts it but cannot sign for it.
Take test coins: 1 tROME a day for everyone, 20 test Canton Coin a day, and 100 tROME for builders who sign in with GitHub.
Compose with Canton assets: any contract can hold and move Canton Coin as the CC ERC-20. On your own Ostia, a payment through the gateway executes a Canton allocation, and the otc-venue Daml package depends only on CIP-0056.
Watch it settle on the External calls page of the explorer: one Canton transaction per block. Since 22 October, more than 53,600 blocks with a 99.99% success rate. Over the last 24 hours, settlement took about 9 seconds on average and about 11 seconds at p95.
This is DevNet: tROME has no value, and Rome runs the Ostia services today. The Trust model and limits page in the docs says who checks what.
A question and an ask:
We derive a Canton key from an EVM wallet signature, so onboarding takes one signature. Is there a pattern you prefer for people who arrive with only an EVM wallet?
If you run a DevNet validator and would confirm Ostia blocks beside ours once we have a tested procedure, tell us.
For technical questions, bugs and ideas, open an issue in the GitHub repository. Report security problems through GitHub’s private reporting. For anything else, reply here; we will read every reply.
From reading the onboarding code at c350f87, signature normalization and the initial repeatability check are useful safeguards. They don’t establish recovery across wallet implementations or updates, so a supported-wallet list and cross-wallet recovery tests would help.
One code-comment correction: KEY_TYPED_DATA says another site produces a different signature, but another site can request the identical typed payload. The warning on STATEMENT correctly acknowledges this.
There’s also a recovery question: topology.ts uses the derived key’s fingerprint as the namespace and registers that key as the sole signing key. Canton 3.7.2 distinguishes removing a self-signed party mapping from revoking namespace authority.
What revocation and migration procedure would you support if the signature leaks and what recovery path exists if a wallet stops reproducing it?
Thanks Georgi, this is a careful read, and you’re right on each point.
The comment on KEY_TYPED_DATA is wrong. EIP-712 binds the signature to the typed payload, not to the site that asks for it, so another site can request the identical payload and get the identical signature. The statement the wallet shows says so; the code comment will be corrected to match.
On recovery: today there is none. The derived key is the party’s namespace and its only signing key, at threshold 1. If the signature leaks, whoever holds it controls the account, and revoking the namespace would need that same key, so revocation is no remedy against a leak. If a wallet stops reproducing the signature, the account cannot be reopened from that wallet. On DevNet this risks only test tokens, but it is the reason the derived account stays a Bridge-only option for people who arrive with just an EVM wallet, and it will not go beyond DevNet in this form.
For people with a Canton wallet, we are adding a way to connect it to the Bridge, so their own wallet holds and signs with its key and its recovery applies.
Your two suggestions are good ones: a list of wallets we have tested, and recovery tests across wallets and wallet updates. We will add both, and state these limits plainly in the docs’ trust model.
Thanks for clarifying. That answers my questions, particularly the lack of recovery and the commitment to keep this design on DevNet. Publishing the tested wallet/version combinations and documenting both signature disclosure and signature reproducibility risks would make the limitations clear.
One small clarification for the docs: identical typed data produces the same signing digest, but identical signature bytes depend on the wallet’s signing implementation. That distinction seems worth including alongside the recovery tests.
Please link the updated trust model and test results here when available.
The trust model now has a section on the Bridge account made from a wallet signature: how the key is made, the signature-disclosure risk, the reproducibility risk (the same typed data always gives the same digest; the same signature bytes depend on how the wallet signs), and that there is no revocation or recovery today, on DevNet only. Trust model and limits | Rome Protocol Docs
Georgi, the third item is published: the tested wallet and version list, with the test that produces it.
The test signs the Bridge’s message with a throwaway key in real browser-extension wallets, twice and again after a browser restart, and compares the signatures with a reference and with each other. First results (2026-11-10):
MetaMask 13.56.0, Rabby 0.94.15 and OKX Wallet 4.23.0 give the same signature bytes every time and the same bytes as each other, so the same key opens the same account in any of them. MetaMask and then Rabby reached the same account on the live Bridge.
Coinbase Wallet and Phantom (EVM) could not be driven by the test yet, so they have no result.
Hardware wallets are not tested. Smart-contract wallets cannot open a Bridge account, since the page checks that the signature comes from the connected address.
A result holds for that wallet version only. The test records each package’s source and SHA-256 and can be rerun when a wallet updates.
