V1 Architecture
Court V1 is built around a single contract, KlerosLiquid, deployed on Ethereum Mainnet (and Gnosis Chain). KlerosLiquid is monolithic: juror staking, random selection, voting, and dispute management all live in the same contract.
Key characteristics:
- Network: Ethereum Mainnet (also Gnosis Chain)
- Standards: ERC-792 (arbitration) and ERC-1497 (evidence); evidence and appeals are handled by the arbitrable contract, not the Court
- Juror selection: built into KlerosLiquid, using a stake-weighted sortition sum tree
- Randomness: blockhash-based RNG
- Voting: commit-reveal with plurality aggregation
- Courts: a hierarchical subcourt tree with the General Court as root
V2 Architecture
Court V2 runs on Arbitrum and splits the monolithic V1 contract into modular components. The rest of this section describes that design.Design Principles
Kleros V2 was designed around six key principles:- Modularity: Dispute resolution logic is separated into pluggable Dispute Kits
- Multi-Dispute-Kit Support: Different courts can use different voting, incentive, and appeal mechanisms
- Fork-Friendly: The protocol supports forking to reduce attack payoffs
- Lightweight PNK: Simple ERC-20 token (replacing the complex Minime token from V1)
- Juror Fraud Protection: Mechanisms to detect and penalize pre-reveal, bribery, and cartelling
- Evidence Spam Protection: Deposit-based evidence submission on L2 where gas is cheap
Component Map
Multi-Chain Vision
The long-term architecture supports Arbitrables on any EVM chain:- Users interact primarily with the Home chain (Arbitrum) for most operations
- Evidence can be submitted from foreign chains for convenience
- Gateways and the Vea bridge abstract away bridging complexity
- Each supported foreign chain has its own Foreign Gateway deployment
Dispute Kit System
Courts can support multiple dispute kits, enabling different:- Drawing methods: PNK-weighted, Proof-of-Humanity-based, etc.
- Voting systems: Plurality, Condorcet-IRV, etc.
- Incentive models: Equal split, weighted functions, etc.
- Appeal systems: Fund-2-only, fund-multiple, stake-based, etc.
DisputeKitClassic (PNK drawing + plurality voting + equal split + fund-2-only appeals) is the only deployed kit and is mandatorily supported by all courts.
Security Model
- Cryptoeconomic: Jurors stake PNK; incoherent voters lose stake
- Random Selection: Prevents manipulation of juror composition
- Appeal Escalation: Exponentially increasing cost to sustain an attack
- Emergency Controls: Guardian pause + Governor unpause for rapid response
- Fork Mechanism: Ultimate defense: honest minority can fork the protocol