Canton & zenith

Diviko perps runs on Zenith, an EVM execution layer that posts to the Canton Network. From a user's perspective, the protocol behaves like any other EVM perpetuals exchange — Solidity contracts, MetaMask-style signing, EVM-style addresses. From the network's perspective, every settled trade is a Canton transaction backed by the network's privacy and finality guarantees.

This page covers what is specific to diviko perps: how assets get in and out of zenith, and how that affects the trading experience. For the inner workings of zenith itself — block production, sequencing, the proof system, the canton bridge — see the zenith docs.

The two surfaces

• Canton mainnet is where assets natively live. USDC, USDT, WBTC, and the canton-native wrapping of ETH are issued as canton token contracts. Diviko wallets hold and transfer them at this layer.
• Zenith is the EVM rollup-style layer that executes the perps contracts. Assets bridged in from canton appear as ERC-20-equivalent balances. The DLP, the position contracts, the oracle adapters, and the keepers all run here.

The protocol does not run on canton mainnet directly. Solidity is the right language for this kind of contract — well-audited, well-tooled, well-understood — and zenith gives us EVM semantics without giving up canton settlement.

Bridging in

To use the protocol, you bridge assets from canton into zenith. The bridge is a pair of mirrored contracts:

1. You submit a deposit on the canton side: a transaction that transfers the asset into the bridge's canton custody contract, with a memo field carrying your destination zenith address.
2. The canton transaction is observed by the zenith sequencer, which mints the corresponding wrapped balance to your zenith address.

Once the deposit is reflected on zenith, you can interact with the perps contracts directly — open positions, mint dlpUSD, do whatever. There is no further canton step until you bridge out.

Deposits are atomic from the user's perspective. If the canton side commits, the zenith mint will happen; if the canton side fails, no zenith mint occurs. The bridge contract on canton holds the underlying 1:1 against zenith supply.

Bridging out

Withdrawing from zenith back to canton reverses the flow:

1. You submit a withdrawal on zenith: the wrapped balance is burned and a withdrawal record is emitted.
2. The bridge releases the underlying asset from canton custody to the destination canton party specified in the withdrawal.

Withdrawals settle as soon as the zenith block carrying the burn is finalised on canton. The current finality window is on the order of seconds — see the zenith docs for the current bound and the conditions that affect it.

What this means for traders

Day-to-day, the canton layer is invisible. You bridge in once, trade for as long as you want, and bridge out when you want native assets back. While you are inside zenith, fees are paid in the asset you're trading with (no separate gas token), and balances are visible to you in the usual EVM way.

Two things are worth knowing:

• Privacy is at the canton boundary. Your zenith balance and trading activity are visible on the zenith chain. The canton transactions backing them are private to the parties involved. So an outside observer can see what you do on zenith, but cannot tie those activities to the canton wallet that funded them unless you tell them.
• Finality is canton's. Once a zenith block is settled on canton, it is final — there are no reorgs to wait through. This is why the protocol uses the bridge for withdrawals: it inherits canton's finality rather than reinventing it.

For developers

The protocol is a set of Solidity contracts that look like any other EVM project. Standard tools (Foundry, Hardhat, ethers, viem) all work. The only zenith-specific concerns are the bridge ABI (for moving assets in and out) and the slightly tighter block time relative to L1.

Contract addresses and the bridge ABI will be published at protocol launch. For the EVM environment, opcodes, and gas model, see the zenith docs.