28 Sep 2026
Identity
A typeface for the paper
Zettl Serif is a display face drawn for the project, with Computer Modern proportions and squircle bowls. The wordmark, headlines and numerals use it. Text is set in Latin Modern.
Zettl: Smart Contract Enabled, Universal Cross-Border Settlement for Agentic and Private Payments
J. RautWorking draft v0.5September 2026Unreviewed
AbstractSummary
We describe Zettl, a settlement layer for cross-border payments made by people, contracts and software agents. It is compatible with the EVM, so existing wallets and smart contracts work. Transactions whose effects commute, and which touch only state owned by their sender, are made final by validator certificates without consensus. Transactions that conflict are ordered by a consensus protocol and anchored in the same ledger. Payments that should be private are shielded with a zero-knowledge proof. Compliance and regulation are foundational to the design: a compliance step runs before validators sign, so jurisdiction-specific rules apply without changing the protocol. Three lanes, with fixed and separate prices, expose the network to users: Fast, Public and Private. This document is a working draft. It reports a design, not measurements.
§ 1Introduction
A cross-border payment has to satisfy several parties at once: the sender, the receiver, and the rules of every place it touches. Zettl is designed to bring compliance, private payments and agentic payments together in one settlement system, instead of leaving each to a separate layer. Compliance modules run before validators sign, private payments are shielded with zero-knowledge proofs, and software agents can pay over x402.
Such a system also has to be fast. Total order is a strong tool used for a weak purpose in most payment traffic. Two transfers between disjoint pairs of accounts have the same outcome in either order, so ordering them adds latency and no safety. Prior work on broadcast-based settlement shows that such transfers can be finalized without consensus[1], and that a simple balance transfer needs less synchronization than a general state machine[2].
Zettl carries this idea to the EVM. The difficulty is that general contracts can read and write shared state. We handle that by making conflicts explicit and by sending only conflicting transactions to an ordered lane. Privacy comes from zero-knowledge proofs on a separate lane, and local rules come from compliance modules that run before validators sign. Compliance and regulation are foundational to this design, not added afterward.
§ 2Model
State is a set of objects. Each transaction carries an access list naming the objects it touches and a mode for each: read, write, add or subtract. Two accesses to one object commute if both are adds or both are reads. Otherwise they conflict.
access(tx) = { (object, mode) }
commute(a,b) = for every shared object: mode_a, mode_b in {read, add}
conflict(a,b) = not commute(a,b)
An object has an owner, which is a signing suite. The base suite is post-quantum-ready, and an adapter accepts secp256k1 signatures over EIP-712 messages so that existing wallets can sign claims.
Definition 1 (Certificate). A set of validator signatures over a claim whose combined weight meets the fast path’s threshold.
§ 3Fast path
The sender broadcasts a claim to validators. Each validator checks the signature, the owner’s balance and the compliance modules configured for the asset, and returns a signature if the claim is valid. The sender collects signatures into a certificate and broadcasts it. Validators apply the claim when they see the certificate.
Version 0.5 studies the unanimous variant, in which every validator must sign, in place of a two-thirds quorum. Unanimity simplifies the argument for finality without expiry and raises a liveness question that the draft treats as an open item.
§ 4Ordered lane
Conflicting transactions are sent to a sequencing protocol from the Simplex family[3]. The ordered lane produces blocks that reference certificates from the fast path, so both paths write to one ledger and a light client can verify either. In version 0.5 the Private lane runs only here.
§ 5Lanes and fees
The Fast lane carries simple public payments. The Public lane carries ordinary EVM execution, with commutative transactions on the fast path and conflicting ones on the ordered lane. The Private lane carries shielded payments. Each lane has a fixed fee in a US dollar stablecoin. The Private fee is the highest because verifying a proof costs validators more than verifying a signature.
§ 6Privacy
Parties to a cross-border payment often do not want amounts or counterparties visible to everyone who can read a public ledger. The Private lane hides amounts and parties with a zero-knowledge proof. Proofs are transparent and hash-based, so they need no trusted setup and are believed to resist quantum attackers. Only assets without a controller can be shielded in v0.5. Private payments over x402 are deferred to v0.6.
§ 7Compliance
Compliance and regulation are foundational considerations in the design of Zettl. The protocol reserves a point before signing where a compliance module can approve or refuse a claim, so a jurisdiction's rules are applied where a claim enters the network and not after it settles. Modules sit outside the core, so different jurisdictions can apply different rules to the same ledger. This draft specifies where modules sit and what they may decide. It does not specify the rules of any jurisdiction.
§ 8Security and verification
Safety rests on two claims. First, two conflicting claims cannot both gather certificates. Second, a certificate is never revoked. The draft states both as properties of a state machine and gives the machine in an appendix so that they can be checked mechanically. Validator certificates use BLS signatures in v0.5. A post-quantum mode is planned and is not a blocker for the first release.
The path to stronger assurance has five stages: proofs on paper, an executable model, mechanized proofs, a verified implementation, and validation of the implementation’s traces against the model. Only the first is complete in this draft. The model is specified but has not been model checked, and the other three are planned, with nothing checked by a machine yet. The properties in scope are certificate safety, replacement safety, liveness of anchoring, and no double spend across epochs. The template compiler, the shared-state write interceptor, the signature and proof verifiers, the soundness of the STARK prover, the hash function, the ordered-lane protocol and the epoch key commitment remain in the trusted base.
ReferencesSelected references
- [1]M. Baudet, G. Danezis, A. Sonnino. FastPay: High-Performance Byzantine Fault Tolerant Settlement. AFT 2020.
- [2]R. Guerraoui, P. Kuznetsov, M. Monti, M. Pavlovic, D.-A. Seredinschi. The Consensus Number of a Cryptocurrency. PODC 2019.
- [3]B. Y. Chan, R. Pass. Simplex Consensus: A Simple and Fast Consensus Protocol. TCC 2023.
The reference list is abbreviated in this draft.