diff --git a/Community & Ecosystem/escrowly.mdx b/Community & Ecosystem/escrowly.mdx index b5c2d65..7c74569 100644 --- a/Community & Ecosystem/escrowly.mdx +++ b/Community & Ecosystem/escrowly.mdx @@ -1,9 +1,11 @@ --- title: "Escrowly" -description: "Alternative frontend for Kleros Escrow V1" +description: "Alternative frontend for Kleros Escrow V1 (retired)" --- - + +**Retired.** Escrowly was a community-created Escrow interface, not officially affiliated with Kleros. It is no longer actively maintained - the app at [escrowly.eth.limo](https://escrowly.eth.limo) fails to load transactions. The content below is kept for historical reference. + **Escrowly** is a community-built alternative frontend for the Kleros Escrow V1 smart contracts. It provides a modern, user-friendly interface for creating and managing escrow transactions backed by Kleros dispute resolution. diff --git a/ai-tools/mcp-server.mdx b/ai-tools/mcp-server.mdx index 335c8eb..22a6381 100644 --- a/ai-tools/mcp-server.mdx +++ b/ai-tools/mcp-server.mdx @@ -4,7 +4,7 @@ description: "Use Kleros documentation as an AI context source via the Model Con icon: "robot" --- -The Kleros documentation site exposes an **MCP (Model Context Protocol) server** that lets AI coding assistants — Claude, Cursor, VS Code Copilot, and others — query these docs directly as context when you are building a Kleros integration. +The Kleros documentation site exposes an **MCP (Model Context Protocol) server** that lets AI coding assistants - Claude, Cursor, VS Code Copilot, and others - query these docs directly as context when you are building a Kleros integration. This means your AI assistant can answer questions like "what is the correct extraData encoding for V2?" or "show me the IArbitrableV2 interface" by reading the authoritative docs rather than relying on training data that may be outdated. diff --git a/api-reference/introduction.mdx b/api-reference/introduction.mdx index bcb45e7..50c84b7 100644 --- a/api-reference/introduction.mdx +++ b/api-reference/introduction.mdx @@ -1,7 +1,7 @@ --- title: "API Reference" -description: "HTTP API reference for the Kleros IPFS gateway — upload and retrieve dispute templates, evidence, and policy documents" +description: "HTTP API reference for the Kleros IPFS gateway - upload and retrieve dispute templates, evidence, and policy documents" --- Every Kleros integration that involves jurors needs off-chain content: dispute templates that tell jurors what question to answer, evidence files that parties submit, and policy documents that define ruling criteria. All of this content is stored on IPFS and referenced on-chain by its CID. @@ -33,11 +33,11 @@ https://cdn.kleros.link | Content | Where it's used | Schema | |---------|----------------|--------| | Dispute template JSON | `DisputeTemplateRegistry.setDisputeTemplate()` | [Dispute Templates](/reference/data-formats/dispute-templates) | -| Evidence file JSON | `EvidenceModule` — submitted by parties during a dispute | [Evidence Format](/reference/data-formats/evidence-format) | +| Evidence file JSON | `EvidenceModule` - submitted by parties during a dispute | [Evidence Format](/reference/data-formats/evidence-format) | | Policy document JSON | `policyURI` field in dispute templates | [Policy Format](/reference/data-formats/policy-format) | | Item attachment | Curate V2 item metadata | Column-based JSON schema | -## Uploading content — SDK +## Uploading content - SDK The `@kleros/kleros-sdk` wraps the gateway upload in a typed helper: diff --git a/changelog/2026-04-14.mdx b/changelog/2026-04-14.mdx index d98441a..5b6d70c 100644 --- a/changelog/2026-04-14.mdx +++ b/changelog/2026-04-14.mdx @@ -19,7 +19,7 @@ You can now export your Foresight prediction history as a CSV file with UTC time ### Foresight onboarding guides -New step-by-step guides walk first-time users through the [Foresight](/products/foresight) interface — covering how predictions work, the profit-and-loss mechanics, and the session timeline. An advanced guide with deeper strategy content is also shown on each prediction to help you improve. +New step-by-step guides walk first-time users through the [Foresight](/products/foresight) interface - covering how predictions work, the profit-and-loss mechanics, and the session timeline. An advanced guide with deeper strategy content is also shown on each prediction to help you improve. ### Automatic Zodiac proposal verification @@ -81,15 +81,15 @@ The SBT (Soulbound Token) contracts for the Argentina Consumer Protection experi ## Bug fixes -- **Court network switch modal** — The modal prompting you to switch to the correct network now works properly even without a connected wallet and can be dismissed as expected. -- **Court wallet connection popups** — Unnecessary wallet connection popups no longer appear when browsing cases. -- **Dispute Resolver court redirects** — Links from the [Dispute Resolver](/legacy/resolver-v1) to Court now correctly specify the chain, preventing you from landing on the wrong network. -- **Foresight prediction reset** — Predictions no longer reset unexpectedly after a successful submission. -- **Foresight dark mode readability** — The advanced guide is now properly styled in dark mode. -- **Foresight gas estimation** — Gas buffers are now capped to prevent unexpectedly high transaction fees. -- **Curate registry display reliability** — In [Curate](/products/curate), a single malformed registry item no longer prevents other valid items from loading. The item list now gracefully handles errors so you always see the items that are available. -- **Scout challenge date accuracy** — Challenge dates in [Scout](/products/scout) item timelines now display correctly. -- **Escrow value formatting** — Small token amounts now display correctly instead of rounding to zero. -- **Escrow seller role checks** — The UI now properly reflects seller-specific actions and conditions. -- **Court smart contract audit fixes** — Several improvements from a security audit have been applied to the core dispute resolution contracts, including simplified reward distribution logic and more efficient event handling. -- **Court type safety improvements** — Resolved edge cases where optional values in dispute timelines, evidence cards, and voting details could cause errors. +- **Court network switch modal** - The modal prompting you to switch to the correct network now works properly even without a connected wallet and can be dismissed as expected. +- **Court wallet connection popups** - Unnecessary wallet connection popups no longer appear when browsing cases. +- **Dispute Resolver court redirects** - Links from the [Dispute Resolver](/legacy/resolver-v1) to Court now correctly specify the chain, preventing you from landing on the wrong network. +- **Foresight prediction reset** - Predictions no longer reset unexpectedly after a successful submission. +- **Foresight dark mode readability** - The advanced guide is now properly styled in dark mode. +- **Foresight gas estimation** - Gas buffers are now capped to prevent unexpectedly high transaction fees. +- **Curate registry display reliability** - In [Curate](/products/curate), a single malformed registry item no longer prevents other valid items from loading. The item list now gracefully handles errors so you always see the items that are available. +- **Scout challenge date accuracy** - Challenge dates in [Scout](/products/scout) item timelines now display correctly. +- **Escrow value formatting** - Small token amounts now display correctly instead of rounding to zero. +- **Escrow seller role checks** - The UI now properly reflects seller-specific actions and conditions. +- **Court smart contract audit fixes** - Several improvements from a security audit have been applied to the core dispute resolution contracts, including simplified reward distribution logic and more efficient event handling. +- **Court type safety improvements** - Resolved edge cases where optional values in dispute timelines, evidence cards, and voting details could cause errors. diff --git a/changelog/2026-04-28.mdx b/changelog/2026-04-28.mdx index 756403e..7d3edf4 100644 --- a/changelog/2026-04-28.mdx +++ b/changelog/2026-04-28.mdx @@ -21,4 +21,4 @@ Curate's attachment and file display has been overhauled with a dedicated header ## Bug fixes -**Curate IPFS error handling** — Curate no longer breaks when IPFS data is temporarily unavailable. Affected items now degrade gracefully instead of blocking the rest of the registry view. \ No newline at end of file +**Curate IPFS error handling** - Curate no longer breaks when IPFS data is temporarily unavailable. Affected items now degrade gracefully instead of blocking the rest of the registry view. \ No newline at end of file diff --git a/changelog/2026-05-12.mdx b/changelog/2026-05-12.mdx index ed0c55d..0b076b9 100644 --- a/changelog/2026-05-12.mdx +++ b/changelog/2026-05-12.mdx @@ -37,6 +37,6 @@ The "last policy change" timer in [Scout](/products/scout) now resolves the seco ## Bug fixes -**Layout and scroll lock** — Modals on Scout no longer break page layout or leave the underlying page scrollable, and returning from a modal now restores your scroll position reliably. +**Layout and scroll lock** - Modals on Scout no longer break page layout or leave the underlying page scrollable, and returning from a modal now restores your scroll position reliably. -**Performance** — Reduced CPU usage on Scout dashboard and registry pages for smoother browsing on lower-powered devices. \ No newline at end of file +**Performance** - Reduced CPU usage on Scout dashboard and registry pages for smoother browsing on lower-powered devices. \ No newline at end of file diff --git a/changelog/2026-05-19.mdx b/changelog/2026-05-19.mdx index 26612af..cd16439 100644 --- a/changelog/2026-05-19.mdx +++ b/changelog/2026-05-19.mdx @@ -11,4 +11,4 @@ description: "Foresight ships a fix that displays accurate redemption values on ## Bug fixes -**Accurate redemption values on Foresight** — Position and redemption amounts shown on resolved [Foresight](/products/foresight) markets now reflect the correct payout, so you can trust the figures before redeeming. \ No newline at end of file +**Accurate redemption values on Foresight** - Position and redemption amounts shown on resolved [Foresight](/products/foresight) markets now reflect the correct payout, so you can trust the figures before redeeming. \ No newline at end of file diff --git a/changelog/2026-05-25.mdx b/changelog/2026-05-25.mdx index 6268749..30cfadb 100644 --- a/changelog/2026-05-25.mdx +++ b/changelog/2026-05-25.mdx @@ -21,6 +21,6 @@ Disputes related to JavaScript submissions in [Scout](/products/scout) now route ## Bug fixes -**Rabby wallet on mainnet** — [Kleros Court](/court/overview) no longer crashes when connecting with Rabby (or other wallets that don't expose the legacy chain ID call) on mainnet. Contract bindings now resolve reliably across providers. +**Rabby wallet on mainnet** - [Kleros Court](/court/overview) no longer crashes when connecting with Rabby (or other wallets that don't expose the legacy chain ID call) on mainnet. Contract bindings now resolve reliably across providers. -**Success popup icon in Foresight** — The confirmation icon shown after submitting predictions in [Foresight](/products/foresight) now renders at the correct size. +**Success popup icon in Foresight** - The confirmation icon shown after submitting predictions in [Foresight](/products/foresight) now renders at the correct size. diff --git a/changelog/2026-06-15.mdx b/changelog/2026-06-15.mdx index 2840c15..5671b55 100644 --- a/changelog/2026-06-15.mdx +++ b/changelog/2026-06-15.mdx @@ -29,8 +29,8 @@ The [Kleros Court V2](/court/overview) header and footer now align consistently ## Bug fixes -**Cross-product security hardening** — [Court](/court/overview), [Curate](/products/curate) (classic and v2), [Dispute Resolver](/products/proof-of-humanity), and [Escrow](/products/escrow) (UI and V2) all received the same round of URL- and attachment-handling improvements. External links and attached files are now validated before they render, and untrusted links route through a warning screen so you can review the destination before leaving the app. +**Cross-product security hardening** - [Court](/court/overview), [Curate](/products/curate) (classic and v2), [Dispute Resolver](/products/proof-of-humanity), and [Escrow](/products/escrow) (UI and V2) all received the same round of URL- and attachment-handling improvements. External links and attached files are now validated before they render, and untrusted links route through a warning screen so you can review the destination before leaving the app. -**Proof of Humanity evidence mismatch** — [Dispute Resolver](/products/proof-of-humanity) no longer shows evidence from the wrong submission on Proof of Humanity cases. Evidence and metadata now stay tied to the correct dispute. +**Proof of Humanity evidence mismatch** - [Dispute Resolver](/products/proof-of-humanity) no longer shows evidence from the wrong submission on Proof of Humanity cases. Evidence and metadata now stay tied to the correct dispute. -**Notifications email save button in Escrow V2** — The Save button on the notification email form in [Escrow](/products/escrow) V2 now activates correctly when you enter a new address, so changes can be saved without refreshing the page. +**Notifications email save button in Escrow V2** - The Save button on the notification email form in [Escrow](/products/escrow) V2 now activates correctly when you enter a new address, so changes can be saved without refreshing the page. diff --git a/changelog/2026-06-29.mdx b/changelog/2026-06-29.mdx index d43df08..a26919c 100644 --- a/changelog/2026-06-29.mdx +++ b/changelog/2026-06-29.mdx @@ -21,4 +21,4 @@ The language selector in [Court V2](/court/overview) settings is now centered fo ## Bug fixes -**File viewer URL hardening in Court V2** — The file viewer in [Court V2](/court/overview) now only loads files served over `http` or `https` and reuses the shared URL sanitizer used elsewhere in the app, so attached evidence and dispute files with unexpected or unsafe URL schemes are rejected before they can render. +**File viewer URL hardening in Court V2** - The file viewer in [Court V2](/court/overview) now only loads files served over `http` or `https` and reuses the shared URL sanitizer used elsewhere in the app, so attached evidence and dispute files with unexpected or unsafe URL schemes are rejected before they can render. diff --git a/concepts/pnk-token.mdx b/concepts/pnk-token.mdx new file mode 100644 index 0000000..a502da3 --- /dev/null +++ b/concepts/pnk-token.mdx @@ -0,0 +1,72 @@ +--- +title: "PNK Token" +description: "The Kleros native token that creates the right incentives and prevents Sybil attacks" +--- + +# PNK Token + +**PNK** is the native token of the Kleros protocol. It serves two core functions: **staking for juror eligibility** and **governance voting rights**. Token holders stake PNK to participate in dispute resolution, with higher stakes increasing selection probability, and use it to vote on governance proposals, court parameters, and platform changes. + +The name references **Pinakions**, the bronze plates used in Ancient Athens for randomized jury selection. + +--- + +## Token Supply + +The max PNK token supply is **915,528,222.07931277**. Supply changes are controlled exclusively through Kleros DAO governance votes. + +- Mainnet contract: [`0x93ED3FBe21207Ec2E8f2d3c3de6e058Cb73Bc04d`](https://etherscan.io/token/0x93ed3fbe21207ec2e8f2d3c3de6e058cb73bc04d) + +--- + +## What PNK Is Used For + +| Function | How it works | +| --- | --- | +| **Juror staking** | Stake PNK in a court to become eligible for juror selection. Selection probability is proportional to stake. | +| **Incentive alignment** | Coherent jurors earn arbitration fees and PNK redistributed from incoherent jurors; incoherent jurors lose part of their stake. | +| **Governance** | PNK holders vote on Kleros Improvement Proposals (KIPs), court parameters, and protocol upgrades. | + + + + + +--- + +## [Why Kleros Needs a Native Token](https://medium.com/kleros/why-kleros-needs-a-native-token-5c6c6e39cdfe) + +PNK's design provides three layers of protection against a 51% [(Sybil) attack](https://en.wikipedia.org/wiki/Sybil_attack): + +1. **Market scarcity defense.** Acquiring 51% of PNK becomes economically prohibitive: large purchases exhaust available liquidity and drive the price up, unlike an attack denominated in ETH or another asset with vastly deeper markets. +2. **Price impact risk.** A successful attack would substantially devalue PNK itself, imposing a massive cost on the attacker that does not exist when attacking with an external asset. +3. **Fork capability.** As a last resort, the community can perform an emergency fork that removes the attacker's holdings, a recovery path unavailable with external tokens. + + +--- + +## How to Get PNK + +The fastest way is the [Buy PNK page of the Court](https://court.kleros.io/tokens), which routes to the exchanges listed there. + +| Venue type | Options | +| --- | --- | +| **DEX aggregators** (large trades) | Paraswap, 1inch | +| **DEXs** (medium trades) | Uniswap, Sushiswap, Balancer | +| **Centralized exchanges** | Bitfinex, Gate.io, OKX | +| **Fiat onramp** | Guardarian | + +--- + +## What's Next? + + + + The full economic model behind Kleros + + + Stake PNK and start judging cases + + + Vote with PNK on protocol decisions + + diff --git a/concepts/sortition.mdx b/concepts/sortition.mdx index 25f1813..e2cc715 100644 --- a/concepts/sortition.mdx +++ b/concepts/sortition.mdx @@ -83,6 +83,10 @@ Kleros V2 uses **Randomizer.io** as the primary random number source on the prod The RNG request is made with a configurable **lookahead** parameter, the random number depends on a future block, not the current one. This prevents the requester from knowing the outcome at request time. + +In Kleros V1, juror selection is built into the KlerosLiquid contract rather than a separate SortitionModule, and randomness comes from a blockhash-based source. V2 moves selection into the standalone SortitionModule and adds swappable RNG sources. + + --- ## Historical Context diff --git a/court/appeals.mdx b/court/appeals.mdx index e574538..a7fd5dc 100644 --- a/court/appeals.mdx +++ b/court/appeals.mdx @@ -7,7 +7,11 @@ sidebarTitle: "Appeals" -The appeals system is a core feature of Kleros Court that ensures fairness and allows for error correction. Any party—or even third parties—can challenge a ruling by funding an appeal. +The appeals system is a core feature of Kleros Court that ensures fairness and allows for error correction. Any party-or even third parties-can challenge a ruling by funding an appeal. [Read more here](https://blog.kleros.io/kleros-decentralized-token-listing-appeal-fees/) + + +Appeal mechanics are fundamentally the same in V1 and V2. The V2-specific enhancements (such as Dispute Kit jumps) are labeled where they appear below. + --- @@ -136,7 +140,7 @@ Kleros V2 introduces significant improvements to court jumps: - If a parent court doesn't support the current dispute kit, the dispute can switch to a compatible kit—including complex question types. + If a parent court doesn't support the current dispute kit, the dispute can switch to a compatible kit-including complex question types. diff --git a/court/architecture.mdx b/court/architecture.mdx index 9d95511..f7cb8c3 100644 --- a/court/architecture.mdx +++ b/court/architecture.mdx @@ -1,11 +1,40 @@ --- -title: "V2 Architecture" -description: "Detailed system architecture of Kleros V2" +title: "Architecture" +description: "System architecture of Kleros Court, V1 and V2" --- +This page covers the Kleros Court architecture for both protocol versions. It starts with the V1 design, then the V2 design, and ends with what changed between them. +--- + +## 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. -## Design Principles +| Component | Responsibility | +|---|---| +| **KlerosLiquid** | Staking, juror drawing, voting, appeals, and ruling execution in one contract | +| **PolicyRegistry** | Court policy storage | +| **Minime PNK token** | The staking token used in V1 | + +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 + +For more on V1, see [Court V1](/legacy/court-v1). + +--- + +## 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: @@ -16,7 +45,7 @@ Kleros V2 was designed around six key principles: 5. **Juror Fraud Protection**: Mechanisms to detect and penalize pre-reveal, bribery, and cartelling 6. **Evidence Spam Protection**: Deposit-based evidence submission on L2 where gas is cheap -## Component Map +### Component Map | Component | Responsibility | |---|---| @@ -29,7 +58,7 @@ Kleros V2 was designed around six key principles: | **Home/Foreign Gateways** | Cross-chain dispute relay | | **Vea Bridge** | Optimistic cross-chain message transport | -## Multi-Chain Vision +### Multi-Chain Vision The long-term architecture supports Arbitrables on any EVM chain: - Users interact primarily with the Home chain (Arbitrum) for most operations @@ -37,7 +66,7 @@ The long-term architecture supports Arbitrables on any EVM chain: - Gateways and the Vea bridge abstract away bridging complexity - Each supported foreign chain has its own Foreign Gateway deployment -## Dispute Kit System +### Dispute Kit System Courts can support multiple dispute kits, enabling different: - **Drawing methods**: PNK-weighted, Proof-of-Humanity-based, etc. @@ -47,10 +76,25 @@ Courts can support multiple dispute kits, enabling different: Currently, `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 +### 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 \ No newline at end of file +- **Fork Mechanism**: Ultimate defense: honest minority can fork the protocol + +--- + +## What Changed in V2 + +| Aspect | V1 (KlerosLiquid) | V2 (KlerosCore) | +|---|---|---| +| **Structure** | Monolithic - one contract for staking, drawing, voting, disputes | Modular - KlerosCore, SortitionModule, and DisputeKits are separate | +| **Network** | Ethereum L1 (also Gnosis Chain) | Arbitrum L2 | +| **Juror selection** | Built into KlerosLiquid | SortitionModule (separate contract) | +| **Dispute resolution** | Single built-in mechanism | Pluggable DisputeKits (Classic, Shutter, Gated, GatedShutter) | +| **PNK token** | Minime token | Lightweight ERC-20 | +| **Evidence & appeals** | Handled by the arbitrable contract | Handled by the Court | +| **Cross-chain** | Single chain | Multi-chain via the Vea bridge and Gateways | +| **RNG** | Blockhash-based | Generic RNG interface with fallback | \ No newline at end of file diff --git a/court/court-hierarchy.mdx b/court/court-hierarchy.mdx index e06b385..fc9faf8 100644 --- a/court/court-hierarchy.mdx +++ b/court/court-hierarchy.mdx @@ -7,6 +7,10 @@ description: "Understanding the hierarchical court structure and specialized dom Kleros courts are organized in a hierarchical tree structure, allowing disputes to be handled by jurors with appropriate expertise while maintaining a clear appeals path. + +The hierarchical model is the same in both protocol versions. V1 uses the term **subcourts** and its court tree runs on Ethereum Mainnet; V2 uses the term **courts** and runs on Arbitrum. The tree, parameters, and examples below reflect V2. Curation for the Curate products also runs on **Gnosis Chain** using V1 courts. Governance proposal **KIP-87** created a new Gnosis Chain Curation Court with hidden voting, which went live in June 2026. + + --- ## Court Structure @@ -15,21 +19,21 @@ The court tree forms an arborescence with the General Court as the current root. ```mermaid graph TD - FC["Forking Court (ID: 0)\nReserved for future use"] - GC["General Court (ID: 1)\nRoot Court"] - BT["Blockchain\nTechnical"] + FC["Forking Court (ID: 0)
Reserved for future use"] + GC["General Court (ID: 1)
Root Court"] + BT["Blockchain
Technical"] CU["Curation"] - EL["English\nLanguage"] + EL["English
Language"] ON["Onboarding"] - DA["Data\nAnalysis"] - VP["Video\nProduction"] - SP["Corte General\nen Español"] - HC["Humanity\nCourt"] + DA["Data
Analysis"] + VP["Video
Production"] + SP["Corte General
en Español"] + HC["Humanity
Court"] SOL["Solidity"] NT["Non-Technical"] - TL["Token\nListing"] - CM["Curation\n(Medium)"] - SM["Statistical\nModeling"] + TL["Token
Listing"] + CM["Curation
(Medium)"] + SM["Statistical
Modeling"] FC -.-> GC GC --> BT @@ -105,7 +109,7 @@ graph TD - **AI-Optimized Resolution** + **AI-Optimized Resolution** V2 only - New court type designed for AI agents - Optimized dispute resolution parameters @@ -132,7 +136,7 @@ Each court has parameters that define how it operates. These are set during cour ### Mainnet Court Parameters (Arbitrum One) -The following table shows the production court configuration as deployed. Values are governance-controlled and may have changed since this was written — always cross-check with [v2.kleros.builders](https://v2.kleros.builders/). +The following table shows the production court configuration as deployed. Values are governance-controlled and may have changed since this was written - always cross-check with [v2.kleros.builders](https://v2.kleros.builders/). | ID | Name | Parent | minStake (PNK) | feeForJuror (ETH) | jurorsForJump | hiddenVotes | |---|---|---|---|---|---|---| diff --git a/court/how-it-works.mdx b/court/how-it-works.mdx index b8c376d..39e9565 100644 --- a/court/how-it-works.mdx +++ b/court/how-it-works.mdx @@ -7,17 +7,72 @@ description: "The complete dispute resolution process from creation to execution Kleros Court resolves disputes through a structured process that ensures fairness, transparency, and economic alignment. This page walks through each stage from dispute creation to final execution. +The same crypto-economic model powers both protocol versions. V1 runs on Ethereum with the KlerosLiquid contract; V2 runs on Arbitrum with a modular architecture. The V1 process is summarized first, followed by the detailed V2 process. + +--- + +## V1 - Production Protocol + +In Court V1, the entire dispute process is handled by a single contract, **KlerosLiquid**, on Ethereum Mainnet (also deployed on Gnosis Chain). + +```mermaid +flowchart LR + A["Dispute
Creation"] --> B["Evidence"] + B --> C["Juror
Drawing"] + C --> D["Commit"] + D --> E["Reveal /
Vote"] + E --> F["Appeal"] + F -->|"Appeal funded"| C + F -->|"No appeal"| G["Execution"] + + style A fill:#9b59b6,color:#fff + style B fill:#a569bd,color:#fff + style C fill:#a569bd,color:#fff + style D fill:#a569bd,color:#fff + style E fill:#a569bd,color:#fff + style F fill:#a569bd,color:#fff + style G fill:#7d3c98,color:#fff +``` + + + + + + An arbitrable application creates a dispute through the ERC-792 arbitrator interface and pays arbitration fees. The target subcourt and juror count are set in the `extraData` parameter. + + + Parties submit evidence following the ERC-1497 standard. Evidence and appeals are handled by the arbitrable contract itself, not by the Court. + + + Jurors are drawn at random from those who have staked PNK in the subcourt, weighted by stake. PNK stays in the juror's wallet while staked. Randomness comes from a blockhash-based RNG. + + + Jurors commit a hashed vote, then reveal it with justification. The outcome is decided by plurality - the choice with the most votes wins. + + + Parties can fund an appeal to trigger a new round with more jurors. Once appeals are exhausted, the ruling is enforced. Coherent jurors are rewarded; incoherent jurors lose part of their stake. + + + +Courts in V1 are organized as a hierarchical **subcourt** tree with the General Court as the root. Staking in a child subcourt automatically includes the juror in its parent subcourts. + +--- + +## V2 - Next-Gen Upgrade + +The sections below describe the V2 dispute process on Arbitrum. V2 keeps the same lifecycle but splits the logic across **KlerosCore**, the **SortitionModule**, and pluggable **DisputeKits**. + --- ## The Dispute Lifecycle ```mermaid flowchart LR - A["Dispute\nCreation"] --> B["Evidence\nPeriod"] - B --> C["Juror\nSelection"] - C --> D["Commit\nPeriod"] - D --> E["Reveal /\nVote Period"] - E --> F["Appeal\nPeriod"] + A["Dispute
Creation"] --> B["Evidence
Period"] + B --> C["Juror
Selection"] + C --> D["Commit
Period"] + D --> E["Reveal /
Vote Period"] + E --> F["Appeal
Period"] F -->|"Appeal funded"| C F -->|"No appeal"| G["Execution"] @@ -107,9 +162,9 @@ The Sortition Module uses a three-phase cycle to prevent manipulation of juror s ```mermaid stateDiagram-v2 [*] --> Staking - Staking --> Generating : disputesWithoutJurors > 0\n& minStakingTime elapsed + Staking --> Generating : disputesWithoutJurors > 0 & minStakingTime elapsed Generating --> Drawing : Random number received - Drawing --> Staking : All disputes have jurors\nor maxDrawingTime elapsed + Drawing --> Staking : All disputes have jurors or maxDrawingTime elapsed note right of Staking : Stake changes take effect immediately note right of Generating : Random number requested from RNG @@ -157,7 +212,7 @@ Kleros V2 introduces modular dispute resolution through pluggable Dispute Kits. | 3 | **Gated** | Classic voting restricted to jurors holding a specific eligibility token (SBT). Used for courts requiring verified credentials. | Live | | 4 | **GatedShutter** | Gated eligibility combined with Shutter encryption. | Live | -All four kits are deployed and registered on the General Court on Arbitrum One. Specialized courts (e.g., courts 29 and 32 for Argentina Consumer Protection) use DisputeKitGated and require specific SBTs — see [Deployment Addresses](/reference/contracts/deployment-addresses). The dispute kit architecture is extensible; new kits can be added through governance. +All four kits are deployed and registered on the General Court on Arbitrum One. Specialized courts (e.g., courts 29 and 32 for Argentina Consumer Protection) use DisputeKitGated and require specific SBTs - see [Deployment Addresses](/reference/contracts/deployment-addresses). The dispute kit architecture is extensible; new kits can be added through governance. --- @@ -261,7 +316,7 @@ The system includes fallback behavior: if the Drawing phase exceeds `maxDrawingT Learn how appeals and escalation work - - Step-by-step staking and voting guide + + Step-by-step staking and voting tutorial
\ No newline at end of file diff --git a/court/overview.mdx b/court/overview.mdx index ac1cdd4..847ce79 100644 --- a/court/overview.mdx +++ b/court/overview.mdx @@ -11,15 +11,39 @@ sidebarTitle: "Overview" # Kleros Court -V2 - **Kleros Court** is a decentralized dispute resolution protocol that provides arbitration services for smart contracts and decentralized applications. It works by randomly selecting jurors from a pool who are incentivized to resolve disputes honestly through a crypto-economic mechanism based on game theory. -Think of it as a decentralized judiciary for Web3. When a dispute arises, jurors are randomly drawn, they review evidence, vote on the outcome, and the majority decision is enforced—all without centralized intermediaries. +Think of it as a decentralized judiciary for Web3. When a dispute arises, jurors are randomly drawn, they review evidence, vote on the outcome, and the majority decision is enforced-all without centralized intermediaries. - -Looking for V1 documentation? See [Court V1 (Legacy)](/legacy/court-v1). - +Kleros Court comes in two versions. **V1** is the production-proven protocol running on Ethereum since 2018. **V2** is the next-generation upgrade on Arbitrum with a modular architecture. + +--- + +## V1 - Production Protocol + +Court V1 launched on Ethereum Mainnet in 2018 and has resolved over 1,500 disputes. Its core smart contract is **KlerosLiquid**, a single (monolithic) contract that combines juror staking, random selection, voting, and dispute management. + + + Court V1 interface, screenshot to be added + + +| Aspect | Court V1 | +| --- | --- | +| **Network** | Ethereum L1 (also Gnosis Chain) | +| **Core contract** | KlerosLiquid (monolithic) | +| **Standards** | ERC-792 (arbitration), ERC-1497 (evidence) | +| **Staking** | PNK stays in the juror's wallet | +| **Voting** | Commit-reveal with plurality aggregation | +| **RNG** | Blockhash-based | +| **Courts** | Hierarchical subcourt tree with the General Court as root | + +Jurors stake PNK directly from their wallet in a subcourt, are drawn at random with probability proportional to their stake, then commit and reveal their votes on the submitted evidence. Coherent jurors are rewarded; incoherent jurors lose part of their stake. + +--- + +## V2 - Next-Gen Upgrade + +Court V2 runs on Arbitrum L2 and replaces the monolithic contract with a modular design: **KlerosCore** coordinates disputes, the **SortitionModule** handles juror selection, and pluggable **DisputeKits** provide the resolution mechanism. Cross-chain disputes are relayed through the **VEA bridge**. --- @@ -113,16 +137,17 @@ This creates a self-policing system where dishonest behavior is economically pun --- -## V2 Improvements +## What Changed in V2 -Kleros Court V2 represents a significant evolution from V1: +V2 keeps the same crypto-economic model as V1 and changes how it is implemented and where it runs: -| Feature | V1 | V2 | +| Component | V1 | V2 | | --- | --- | --- | -| **Network** | Ethereum Mainnet | Arbitrum (lower gas costs) | -| **Cross-Chain** | Single chain only | Multi-chain via Vea bridge | -| **Dispute Kits** | Single mechanism | Modular, pluggable kits | -| **Vote Privacy** | Basic commit-reveal | Shutter encryption (in testing) | +| **Network** | Ethereum L1 | Arbitrum L2 | +| **Core contract** | KlerosLiquid (monolithic) | KlerosCore (modular) | +| **Juror selection** | Built into KlerosLiquid | SortitionModule (separate) | +| **Dispute resolution** | Single mechanism | Pluggable DisputeKits (Classic, Shutter, Gated, GatedShutter) | +| **Cross-chain** | Single chain | Multi-chain via VEA bridge | | **Staking** | PNK stays in wallet | PNK transfers to contract | | **RNG** | Single source | Enhanced with fallback mechanisms | @@ -132,6 +157,17 @@ Kleros V2 is currently in beta with 100+ disputes successfully processed. The sy --- +## Current Status + +As of the May 2026 development update: + +- **Court V2**: the partial-coherence dispute kit was merged, and contract simplification across dispute kits was merged (June 2026). +- **Court V1**: April staking rewards were shipped in the rewards exporter. + +Follow development on the [Kleros blog - developer updates](https://blog.kleros.io/tag/developer/). + +--- + ## What's Next? @@ -164,8 +200,8 @@ Kleros V2 is currently in beta with 100+ disputes successfully processed. The sy Open the Kleros Court application - - Step-by-step guide to staking and voting + + Step-by-step staking and voting tutorial diff --git a/developers/arbitrable-apps/arbitrable-guide.mdx b/developers/arbitrable-apps/arbitrable-guide.mdx index 4a1cc26..2eec640 100644 --- a/developers/arbitrable-apps/arbitrable-guide.mdx +++ b/developers/arbitrable-apps/arbitrable-guide.mdx @@ -80,7 +80,7 @@ interface IArbitrableV2 { /// @dev Called by the arbitrator when a ruling is final. /// @param _disputeID The arbitrator-assigned dispute ID. - /// @param _ruling The winning option. 0 = "Refuse to Arbitrate" — always handle this. + /// @param _ruling The winning option. 0 = "Refuse to Arbitrate" - always handle this. function rule(uint256 _disputeID, uint256 _ruling) external; event Ruling(IArbitratorV2 indexed _arbitrator, uint256 indexed _disputeID, uint256 _ruling); @@ -92,10 +92,10 @@ interface IArbitrableV2 { `extraData` configures the court and juror count: ```solidity -// V2 uses uint96 for courtID (not uint256 as in V1 — this is a breaking change) +// V2 uses uint96 for courtID (not uint256 as in V1 - this is a breaking change) bytes memory extraData = abi.encodePacked( - uint96(1), // courtID — 1 = General Court - uint256(3) // minJurors — always use odd numbers to avoid ties + uint96(1), // courtID - 1 = General Court + uint256(3) // minJurors - always use odd numbers to avoid ties ); ``` @@ -220,7 +220,7 @@ function raiseDispute(uint256 _txID) external payable { templateUri ); - // Refund excess — use .call() not .transfer() + // Refund excess - use .call() not .transfer() if (msg.value > cost) { (bool ok,) = payable(msg.sender).call{value: msg.value - cost}(""); require(ok, "Refund failed"); @@ -242,7 +242,7 @@ function rule(uint256 _disputeID, uint256 _ruling) external override { tx.status = Status.Resolved; - // Execute ruling — use .call() not .transfer() to avoid gas limit issues + // Execute ruling - use .call() not .transfer() to avoid gas limit issues if (_ruling == uint256(Ruling.PaySeller)) { (bool ok,) = tx.seller.call{value: tx.amount}(""); require(ok, "Transfer failed"); diff --git a/developers/arbitrable-apps/arbitrable-overview.mdx b/developers/arbitrable-apps/arbitrable-overview.mdx index c9a84f7..1355d6b 100644 --- a/developers/arbitrable-apps/arbitrable-overview.mdx +++ b/developers/arbitrable-apps/arbitrable-overview.mdx @@ -12,6 +12,10 @@ An arbitrable contract is any smart contract that can create disputes and enforc Kleros handles everything in between: juror selection, voting, appeals, and determining the final ruling. + +This section includes both V2 arbitrable contract guides (`IArbitrableV2`) and the V1 protocol standards - [ERC-792](/developers/arbitrable-apps/erc-792) and [ERC-1497](/developers/arbitrable-apps/erc-1497) - along with their integration references ([V1 Arbitrable Apps](/developers/arbitrable-apps/v1-arbitrable-apps), [Centralized Arbitrator](/developers/arbitrable-apps/centralized-arbitrator), [Arbitrable Proxy](/developers/arbitrable-apps/arbitrable-proxy)). + + ## When to Use Kleros Arbitration diff --git a/developers/arbitrable-apps/arbitrable-production.mdx b/developers/arbitrable-apps/arbitrable-production.mdx index 0260f62..1392679 100644 --- a/developers/arbitrable-apps/arbitrable-production.mdx +++ b/developers/arbitrable-apps/arbitrable-production.mdx @@ -228,8 +228,8 @@ Kleros disputes follow a fixed phase sequence. Understand the timing impact on y | Contract | Expected | Deployed | |----------|----------|----------| | KlerosCore | `0x33d0b8879...` | ▢ Match | -| Your Arbitrable | — | ▢ Verified | -| Dispute Template | — | ▢ Accessible | +| Your Arbitrable | - | ▢ Verified | +| Dispute Template | - | ▢ Accessible | ### Initialization @@ -286,7 +286,7 @@ Kleros disputes follow a fixed phase sequence. Understand the timing impact on y ## Kleros V2 on Mainnet -Kleros V2 (Neo) is live on **Arbitrum One** mainnet. Court access is open to all — users can stake PNK and participate as jurors. These items are still relevant for integrators: +Kleros V2 (Neo) is live on **Arbitrum One** mainnet. Court access is open to all - users can stake PNK and participate as jurors. These items are still relevant for integrators: - [ ] **Contract upgrades:** V2 contracts use UUPS proxy patterns and may be upgraded via governance. Subscribe to the [Kleros blog](https://blog.kleros.io) and [Discord](https://discord.gg/kleros) for announcements. - [ ] **Subgraph stability:** Pin to a specific subgraph deployment version in production. Check the [kleros-v2 subgraph README](https://github.com/kleros/kleros-v2/tree/dev/subgraph) for the latest stable deployment IDs. diff --git a/developers/legacy/arbitrable-proxy.mdx b/developers/arbitrable-apps/arbitrable-proxy.mdx similarity index 84% rename from developers/legacy/arbitrable-proxy.mdx rename to developers/arbitrable-apps/arbitrable-proxy.mdx index 1f9a070..89140b5 100644 --- a/developers/legacy/arbitrable-proxy.mdx +++ b/developers/arbitrable-apps/arbitrable-proxy.mdx @@ -6,7 +6,7 @@ description: "Generic proxy contract for creating disputes in Kleros Court witho -This covers the V1 ArbitrableProxy. For V2, the [Dispute Resolver](/legacy/integrate/dispute-resolver) provides a web UI for standalone dispute creation, and the `IDisputeResolver` interface serves a similar role for custom contracts. +This covers the V1 ArbitrableProxy. For V2, the [Dispute Resolver](/developers/products/dispute-resolver/overview) provides a web UI for standalone dispute creation, and the `IDisputeResolver` interface serves a similar role for custom contracts. --- @@ -67,10 +67,10 @@ function withdrawFeesAndRewards( ## Resources - + Arbitration interface specification - + Web-based dispute creation tool for V2 \ No newline at end of file diff --git a/developers/legacy/centralized-arbitrator.mdx b/developers/arbitrable-apps/centralized-arbitrator.mdx similarity index 100% rename from developers/legacy/centralized-arbitrator.mdx rename to developers/arbitrable-apps/centralized-arbitrator.mdx diff --git a/developers/legacy/erc-1497.mdx b/developers/arbitrable-apps/erc-1497.mdx similarity index 98% rename from developers/legacy/erc-1497.mdx rename to developers/arbitrable-apps/erc-1497.mdx index 7b63a11..2b0ad04 100644 --- a/developers/legacy/erc-1497.mdx +++ b/developers/arbitrable-apps/erc-1497.mdx @@ -159,8 +159,6 @@ In V2, ERC-1497 is replaced by: - **`DisputeRequest` event**: Replaces the `Dispute` event, linking disputes to templates by `templateId`. - **Cross-chain evidence**: Evidence can be submitted on either the home or foreign chain, with the Court UI consolidating from both. -See the [Migration Guide](/developers/legacy/migrating-to-v2) for the specific changes. - --- ## References diff --git a/developers/legacy/erc-792.mdx b/developers/arbitrable-apps/erc-792.mdx similarity index 100% rename from developers/legacy/erc-792.mdx rename to developers/arbitrable-apps/erc-792.mdx diff --git a/developers/legacy/v1-arbitrable-apps.mdx b/developers/arbitrable-apps/v1-arbitrable-apps.mdx similarity index 100% rename from developers/legacy/v1-arbitrable-apps.mdx rename to developers/arbitrable-apps/v1-arbitrable-apps.mdx diff --git a/developers/architecture.mdx b/developers/architecture.mdx index fb7dd3c..5f688d4 100644 --- a/developers/architecture.mdx +++ b/developers/architecture.mdx @@ -1,9 +1,32 @@ --- title: "Architecture" -description: "Protocol components and how they interact" +description: "Protocol components and how they interact, across V1 and V2" --- -## System Overview +Kleros runs on two protocol versions. This page covers both: V1 first, then the V2 component architecture in detail. + +## V1 Architecture + +Court V1 is built around a single contract, **KlerosLiquid**, on Ethereum Mainnet and Gnosis Chain. It is monolithic: staking, juror drawing, voting, appeals, and ruling execution all live in one contract. + +```mermaid +graph TB + Arbitrable[Your Contract] -->|createDispute / ERC-792| KlerosLiquid + KlerosLiquid -->|draw + vote + rule| Arbitrable + KlerosLiquid -->|policies| PolicyRegistry + PNK[PNK staking] --> KlerosLiquid +``` + +| Component | Role | +| --- | --- | +| **KlerosLiquid** | Staking, juror drawing, voting, appeals, ruling execution | +| **PNK** | Staking token | +| **PolicyRegistry** | Court policy storage | +| **Arbitrable contracts** | Implement ERC-792 to create disputes and receive rulings | + +V1 uses the ERC-792 (arbitration) and ERC-1497 (evidence) standards, blockhash-based randomness, commit-reveal plurality voting, and a hierarchical subcourt tree. For V1 contract addresses, see [Deployment Addresses](/reference/contracts/deployment-addresses-v1). + +## V2 System Overview Kleros V2 uses a modular architecture where specialized contracts handle specific responsibilities: @@ -55,6 +78,8 @@ Handles juror selection using weighted randomness. - **Phases**: Staking → Generating → Drawing (prevents RNG manipulation) - **Delayed Stakes**: Stake changes queue until the drawing phase completes +Sortition tree simplification is queued as the next piece of contract simplification work (May 2026), and a reworked reward staking mechanism is in planning (May 2026). + ```mermaid graph LR subgraph Phases @@ -79,6 +104,14 @@ Modular voting mechanisms. The protocol ships with **DisputeKitClassic** but sup - Coherence-based rewards (vote with majority = keep stake) - Appeal crowdfunding +**Development status:** Court V2 contracts went through four internal review rounds (Rounds 1–4, September–November 2025), then an external audit by Certora (December 2025–January 2026), with audit responses submitted in January 2026. Internal review completed in April 2026, with findings triaged. Contract simplification across dispute kits was merged (June 2026), and a partial-coherence dispute kit was merged (May 2026). The forking court specification progressed from draft to governance-level discussion (May–June 2026), and the forking dispute kit moved from in-progress to draft (June 2026). + + +Because contract simplification continued after the Certora audit (December 2025–January 2026), the audit does not cover the final version of the contracts. + + +**Specialized dispute kits** include the Argentina Consumer Protection DK (gated, SBT-based), a University DK, and a Shutter DK (commit/reveal with threshold encryption via the Shutter Network). + ### Gateways (Cross-Chain) Enable disputes from other chains to be resolved on Arbitrum. @@ -97,6 +130,20 @@ Enable disputes from other chains to be resolved on Arbitrum. 3. Dispute resolved on Arbitrum 4. Ruling bridged back to mainnet +Recent cross-chain development (see [Vea Bridge](/developers/crosschain/vea-bridge) for details): the VeaShi package was created to package Hashi and Vea contracts for consumption by Kleros V2 (March 2026); deBridge was added as a second bridge protocol alongside LayerZero (February 2026); the Hashi executor was made chain-agnostic (January 2026); `veashi-sdk` was published to npm as `@kleros/veashi-sdk` v0.0.2 (May 2026); new Base ↔ Ethereum and Base ↔ Arbitrum routes were added (June 2026); a three-oracle approach for VeaShi was adopted, with LayerZero and Chainlink CCIP as the two primary oracles and deBridge or Wormhole as a third slot (June 2026); the Envio HyperIndex indexer was integrated into the VeaShi scanner (June 2026); and a second validator became operational (February 2026). + +### Atlas (internal backend) + + +Atlas is an internal backend library for Kleros development teams only. It is not intended for community use or integration. + + +Atlas is the notification and backend services layer. It handles email notifications, IPFS uploads (SIWE-authenticated), keeper bots, and data streaming. It reached v1.6.0 by May 2026. Key capabilities include per-product signup (Court V1, Court V2, Foresight), configurable vote reminders, SendGrid delivery tracking, and PoH V2 email notifications. + +### Components Library (kleros-app) + +A shared UI components library is used by all V2 frontends. `kleros-app` v3.0.1 shipped in June 2026 with product differentiation between signup and IPFS and unsubscribe support, and the file viewer was extracted as a shared component (June 2026). + ## Dispute Lifecycle @@ -123,10 +170,10 @@ Courts form a tree. Appeals can "jump" to parent courts when juror count exceeds ```mermaid flowchart TD - FC[Forking Court\nID: 0, Reserved] --> GC[General Court\nID: 1] - GC --> BT[Blockchain\nTechnical] + FC[Forking Court
ID: 0, Reserved] --> GC[General Court
ID: 1] + GC --> BT[Blockchain
Technical] GC --> CU[Curation] - GC --> EL[English\nLanguage] + GC --> EL[English
Language] BT --> SO[Solidity] style FC fill:#e8e8e8,stroke:#999,stroke-dasharray:5 5 @@ -181,6 +228,14 @@ sequenceDiagram | **Phase system** | Prevents RNG manipulation | | **Guardian/Governor** | Emergency pause capability | +### Audits and security work + +- Court V2 contracts went through four internal review rounds plus an external Certora audit (see Dispute Kits above for the timeline and the note on audit coverage). +- Frontend security audits were conducted across all V1, V2, and PoH frontends, with an XSS attack-vector review (June 2026). +- React vulnerabilities (CVE-55183, CVE-55184, CVE-67779) were patched across multiple applications in a coordinated effort (December 2025). +- The bug bounty program is migrating from Hats Finance (shut down) to alternative platforms. +- Kleros Skills launched at [skills.kleros.io](https://skills.kleros.io) - agent-readable knowledge packs for the protocol (May 2026). Packs available: IPFS Upload and Curate operations. Roadmap: CLI, ERC-8004 agent verification, Escrow v1/v2, and an Arbitrable App Builder. + ## Key Addresses (Arbitrum One) | Contract | Purpose | diff --git a/developers/crosschain/vea-bridge.mdx b/developers/crosschain/vea-bridge.mdx index eeae846..f6f5470 100644 --- a/developers/crosschain/vea-bridge.mdx +++ b/developers/crosschain/vea-bridge.mdx @@ -96,6 +96,11 @@ If a claim is challenged, the message is sent over the canonical bridge. This ca | Arbitrum to Ethereum | Home to Foreign | Fast Bridge | | Ethereum to Arbitrum | Foreign to Home | Simple Bridge | | Arbitrum to Gnosis Chain | Home to Foreign | Fast Bridge (multi-hop via Ethereum in unhappy path) | +| Base ↔ Ethereum | Both | Added June 2026 | +| Base ↔ Arbitrum | Both | Added June 2026 | +| Arbitrum ↔ Story | Both | Deployed and tested January 2026 | + +Bridge dependencies were upgraded to the latest LayerZero and Chainlink CCIP versions (March 2026). Vea does not rely on a direct native bridge between Arbitrum and Gnosis Chain. In the unhappy path, challenged claims are resolved using two Safe Bridges: Arbitrum to Ethereum Mainnet, then Ethereum Mainnet to Gnosis Chain. @@ -137,6 +142,34 @@ Time is partitioned into epochs defined by an `epochPeriod`. Epochs mark the per --- +## Bridge Protocols + +Vea supports multiple underlying bridge protocols: + +- deBridge was added as a second bridge protocol alongside LayerZero (February 2026). The `DeBridgeReporter` contract was deployed and tested, with a full end-to-end message tested on the Story-to-Arbitrum route (February 2026). +- A three-oracle approach for VeaShi was approved (June 2026): LayerZero and Chainlink CCIP as the two primary oracles, with deBridge or Wormhole as a third slot. +- Mainnet deployments were completed on Base and Ethereum with three DVNs in LayerZero (June 2026). + +## VeaShi + +- The VeaShi package packages Hashi and Vea contracts for consumption by Kleros V2 (March 2026). +- `veashi-sdk` was published to npm as `@kleros/veashi-sdk` v0.0.2 (May 2026). +- LayerZero contracts were moved under an adapter layout for consistency (May 2026). +- The Hashi executor was decoupled from the relayer - splitting message indexing from execution and introducing state-file logic for pending messages that don't yet meet the Hashi threshold (May 2026). +- The Hashi executor was made chain-agnostic (January 2026). + +## Validator Infrastructure + +- A second validator became operational (February 2026). +- A validator RPC fallback shipped - a degraded primary RPC no longer takes the validator down (June 2026). +- The relayer error-handling was refactored - listener setup moved out of the per-network loop, with error-per-chain logging (May 2026). +- An RPC provider wrapper handles errors and fallback URLs in both the validator and the relayer (May 2026). + +## Indexing + +- The Envio HyperIndex indexer was integrated into the VeaShi scanner, with the existing subgraph kept as a fallback (June 2026). +- The VeaShi scanner was moved into the Vea monorepo (June 2026). + ## VeaScan [VeaScan](https://veascan.io) is the block explorer for Vea bridge transactions. It displays pending claims, challenge status, and relay history. diff --git a/developers/crosschain/vea-deployment-addresses.mdx b/developers/crosschain/vea-deployment-addresses.mdx index a394404..a171072 100644 --- a/developers/crosschain/vea-deployment-addresses.mdx +++ b/developers/crosschain/vea-deployment-addresses.mdx @@ -9,6 +9,10 @@ description: "Contract addresses for Vea bridge deployments on each supported ro Always verify addresses against the [official Vea repository](https://github.com/kleros/vea) before use. The canonical source is the [Vea GitHub deployment artifacts](https://github.com/kleros/vea/tree/master/contracts/deployments). + +Base and Arbitrum routes were deployed in June 2026. The `veashi-sdk` is available on npm as `@kleros/veashi-sdk` v0.0.2. + + --- ## Testnet Deployments (Arbitrum Sepolia) diff --git a/developers/examples/escrow-contract.mdx b/developers/examples/escrow-contract.mdx index ce6b0e9..ac8604b 100644 --- a/developers/examples/escrow-contract.mdx +++ b/developers/examples/escrow-contract.mdx @@ -1,13 +1,13 @@ --- title: "Escrow Contract" -description: "Build a simple escrow contract with Kleros V2 dispute resolution." +description: "Build a simple escrow contract with Kleros V1 dispute resolution." --- ## Overview -This example demonstrates how to build an escrow contract that uses Kleros Court V2 as an external arbitrator. The contract holds funds in escrow until both parties agree on payment, or a dispute is raised and resolved by Kleros jurors. +This example demonstrates how to build an escrow contract that uses Kleros Court V1 as an external arbitrator, following the ERC-792 arbitration standard and ERC-1497 evidence standard. The contract holds funds in escrow until the payer releases them, or a dispute is raised and resolved by Kleros jurors. -This is a simplified version of the [Escrow V2 product](/developers/products/escrow/overview) to illustrate the core integration pattern. +It is based on the SimpleEscrow tutorial on [docs.kleros.io](https://docs.kleros.io/) and illustrates the core V1 integration pattern. --- @@ -15,128 +15,98 @@ This is a simplified version of the [Escrow V2 product](/developers/products/esc ```solidity // SPDX-License-Identifier: MIT -pragma solidity ^0.8.24; +pragma solidity ^0.7.6; -import {IArbitrableV2, IArbitratorV2} from "@kleros/kleros-v2-contracts/interfaces/IArbitrableV2.sol"; -import {IDisputeTemplateRegistry} from "@kleros/kleros-v2-contracts/interfaces/IDisputeTemplateRegistry.sol"; +import "@kleros/erc-792/contracts/IArbitrable.sol"; +import "@kleros/erc-792/contracts/IArbitrator.sol"; +import "@kleros/erc-792/contracts/erc-1497/IEvidence.sol"; -contract SimpleEscrow is IArbitrableV2 { - enum Status { Created, Reclaimed, Disputed, Resolved } +contract SimpleEscrow is IArbitrable, IEvidence { + address payable public payer = msg.sender; + address payable public payee; + uint256 public value; + IArbitrator public arbitrator; + string public agreement; + uint256 public createdAt; + uint256 public constant reclamationPeriod = 3 days; + uint256 public constant arbitrationFeeDepositPeriod = 3 days; - struct Transaction { - address payable sender; - address payable receiver; - uint256 amount; - uint256 disputeID; - Status status; - } - - IArbitratorV2 public immutable arbitrator; - bytes public arbitratorExtraData; - uint256 public immutable feeTimeout; - uint256 public templateId; + uint256 public reclaimedAt; - mapping(uint256 => Transaction) public transactions; - mapping(uint256 => uint256) public disputeIDtoTxID; - uint256 public txCount; + enum Status { Initial, Reclaimed, Disputed, Resolved } + Status public status; - // Ruling options: 0 = Refuse, 1 = Pay Sender, 2 = Pay Receiver - uint256 constant SENDER_WINS = 1; - uint256 constant RECEIVER_WINS = 2; + uint256 public disputeID; + uint256 constant numberOfRulingOptions = 2; + enum RulingOptions { RefusedToArbitrate, PayerWins, PayeeWins } constructor( - IArbitratorV2 _arbitrator, - bytes memory _arbitratorExtraData, - uint256 _feeTimeout, - IDisputeTemplateRegistry _templateRegistry, - string memory _templateData, - string memory _templateDataMappings - ) { + address payable _payee, + IArbitrator _arbitrator, + string memory _agreement + ) payable { + value = msg.value; + payee = _payee; arbitrator = _arbitrator; - arbitratorExtraData = _arbitratorExtraData; - feeTimeout = _feeTimeout; - templateId = _templateRegistry.setDisputeTemplate( - "", _templateData, _templateDataMappings - ); - } + agreement = _agreement; + createdAt = block.timestamp; - /// @dev Create an escrow transaction. - function createTransaction(address payable _receiver) external payable returns (uint256 txID) { - require(msg.value > 0, "Must send ETH"); - txID = txCount++; - transactions[txID] = Transaction({ - sender: payable(msg.sender), - receiver: _receiver, - amount: msg.value, - disputeID: 0, - status: Status.Created - }); + // ERC-1497: announce the agreement (MetaEvidence) at deployment. + emit MetaEvidence(0, _agreement); } - /// @dev Sender releases payment to receiver (both parties agree). - function pay(uint256 _txID) external { - Transaction storage tx_ = transactions[_txID]; - require(msg.sender == tx_.sender, "Only sender"); - require(tx_.status == Status.Created, "Wrong status"); - tx_.status = Status.Resolved; - // Use .call() not .transfer() — .transfer() can fail with smart contract recipients - (bool ok,) = tx_.receiver.call{value: tx_.amount}(""); - require(ok, "Transfer failed"); + /// @dev Payer releases the funds to the payee. + function releaseFunds() public { + require(status == Status.Initial, "Transaction is not in Initial state."); + if (msg.sender != payer) + require(block.timestamp - createdAt > reclamationPeriod, "Payer still has time to reclaim."); + status = Status.Resolved; + payee.transfer(value); } - /// @dev Raise a dispute with Kleros Court. - function raiseDispute(uint256 _txID) external payable { - Transaction storage tx_ = transactions[_txID]; - require(tx_.status == Status.Created, "Wrong status"); - require( - msg.sender == tx_.sender || msg.sender == tx_.receiver, - "Only parties" - ); - - uint256 cost = arbitrator.arbitrationCost(arbitratorExtraData); - require(msg.value >= cost, "Insufficient fee"); - - tx_.status = Status.Disputed; - tx_.disputeID = arbitrator.createDispute{value: msg.value}( - 2, // number of ruling options - arbitratorExtraData - ); - disputeIDtoTxID[tx_.disputeID] = _txID; - - emit DisputeRequest( - arbitrator, - tx_.disputeID, - _txID, - templateId, - "" - ); - } + /// @dev Payer reclaims the funds, opening a window for the payee to dispute. + function reclaimFunds() public payable { + require(status == Status.Initial || status == Status.Reclaimed, "Cannot reclaim in this state."); + require(msg.sender == payer, "Only the payer can reclaim."); - /// @dev Called by the arbitrator when a ruling is final. - function rule(uint256 _disputeID, uint256 _ruling) external override { - require(msg.sender == address(arbitrator), "Only arbitrator"); - uint256 txID = disputeIDtoTxID[_disputeID]; - Transaction storage tx_ = transactions[txID]; - require(tx_.status == Status.Disputed, "Not disputed"); - - tx_.status = Status.Resolved; - - if (_ruling == SENDER_WINS) { - (bool ok,) = tx_.sender.call{value: tx_.amount}(""); - require(ok, "Transfer failed"); - } else if (_ruling == RECEIVER_WINS) { - (bool ok,) = tx_.receiver.call{value: tx_.amount}(""); - require(ok, "Transfer failed"); + if (status == Status.Reclaimed) { + require(block.timestamp - reclaimedAt > arbitrationFeeDepositPeriod, "Payee still has time to deposit."); + payer.transfer(address(this).balance); + status = Status.Resolved; } else { - // Ruling 0 = Refuse to Arbitrate — split equally as fallback - uint256 half = tx_.amount / 2; - (bool ok1,) = tx_.sender.call{value: half}(""); - (bool ok2,) = tx_.receiver.call{value: tx_.amount - half}(""); - require(ok1 && ok2, "Transfer failed"); + require(msg.value == arbitrator.arbitrationCost(""), "Must deposit the arbitration cost."); + reclaimedAt = block.timestamp; + status = Status.Reclaimed; } + } + + /// @dev Payee deposits the arbitration fee, creating a dispute in Kleros Court. + function depositArbitrationFeeForPayee() public payable { + require(status == Status.Reclaimed, "Transaction is not in Reclaimed state."); + disputeID = arbitrator.createDispute{value: msg.value}(numberOfRulingOptions, ""); + status = Status.Disputed; + // ERC-1497: link the dispute to metaEvidence 0 and evidence group 0. + emit Dispute(arbitrator, disputeID, 0, 0); + } + + /// @dev Called by the arbitrator to enforce the ruling. + function rule(uint256 _disputeID, uint256 _ruling) public override { + require(msg.sender == address(arbitrator), "Only the arbitrator can rule."); + require(status == Status.Disputed, "There must be a dispute to execute a ruling."); + require(_ruling <= numberOfRulingOptions, "Ruling out of bounds."); + + status = Status.Resolved; + if (_ruling == uint256(RulingOptions.PayerWins)) payer.transfer(address(this).balance); + else payee.transfer(address(this).balance); emit Ruling(arbitrator, _disputeID, _ruling); } + + /// @dev Submit evidence for the dispute (ERC-1497). + function submitEvidence(string memory _evidence) public { + require(status != Status.Resolved, "The dispute is already resolved."); + emit Evidence(arbitrator, 0, msg.sender, _evidence); + } } ``` @@ -144,29 +114,33 @@ contract SimpleEscrow is IArbitrableV2 { ## Key Integration Points -**`createDispute()`**: Sends the arbitration fee to KlerosCore and receives a `disputeID`. The `arbitratorExtraData` encodes the court ID and juror count. +**`createDispute()`**: Sends the arbitration fee to the V1 arbitrator (KlerosLiquid) and receives a `disputeID`. The `_extraData` argument (empty string here) can encode the subcourt ID and juror count. -**`rule()`**: KlerosCore calls this when the dispute is resolved. The ruling is enforced immediately by transferring funds. +**`rule()`**: The arbitrator calls this when the dispute is resolved. The ruling is enforced immediately by transferring the escrowed funds. -**`DisputeRequest` event**: Emitted to link the dispute with a display template in the Court V2 UI. The `templateId` references a template registered in the `DisputeTemplateRegistry`. +**ERC-1497 events**: `MetaEvidence` announces the agreement at deployment, `Dispute` links the dispute to that metaEvidence and an evidence group, and `Evidence` records each submission. These are the V1 evidence standard events consumed by the Court V1 and Dispute Resolver interfaces. --- -## Dispute Template +## Agreement (MetaEvidence) -The dispute template tells the Court UI how to display this dispute: +In V1, the agreement is described with an ERC-1497 MetaEvidence JSON document, uploaded to IPFS and passed to the constructor: ```json { - "title": "Escrow Payment Dispute: {{ amount }} ETH", - "description": "Should the funds be released to the receiver or returned to the sender?", + "title": "Escrow Payment Dispute", + "description": "Should the escrowed funds be released to the payee or returned to the payer?", "question": "Which party should receive the escrowed funds?", - "answers": [ - { "title": "Refuse to Rule", "id": "0x0" }, - { "title": "Return to Sender", "id": "0x1" }, - { "title": "Release to Receiver", "id": "0x2" } - ], - "policyURI": "/ipfs/QmEscrowPolicy..." + "rulingOptions": { + "titles": ["Refuse to Arbitrate", "Payer Wins", "Payee Wins"], + "descriptions": [ + "The arbitrator refuses to rule.", + "Return the funds to the payer.", + "Release the funds to the payee." + ] + }, + "category": "Escrow", + "fileURI": "/ipfs/QmEscrowAgreement..." } ``` @@ -174,6 +148,6 @@ The dispute template tells the Court UI how to display this dispute: ## Next Steps -- Add appeal support for losing parties to fund additional rounds -- Add ERC20 token support alongside native ETH -- Add settlement negotiation before disputes reach court \ No newline at end of file +- Add appeal support so a losing party can fund additional rounds +- Add ERC20 token support alongside native ETH (see the token compatibility notes for [Escrow V1](/products/escrow)) +- Review the [ERC-792](/developers/arbitrable-apps/erc-792) and [ERC-1497](/developers/arbitrable-apps/erc-1497) standards in full diff --git a/developers/examples/insurance-claim.mdx b/developers/examples/insurance-claim.mdx index 634cb47..2f096ad 100644 --- a/developers/examples/insurance-claim.mdx +++ b/developers/examples/insurance-claim.mdx @@ -1,11 +1,13 @@ --- title: "Insurance Claim" -description: "Build a decentralized insurance claim contract with Kleros V2 arbitration for disputed claims." +description: "Build a decentralized insurance claim contract with Kleros V1 arbitration for disputed claims." --- ## Overview -This example demonstrates a parametric insurance contract that uses Kleros Court V2 to arbitrate disputed claims. The contract covers a specific insured event (e.g., flight delay, crop failure) and pays out when jurors confirm the event occurred. +This example demonstrates a parametric insurance contract that uses Kleros Court V1 to arbitrate disputed claims, following the ERC-792 arbitration standard and ERC-1497 evidence standard. The contract covers a specific insured event (for example, flight delay or crop failure) and pays out when jurors confirm the event occurred. + +It follows the V1 arbitrable pattern documented on [docs.kleros.io](https://docs.kleros.io/). --- @@ -13,33 +15,32 @@ This example demonstrates a parametric insurance contract that uses Kleros Court ```solidity // SPDX-License-Identifier: MIT -pragma solidity ^0.8.24; +pragma solidity ^0.7.6; -import {IArbitrableV2, IArbitratorV2} from "@kleros/kleros-v2-contracts/interfaces/IArbitrableV2.sol"; -import {IDisputeTemplateRegistry} from "@kleros/kleros-v2-contracts/interfaces/IDisputeTemplateRegistry.sol"; +import "@kleros/erc-792/contracts/IArbitrable.sol"; +import "@kleros/erc-792/contracts/IArbitrator.sol"; +import "@kleros/erc-792/contracts/erc-1497/IEvidence.sol"; -contract InsuranceClaim is IArbitrableV2 { - enum ClaimStatus { None, Filed, Disputed, Resolved } +contract InsuranceClaim is IArbitrable, IEvidence { + enum ClaimStatus { None, Disputed, Resolved } struct Policy { address payable insured; uint256 premium; uint256 coverage; uint256 expiresAt; - string termsURI; // IPFS URI to the policy document + string termsURI; // IPFS URI to the policy document (MetaEvidence) } struct Claim { uint256 policyID; - string evidenceURI; ClaimStatus status; uint256 disputeID; uint256 ruling; } - IArbitratorV2 public immutable arbitrator; + IArbitrator public arbitrator; bytes public arbitratorExtraData; - uint256 public templateId; mapping(uint256 => Policy) public policies; mapping(uint256 => Claim) public claims; @@ -47,25 +48,17 @@ contract InsuranceClaim is IArbitrableV2 { uint256 public policyCount; uint256 public claimCount; - // Ruling: 1 = Approve claim, 2 = Deny claim + uint256 constant numberOfRulingOptions = 2; + // Ruling: 0 = Refuse, 1 = Approve claim, 2 = Deny claim uint256 constant APPROVE = 1; uint256 constant DENY = 2; - constructor( - IArbitratorV2 _arbitrator, - bytes memory _arbitratorExtraData, - IDisputeTemplateRegistry _templateRegistry, - string memory _templateData, - string memory _templateDataMappings - ) { + constructor(IArbitrator _arbitrator, bytes memory _arbitratorExtraData) { arbitrator = _arbitrator; arbitratorExtraData = _arbitratorExtraData; - templateId = _templateRegistry.setDisputeTemplate( - "", _templateData, _templateDataMappings - ); } - /// @dev Purchase an insurance policy. + /// @dev Purchase an insurance policy. The terms document is the MetaEvidence. function purchasePolicy( uint256 _coverage, uint256 _duration, @@ -82,12 +75,15 @@ contract InsuranceClaim is IArbitrableV2 { expiresAt: block.timestamp + _duration, termsURI: _termsURI }); + + // ERC-1497: register the policy terms as MetaEvidence, keyed by policyID. + emit MetaEvidence(policyID, _termsURI); } - /// @dev File a claim against a policy. + /// @dev File a claim, creating a dispute in Kleros Court. function fileClaim( uint256 _policyID, - string calldata _evidenceURI + string calldata _evidence ) external payable returns (uint256 claimID) { Policy storage policy = policies[_policyID]; require(msg.sender == policy.insured, "Only insured"); @@ -98,31 +94,28 @@ contract InsuranceClaim is IArbitrableV2 { claimID = claimCount++; uint256 disputeID = arbitrator.createDispute{value: msg.value}( - 2, + numberOfRulingOptions, arbitratorExtraData ); claims[claimID] = Claim({ policyID: _policyID, - evidenceURI: _evidenceURI, status: ClaimStatus.Disputed, disputeID: disputeID, ruling: 0 }); disputeIDtoClaimID[disputeID] = claimID; - emit DisputeRequest( - arbitrator, - disputeID, - claimID, - templateId, - "" - ); + // ERC-1497: link the dispute to the policy MetaEvidence and an evidence group. + emit Dispute(arbitrator, disputeID, _policyID, claimID); + emit Evidence(arbitrator, claimID, msg.sender, _evidence); } - /// @dev Called by arbitrator when ruling is final. + /// @dev Called by the arbitrator when the ruling is final. function rule(uint256 _disputeID, uint256 _ruling) external override { require(msg.sender == address(arbitrator), "Only arbitrator"); + require(_ruling <= numberOfRulingOptions, "Ruling out of bounds"); + uint256 claimID = disputeIDtoClaimID[_disputeID]; Claim storage claim = claims[claimID]; require(claim.status == ClaimStatus.Disputed, "Not disputed"); @@ -134,7 +127,7 @@ contract InsuranceClaim is IArbitrableV2 { Policy storage policy = policies[claim.policyID]; policy.insured.transfer(policy.coverage); } - // If DENY or refuse to rule, no payout + // If DENY or refuse to rule, no payout. emit Ruling(arbitrator, _disputeID, _ruling); } @@ -148,26 +141,32 @@ contract InsuranceClaim is IArbitrableV2 { ## How It Works -1. **Policy purchase**: A user pays a premium and receives a policy with defined coverage amount, duration, and terms document (stored on IPFS) -2. **Claim filing**: The insured submits a claim with evidence and pays the arbitration fee, which immediately creates a dispute in Kleros Court +1. **Policy purchase**: A user pays a premium and receives a policy with a defined coverage amount, duration, and terms document (stored on IPFS and announced as ERC-1497 MetaEvidence) +2. **Claim filing**: The insured submits evidence and pays the arbitration fee, which immediately creates a dispute in Kleros Court V1 3. **Juror evaluation**: Kleros jurors review the evidence against the policy terms and vote to approve or deny 4. **Payout or denial**: If approved, the coverage amount is transferred to the insured. If denied, no payout occurs --- -## Dispute Template +## Policy Terms (MetaEvidence) + +The policy terms are an ERC-1497 MetaEvidence JSON document uploaded to IPFS: ```json { - "title": "Insurance Claim #{{ claimID }}", - "description": "The insured has filed a claim. Evaluate whether the insured event occurred according to the policy terms.", + "title": "Insurance Claim", + "description": "Evaluate whether the insured event occurred according to the policy terms.", "question": "Should this insurance claim be approved?", - "answers": [ - { "title": "Refuse to Rule", "id": "0x0" }, - { "title": "Approve Claim", "id": "0x1" }, - { "title": "Deny Claim", "id": "0x2" } - ], - "policyURI": "{{ termsURI }}" + "rulingOptions": { + "titles": ["Refuse to Rule", "Approve Claim", "Deny Claim"], + "descriptions": [ + "The arbitrator refuses to rule.", + "The insured event occurred; approve the payout.", + "The insured event did not occur; deny the claim." + ] + }, + "category": "Insurance", + "fileURI": "/ipfs/QmPolicyTerms..." } ``` @@ -181,4 +180,4 @@ This example omits several features needed for production use: - **Claim period**: Add a review period before disputes are raised, allowing the insurer to approve claims without arbitration - **Multi-claim policies**: Support multiple claims against a single policy - **Pool solvency**: Add mechanisms to ensure the insurance pool can cover all outstanding policies -- **Premium pricing**: Calculate premiums based on risk models rather than fixed amounts \ No newline at end of file +- **Premium pricing**: Calculate premiums based on risk models rather than fixed amounts diff --git a/developers/legacy/light-curate.mdx b/developers/legacy/light-curate.mdx deleted file mode 100644 index acd8a28..0000000 --- a/developers/legacy/light-curate.mdx +++ /dev/null @@ -1,123 +0,0 @@ ---- -title: "Light Curate Integration" -description: "Developer guide for integrating with Kleros Light Curate (V1 with subgraph-based storage)" ---- - -# Light Curate: Integration for Devs - - -This covers Light Curate (V1). For V2 Curate, see the [Developers Curate section](/developers/products/curate/overview). - - ---- - -## Overview - -Light Curate significantly decreases deployment and operation costs compared to Curate Classic by changing the data storage strategy: - -- Item data is NOT stored in contract storage. Only the IPFS multihash is stored on-chain. Storage cost is O(1) instead of O(n). -- Item fields are stored in the subgraph via The Graph's IPFS API. No need for `@kleros/gtcr-encoder`. -- Uses EIP-1167 minimal proxy for deployments. Deployment cost dropped from ~7M gas to ~700K gas. - -Tradeoff: other contracts cannot query the TCR for field values on-chain (only the IPFS hash is available). - ---- - -## Reading Data - -### Fetching Items via Subgraph - -Light Curate uses `litems` entities (prefixed with `l`). Pass the TCR address to filter: - -```graphql -{ - litems( - first: 10 - where: { - status: Registered - registryAddress: "0xYOUR_LIST_ADDRESS_LOWERCASE" - } - orderBy: latestRequestResolutionTime - orderDirection: desc - ) { - itemID - data - props { - type - label - description - value - } - } -} -``` - -The `props` field contains decoded item fields directly. No encoder library needed. - -### Fetching a Specific Item - -Item entities have IDs in the format `@`: - -```typescript -const compoundId = `${itemID}@${tcrAddress.toLowerCase()}`; -const result = useQuery(ITEM_DETAILS_QUERY, { variables: { id: compoundId } }); -``` - -### View Contract - -A view contract is available for fetching all relevant info in a single call. - -Gnosis Chain deployment: `0x08e58Bc26CFB0d346bABD253A1799866F269805a` - ---- - -## Writing Data - -### Submitting an Item - -1. Upload item data to IPFS (use both The Graph's IPFS endpoint and Kleros IPFS node) -2. Call `addItem()` on the LightGeneralizedTCR contract with the IPFS URI and required deposit - -``` -REACT_APP_IPFS_GATEWAY=https://cdn.kleros.link -REACT_APP_HOSTED_GRAPH_IPFS_ENDPOINT=https://api.thegraph.com/ipfs -``` - -Pin data to IPFS nodes you control in addition to The Graph's and Kleros' nodes. - -### Challenging and Executing Requests - -- Challenge: call `challengeRequest()` with a deposit -- Execute: call `executeRequest()` after the challenge period passes unchallenged - ---- - -## Subgraph Conventions - -| Entity Prefix | Version | -| --- | --- | -| `litems`, `lrequests`, etc. | Light Curate | -| `items`, `requests`, etc. | Curate Classic | - -Addresses must be **lowercase** in queries. The subgraph does not understand checksummed addresses. - -The hosted service has a **1000 item limit** per query. For larger registries, paginate using `skip` or `id_gt`. - ---- - -## Subgraph Deployment - -If you deployed a list using the factory, it already has a subgraph deployed and available. For custom deployments, see [The Graph documentation](https://thegraph.com/docs/). - ---- - -## Resources - - - - Source code - - - More GraphQL query examples - - \ No newline at end of file diff --git a/developers/legacy/migrating-to-v2.mdx b/developers/legacy/migrating-to-v2.mdx deleted file mode 100644 index b68c16b..0000000 --- a/developers/legacy/migrating-to-v2.mdx +++ /dev/null @@ -1,204 +0,0 @@ ---- -title: "Migrating to V2" -description: "Step-by-step guide for migrating existing Kleros V1 integrations to V2 on Arbitrum." ---- - -## Overview - -Kleros V2 introduces a new arbitration standard, dispute template system, and cross-chain architecture. This guide covers the contract-level changes required to migrate an existing V1 (ERC-792 + ERC-1497) integration to V2. - ---- - -## Interface Changes - -### Arbitrable Interface - - - - ```solidity - import {IArbitrable} from "@kleros/erc-792/contracts/IArbitrable.sol"; - import {IEvidence} from "@kleros/erc-792/contracts/erc-1497/IEvidence.sol"; - - contract MyContract is IArbitrable, IEvidence { - function rule(uint256 _disputeID, uint256 _ruling) external override; - } - ``` - - - ```solidity - import {IArbitrableV2} from "@kleros/kleros-v2-contracts/interfaces/IArbitrableV2.sol"; - - contract MyContract is IArbitrableV2 { - function rule(uint256 _disputeID, uint256 _ruling) external override; - } - ``` - - - -Key change: `IArbitrableV2` combines the arbitrable and evidence interfaces. There is no separate `IEvidence` interface in V2. - -### Arbitrator Interface - - - - ```solidity - IArbitrator public arbitrator; - // Appeals are part of the interface - arbitrator.appeal{value: cost}(disputeID, extraData); - arbitrator.appealCost(disputeID, extraData); - ``` - - - ```solidity - IArbitratorV2 public arbitrator; - // Appeals are NOT part of the interface - // Appeal logic is handled internally by KlerosCore - // Arbitrable contracts do not call appeal() - ``` - - - -Key change: V2 removes appeals from the arbitrator interface. Appeals are managed internally by KlerosCore and funded through the Court UI. Your contract no longer needs appeal-related code. - ---- - -## Evidence and MetaEvidence → Dispute Templates - -### V1: MetaEvidence + Dispute Event - -```solidity -// V1: Emit MetaEvidence at deployment -emit MetaEvidence(0, "/ipfs/QmMetaEvidence..."); - -// V1: Link dispute to MetaEvidence -emit Dispute(arbitrator, disputeID, metaEvidenceID, evidenceGroupID); - -// V1: Submit evidence -emit Evidence(arbitrator, evidenceGroupID, msg.sender, "/ipfs/QmEvidence..."); -``` - -### V2: Dispute Templates + DisputeRequest Event - -```solidity -// V2: Register a template at deployment -IDisputeTemplateRegistry templateRegistry = IDisputeTemplateRegistry(registryAddress); -uint256 templateId = templateRegistry.setDisputeTemplate( - "", // template tag - templateData, // JSON template with Mustache variables - templateDataMappings // maps variables to on-chain data -); - -// V2: Link dispute to template -emit DisputeRequest(arbitrator, disputeID, externalDisputeID, templateId, ""); - -// V2: Submit evidence (same event signature, different import) -// Evidence can be submitted from either home or foreign chain -``` - ---- - -## extraData Format - - - - ```solidity - // Two uint256 values, ABI-packed - bytes memory extraData = abi.encodePacked( - uint256(subcourtID), // e.g., 0 for General Court - uint256(numberOfJurors) // e.g., 3 - ); - ``` - - - ```solidity - // courtID as uint96 + numberOfJurors as uint256 - bytes memory extraData = abi.encodePacked( - uint96(courtID), // e.g., 1 for General Court - uint256(numberOfJurors) // e.g., 3 - ); - ``` - - - -Key changes: -- **Court IDs are renumbered**: V1 uses 0-based court IDs (General Court = `0`). -V2 uses 1-based IDs (General Court = `1`, Forking Court = `0` — reserved). Hardcoded V1 court IDs will silently route disputes to the wrong court. -- `courtID` is encoded as `uint96` instead of `uint256` - - -**Breaking change for hardcoded court IDs.** If your V1 contract hardcoded `subcourtID = 0` for General Court, you must change this to `courtID = 1` for V2. Using `courtID = 0` on V2 targets the reserved Forking Court and will revert. - - ---- - -## Event Changes - -| V1 Event | V2 Replacement | -| --- | --- | -| `MetaEvidence(metaEvidenceID, evidence)` | `DisputeTemplate` registered in `DisputeTemplateRegistry` | -| `Dispute(arbitrator, disputeID, metaEvidenceID, evidenceGroupID)` | `DisputeRequest(arbitrator, disputeID, externalDisputeID, templateId, templateUri)` | -| `Evidence(arbitrator, evidenceGroupID, party, evidence)` | Same event, but now in `IArbitrableV2` | -| `Ruling(arbitrator, disputeID, ruling)` | Same event, now in `IArbitrableV2` | - ---- - -## Chain Migration - -V1 contracts live on Ethereum Mainnet (or Gnosis/Polygon). V2 contracts live on Arbitrum One. - -**If your arbitrable is on Arbitrum:** Integrate directly with KlerosCore. - -**If your arbitrable stays on another chain:** Use the [Foreign Gateway](/developers/crosschain/l2-integration) as your arbitrator. The gateway handles cross-chain dispute creation and ruling relay via [Vea](/developers/crosschain/vea-bridge). - ---- - -## Fee Token Support - -V2 adds ERC-20 fee token support. You can pay arbitration fees in accepted ERC-20 tokens instead of only ETH, **when integrating directly with KlerosCore on Arbitrum**: - -```solidity -// V2: Create dispute with ERC20 fee (direct KlerosCore only) -IERC20 feeToken = IERC20(wethAddress); -uint256 cost = arbitrator.arbitrationCost(extraData, feeToken); -feeToken.approve(address(arbitrator), cost); -arbitrator.createDispute(choices, extraData, feeToken, cost); -``` - - -ERC-20 fees are **not available** when using the `ForeignGateway` for cross-chain arbitration. The gateway's ERC-20 `createDispute` overload reverts with `"Not supported"`. Cross-chain arbitrables must always pay fees in ETH. - - ---- - -## Migration Checklist - - - - Replace `@kleros/erc-792` with `@kleros/kleros-v2-contracts`. Change `IArbitrable` + `IEvidence` to `IArbitrableV2`. - - - Delete any `appeal()`, `appealCost()`, or `appealPeriod()` calls from your contract. V2 handles appeals internally. - - - Create a dispute template JSON and register it with `DisputeTemplateRegistry`. Replace `MetaEvidence` and `Dispute` events with `DisputeRequest`. - - - Change from `abi.encodePacked(uint256, uint256)` to `abi.encodePacked(uint96, uint256)` and use V2 court IDs. - - - Deploy your arbitrable on Arbitrum for direct integration, or use the Foreign Gateway on your current chain for cross-chain disputes. - - - Deploy and test against the V2 testnet contracts on Arbitrum Sepolia before going to production. - - - ---- - -## Reference Contracts - -| Contract | Purpose | Repository | -| --- | --- | --- | -| ArbitrableExample | Minimal V2 arbitrable implementation | [kleros-v2/contracts/](https://github.com/kleros/kleros-v2) | -| DisputeTemplateRegistry | Template registration | [kleros-v2/contracts/](https://github.com/kleros/kleros-v2) | -| ForeignGateway | Cross-chain arbitrator | [kleros-v2/contracts/](https://github.com/kleros/kleros-v2) | \ No newline at end of file diff --git a/developers/legacy/v1-overview.mdx b/developers/legacy/v1-overview.mdx deleted file mode 100644 index bdfeb4d..0000000 --- a/developers/legacy/v1-overview.mdx +++ /dev/null @@ -1,65 +0,0 @@ ---- -title: "V1 Overview" -description: "Overview of Kleros Court V1 architecture, contracts, and deployment status." ---- - -## Status - -Kleros Court V1 is deployed on Ethereum Mainnet, Gnosis Chain, and Polygon. It remains operational for existing integrations. New integrations should use [Kleros V2 on Arbitrum One](/developers/overview). - ---- - -## Architecture - -V1 uses a single `KlerosLiquid` contract that combines arbitration, staking, juror drawing, voting, and appeal logic: - -| Contract | Role | -| --- | --- | -| **KlerosLiquid** | Core court contract handling disputes, juror selection, and ruling enforcement | -| **PNK** | ERC-20 token used for staking and juror incentives | -| **PolicyRegistry** | Stores court policies describing juror guidelines | -| **Arbitrable Contracts** | Implement ERC-792 to interact with KlerosLiquid | - -### V1 vs V2 Differences - -| Feature | V1 | V2 | -| --- | --- | --- | -| Home chain | Ethereum Mainnet | Arbitrum One | -| Arbitration standard | ERC-792 | IArbitratorV2 (no appeal in interface) | -| Evidence standard | ERC-1497 | Dispute Templates + cross-chain evidence | -| Dispute kits | None (monolithic) | Modular (DisputeKitClassic, specialized kits) | -| Voting | Commit-reveal | Commit-reveal (default); Shutter encryption available in testing | -| Cross-chain | Limited (xDAI bridge) | Vea bridge (Ethereum, Gnosis, extensible) | -| Staking | Direct in KlerosLiquid | SortitionModule (sortition tree) | - ---- - -## V1 Deployment Addresses - -### Ethereum Mainnet - -| Contract | Address | -| --- | --- | -| KlerosLiquid | `0x988b3A538b618C7A603e1c11Ab82Cd16dbE28069` | -| PNK | `0x93ED3FBe21207Ec2E8f2d3c3de6e058Cb73Bc04d` | - -### Gnosis Chain - -| Contract | Address | -| --- | --- | -| xKlerosLiquid | See the [kleros-v2 repository](https://github.com/kleros/kleros-v2/tree/master/contracts/deployments) for current addresses | - ---- - -## V1 Standards - -V1 integrations use two ERC standards: - -- **[ERC-792](/developers/legacy/erc-792)**: Arbitration Standard defining the `IArbitrable` and `IArbitrator` interfaces -- **[ERC-1497](/developers/legacy/erc-1497)**: Evidence Standard defining `MetaEvidence`, `Evidence`, and `Dispute` events for sharing dispute context - ---- - -## Migration - -If you have an existing V1 integration and want to migrate to V2, see the [Migration Guide](/developers/legacy/migrating-to-v2). \ No newline at end of file diff --git a/developers/overview.mdx b/developers/overview.mdx index 47d1c60..b4fe5b0 100644 --- a/developers/overview.mdx +++ b/developers/overview.mdx @@ -3,11 +3,18 @@ title: "Overview" description: "Decentralized arbitration for your smart contracts" --- -## What is Kleros V2? +## What is Kleros? -Kleros is a decentralized dispute resolution protocol. Think of it as a **court system for smart contracts** when parties disagree, Kleros provides a trustless way to reach an enforceable ruling. +Kleros is a decentralized dispute resolution protocol. Think of it as a **court system for smart contracts** - when parties disagree, Kleros provides a trustless way to reach an enforceable ruling. -**V2** brings major upgrades: cross-chain support, modular dispute resolution, and improved scalability by operating on Arbitrum. +Kleros is implemented on Ethereum (V1) and Arbitrum (V2): + +- **V1** is production infrastructure running on Ethereum Mainnet and Gnosis Chain. It has been in production since 2018 and continues to receive active development. +- **V2** operates on Arbitrum, with cross-chain support via the [Vea bridge](/developers/crosschain/vea-bridge), modular dispute resolution via dispute kits, and improved scalability. + + +Each product section covers both V1 and V2. V1 integration guides and examples are included directly. V2 pages document technical specifications and contract references. + ## Why Integrate? @@ -16,13 +23,13 @@ Kleros is a decentralized dispute resolution protocol. Think of it as a **court No central authority. Rulings are cryptoeconomically secured by staked jurors.
- Binary yes/no, multiple choice, or nuanced rulings your contract defines the options. + Binary yes/no, multiple choice, or nuanced rulings - your contract defines the options. Disputes can originate from Ethereum mainnet or other chains via the gateway system. - Over $50M in value secured through Kleros arbitration since 2018. + Over $50M in value secured through Kleros arbitration since 2018, with 100+ cases resolved on Court V2 Beta (September 2025).
@@ -42,15 +49,11 @@ Kleros is a decentralized dispute resolution protocol. Think of it as a **court Your Contract → Creates Dispute → Jurors Vote → Ruling Returned → Your Contract Enforces ``` -1. Your contract implements `IArbitrableV2` interface +1. Your contract implements the `IArbitrableV2` interface 2. When a dispute arises, call `createDispute()` with arbitration fees 3. Random jurors are drawn (weighted by staked PNK) 4. Jurors vote, with appeals possible -5. Final ruling is passed back to your contract via `rule()` - - - - +5. The final ruling is passed back to your contract via `rule()` ## Next Steps @@ -61,4 +64,7 @@ Your Contract → Creates Dispute → Jurors Vote → Ruling Returned → Your C Understand the protocol components - \ No newline at end of file + + Reference for every Kleros product + + diff --git a/developers/products/court/overview.mdx b/developers/products/court/overview.mdx new file mode 100644 index 0000000..794953b --- /dev/null +++ b/developers/products/court/overview.mdx @@ -0,0 +1,91 @@ +--- +title: "Court" +description: "The core Kleros dispute resolution interface" +--- + +Kleros Court is the core dispute resolution protocol. This page covers both V1 (Ethereum Mainnet and Gnosis Chain) and V2 (Arbitrum). + +--- + +## V1 (Ethereum Mainnet / Gnosis Chain) + +Court V1 is the production interface for Kleros dispute resolution on Ethereum Mainnet and Gnosis Chain. It has been in production since 2018 and continues to receive active development. + +Technical details: + +- Operates on Ethereum Mainnet and Gnosis Chain +- Uses the ERC-792 arbitration standard and ERC-1497 evidence standard +- Juror selection via a sortition tree with PNK staking +- Staking rewards distributed monthly (KIP-66, implemented September 2025) + +V1 uses a single `KlerosLiquid` contract that combines arbitration, staking, juror drawing, voting, and appeal logic: + +| Contract | Role | +| --- | --- | +| **KlerosLiquid** | Core court contract handling disputes, juror selection, and ruling enforcement | +| **PNK** | ERC-20 token used for staking and juror incentives | +| **PolicyRegistry** | Stores court policies describing juror guidelines | +| **Arbitrable Contracts** | Implement ERC-792 to interact with KlerosLiquid | + +**V1 integration is fully supported.** Developers can use the [ERC-792](/developers/arbitrable-apps/erc-792) and [ERC-1497](/developers/arbitrable-apps/erc-1497) standards (documented under Arbitrable Apps) to build arbitrable contracts that use Court V1. + +### V1 interface + +The Court V1 interface at [court.kleros.io](https://court.kleros.io/) supports: + +- **Wallet-optional browsing**: the interface works without a connected wallet, defaulting to view mode with a Connect prompt, including the switch-to-mainnet modal +- **Dark mode** +- **Notifications via Atlas**: vote reminders (with a fixed, configurable reminder time), dispute outcomes (won/lost), appeals, and appealable disputes, with an unsubscribe option on the settings page +- **Staking rewards exporter**: a paginated, mobile-friendly page showing monthly KIP-66 staking rewards and monthly totals, with APY calculated using adjusted KLEROS supply +- **Per-court vote visibility**: public vs. hidden vote details for each court are visible at staking time +- **Reality case display**: "Invalid" is shown instead of "Refuse to Arbitrate" for Reality cases +- **Registry whitelists**: Seer Curate on Gnosis, the Kleros Tokens Registry, and the Seer Market registry + +For the history of changes, see the [Changelog](/changelog) and the [Kleros blog developer updates](https://blog.kleros.io/tag/developer/). For V1 contract addresses, see [Deployment Addresses V1](/reference/contracts/deployment-addresses-v1). + +--- + +## V2 (Arbitrum) + +Court V2 is the next-generation dispute resolution protocol on Arbitrum. This section documents technical details only. + +Technical details: + +- Modular dispute resolution via pluggable dispute kits (DisputeKitClassic, DisputeKitSybilResistant, and others) +- Cross-chain ruling delivery via the [Vea bridge](/developers/crosschain/vea-bridge) +- Juror selection via the SortitionModule using Chainlink VRF v2.5 for verifiable randomness +- Support for multiple specialized dispute kits per court + +Contract audit status: + +- Four internal review rounds (Rounds 1–4, September–November 2025) with all findings triaged +- External audit by Certora (December 2025–January 2026); audit responses submitted +- Internal review completed April 2026 +- Contract simplification work across dispute kits (May–June 2026) + + +The Certora audit was conducted on the contracts as submitted (December 2025–January 2026). Contract simplification work continued afterward, so the audit does not cover the final version. + + +Specialized dispute kits: + +- Argentina Consumer Protection DK (gated, SBT-based) +- University DK +- Shutter DK (commit/reveal with threshold encryption via Shutter Network) +- Partial-coherence dispute kit (merged) +- Forking dispute kit (in draft) + +Frontend: + +- 100+ cases resolved on Court V2 Beta +- Profile page live; commit logic extracted from the UI for testability +- End-to-end test infrastructure in progress + +For V2 contract addresses, see the [V2 Deployment Addresses](/reference/contracts/deployment-addresses) reference. + +--- + +## Links + +- Court V1: [court.kleros.io](https://court.kleros.io/) +- Court V2: [v2.kleros.builders](https://v2.kleros.builders/) diff --git a/developers/legacy/curate-classic.mdx b/developers/products/curate/curate-classic.mdx similarity index 93% rename from developers/legacy/curate-classic.mdx rename to developers/products/curate/curate-classic.mdx index 6574171..c5f7e39 100644 --- a/developers/legacy/curate-classic.mdx +++ b/developers/products/curate/curate-classic.mdx @@ -6,7 +6,7 @@ description: "Developer guide for integrating with Kleros Curate Classic (V1 on- # Curate Classic: Integration for Devs -This covers Curate Classic (V1) with on-chain storage. For the newer Light Curate with subgraph-based storage, see [Light Curate Integration](/developers/legacy/light-curate). For V2 Curate, see the [Developers Curate section](/developers/products/curate/overview). +This covers Curate Classic (V1) with on-chain storage. For the newer Light Curate with subgraph-based storage, see [Light Curate Integration](/developers/products/curate/light-curate). For V2 Curate, see the [Developers Curate section](/developers/products/curate/overview). --- diff --git a/developers/products/curate/integration.mdx b/developers/products/curate/integration.mdx deleted file mode 100644 index d3c77db..0000000 --- a/developers/products/curate/integration.mdx +++ /dev/null @@ -1,657 +0,0 @@ ---- -title: "Integration Guide" -description: "Frontend implementation, React setup, and event monitoring for Curate V2" - ---- - -## Prerequisites - -Before integrating Curate V2, ensure you have: - -- Node.js 18+ and npm/yarn -- React project with TypeScript (recommended) -- Familiarity with ethers.js v6 - ---- - -## Setup - -### Install Dependencies - -```bash -npm install ethers@6 @tanstack/react-query -``` - -### Environment Configuration - -Create a `.env` file: - -```bash -# RPC Endpoints -NEXT_PUBLIC_RPC_ARBITRUM="https://arb1.arbitrum.io/rpc" -NEXT_PUBLIC_RPC_ARBITRUM_SEPOLIA="https://sepolia-rollup.arbitrum.io/rpc" - -# Optional: For contract deployment -PRIVATE_KEY="your_private_key" -ARBISCAN_API_KEY="your_api_key" -``` - ---- - -## Web3 Context Setup - -### Create Web3 Provider - -```tsx -// context/Web3Provider.tsx -import { createContext, useContext, useState, useCallback, ReactNode } from 'react'; -import { BrowserProvider, JsonRpcSigner } from 'ethers'; - -interface Web3ContextType { - provider: BrowserProvider | null; - signer: JsonRpcSigner | null; - address: string | null; - chainId: number | null; - connect: () => Promise; - disconnect: () => void; -} - -const Web3Context = createContext(undefined); - -export const Web3Provider = ({ children }: { children: ReactNode }) => { - const [provider, setProvider] = useState(null); - const [signer, setSigner] = useState(null); - const [address, setAddress] = useState(null); - const [chainId, setChainId] = useState(null); - - const connect = useCallback(async () => { - if (!window.ethereum) throw new Error("No wallet found"); - - const web3Provider = new BrowserProvider(window.ethereum); - const web3Signer = await web3Provider.getSigner(); - const userAddress = await web3Signer.getAddress(); - const network = await web3Provider.getNetwork(); - - setProvider(web3Provider); - setSigner(web3Signer); - setAddress(userAddress); - setChainId(Number(network.chainId)); - }, []); - - const disconnect = useCallback(() => { - setProvider(null); - setSigner(null); - setAddress(null); - setChainId(null); - }, []); - - return ( - - {children} - - ); -}; - -export const useWeb3 = () => { - const context = useContext(Web3Context); - if (!context) throw new Error('useWeb3 must be used within Web3Provider'); - return context; -}; -``` - ---- - -## Contract Hooks - -### Generic Contract Hook - -```typescript -// hooks/useContract.ts -import { Contract } from 'ethers'; -import { useMemo } from 'react'; -import { useWeb3 } from '../context/Web3Provider'; - -export const useContract = ( - address: string | undefined, - abi: any -): T | null => { - const { signer, provider } = useWeb3(); - - return useMemo(() => { - if (!address) return null; - const signerOrProvider = signer || provider; - return signerOrProvider - ? new Contract(address, abi, signerOrProvider) as T - : null; - }, [address, abi, signer, provider]); -}; -``` - -### Registry Hook - -```typescript -// hooks/useRegistry.ts -import { useQuery } from '@tanstack/react-query'; -import { useContract } from './useContract'; -import CurateABI from '../abis/CurateV2.json'; -import CurateViewABI from '../abis/CurateView.json'; -import { formatEther } from 'ethers'; - -interface RegistryConfig { - governor: string; - relayer: string; - submissionDeposit: bigint; - removalDeposit: bigint; - submissionChallengeDeposit: bigint; - removalChallengeDeposit: bigint; - challengePeriod: bigint; - arbitrationCost: bigint; -} - -export const useRegistry = (curateAddress: string, viewAddress: string) => { - const view = useContract(viewAddress, CurateViewABI); - - return useQuery({ - queryKey: ['registry', curateAddress], - queryFn: async (): Promise => { - if (!view) throw new Error('View contract not ready'); - - const config = await view.fetchArbitrable(curateAddress); - - return { - governor: config.governor, - relayer: config.relayerContract, - submissionDeposit: config.submissionBaseDeposit, - removalDeposit: config.removalBaseDeposit, - submissionChallengeDeposit: config.submissionChallengeBaseDeposit, - removalChallengeDeposit: config.removalChallengeBaseDeposit, - challengePeriod: config.challengePeriodDuration, - arbitrationCost: config.arbitrationCost, - }; - }, - enabled: !!view, - staleTime: 60000, // Cache for 1 minute - }); -}; -``` - -### Item Hook - -```typescript -// hooks/useItem.ts -import { useQuery } from '@tanstack/react-query'; -import { useContract } from './useContract'; -import CurateViewABI from '../abis/CurateView.json'; - -enum Status { - Absent = 0, - Registered = 1, - RegistrationRequested = 2, - ClearingRequested = 3 -} - -interface ItemData { - status: Status; - statusName: string; - disputed: boolean; - sumDeposit: bigint; - requester: string; -} - -export const useItem = (curateAddress: string, viewAddress: string, itemId: string) => { - const view = useContract(viewAddress, CurateViewABI); - - return useQuery({ - queryKey: ['item', curateAddress, itemId], - queryFn: async (): Promise => { - if (!view) throw new Error('View contract not ready'); - - const item = await view.getItem(curateAddress, itemId); - const statusNames = ['Absent', 'Registered', 'RegistrationRequested', 'ClearingRequested']; - - return { - status: item.status, - statusName: statusNames[item.status], - disputed: item.disputed, - sumDeposit: item.sumDeposit, - requester: item.requester, - }; - }, - enabled: !!view && !!itemId, - refetchInterval: 30000, // Refresh every 30 seconds - }); -}; -``` - ---- - -## Submission Hook - -### Submit Item - -```typescript -// hooks/useSubmitItem.ts -import { useState } from 'react'; -import { keccak256, toUtf8Bytes, parseEther } from 'ethers'; -import { useContract } from './useContract'; -import { useRegistry } from './useRegistry'; -import CurateABI from '../abis/CurateV2.json'; - -interface SubmitItemParams { - data: Record; -} - -export const useSubmitItem = (curateAddress: string, viewAddress: string) => { - const [isLoading, setIsLoading] = useState(false); - const [error, setError] = useState(null); - - const curate = useContract(curateAddress, CurateABI); - const { data: registry } = useRegistry(curateAddress, viewAddress); - - const submitItem = async ({ data }: SubmitItemParams) => { - if (!curate || !registry) throw new Error('Contracts not ready'); - - setIsLoading(true); - setError(null); - - try { - const itemString = JSON.stringify(data); - const itemId = keccak256(toUtf8Bytes(itemString)); - - // Calculate total cost - const totalCost = registry.submissionDeposit + registry.arbitrationCost; - - // Submit item - const tx = await curate.addItem(itemString, { value: totalCost }); - const receipt = await tx.wait(); - - return { - itemId, - transactionHash: receipt.hash, - }; - } catch (err) { - const error = err instanceof Error ? err : new Error('Submission failed'); - setError(error); - throw error; - } finally { - setIsLoading(false); - } - }; - - return { submitItem, isLoading, error }; -}; -``` - ---- - -## Challenge Hook - -### Challenge Item - -```typescript -// hooks/useChallengeItem.ts -import { useState } from 'react'; -import { useContract } from './useContract'; -import { useItem } from './useItem'; -import { useRegistry } from './useRegistry'; -import CurateABI from '../abis/CurateV2.json'; - -interface ChallengeParams { - itemId: string; - evidence: { - name: string; - description: string; - supportingInfo?: string; - }; -} - -export const useChallengeItem = (curateAddress: string, viewAddress: string) => { - const [isLoading, setIsLoading] = useState(false); - const [error, setError] = useState(null); - - const curate = useContract(curateAddress, CurateABI); - const { data: registry } = useRegistry(curateAddress, viewAddress); - - const challengeItem = async ({ itemId, evidence }: ChallengeParams) => { - if (!curate || !registry) throw new Error('Contracts not ready'); - - setIsLoading(true); - setError(null); - - try { - // Get item to determine challenge deposit type - const itemInfo = await curate.getItemInfo(itemId); - const status = itemInfo[0]; - - // Status 2 = RegistrationRequested, Status 3 = ClearingRequested - const challengeDeposit = status === 2 - ? registry.submissionChallengeDeposit - : registry.removalChallengeDeposit; - - const totalCost = challengeDeposit + registry.arbitrationCost; - const evidenceString = JSON.stringify(evidence); - - const tx = await curate.challengeRequest(itemId, evidenceString, { - value: totalCost - }); - const receipt = await tx.wait(); - - return { - transactionHash: receipt.hash, - }; - } catch (err) { - const error = err instanceof Error ? err : new Error('Challenge failed'); - setError(error); - throw error; - } finally { - setIsLoading(false); - } - }; - - return { challengeItem, isLoading, error }; -}; -``` - ---- - -## Execute Request Hook - -### Execute Unchallenged Request - -```typescript -// hooks/useExecuteRequest.ts -import { useState } from 'react'; -import { useContract } from './useContract'; -import { useRegistry } from './useRegistry'; -import CurateABI from '../abis/CurateV2.json'; - -export const useExecuteRequest = (curateAddress: string, viewAddress: string) => { - const [isLoading, setIsLoading] = useState(false); - const [error, setError] = useState(null); - - const curate = useContract(curateAddress, CurateABI); - const { data: registry } = useRegistry(curateAddress, viewAddress); - - const canExecute = async (itemId: string): Promise => { - if (!curate || !registry) return false; - - try { - const [status, requestCount] = await curate.getItemInfo(itemId); - - // Must be in a pending state - if (status !== 2 && status !== 3) return false; - - const requestInfo = await curate.getRequestInfo(itemId, requestCount - 1); - const now = Math.floor(Date.now() / 1000); - - return now > Number(requestInfo.submissionTime) + Number(registry.challengePeriod); - } catch { - return false; - } - }; - - const executeRequest = async (itemId: string) => { - if (!curate) throw new Error('Contract not ready'); - - const executable = await canExecute(itemId); - if (!executable) throw new Error('Request cannot be executed yet'); - - setIsLoading(true); - setError(null); - - try { - const tx = await curate.executeRequest(itemId); - const receipt = await tx.wait(); - - return { - transactionHash: receipt.hash, - }; - } catch (err) { - const error = err instanceof Error ? err : new Error('Execution failed'); - setError(error); - throw error; - } finally { - setIsLoading(false); - } - }; - - return { executeRequest, canExecute, isLoading, error }; -}; -``` - ---- - -## Event Monitoring - -### Event Listeners - -```typescript -// hooks/useEventListeners.ts -import { useEffect } from 'react'; -import { useContract } from './useContract'; -import CurateABI from '../abis/CurateV2.json'; - -interface EventCallbacks { - onNewItem?: (itemId: string, data: string, addedDirectly: boolean) => void; - onStatusChange?: (itemId: string, updatedDirectly: boolean) => void; - onDispute?: (disputeId: bigint, requestId: bigint) => void; - onRuling?: (disputeId: bigint, ruling: number) => void; -} - -export const useEventListeners = (curateAddress: string, callbacks: EventCallbacks) => { - const curate = useContract(curateAddress, CurateABI); - - useEffect(() => { - if (!curate) return; - - // Listen for new items - if (callbacks.onNewItem) { - curate.on("NewItem", (itemID, data, addedDirectly) => { - callbacks.onNewItem!(itemID, data, addedDirectly); - }); - } - - // Listen for status changes - if (callbacks.onStatusChange) { - curate.on("ItemStatusChange", (itemID, updatedDirectly) => { - callbacks.onStatusChange!(itemID, updatedDirectly); - }); - } - - // Listen for disputes - if (callbacks.onDispute) { - curate.on("DisputeRequest", (arbitrator, disputeID, requestID, templateId) => { - callbacks.onDispute!(disputeID, requestID); - }); - } - - // Listen for rulings - if (callbacks.onRuling) { - curate.on("Ruling", (arbitrator, disputeID, ruling) => { - callbacks.onRuling!(disputeID, Number(ruling)); - }); - } - - // Cleanup listeners on unmount - return () => { - curate.removeAllListeners(); - }; - }, [curate, callbacks]); -}; -``` - -### Usage Example - -```tsx -// components/RegistryMonitor.tsx -import { useEventListeners } from '../hooks/useEventListeners'; - -export function RegistryMonitor({ curateAddress }: { curateAddress: string }) { - useEventListeners(curateAddress, { - onNewItem: (itemId, data, addedDirectly) => { - console.log('New item:', { - itemId, - data: JSON.parse(data), - addedDirectly - }); - }, - onStatusChange: (itemId, updatedDirectly) => { - console.log(`Item ${itemId} status changed`); - }, - onDispute: (disputeId, requestId) => { - console.log('Dispute created:', { - disputeId: disputeId.toString(), - requestId: requestId.toString() - }); - }, - onRuling: (disputeId, ruling) => { - const outcomes = ['None', 'Requester', 'Challenger']; - console.log(`Dispute ${disputeId} ruled: ${outcomes[ruling]}`); - }, - }); - - return
Monitoring registry events...
; -} -``` - ---- - -## Complete Integration Example - -```tsx -// pages/CuratePage.tsx -import { useState } from 'react'; -import { Web3Provider, useWeb3 } from '../context/Web3Provider'; -import { useRegistry, useItem, useSubmitItem, useChallengeItem } from '../hooks'; -import { formatEther } from 'ethers'; - -const CURATE_ADDRESS = '0x...'; // Your registry address -const VIEW_ADDRESS = '0x...'; // CurateView address - -function CurateContent() { - const { address, connect } = useWeb3(); - const [itemId, setItemId] = useState(''); - - const { data: registry, isLoading: registryLoading } = useRegistry(CURATE_ADDRESS, VIEW_ADDRESS); - const { data: item, isLoading: itemLoading } = useItem(CURATE_ADDRESS, VIEW_ADDRESS, itemId); - const { submitItem, isLoading: submitting } = useSubmitItem(CURATE_ADDRESS, VIEW_ADDRESS); - const { challengeItem, isLoading: challenging } = useChallengeItem(CURATE_ADDRESS, VIEW_ADDRESS); - - if (!address) { - return ( - - ); - } - - return ( -
-

Curate V2 Integration

- - {/* Registry Info */} - {registry && ( -
-

Registry Configuration

-

Submission Deposit: {formatEther(registry.submissionDeposit)} ETH

-

Challenge Period: {Number(registry.challengePeriod) / 3600} hours

-
- )} - - {/* Submit Item */} -
-

Submit New Item

- -
- - {/* Item Details */} - {item && ( -
-

Item Details

-

Status: {item.statusName}

-

Disputed: {item.disputed ? 'Yes' : 'No'}

- - {item.status === 2 && !item.disputed && ( - - )} -
- )} -
- ); -} - -export default function CuratePage() { - return ( - - - - ); -} -``` - ---- - -## Deployment - -### Deploy to Testnet - -```bash -npx hardhat deploy --network arbitrumSepolia -``` - -### Deploy to Mainnet - -```bash -npx hardhat deploy --network arbitrum -``` - -### Verify Contracts - -```bash -npx hardhat verify --network arbitrum DEPLOYED_ADDRESS -``` - ---- - -## Resources - - - - Full source code and deployment scripts - - - JavaScript Ethereum library - - - Development environment for Ethereum - - - Get help with integration - - \ No newline at end of file diff --git a/developers/products/curate/light-curate.mdx b/developers/products/curate/light-curate.mdx new file mode 100644 index 0000000..7ef3d9a --- /dev/null +++ b/developers/products/curate/light-curate.mdx @@ -0,0 +1,348 @@ +--- +title: "Light Curate Integration" +description: "Developer guide for integrating with Kleros Light Curate (V1 with subgraph-based storage)" +--- + +# Light Curate: Integration for Devs + + +This covers Light Curate (V1). For V2 Curate, see the [Developers Curate section](/developers/products/curate/overview). + + +--- + +## Overview + +Light Curate significantly decreases deployment and operation costs compared to Curate Classic by changing the data storage strategy: + +- Item data is NOT stored in contract storage. Only the IPFS multihash is stored on-chain. Storage cost is O(1) instead of O(n). +- Item fields are stored in the subgraph via The Graph's IPFS API. No need for `@kleros/gtcr-encoder`. +- Uses EIP-1167 minimal proxy for deployments. Deployment cost dropped from ~7M gas to ~700K gas. + +Tradeoff: other contracts cannot query the TCR for field values on-chain (only the IPFS hash is available). + +--- + +## Reading Data + +### Fetching Items via Subgraph + +Light Curate uses `litems` entities (prefixed with `l`). Pass the TCR address to filter: + +```graphql +{ + litems( + first: 10 + where: { + status: Registered + registryAddress: "0xYOUR_LIST_ADDRESS_LOWERCASE" + } + orderBy: latestRequestResolutionTime + orderDirection: desc + ) { + itemID + data + props { + type + label + description + value + } + } +} +``` + +The `props` field contains decoded item fields directly. No encoder library needed. + +### Fetching a Specific Item + +Item entities have IDs in the format `@`: + +```typescript +const compoundId = `${itemID}@${tcrAddress.toLowerCase()}`; +const result = useQuery(ITEM_DETAILS_QUERY, { variables: { id: compoundId } }); +``` + +### View Contract + +A view contract is available for fetching all relevant info in a single call. + +Gnosis Chain deployment: `0x08e58Bc26CFB0d346bABD253A1799866F269805a` + +--- + +## Writing Data + +### Submitting an Item + +1. Upload item data to IPFS (use both The Graph's IPFS endpoint and Kleros IPFS node) +2. Call `addItem()` on the LightGeneralizedTCR contract with the IPFS URI and required deposit + +``` +REACT_APP_IPFS_GATEWAY=https://cdn.kleros.link +REACT_APP_HOSTED_GRAPH_IPFS_ENDPOINT=https://api.thegraph.com/ipfs +``` + +Pin data to IPFS nodes you control in addition to The Graph's and Kleros' nodes. + +### Challenging and Executing Requests + +- Challenge: call `challengeRequest()` with a deposit +- Execute: call `executeRequest()` after the challenge period passes unchallenged + +--- + +## MetaEvidence Standard + +MetaEvidence is the single on-chain source of truth for both the human-readable policy and the machine-readable item schema. Always resolve it live from chain events. Never hardcode, cache, or infer it. + +### Two independent streams + +Light Curate (LGTCR) requires two separate MetaEvidence documents: + +| Stream | Governs | Used by | +|---|---|---| +| Registration MetaEvidence | Adding an item | `addItem`, challenging a registration request | +| Clearing MetaEvidence | Removing an item | `removeItem`, challenging a removal request | + +Both are normally emitted at deployment (`_metaEvidenceID = 0` for registration, `= 1` for clearing by convention), but a registry governor can push new MetaEvidence, incrementing the ID. Never assume only IDs 0/1 exist; always take the latest applicable event per stream. + +### Retrieval + +1. Query `eth_getLogs` against the registry address, filtered on the `MetaEvidence` event topic: + ``` + topic0 = 0x61606860eb6c87306811e2695215385101daab53bd6ab4e9f9049aead9363c7d + // MetaEvidence(uint256 indexed _metaEvidenceID, string _evidence) + ``` +2. Sort matching logs by `blockNumber`, then `transactionIndex`, then `logIndex`. +3. Fetch each `_evidence` IPFS pointer via a gateway (for example `https://cdn.kleros.link/ipfs/`). Do not double-prefix `/ipfs/`. +4. Classify each JSON as registration or clearing by its `title`/`description`/ruling-option content ("Add" vs "Remove"), not by log order. Some governor transactions emit a registration event immediately followed by a clearing event in the same block. +5. Use the latest event matching the operation you are performing. If classification is ambiguous, stop and ask a human. + +### Production MetaEvidence shape + +```json +{ + "title": "Add one to ", + "description": "Someone requested to add one to ", + "rulingOptions": { + "titles": ["Yes, Add It", "No, Don't Add It"], + "descriptions": [ + "Select this if the item complies with the required criteria and should be added.", + "Select this if the item does not comply and should not be added." + ] + }, + "category": "Curated Lists", + "question": "Does the comply with the required criteria?", + "fileURI": "/ipfs//policy.pdf", + "evidenceDisplayInterfaceURI": "/ipfs//index.html", + "metadata": { + "tcrTitle": "", + "tcrDescription": "", + "columns": [], + "itemName": "", + "itemNamePlural": "", + "logoURI": "/ipfs//logo.png", + "requireRemovalEvidence": true, + "isTCRofTCRs": false + } +} +``` + +The clearing MetaEvidence uses the identical shape with removal-oriented `title`/`description`/`question`, and reuses the same `metadata.columns`. `metadata.columns` is the authoritative schema of the registry: every submitted `item.json` must contain an identical deep copy of this array. Use lowercase common nouns for `itemName`/`itemNamePlural` (for example `"token"`, `"tokens"`). + +### Field requirements + +| Field | Status | Notes | +|---|---|---| +| `title` | Required | Must unambiguously indicate Add vs Remove | +| `description` | Required | Single sentence recommended | +| `rulingOptions` | Strongly recommended | Juror voting labels, in option order | +| `question` | Required | The question jurors vote on | +| `category` | Required | Conventionally `"Curated Lists"` | +| `fileURI` | Required | Governing policy document; PDF strongly preferred | +| `evidenceDisplayInterfaceURI` | Strongly recommended | ERC-1497 evidence renderer | +| `metadata.tcrTitle` / `tcrDescription` | Required | List identity and description | +| `metadata.itemName` / `itemNamePlural` | Required | Used by frontends for copy | +| `metadata.logoURI` | Required for production | Never deploy production without a logo | +| `metadata.requireRemovalEvidence` | Recommended | Forces removal justification | +| `metadata.columns` | Required | Item schema copied into every `item.json` | + +When calling the factory `deploy(...)`, pass MetaEvidence URIs registration first, clearing second. The constructor assigns `_metaEvidenceID` positionally. + +**Hard stops** (do not deploy): JSON does not parse; `metadata.columns` missing or empty; any column uses an unsupported `type`; `fileURI` missing; production `logoURI` missing; policy is not a PDF and the risk was not accepted; both streams not validated. + +--- + +## item.json Standard + +`item.json` is uploaded to IPFS and referenced on-chain via `addItem(string _item)`. + +```json +{ + "columns": [ + { "label": "Name", "description": "The token name.", "type": "text", "isIdentifier": true } + ], + "values": { "Name": "Pinakion" } +} +``` + +Construction rules (non-negotiable): + +- `columns` must be a verbatim deep copy of the active `MetaEvidence.metadata.columns` (same labels, descriptions, types, `isIdentifier` flags, same order). Even a grammar fix violates the contract. +- `values` is the only dynamic part. +- `Object.keys(values)` must exactly equal `columns.map(c => c.label)`, in the same order. No missing, extra, renamed, or reordered keys. +- Never reconstruct the schema from UI text, screenshots, old docs, or memory; always pull `metadata.columns` from the currently active MetaEvidence. + +Common failures to reject in review: renaming a label, reordering columns, rewriting descriptions, changing `isIdentifier`, using `type: "url"`, or submitting partial/placeholder values. + +--- + +## Field Type Standard + +Only these type strings are valid for Curate V1 (GTCR) columns. Do not use V2-only spellings unless a live MetaEvidence proves that spelling is already in production for the list. + +| Type | Value format | Notes | +|---|---|---| +| `text` | Plain string | | +| `long text` | Multi-line string | Never an identifier | +| `link` | URL string | Use instead of `url` | +| `address` | `0x`-prefixed EVM address | | +| `rich address` | `::
` | See below | +| `image` | `/ipfs//` | Path form, not a gateway URL; never an identifier | +| `file` | `/ipfs//` | Requires `allowedFileTypes`; never an identifier | +| `number` | Match existing submissions (strings are common) | | +| `boolean` | `"true"` / `"false"` strings | | +| `GTCR address` | Address of another GTCR list | List-of-lists schemas only | + +Forbidden aliases: `url` → `link`; `string` → `text`; `markdown` → `long text`; `bool` → `boolean`; `integer`/`int`/`float`/`decimal` → `number`; `longText`/`richAddress`/`chain` (V2 spellings) → `long text`/`rich address`. Using an unsupported type surfaces as an interface error such as `Unhandled input type url`. + +Identifier rules: at least one identifier column is required; up to five are supported; `image`, `file`, and `long text` must never be identifiers. For multi-chain token registries, prefer `rich address` over plain `address`. + +--- + +## Rich Address Standard + +`rich address` is a CAIP-style value that references an address on a specific chain, avoiding the ambiguity of a bare `0x...` string: + +``` +::
+// EVM / Ethereum Mainnet: +eip155:1:0x1234567890123456789012345678901234567890 +``` + +Namespaces: `eip155` (EVM chains), `bip122` (Bitcoin-like), `solana`, `tvm` (TON), `stacks`. Common `eip155` reference IDs include Ethereum Mainnet `1`, Optimism `10`, BNB Smart Chain `56`, Gnosis `100`, Polygon `137`, Base `8453`, Arbitrum One `42161`, Avalanche `43114`, Linea `59144`, and Sepolia `11155111`. + +Never infer the target chain of a rich address from surrounding context; always confirm it explicitly. A bare address resolved under the wrong `referenceId` silently points to a different account on a different chain. + +--- + +## Deposit Computation + +Curate V1 deposits are paid entirely in the chain's native token (ETH on Mainnet/Sepolia, xDAI on Gnosis). + +**Never hardcode a deposit.** Deposit parameters are governance-controlled. Compute live from on-chain reads immediately before building a transaction. The frontend shows only the base deposit; sending only that as `msg.value` reverts, because the contract requires base deposit plus arbitration cost in a single value. + +| Action | Formula | +|---|---| +| `addItem` | `submissionBaseDeposit() + arbitrationCost` | +| `removeItem` | `removalBaseDeposit() + arbitrationCost` | +| `challengeRequest` (against registration) | `submissionChallengeBaseDeposit() + arbitrationCost` | +| `challengeRequest` (against removal) | `removalChallengeBaseDeposit() + arbitrationCost` | + +`arbitrationCost` is derived from `registry.arbitrator()` and `registry.arbitratorExtraData()`, then `IArbitrator(arbitrator).arbitrationCost(extraData)`. + +Appeal funding: `requiredForSide = appealCost + appealCost * feeStakeMultiplier / MULTIPLIER_DIVISOR`, where the multiplier is `sharedStakeMultiplier()` (no ruling yet), `winnerStakeMultiplier()` (side matches the current ruling), or `loserStakeMultiplier()` (side opposes it). The losing side must fund before the midpoint of the appeal window. + +--- + +## Contract Interface (LightGeneralizedTCR) + +**Write functions:** + +```solidity +function addItem(string _item) external payable +function removeItem(bytes32 _itemID, string _evidence) external payable +function challengeRequest(bytes32 _itemID, string _evidence) external payable +function submitEvidence(bytes32 _itemID, string _evidence) external +function fundAppeal(bytes32 _itemID, uint8 _side) external payable +function executeRequest(bytes32 _itemID) external +function withdrawFeesAndRewards(address _beneficiary, bytes32 _itemID, uint256 _requestID, uint256 _roundID) external +``` + +`_side` in `fundAppeal` uses the Party enum: `0 = None`, `1 = Requester`, `2 = Challenger`. + +**Key read functions:** `submissionBaseDeposit()`, `removalBaseDeposit()`, `submissionChallengeBaseDeposit()`, `removalChallengeBaseDeposit()`, `challengePeriodDuration()`, `arbitrator()`, `arbitratorExtraData()`, `winnerStakeMultiplier()`, `loserStakeMultiplier()`, `sharedStakeMultiplier()`, `MULTIPLIER_DIVISOR()`, `getItemInfo(bytes32)`, `getRequestInfo(bytes32, uint256)`. + +**Key events:** + +```solidity +event MetaEvidence(uint256 indexed _metaEvidenceID, string _evidence) +event NewItem(bytes32 indexed _itemID, string _data, bool _addedDirectly) +event RequestSubmitted(bytes32 indexed _itemID, uint256 indexed _requestIndex) +event Evidence(address indexed _arbitrator, uint256 indexed _evidenceGroupID, address indexed _party, string _evidence) +event Dispute(address indexed _arbitrator, uint256 indexed _disputeID, uint256 _metaEvidenceID, uint256 _evidenceGroupID) +event Ruling(address indexed _arbitrator, uint256 indexed _disputeID, uint256 _ruling) +``` + +**Factory:** `deploy(address _arbitrator, bytes _arbitratorExtraData, address _connectedTCR, string _registrationMetaEvidence, string _clearingMetaEvidence, address _governor, uint256[4] _baseDeposits, uint256 _challengePeriodDuration, uint256[3] _stakeMultipliers, address _relayContract)`, emitting `NewGTCR(address)`. Do not hardcode the factory address; verify it per chain. + +**View helper:** `LightGeneralizedTCRView.fetchArbitrable(address)` returns all deposit parameters in a single call. Prefer it for aggregated reads; use direct contract reads as final truth for critical values. + +--- + +## Registry Verification + +Before touching MetaEvidence or deposits for an unfamiliar address: + +1. Confirm the `chainId` matches intent (Mainnet `1`, Sepolia `11155111`, Gnosis `100`). +2. Call `eth_getCode(listAddress)` on that chain. If the result is `0x`, it is not a contract there; stop. +3. Perform a hallmark read (`submissionBaseDeposit()` or `arbitrator()`). If it reverts, this is not a valid LGTCR instance; stop. + +--- + +## Submit an Item (end-to-end) + +1. Fetch the latest registration MetaEvidence. +2. Read the policy at `fileURI` before building anything. +3. Build `item.json` from `metadata.columns`; run a schema-drift audit against a recent `NewItem` sample if this is your first submission. +4. Upload `item.json` to IPFS to obtain `/ipfs/`. +5. Compute the live deposit: `submissionBaseDeposit() + arbitrationCost`. +6. Simulate the transaction with identical calldata and `msg.value`. +7. Call `addItem("/ipfs/")` with `msg.value = deposit`. + + +Deploying a list does not make it visible on the Curate frontend. The public list-of-lists mechanism uses Curate Classic (`GeneralizedTCR`), not Light Curate's `addItem(string)`; submitting a new list for discoverability is a separate, optional workflow. + + +--- + +## Subgraph Conventions + +| Entity Prefix | Version | +| --- | --- | +| `litems`, `lrequests`, etc. | Light Curate | +| `items`, `requests`, etc. | Curate Classic | + +Addresses must be **lowercase** in queries. The subgraph does not understand checksummed addresses. + +The hosted service has a **1000 item limit** per query. For larger registries, paginate using `skip` or `id_gt`. + +--- + +## Subgraph Deployment + +If you deployed a list using the factory, it already has a subgraph deployed and available. For custom deployments, see [The Graph documentation](https://thegraph.com/docs/). + +--- + +## Resources + + + + Source code + + + More GraphQL query examples + + \ No newline at end of file diff --git a/developers/products/curate/overview.mdx b/developers/products/curate/overview.mdx index 71305ea..c4b30b8 100644 --- a/developers/products/curate/overview.mdx +++ b/developers/products/curate/overview.mdx @@ -1,24 +1,50 @@ --- -title: "Curate V2 Overview" -description: "Decentralized system for creating community-curated lists on the blockchain" - +title: "Curate" +description: "Decentralized curation protocol for community-governed registries" --- ## Introduction -Curate V2 is a decentralized system for creating community-curated lists on the blockchain. Anyone can submit items, challenge entries, and participate through economic incentives. When disputes arise, they're resolved through Kleros Court. +Curate is a decentralized system for creating community-curated lists on the blockchain. Anyone can submit items, challenge entries, and participate through economic incentives. When disputes arise, they're resolved through Kleros Court. This page covers both V1 (Classic and Light Curate on Ethereum / Gnosis Chain) and V2 (Arbitrum). Core contract interfaces and data structures - - Frontend implementation and event monitoring + + V1 integration guide - full TCR + + + V1 integration guide - simplified TCR + + + Registry reference --- +## V1 - Curate Classic and Light Curate (Ethereum / Gnosis Chain) + +Curate Classic is the full Token-Curated Registry, and Light Curate is the simplified, higher-volume variant. Both are on Ethereum and Gnosis Chain and are eligible for direct integration by third-party developers. + +**Full V1 integration guides are available:** see the [Curate Classic](/developers/products/curate/curate-classic) and [Light Curate](/developers/products/curate/light-curate) subpages. For V1 contract addresses, see [Deployment Addresses](/reference/contracts/deployment-addresses-v1). + +--- + +## V2 - Curate V2 (Arbitrum) + +The sections below document Curate V2 technical details. + +Technical notes for integrators: + +- **Evidence handling**: Curate V2 does not use a separate Evidence Module; evidence submission is handled directly by the `CurateV2` and `CurateFactory` contracts +- **Subgraph**: the schema includes dedicated fields for requester and challenger evidence +- **Frontend stack**: the interface uses Tailwind CSS and the shared components library, including the shared file viewer +- **Developer documentation**: basic developer documentation is available in the [Curate V2 GitHub repository](https://github.com/kleros/curate-v2) + +--- + ## Deployment @@ -226,6 +252,20 @@ This prevents governance from affecting ongoing disputes by changing arbitrator --- +## Stake Curate + +Stake Curate is part of the Curate product family. It uses V1 Kleros Court on Gnosis Chain for dispute resolution. Unlike traditional Curate, where deposits are returned after listing, Stake Curate keeps deposits locked - anyone can challenge at any time, and challengers earn bounties. It launched in January 2026, with its first use case being Battle-Tested DeFi Vaults. + +--- + +## Scout + +Scout is the primary frontend for the Curate-based address tag registries. It reached its definitive version in May 2026 with over 2.6 million curated on-chain addresses. For technical details, chain support, partners, and the GTCR Indexer, see the [Scout page](/developers/products/scout/overview). + +The GTCR Indexer schema was extended with challenge transaction hashes, challenge dates, and appeal transaction hashes (v0.1.7, April 2026), with an Envio branch maintained alongside the main branch. + +--- + ## Resources diff --git a/developers/products/curate/registries.mdx b/developers/products/curate/registries.mdx index 56aaaf4..8685102 100644 --- a/developers/products/curate/registries.mdx +++ b/developers/products/curate/registries.mdx @@ -1,7 +1,7 @@ --- title: "Kleros Registries" -description: "Address Tags, Tokens, CDN, and ATQ — the four live Kleros curation registries, their data models, subgraph access, and consumer integrations" +description: "Address Tags, Tokens, CDN, and ATQ - the four live Kleros curation registries, their data models, subgraph access, and consumer integrations" --- Kleros runs four production curation registries built on Curate V2. Each registry curates a specific type of data; disputed entries are resolved by Kleros Court. Together they form the core data layer used by wallets, block explorers, and token lists to display trusted metadata for contracts and tokens. @@ -9,7 +9,7 @@ Kleros runs four production curation registries built on Curate V2. Each registr | Registry | Short name | What it curates | Chain | |----------|-----------|-----------------|-------| | Address Tags | ATR | Human-readable tags for contract addresses | Gnosis Chain | -| Tokens | — | ERC-20 token metadata (name, symbol, logo, decimals) | Gnosis Chain | +| Tokens | - | ERC-20 token metadata (name, symbol, logo, decimals) | Gnosis Chain | | Contract Domain Names | CDN | Mapping from contract address → web domain | Gnosis Chain | | Address Tag Query | ATQ | Batch meta-registry of NPM packages that generate address tag data | Gnosis Chain | @@ -51,7 +51,7 @@ The registry is indexed by an Envio-hosted subgraph (private deployment). Query - Addresses must be **lowercase** in `where` filters - Filter by `chain_id` in `props` to narrow to a specific network -- Items with `ClearingRequested` are still active — include them in "active tags" queries +- Items with `ClearingRequested` are still active - include them in "active tags" queries ### Resolution Rules @@ -252,7 +252,7 @@ Consumers typically fetch a pre-built static export (JSON file) rather than quer ## Architecture -### Level 1 — System Context +### Level 1 - System Context ``` ┌─────────────────────┐ @@ -283,7 +283,7 @@ Consumers typically fetch a pre-built static export (JSON file) rather than quer └─────────────────────┘ ``` -### Level 2 — Container View +### Level 2 - Container View ``` Gnosis Chain diff --git a/developers/products/curate/smart-contracts.mdx b/developers/products/curate/smart-contracts.mdx index 375e406..0787bf5 100644 --- a/developers/products/curate/smart-contracts.mdx +++ b/developers/products/curate/smart-contracts.mdx @@ -88,7 +88,7 @@ function initialize( ### Example Initialization ```javascript -// Court ID must be uint96, juror count uint256 — matches IArbitratorV2 spec +// Court ID must be uint96, juror count uint256 - matches IArbitratorV2 spec const extraData = ethers.solidityPacked( ["uint96", "uint256"], [1, 3] // Court ID 1 (General Court), 3 jurors @@ -153,16 +153,16 @@ A submitted item must be a JSON object with one key per column label: } ``` -The `itemID` is `keccak256(abi.encodePacked(itemJSON))` — the hash of the exact JSON string submitted. The data mappings system uses this column structure to extract `{{itemName}}` and `{{itemDescription}}` template variables. +The `itemID` is `keccak256(abi.encodePacked(itemJSON))` - the hash of the exact JSON string submitted. The data mappings system uses this column structure to extract `{{itemName}}` and `{{itemDescription}}` template variables. --- -## `arbitrationParamsIndex` — Versioning +## `arbitrationParamsIndex` - Versioning Each `Request` stores a `uint24 arbitrationParamsIndex` that snapshots the registry's arbitration parameters at submission time. This is critical: if the governor updates the arbitrator or extraData after a request is submitted, the **original parameters are preserved** for that request's challenge and dispute lifecycle. This means: -- Challengers must use the **same arbitrationParamsIndex** as the original submission — fetch it from the request before challenging +- Challengers must use the **same arbitrationParamsIndex** as the original submission - fetch it from the request before challenging - Cost calculations must use the arbitration params at `request.arbitrationParamsIndex`, not the current params ```solidity @@ -175,7 +175,7 @@ uint256 cost = arb.arbitrationCost(extraData); --- -## Registration vs Removal — Separate Dispute Templates +## Registration vs Removal - Separate Dispute Templates Curate V2 uses **two separate dispute templates**: one for registration requests and one for removal (clearing) requests. They have different answer logic: diff --git a/developers/products/dispute-resolver/overview.mdx b/developers/products/dispute-resolver/overview.mdx new file mode 100644 index 0000000..50d68ee --- /dev/null +++ b/developers/products/dispute-resolver/overview.mdx @@ -0,0 +1,21 @@ +--- +title: "Dispute Resolver" +description: "V1 tool for creating disputes in Kleros Court without a custom arbitrable contract" +--- + +The Dispute Resolver (formerly "Resolve") is a V1 tool that lets users create disputes in Kleros Court directly, without building a custom arbitrable contract. Users define the dispute question, options, and evidence, then submit it to Court for resolution. Evidence submission and appeal management happen through the Dispute Resolver interface. + +In V2, the ability to create disputes directly is integrated into the Court interface. + +--- + +## Technical notes + +- **File uploads**: evidence uploads go through Atlas to IPFS, with a SIWE info message at the upload step +- **Evidence display**: the interface fetches data from dynamic scripts for flexible evidence display, and normalizes PoH evidence payloads (including older submissions and non-object payloads) +- **MetaEvidence**: fetched via an API-based approach +- **Realitio cases**: ruling options display correctly for Realitio disputes +- **Networks**: Base Sepolia is supported alongside the existing networks +- **Dispute creation**: the create-dispute form validates inputs before submission + +For the history of changes, see the [Changelog](/changelog) and the [Kleros blog developer updates](https://blog.kleros.io/tag/developer/). diff --git a/developers/products/escrow/integration.mdx b/developers/products/escrow/integration.mdx deleted file mode 100644 index f597d6c..0000000 --- a/developers/products/escrow/integration.mdx +++ /dev/null @@ -1,686 +0,0 @@ ---- -title: "Integration Guide" -description: "React hooks, Web3 setup, and frontend implementation for Escrow V2" - ---- - -## Prerequisites - -Before integrating Escrow V2, ensure you have: - -- Node.js 18+ and npm/yarn -- React 18+ project with TypeScript -- Familiarity with Wagmi v2 and Viem - ---- - -## Web3 Provider Setup - -### Install Dependencies - -```bash -npm install @reown/appkit @reown/appkit-adapter-wagmi wagmi viem @tanstack/react-query -``` - -### Configure Provider - -```typescript -// providers/Web3Provider.tsx -import { arbitrum, arbitrumSepolia, mainnet } from '@reown/appkit/networks'; -import { createAppKit } from '@reown/appkit/react'; -import { WagmiAdapter } from '@reown/appkit-adapter-wagmi'; -import { http, fallback, webSocket } from 'wagmi'; -import { WagmiProvider } from 'wagmi'; -import { QueryClient, QueryClientProvider } from '@tanstack/react-query'; - -const isProduction = process.env.NODE_ENV === 'production'; - -// Alchemy transport helper -const alchemyTransport = (chainId: number) => - fallback([ - http(`https://arb-mainnet.g.alchemy.com/v2/${process.env.NEXT_PUBLIC_ALCHEMY_API_KEY}`), - webSocket(`wss://arb-mainnet.g.alchemy.com/v2/${process.env.NEXT_PUBLIC_ALCHEMY_API_KEY}`) - ]); - -const chains = [ - isProduction ? arbitrum : arbitrumSepolia, - mainnet, // Always included for ENS resolution -] as const; - -const wagmiAdapter = new WagmiAdapter({ - networks: chains, - projectId: process.env.NEXT_PUBLIC_WALLETCONNECT_PROJECT_ID!, - transports: { - [arbitrum.id]: alchemyTransport(arbitrum.id), - [arbitrumSepolia.id]: alchemyTransport(arbitrumSepolia.id), - [mainnet.id]: alchemyTransport(mainnet.id), - }, -}); - -createAppKit({ - adapters: [wagmiAdapter], - networks: chains, - defaultNetwork: isProduction ? arbitrum : arbitrumSepolia, - projectId: process.env.NEXT_PUBLIC_WALLETCONNECT_PROJECT_ID!, - allowUnsupportedChain: true, - themeVariables: { - '--w3m-color-mix': '#6134FE', - '--w3m-color-mix-strength': 20, - '--w3m-z-index': 10000, - }, -}); - -const queryClient = new QueryClient(); - -export default function Web3Provider({ children }: { children: React.ReactNode }) { - return ( - - - {children} - - - ); -} -``` - ---- - -## Contract Configuration - -### Addresses and ABIs - -```typescript -// config/contracts.ts -import { Address } from 'viem'; - -export const ESCROW_ADDRESSES = { - arbitrum: { - escrow: '0x79530E7Bb3950A3a4b5a167816154715681F2f6c' as Address, - view: '0x3Fed94ee4FA1B5665DB84489f913E2c7e1290459' as Address, - }, - arbitrumSepolia: { - escrow: '0x5ef185810BCe41c03c9E5ca271B8C91F1024F953' as Address, - view: '0x6451046caB9291a919FCba045bf6Bb8E0Bb71467' as Address, - }, -} as const; - -// Import ABIs from the escrow-v2 package or copy from GitHub -import EscrowUniversalABI from './abis/EscrowUniversal.json'; -import EscrowViewABI from './abis/EscrowView.json'; - -export { EscrowUniversalABI, EscrowViewABI }; -``` - -### Get Contract Address Hook - -```typescript -// hooks/useEscrowAddress.ts -import { useAccount } from 'wagmi'; -import { ESCROW_ADDRESSES } from '../config/contracts'; - -export function useEscrowAddress() { - const { chainId } = useAccount(); - - return chainId === 42161 - ? ESCROW_ADDRESSES.arbitrum - : ESCROW_ADDRESSES.arbitrumSepolia; -} -``` - ---- - -## Transaction Creation - -### Create Transaction Hook - -```typescript -// hooks/useCreateTransaction.ts -import { useWriteContract, useWaitForTransactionReceipt, useAccount, useReadContract } from 'wagmi'; -import { parseEther, parseUnits, Address } from 'viem'; -import { useEscrowAddress } from './useEscrowAddress'; -import { EscrowUniversalABI } from '../config/contracts'; - -interface TransactionMetadata { - title: string; - description: string; - extraDescriptionUri?: string; - // For crypto swaps - otherChain?: string; - otherChainAddress?: string; - otherAsset?: string; - otherAmount?: string; -} - -interface CreateTransactionParams { - seller: Address; - amount: string; - token: { - address: Address | 'native'; - decimals: number; - symbol: string; - }; - deadline: Date; - metadata: TransactionMetadata; -} - -// Helper function to create data URI from metadata -function createMetadataUri(metadata: TransactionMetadata): string { - const jsonString = JSON.stringify(metadata); - const base64Encoded = btoa(jsonString); - return `data:application/json;base64,${base64Encoded}`; -} - -export function useCreateTransaction() { - const { escrow } = useEscrowAddress(); - const { writeContractAsync, data: hash } = useWriteContract(); - const { isLoading, isSuccess } = useWaitForTransactionReceipt({ hash }); - - const createTransaction = async (params: CreateTransactionParams) => { - const deadlineTimestamp = BigInt(Math.floor(params.deadline.getTime() / 1000)); - const metadataUri = createMetadataUri(params.metadata); - - const amount = params.token.address === 'native' - ? parseEther(params.amount) - : parseUnits(params.amount, params.token.decimals); - - if (params.token.address === 'native') { - return await writeContractAsync({ - address: escrow, - abi: EscrowUniversalABI, - functionName: 'createNativeTransaction', - args: [deadlineTimestamp, metadataUri, params.seller], - value: amount, - }); - } else { - // For ERC20, ensure approval is granted first - return await writeContractAsync({ - address: escrow, - abi: EscrowUniversalABI, - functionName: 'createERC20Transaction', - args: [ - amount, - params.token.address, - deadlineTimestamp, - metadataUri, - params.seller, - ], - }); - } - }; - - return { - createTransaction, - isLoading, - isSuccess, - transactionHash: hash - }; -} -``` - -### Usage Example - -```tsx -// components/CreateTransactionForm.tsx -import { useCreateTransaction } from '../hooks/useCreateTransaction'; -import { Address } from 'viem'; - -export function CreateTransactionForm() { - const { createTransaction, isLoading, isSuccess } = useCreateTransaction(); - - const handleSubmit = async () => { - try { - const hash = await createTransaction({ - seller: '0x...' as Address, - amount: '0.1', - token: { address: 'native', decimals: 18, symbol: 'ETH' }, - deadline: new Date(Date.now() + 7 * 24 * 60 * 60 * 1000), // 7 days - metadata: { - title: 'Website Development', - description: 'Build a responsive landing page', - }, - }); - console.log('Transaction created:', hash); - } catch (error) { - console.error('Failed to create transaction:', error); - } - }; - - return ( - - ); -} -``` - ---- - -## Transaction Management - -### Payment and Reimbursement Hooks - -```typescript -// hooks/useTransactionActions.ts -import { useWriteContract } from 'wagmi'; -import { useEscrowAddress } from './useEscrowAddress'; -import { EscrowUniversalABI } from '../config/contracts'; - -export function usePay() { - const { escrow } = useEscrowAddress(); - const { writeContractAsync, isPending } = useWriteContract(); - - const pay = async (transactionId: bigint, amount: bigint) => { - return await writeContractAsync({ - address: escrow, - abi: EscrowUniversalABI, - functionName: 'pay', - args: [transactionId, amount], - }); - }; - - return { pay, isPending }; -} - -export function useReimburse() { - const { escrow } = useEscrowAddress(); - const { writeContractAsync, isPending } = useWriteContract(); - - const reimburse = async (transactionId: bigint, amount: bigint) => { - return await writeContractAsync({ - address: escrow, - abi: EscrowUniversalABI, - functionName: 'reimburse', - args: [transactionId, amount], - }); - }; - - return { reimburse, isPending }; -} - -export function useExecuteTransaction() { - const { escrow } = useEscrowAddress(); - const { writeContractAsync, isPending } = useWriteContract(); - - const executeTransaction = async (transactionId: bigint) => { - return await writeContractAsync({ - address: escrow, - abi: EscrowUniversalABI, - functionName: 'executeTransaction', - args: [transactionId], - }); - }; - - return { executeTransaction, isPending }; -} -``` - -### Settlement Hooks - -```typescript -// hooks/useSettlement.ts -import { useWriteContract } from 'wagmi'; -import { useEscrowAddress } from './useEscrowAddress'; -import { EscrowUniversalABI } from '../config/contracts'; - -export function useProposeSettlement() { - const { escrow } = useEscrowAddress(); - const { writeContractAsync, isPending } = useWriteContract(); - - const proposeSettlement = async (transactionId: bigint, amount: bigint) => { - return await writeContractAsync({ - address: escrow, - abi: EscrowUniversalABI, - functionName: 'proposeSettlement', - args: [transactionId, amount], - }); - }; - - return { proposeSettlement, isPending }; -} - -export function useAcceptSettlement() { - const { escrow } = useEscrowAddress(); - const { writeContractAsync, isPending } = useWriteContract(); - - const acceptSettlement = async (transactionId: bigint) => { - return await writeContractAsync({ - address: escrow, - abi: EscrowUniversalABI, - functionName: 'acceptSettlement', - args: [transactionId], - }); - }; - - return { acceptSettlement, isPending }; -} -``` - ---- - -## Reading Transaction Data - -### Transaction Query Hooks - -```typescript -// hooks/useTransactionData.ts -import { useReadContract } from 'wagmi'; -import { useEscrowAddress } from './useEscrowAddress'; -import { EscrowUniversalABI } from '../config/contracts'; - -export function useTransaction(transactionId: bigint) { - const { escrow } = useEscrowAddress(); - - const { data: transaction, isLoading, error, refetch } = useReadContract({ - address: escrow, - abi: EscrowUniversalABI, - functionName: 'transactions', - args: [transactionId], - query: { - enabled: transactionId !== undefined, - refetchInterval: 30000, // Refresh every 30 seconds - }, - }); - - return { transaction, isLoading, error, refetch }; -} - -export function useTransactionCount() { - const { escrow } = useEscrowAddress(); - - const { data: count, isLoading, error } = useReadContract({ - address: escrow, - abi: EscrowUniversalABI, - functionName: 'getTransactionCount', - }); - - return { count, isLoading, error }; -} - -export function usePayouts(transactionId: bigint, winningParty: number) { - const { escrow } = useEscrowAddress(); - - const { data: payouts, isLoading, error } = useReadContract({ - address: escrow, - abi: EscrowUniversalABI, - functionName: 'getPayouts', - args: [transactionId, winningParty], - query: { - enabled: transactionId !== undefined && winningParty !== undefined, - }, - }); - - return { payouts, isLoading, error }; -} - -export function useAmountCap(tokenAddress: Address) { - const { escrow } = useEscrowAddress(); - - const { data: cap, isLoading, error } = useReadContract({ - address: escrow, - abi: EscrowUniversalABI, - functionName: 'amountCaps', - args: [tokenAddress], - query: { - enabled: !!tokenAddress, - }, - }); - - return { cap, isLoading, error }; -} -``` - -### Decode Metadata Hook - -```typescript -// hooks/useTransactionMetadata.ts -import { useState, useEffect } from 'react'; - -interface TransactionMetadata { - title: string; - description: string; - extraDescriptionUri?: string; - otherChain?: string; - otherChainAddress?: string; - otherAsset?: string; - otherAmount?: string; -} - -export function useTransactionMetadata(transactionUri: string) { - const [metadata, setMetadata] = useState(null); - const [isLoading, setIsLoading] = useState(false); - const [error, setError] = useState(null); - - useEffect(() => { - if (!transactionUri) return; - - setIsLoading(true); - try { - if (transactionUri.startsWith('data:application/json;base64,')) { - const base64Data = transactionUri.split(',')[1]; - const jsonString = atob(base64Data); - const decoded = JSON.parse(jsonString); - setMetadata(decoded); - } - } catch (err) { - setError(err instanceof Error ? err : new Error('Failed to decode metadata')); - } finally { - setIsLoading(false); - } - }, [transactionUri]); - - return { metadata, isLoading, error }; -} -``` - ---- - -## Dispute Management - -### Arbitration Fee Hooks - -```typescript -// hooks/useDispute.ts -import { useWriteContract, useReadContract } from 'wagmi'; -import { useEscrowAddress } from './useEscrowAddress'; -import { EscrowUniversalABI } from '../config/contracts'; - -export function useArbitrationCost() { - const { escrow } = useEscrowAddress(); - - // Get arbitrator address - const { data: arbitrator } = useReadContract({ - address: escrow, - abi: EscrowUniversalABI, - functionName: 'arbitrator', - }); - - const { data: extraData } = useReadContract({ - address: escrow, - abi: EscrowUniversalABI, - functionName: 'arbitratorExtraData', - }); - - // This would need the arbitrator ABI to get the actual cost - // Simplified for this example - return { arbitrator, extraData }; -} - -export function usePayArbitrationFee(isBuyer: boolean) { - const { escrow } = useEscrowAddress(); - const { writeContractAsync, isPending } = useWriteContract(); - - const payFee = async (transactionId: bigint, feeAmount: bigint) => { - const functionName = isBuyer - ? 'payArbitrationFeeByBuyer' - : 'payArbitrationFeeBySeller'; - - return await writeContractAsync({ - address: escrow, - abi: EscrowUniversalABI, - functionName, - args: [transactionId], - value: feeAmount, - }); - }; - - return { payFee, isPending }; -} - -export function useTimeout(isBuyer: boolean) { - const { escrow } = useEscrowAddress(); - const { writeContractAsync, isPending } = useWriteContract(); - - const timeout = async (transactionId: bigint) => { - const functionName = isBuyer ? 'timeOutByBuyer' : 'timeOutBySeller'; - - return await writeContractAsync({ - address: escrow, - abi: EscrowUniversalABI, - functionName, - args: [transactionId], - }); - }; - - return { timeout, isPending }; -} -``` - ---- - -## Security Considerations - - -### Token Compatibility -- Only use standard ERC20 tokens without transfer hooks -- Avoid tokens with fee-on-transfer, rebasing, or pausable mechanisms -- The contract uses SafeERC20 but assumes standard behavior - - -### Frontend Security Best Practices - - - - ```typescript - import { isAddress } from 'viem'; - - // Validate addresses - if (!isAddress(sellerAddress)) { - throw new Error('Invalid seller address'); - } - - // Check token decimals for accurate amount parsing - const amount = parseUnits(userInput, token.decimals); - ``` - - - - ```typescript - import { simulateContract } from 'wagmi/actions'; - - // Preview transaction outcomes before confirmation - const { request } = await simulateContract(config, { - address: escrow, - abi: EscrowUniversalABI, - functionName: 'createNativeTransaction', - args: [deadline, metadataUri, seller], - value: amount, - }); - ``` - - - - - Validate metadata size to prevent excessive gas costs - - Sanitize all user-provided metadata fields - - Use `extraDescriptionUri` for large documents - - Ensure proper base64 encoding/decoding of data URIs - - - ---- - -## Complete Integration Example - -```tsx -// pages/EscrowPage.tsx -import { useState } from 'react'; -import { useAccount } from 'wagmi'; -import { parseEther, formatEther, Address } from 'viem'; -import { - useCreateTransaction, - useTransaction, - usePay, - useExecuteTransaction -} from '../hooks'; - -export function EscrowPage() { - const { address, isConnected } = useAccount(); - const [transactionId, setTransactionId] = useState(null); - - const { createTransaction, isLoading: isCreating } = useCreateTransaction(); - const { transaction, isLoading: isLoadingTx } = useTransaction(transactionId!); - const { pay, isPending: isPaying } = usePay(); - const { executeTransaction, isPending: isExecuting } = useExecuteTransaction(); - - if (!isConnected) { - return
Please connect your wallet
; - } - - return ( -
-

Escrow V2 Integration

- - {/* Create Transaction */} -
-

Create New Escrow

- -
- - {/* View Transaction */} - {transactionId && transaction && ( -
-

Transaction Details

-

Amount: {formatEther(transaction.amount)} ETH

-

Status: {transaction.status}

-

Deadline: {new Date(Number(transaction.deadline) * 1000).toLocaleString()}

-
- )} -
- ); -} -``` - ---- - -## Resources - - - - Full source code and ABIs - - - React hooks for Ethereum - - - TypeScript interface for Ethereum - - - Get help with integration - - \ No newline at end of file diff --git a/developers/products/escrow/overview.mdx b/developers/products/escrow/overview.mdx index 98cef68..e9672cd 100644 --- a/developers/products/escrow/overview.mdx +++ b/developers/products/escrow/overview.mdx @@ -1,21 +1,39 @@ --- -title: "Escrow V2 Overview" -description: "Secure peer-to-peer transactions with decentralized dispute resolution through Kleros Court" - +title: "Escrow" +description: "Secure transaction escrow with Kleros arbitration for dispute resolution" --- ## Introduction -Kleros Escrow V2 enables secure peer-to-peer transactions with built-in dispute resolution through Kleros Court. The system supports both native ETH and ERC20 tokens, with features including settlement negotiations, partial payments, and deadline-based automatic execution. +Kleros Escrow enables secure transactions with built-in dispute resolution through Kleros Court. This page covers both V1 (Ethereum Mainnet) and V2 (Arbitrum). - - - Core contract interfaces and data structures - - - React hooks and frontend implementation - - + + Core contract interfaces and data structures + + +--- + +## V1 (Ethereum Mainnet) + +Escrow V1 is a two-party escrow on Ethereum Mainnet, with Kleros Court available for dispute resolution. **V1 integration is fully supported.** + +The V1 interface enforces token compatibility: unsupported tokens are blacklisted with toast notifications, and the token selector modal warns about non-standard ERC20 tokens (such as USDT) that V1 does not support. The application at `escrow.kleros.io` is whitelisted on Reown for WalletConnect sessions. + +For V1 contract addresses, see [Deployment Addresses V1](/reference/contracts/deployment-addresses-v1). + +--- + +## V2 (Arbitrum) + +Kleros Escrow V2 is in production and supports both native ETH and ERC20 tokens, with settlement negotiations, partial payments, and deadline-based automatic execution. The sections below document V2 technical details. + +Technical notes for integrators: + +- **Token decimals**: the contract handles tokens with non-18 decimals correctly (USDC and USDT are supported; both are whitelisted, USDT being a V2-only addition since V1 does not support it) +- **Dispute policy**: the General Escrow dispute policy document is finalized and stored on IPFS +- **Subgraph**: version 2.2.1 runs on Goldsky and exposes `transactionHash` fields, which power block explorer links in the transaction timeline +- **File storage**: uploads go through the Atlas SIWE flow to IPFS +- **Frontend stack**: the interface uses kleros-app 3.0.1 (including unsubscribe-from-notifications support) and the shared UI Components Library, including the shared file viewer --- diff --git a/developers/products/escrow/smart-contracts.mdx b/developers/products/escrow/smart-contracts.mdx index 039f133..064f13d 100644 --- a/developers/products/escrow/smart-contracts.mdx +++ b/developers/products/escrow/smart-contracts.mdx @@ -4,6 +4,10 @@ description: "Escrow V2 contract interfaces, data structures, and function refer --- + +V2 contracts now correctly handle tokens with non-18 decimal places (USDC = 6 decimals, USDT = 6 decimals). The General Escrow dispute policy document was finalized and uploaded to IPFS (March 2026). + + ## Core Data Structures ### Transaction Struct diff --git a/developers/products/foresight/overview.mdx b/developers/products/foresight/overview.mdx new file mode 100644 index 0000000..61acb8f --- /dev/null +++ b/developers/products/foresight/overview.mdx @@ -0,0 +1,52 @@ +--- +title: "Foresight" +description: "Prediction-market-based decision making with Kleros dispute resolution" +--- + +Kleros Foresight is a V2 product with no V1 equivalent. This page documents technical details only. + +--- + +## What is Kleros Foresight + +- Officially named Kleros Foresight in February 2026 (previously referred to as the Futarchy UI) +- A prediction market platform for decision-making, where market outcomes are resolved through Kleros arbitration +- Uses a conditional token framework on Gnosis Chain with Swapr-based AMM pools +- Supports both DAI and Foresight Credits for participation + +--- + +## Architecture + +- Built on a conditional token framework +- Trade wallet system for depositing/withdrawing DAI, minting/merging prediction tokens, and redeeming after market resolution +- Batch predictions via CSV upload, with a trade executor for batch operations +- Transaction chunking splits large prediction batches into multiple transactions to stay within gas limits +- On-chain price fetch for markets without subgraph entries +- Market resolution logic uses Kleros arbitration + +--- + +## Experiments + +- Movie Experiment round 1 launched March 2026 - participants predict the CTO's percentile scores for 16 movies +- Movie Experiment round 2 launched June 2026 + +--- + +## Technical capabilities + +- Batch redeem +- P&L display wired through the API +- CSV export for predictions with UTC timestamps +- Foresight Credits system +- Resolved answers shown on the slider and market cards +- Redemption value calculation with a pre-check +- Email notifications triggered when a market resolves, processed through the per-product Atlas pipeline with a Foresight-specific unsubscribe + +--- + +## Links + +- App: [foresight.kleros.io](https://foresight.kleros.io/) +- Repository: [github.com/kleros/futarchy-ui](https://github.com/kleros/futarchy-ui) diff --git a/developers/products/governor/overview.mdx b/developers/products/governor/overview.mdx new file mode 100644 index 0000000..7d9b018 --- /dev/null +++ b/developers/products/governor/overview.mdx @@ -0,0 +1,30 @@ +--- +title: "Governor" +description: "Decentralized governance execution with dispute resolution for contested actions" +--- + +Governor V2 is a V2 product. This page documents technical details only. + +--- + +## What is Governor V2 + +- An on-chain governance contract (`KlerosGovernor`) for executing community decisions +- Proposals go through a submission period, then are resolved via Kleros Court if disputed +- Supports transaction simulations via Tenderly before submission + +--- + +## Architecture + +- A pre-seeded dummy entry at `submissions[0]` reserves listID 0 for the "Refuse to Arbitrate" slot in the dispute template +- Built against the v2 contracts package `^2.0.0-rc.2`, using the 3-parameter `DisputeRequest` signature +- A full Foundry test suite covers KlerosGovernor end-to-end: 1,820 lines of test code across 15 files +- Tenderly simulations run for transaction proposals before submission +- Contracts and templates are deployed and verified, and the Governor contract lives in its own repository + +--- + +## Links + +- Repository: [github.com/kleros/governor-v2](https://github.com/kleros/governor-v2) diff --git a/developers/products/overview.mdx b/developers/products/overview.mdx index e2a8e7e..64110f5 100644 --- a/developers/products/overview.mdx +++ b/developers/products/overview.mdx @@ -1,47 +1,52 @@ --- -title: "Building on Kleros Products" -description: "Integrate with Kleros products to add dispute resolution, curation, identity verification, and oracle capabilities to your application." +title: "Kleros Products" +description: "Developer reference for every Kleros product, covering V1 and V2 together" --- ## Overview -Kleros provides a suite of products built on top of Kleros Court V2. Each product implements the arbitration standard and can be integrated into third-party applications through smart contract calls, subgraph queries, or frontend SDKs. +This section documents every Kleros product, with V1 and V2 covered together on each product's page. -All products use Kleros Court on Arbitrum One as the arbitration backend. Disputes raised through any product follow the same resolution flow: juror drawing, evidence submission, voting, appeal, and ruling enforcement. +**V1 products include full integration guides and code examples. V2 products document technical specifications, contract interfaces, and architecture.** + +All products use Kleros Court as the arbitration backend. Disputes raised through any product follow the same resolution flow: juror drawing, evidence submission, voting, appeal, and ruling enforcement. --- ## Products - - Decentralized token-curated registries for maintaining community-governed lists. Supports challenge-based curation with deposit and reward mechanics. + + The core dispute resolution interface. V1 on Ethereum / Gnosis Chain, V2 on Arbitrum. + + + Community-governed registries. Classic and Light Curate (V1) plus Curate V2. - - Peer-to-peer escrow transactions with ETH and ERC20 support, settlement negotiations, and deadline-based execution. + + Secure transactions with Kleros arbitration. V1 on Ethereum, V2 on Arbitrum. - Sybil-resistant identity registry using soulbound humanity IDs. Verify unique human identities on-chain with cross-chain state synchronization. + Sybil-resistant registry of verified unique humans. V1 on Ethereum, V2 on Gnosis Chain. + + + Reality.eth + Kleros oracle with SafeSnap integration for DAO governance. + + + Prediction-market-based decision making with Kleros dispute resolution. - - Subjective oracle system combining Reality.eth bond escalation with Kleros arbitration for on-chain verification of real-world events. + + On-chain governance execution with dispute resolution for contested actions. + + + Community-curated safety information for contracts, tokens, and dApps. + + + V1 tool for creating disputes in Court without a custom arbitrable contract. --- -## Integration Approaches - -Kleros products can be integrated in two ways: - -**Direct smart contract integration**: Your contract calls the product's contract functions directly. This is the recommended path for on-chain applications that need trustless dispute resolution or curation. - -**Recognition of jurisdiction**: Your platform uses Kleros products through an off-chain agreement, where the dispute is escalated to Kleros Court and the ruling is enforced by your platform's own mechanisms. This is suitable when full smart contract integration is not yet feasible. - -For both approaches, refer to the individual product guides for contract addresses, interface specifications, and working code examples. - ---- - ## Shared Infrastructure All Kleros V2 products share these components: @@ -54,4 +59,4 @@ All Kleros V2 products share these components: | **DisputeTemplateRegistry** | Stores dispute display metadata for Court UI | | **Vea** | Cross-chain message bridge for relaying disputes and rulings | -For the full architecture, see the [Architecture guide](/developers/architecture). \ No newline at end of file +For the full architecture, see the [Architecture guide](/developers/architecture). diff --git a/developers/products/poh/integration.mdx b/developers/products/poh/integration.mdx index 1396319..0aebac4 100644 --- a/developers/products/poh/integration.mdx +++ b/developers/products/poh/integration.mdx @@ -1,161 +1,115 @@ --- title: "Integration Guide" -description: "Integrate Proof of Humanity V2 for Sybil-resistant identity verification in your application." +description: "Integrate Proof of Humanity 2.0 to verify real humans in your application" --- -## Basic Identity Check +# Proof of Humanity 2.0 Integration Guide -The simplest integration queries whether an address belongs to a verified human: - -```solidity -import {IProofOfHumanity} from "./interfaces/IProofOfHumanity.sol"; - -contract GatedApp { - IProofOfHumanity public immutable poh; - - constructor(address _pohAddress) { - poh = IProofOfHumanity(_pohAddress); - } - - modifier onlyHuman() { - require(poh.isHuman(msg.sender), "Not a verified human"); - _; - } - - function protectedAction() external onlyHuman { - // Only verified humans can call this - } -} -``` - -The `isHuman()` function automatically checks both V2 native registrations and V1 legacy registrations through the Fork Module. +This guide shows how to integrate PoH V2 to verify that an address belongs to a real, verified human. PoH V2 runs on Gnosis Chain as the home chain, with cross-chain state synchronized to Ethereum Mainnet. --- -## Working with Humanity IDs - -PoH V2 uses `bytes20` humanity IDs that persist across wallet changes. Store user data by `humanityId` instead of `address` to maintain continuity when users change wallets: - -```solidity -contract SoulboundProfile { - IProofOfHumanity public immutable poh; - - struct Profile { - uint256 reputation; - string username; - bool exists; - } - - // Key by humanityId, not address - mapping(bytes20 => Profile) public profiles; - - function createProfile(string calldata _username) external { - require(poh.isHuman(msg.sender), "Must be verified human"); - - bytes20 humanityId = poh.humanityOf(msg.sender); - require(humanityId != bytes20(0), "No humanity ID"); - require(!profiles[humanityId].exists, "Profile exists"); - - profiles[humanityId] = Profile({ - reputation: 0, - username: _username, - exists: true - }); - } - - function getProfile(address _user) external view returns (Profile memory) { - bytes20 humanityId = poh.humanityOf(_user); - return profiles[humanityId]; - } -} -``` +## Contract Addresses + + + + | Contract | Address | + | --- | --- | + | ProofOfHumanity | `0xa4AC94C4fa65Bb352eFa30e3408e64F72aC857bc` | + | CrossChainProofOfHumanity | `0x16044E1063C08670f8653055A786b7CC2034d2b0` | + | AMB Bridge Gateway | `0x6Ef5073d79c42531352d1bF5F584a7CBd270c6B1` | + + + | Contract | Address | + | --- | --- | + | ProofOfHumanityExtended | `0xbE9834097A4E97689d9B667441acafb456D0480A` | + | CrossChainProofOfHumanity | `0xa478095886659168E8812154fB0DE39F103E74b2` | + | AMB Bridge Gateway | `0xddafACf8B4a5087Fc89950FF7155c76145376c1e` | + | Fork Module | `0x068a27Db9c3B8595D03be263d52c813cb2C99cCB` | + + --- -## Detecting V1 vs V2 Registrations +## Core Interface -V1 users have a humanity ID equal to their original registration address. You can use this to detect registration version: +The primary verification functions: ```solidity -function isV1Registration(address _user) public view returns (bool) { - if (!poh.isHuman(_user)) return false; - bytes20 humanityId = poh.humanityOf(_user); - return humanityId == bytes20(_user); -} +function isHuman(address _account) external view returns (bool); +function humanityOf(address _account) external view returns (bytes20); +function isClaimed(bytes20 _humanityId) external view returns (bool); +function boundTo(bytes20 _humanityId) external view returns (address); +function getHumanityInfo(bytes20 _humanityId) external view returns ( + bool vouching, bool pendingRevocation, uint48 nbPendingRequests, + uint40 expirationTime, address owner, uint256 nbRequests +); ``` +| Function | Purpose | +| --- | --- | +| `isHuman(address)` | Returns true if the address belongs to a verified human | +| `humanityOf(address)` | Returns the `humanityId` bound to an address (zero if none) | +| `isClaimed(humanityId)` | Returns true if the humanity ID is actively claimed | +| `boundTo(humanityId)` | Returns the wallet address currently bound to a humanity ID | +| `getHumanityInfo(humanityId)` | Full status: vouching state, pending requests, expiration, owner | + --- -## Cross-Chain Verification +## Basic Integration Pattern -If your application is deployed on a chain different from PoH's home chain (Gnosis), use the `CrossChainProofOfHumanity` contract: +The simplest integration is a modifier that gates functions to verified humans: ```solidity -interface ICrossChainProofOfHumanity { +interface IProofOfHumanity { function isHuman(address _account) external view returns (bool); - function humanityOf(address _account) external view returns (bytes20); - function boundTo(bytes20 _humanityId) external view returns (address); - function isClaimed(bytes20 _humanityId) external view returns (bool); } -contract CrossChainDApp { - IProofOfHumanity public immutable pohMain; - ICrossChainProofOfHumanity public immutable pohCrossChain; +contract MyApp { + IProofOfHumanity public poh; - constructor(address _pohMain, address _pohCrossChain) { - pohMain = IProofOfHumanity(_pohMain); - pohCrossChain = ICrossChainProofOfHumanity(_pohCrossChain); + constructor(IProofOfHumanity _poh) { + poh = _poh; } - function isVerifiedHuman(address _account) public view returns (bool) { - return pohMain.isHuman(_account) || pohCrossChain.isHuman(_account); + modifier onlyHuman() { + require(poh.isHuman(msg.sender), "Must be verified human"); + _; + } + + function humanOnlyAction() external onlyHuman { + // Only verified humans reach this point } } ``` - - Cross-chain state synchronization is **not instant**. PoH V2 lives on Gnosis Chain. When a user registers or renews on Gnosis, the state must be relayed to other chains via cross-chain bridges (e.g. AMB). This propagation typically takes **minutes to hours** depending on the bridge and relayer activity, but can take up to **24 hours** in practice. Design your application to handle this delay: - - Do not gate critical actions on cross-chain PoH status without a fallback - - Show users a "pending propagation" state in your UI - - Cache the result locally and re-check periodically rather than blocking the user - - - - PoH V2 is deployed on **Gnosis Chain** (home chain). The `CrossChainProofOfHumanity` contract on other chains (Ethereum, Arbitrum, etc.) receives state updates from Gnosis via the AMB bridge. The `pohMain` in your contract should point to the `CrossChainProofOfHumanity` address on your target chain, not the Gnosis deployment directly. - - --- -## Use Cases +## Soulbound Identity Design -**Sybil-resistant voting**: Gate governance participation to verified humans. Use `isHuman()` as a modifier on vote functions to prevent one-person-multiple-vote attacks. +PoH V2 follows the principle: **1 human → 1 humanity ID ↔ 1 wallet address**. -**Airdrop distribution**: Distribute tokens to unique humans rather than addresses. Query `humanityOf()` to deduplicate claims. +The `humanityId` is a soulbound identifier that persists across wallet transitions. If a user loses wallet access, they can re-register with a new address while keeping the same `humanityId`. Applications that key reputation, assets, or history by `humanityId` rather than by address preserve them across the user's wallet changes. -**Reputation systems**: Store reputation by `humanityId` so users retain their standing across wallet migrations. +``` +humanity.owner == lostAddress // Lost access +humanity.owner == address(0) // Removal requested +humanity.owner == newAddress // Re-registered with new wallet +``` -**Access control**: Restrict access to platform features, DAOs, or communities to verified humans only. + +V1 users have a `humanityId` equal to their original registration address (`bytes20(address)`). V2 users receive a new unique `humanityId` at registration. The `isHuman()` call automatically covers V1 registrations through the Fork Module. + --- -## Subgraph +## What's Next? -PoH V2 data is indexed via a subgraph for frontend queries. Use the subgraph to list registrations, query profile status, and display challenge history without direct contract calls. - -```graphql -{ - humanities(where: { registered: true }, first: 10) { - id - owner - expirationTime - requests { - status - challenger - } - } -} -``` - - - Subgraph endpoints and schema are subject to change during beta. Check the [PoH V2 GitHub repository](https://github.com/kleros/proof-of-humanity-v2-contracts) for the latest subgraph configuration. - \ No newline at end of file + + + Architecture and technical details + + + Core interfaces and data structures + + diff --git a/developers/products/poh/overview.mdx b/developers/products/poh/overview.mdx index a6b8ceb..6fdc15b 100644 --- a/developers/products/poh/overview.mdx +++ b/developers/products/poh/overview.mdx @@ -1,22 +1,45 @@ --- -title: "Proof of Humanity V2 Overview" -description: "Sybil-resistant identity registry with soulbound humanity IDs and cross-chain verification through Kleros Court." +title: "Proof of Humanity" +description: "Sybil-resistant registry of verified unique humans" --- ## Introduction -Proof of Humanity (PoH) V2 is a Sybil-resistant registry of unique human identities. Each verified human receives a soulbound humanity ID (`humanityId`) that persists across wallet changes. PoH V2 uses Kleros Court for dispute resolution when profiles are challenged. +Proof of Humanity (PoH) is a Sybil-resistant registry of unique human identities. This page covers both V1 (Ethereum Mainnet) and V2 (Gnosis Chain). -Unlike V1 where each registration was bound to a specific wallet address, V2 decouples identity from address. One human maps to one humanity ID, which maps to one wallet address at any time. If a user loses wallet access, they can remove the lost address and re-register with a new one using the same `humanityId`. +Each verified human receives a soulbound humanity ID (`humanityId`) that persists across wallet changes. PoH V2 uses Kleros Court for dispute resolution when profiles are challenged. Unlike V1, where each registration was bound to a specific wallet address, V2 decouples identity from address. One human maps to one humanity ID, which maps to one wallet address at any time. If a user loses wallet access, they can remove the lost address and re-register with a new one using the same `humanityId`. - - - Core interfaces, data structures, and contract addresses - - - Integrate PoH identity verification into your application - - + + Core interfaces, data structures, and contract addresses + + +--- + +## V1 (Ethereum Mainnet) + +PoH V1 runs on Ethereum Mainnet and **V1 integration remains available**. A Fork Module allows V1 registrations to be recognized by V2. The EPNS/Push Protocol integration that was active in V1 has been discontinued, and is replaced in V2 by Atlas + SendGrid. + +For V1 contract addresses, see [Deployment Addresses](/reference/contracts/deployment-addresses-v1). + +--- + +## V2 (Gnosis Chain) + +The sections below document PoH V2 technical details. + +Technical notes for integrators: + +- **PNK airdrop**: the first 10,000 verified humans can claim 1,200 PNK, doubled by staking in the Humanity Court. A dashboard tracks registrations and airdrop claims. +- **Ledger limitation**: hardware wallets do not currently support EIP-7702 on Gnosis Chain, which the standard airdrop claim flow requires. A manual claiming guide is available. +- **Email notifications**: every step of the profile flow triggers notifications processed end-to-end by Atlas, including pending revocation, vouching activity, disputed flows, and challenge outcomes. +- **Evidence keys**: the interface writes evidence files with the correct evidence key. Court V1 and the Dispute Resolver include a normalization workaround for older submissions that used the wrong key. +- **Execution pipeline**: profile advancement uses a rewritten auto-advance execute pipeline. +- **Security**: frontend security reviews cover XSS attack vectors, and the app runs on a patched NextJS 15. +- **In progress**: a voucher reward distributor contract and a referral system (technical specifications under review). + + +Atlas is an internal backend library for Kleros development teams only. It is not intended for community use or integration. + --- @@ -101,7 +124,7 @@ graph TD The `isHuman()` function is available on multiple chains through `CrossChainProofOfHumanity` contracts. Synchronization uses bridge infrastructure to propagate registration state. - A Fork Module allows V1 registrations to be recognized by V2. The `isHuman()` call automatically checks both V2 native registrations and V1 legacy registrations. + A Fork Module allows V1 registrations to be recognized by V2. The `isHuman()` call automatically checks both V2 native registrations and V1 registrations. New registrants need a vouch from an existing verified human. The keeper bot processes vouches and reward withdrawals automatically, reducing manual intervention. diff --git a/developers/products/poh/smart-contracts.mdx b/developers/products/poh/smart-contracts.mdx index 24a21c7..ebedab7 100644 --- a/developers/products/poh/smart-contracts.mdx +++ b/developers/products/poh/smart-contracts.mdx @@ -125,6 +125,6 @@ When a registration is challenged, PoH creates a dispute in Kleros Court with th | **Choices** | 2 (Accept Registration / Reject Registration) | | **Ruling 0** | Refuse to arbitrate | | **Ruling 1** | Accept -> registration is valid | -| **Ruling 2** | Reject —> registration is invalid | +| **Ruling 2** | Reject -> registration is invalid | Evidence is submitted on-chain and displayed in the Court V2 interface. The dispute template specifies the PoH registration policy as the primary document for juror evaluation. \ No newline at end of file diff --git a/developers/products/reality/integration.mdx b/developers/products/reality/integration.mdx index 36caee8..f97d7f3 100644 --- a/developers/products/reality/integration.mdx +++ b/developers/products/reality/integration.mdx @@ -21,7 +21,7 @@ The RealityV2 Kleros integration contract has a `feeTimeout` parameter (set to * uint32 public constant FEE_TIMEOUT = 600; // 10 minutes ``` -Inform your users about this window — if they request arbitration, the other party has only 10 minutes to match the fee. +Inform your users about this window - if they request arbitration, the other party has only 10 minutes to match the fee. The `disputeTemplateMappings` field in the Reality V2 deployment script is currently marked `TODO` in the reference implementation. This means the dispute template shown to Kleros jurors for Reality questions does not yet have dynamic data mappings (it shows static text). Check the [kleros/reality-v2 repository](https://github.com/kleros/reality-v2) for the latest status before relying on dynamic template population. @@ -83,15 +83,15 @@ Any ETH sent with `askQuestion` becomes the question reward, incentivizing answe #### Question Parameters -- **`templateID`** — `0` for bool, `1` for uint, `2` for single-select, `3` for multiple-select, `4` for datetime, `5` for hash. -- **`question`** — Parameters separated by the `␟` (U+241F) delimiter, formatted to match the template. Examples: +- **`templateID`** - `0` for bool, `1` for uint, `2` for single-select, `3` for multiple-select, `4` for datetime, `5` for hash. +- **`question`** - Parameters separated by the `␟` (U+241F) delimiter, formatted to match the template. Examples: - Bool: `"Did event X happen?␟category␟en"` - Uint: `"What was the price of ETH on April 16, 2025?␟crypto␟en"` - Single-select: `"Which team won?␟\"Lakers\",\"Celtics\",\"Bucks\"␟sports␟en"` -- **`arbitrator`** — Kleros Arbitrator Proxy address. See [Smart Contracts](/developers/products/reality/smart-contracts#kleros-arbitrator-proxy-addresses) for available proxies. -- **`timeout`** — Seconds before an unchallenged answer finalizes. Typically 86400 (24 hours). The contract enforces a maximum of 365 days. -- **`openingTimestamp`** — Earliest time answers can be submitted. Set to `0` for immediate. -- **`nonce`** — Differentiator for identical questions with the same parameters. Use `0` if you don't need to ask the same question more than once. +- **`arbitrator`** - Kleros Arbitrator Proxy address. See [Smart Contracts](/developers/products/reality/smart-contracts#kleros-arbitrator-proxy-addresses) for available proxies. +- **`timeout`** - Seconds before an unchallenged answer finalizes. Typically 86400 (24 hours). The contract enforces a maximum of 365 days. +- **`openingTimestamp`** - Earliest time answers can be submitted. Set to `0` for immediate. +- **`nonce`** - Differentiator for identical questions with the same parameters. Use `0` if you don't need to ask the same question more than once. ### Step 2: Read the Finalized Answer @@ -155,10 +155,10 @@ When a Reality.eth question goes to arbitration, evidence helps jurors make info ### Evidence Timeline 1. Question posted on Reality.eth -2. Answer phase — users submit answers with bonds -3. Arbitration requested — someone pays the arbitration fee +2. Answer phase - users submit answers with bonds +3. Arbitration requested - someone pays the arbitration fee 4. **Evidence period opens** (typically 3-7 days, varies by court configuration) -5. Voting phase — Kleros jurors review evidence and vote +5. Voting phase - Kleros jurors review evidence and vote 6. Final ruling reported back to Reality.eth ### Submitting Evidence from a Contract @@ -214,11 +214,11 @@ Evidence JSON follows the [ERC-1497](https://github.com/ethereum/EIPs/issues/149 ### Evidence Best Practices -- **IPFS first** — `/ipfs/QmHash` or `ipfs://QmHash` is preferred for permanence. Web URLs work but rely on host availability. -- **Both sides should submit** — supporters of each answer should submit their own evidence. Jurors weigh both. -- **Quality over quantity** — clear, authoritative sources beat numerous weak ones. -- **Submit early** — anyone can submit during the evidence period, but late submissions risk being missed. -- **Reference the underlying claim** — each evidence file should clearly map to the answer it supports. +- **IPFS first** - `/ipfs/QmHash` or `ipfs://QmHash` is preferred for permanence. Web URLs work but rely on host availability. +- **Both sides should submit** - supporters of each answer should submit their own evidence. Jurors weigh both. +- **Quality over quantity** - clear, authoritative sources beat numerous weak ones. +- **Submit early** - anyone can submit during the evidence period, but late submissions risk being missed. +- **Reference the underlying claim** - each evidence file should clearly map to the answer it supports. ### Monitoring Evidence Submissions @@ -292,7 +292,7 @@ The Reality.eth + Kleros system has five fee types. Each plays a specific role i ## Custom Primary Document for Arbitration -Most DApp integrations work fine with the standard [Question Resolution Policy](https://ipfs.io/ipfs/QmaUr6hnSVxYD899xdcn2GUVtXVjXoSXKZbce3zFtGWw4H/Question_Resolution_Policy.pdf). In some cases, you may need a custom primary document tailored to your application. +Most DApp integrations work fine with the standard [Question Resolution Policy](https://cdn.kleros.link/ipfs/QmaUr6hnSVxYD899xdcn2GUVtXVjXoSXKZbce3zFtGWw4H/Question_Resolution_Policy.pdf). In some cases, you may need a custom primary document tailored to your application. ### When You Need a Custom Document @@ -303,18 +303,18 @@ Most DApp integrations work fine with the standard [Question Resolution Policy]( ### How the Process Works -1. **Initial assessment** — the Kleros team reviews your use case to confirm a custom document is necessary -2. **Document drafting** — you work with Kleros to create a document that: +1. **Initial assessment** - the Kleros team reviews your use case to confirm a custom document is necessary +2. **Document drafting** - you work with Kleros to create a document that: - Explains your application's context to jurors - Provides guidance on evaluating evidence - Defines specialized terminology - Establishes clear criteria for determining correct answers -3. **Deployment** — Kleros deploys a dedicated arbitrator proxy with your primary document embedded as part of the proxy's metaevidence -4. **Usage** — when disputes go to arbitration, jurors apply your guidelines +3. **Deployment** - Kleros deploys a dedicated arbitrator proxy with your primary document embedded as part of the proxy's metaevidence +4. **Usage** - when disputes go to arbitration, jurors apply your guidelines ### Real-World Example: Seer Prediction Markets -[Seer](https://seer.pm) needed a [custom resolution policy](https://ipfs.io/ipfs/QmPmRkXFUmzP4rq2YfD3wNwL8bg3WDxkYuvTP9A9UZm9gJ/seer-markets-resolution-policy.pdf) because their prediction markets have specific rules for handling complex outcomes, edge cases like delayed events, and explicit authoritative information sources. +[Seer](https://seer.pm) needed a [custom resolution policy](https://cdn.kleros.link/ipfs/QmPmRkXFUmzP4rq2YfD3wNwL8bg3WDxkYuvTP9A9UZm9gJ/seer-markets-resolution-policy.pdf) because their prediction markets have specific rules for handling complex outcomes, edge cases like delayed events, and explicit authoritative information sources. If your application might need this level of customization, contact `integrations@kleros.io`. @@ -352,9 +352,9 @@ Full deployment data: [Reality.eth monorepo](https://github.com/RealityETH/reali The Reality.eth + Kleros oracle is used in production by: -- **Prediction Markets** — [Seer](https://seer.pm), Polkamarkets/Foreland, and [Omen](https://omen.eth.limo) use it to verify real-world event outcomes -- **Optimistic Governance** — the [Zodiac SafeSnap module](https://docs.kleros.io/integrations/types-of-integrations/1.-dispute-resolution-integration-plan/channel-partners/kleros-reality-module#safesnap) uses it for secure DAO proposal execution -- **Content Moderation** — [Moderate / Susie bot](https://kleros.io/moderate) uses it for decentralized content policy enforcement +- **Prediction Markets** - [Seer](https://seer.pm), Polkamarkets/Foreland, and [Omen](https://omen.eth.limo) use it to verify real-world event outcomes +- **Optimistic Governance** - the [Zodiac SafeSnap module](https://docs.kleros.io/integrations/types-of-integrations/1.-dispute-resolution-integration-plan/channel-partners/kleros-reality-module#safesnap) uses it for secure DAO proposal execution +- **Content Moderation** - [Moderate / Susie bot](/legacy/retired/moderate) uses it for decentralized content policy enforcement *** @@ -381,7 +381,7 @@ For integration testing with Kleros Court V2, use the **Arbitrum Sepolia** testn No. Your DApp only needs to interact with Reality.eth for the standard question/answer flow. The proxy is invoked automatically when arbitration is requested. You only need to call the proxy directly to submit evidence during an active arbitration. **What happens if there's a dispute?** -Reality.eth and Kleros handle the dispute flow through the arbitrator proxy. Your DApp doesn't need any special logic — once the dispute resolves, `resultFor()` returns the arbitrated answer. +Reality.eth and Kleros handle the dispute flow through the arbitrator proxy. Your DApp doesn't need any special logic - once the dispute resolves, `resultFor()` returns the arbitrated answer. **How do I write a clear question?** Be specific, include resolution criteria, and specify a trusted information source. Example: "Did the S&P 500 close above 5,000 on April 10, 2025, according to the official S&P website?" diff --git a/developers/products/reality/overview.mdx b/developers/products/reality/overview.mdx index a2d8692..0253902 100644 --- a/developers/products/reality/overview.mdx +++ b/developers/products/reality/overview.mdx @@ -1,6 +1,6 @@ --- -title: "Reality (Oracle) Overview" -description: "Subjective oracle system combining Reality.eth bond escalation with Kleros Court arbitration for on-chain verification of real-world events." +title: "Reality" +description: "Oracle integration with Reality.eth and SafeSnap for DAO governance" --- ## Introduction @@ -21,6 +21,21 @@ Your application only interacts with Reality.eth. Kleros is invoked automaticall *** +## V1 - SafeSnap Integration (Ethereum / Gnosis Chain) + +The Reality.eth + Kleros oracle powers SafeSnap for DAO governance, and **V1 integration is actively supported**. + +Technical notes for integrators: + +- **Zodiac / SafeSnap**: the Kleros Reality Module works with Snapshot through the Gnosis Zodiac Safe configuration. The Zodiac bots validate keccak hashes for Reality questions automatically (issuing a warning rather than failing when a hash cannot be verified), normalize Reality links to consistent casing, and handle Reality questions with no Snapshot proposal attached. +- **Monitoring**: integrations can be monitored using ENS, Snapshot, and contract addresses (as done for Panther Protocol). +- **Court display**: Court V1 displays "Invalid" instead of "Refuse to Arbitrate" for Reality cases. +- **Networks**: the Realitio integration extends to the Base Sepolia testnet, and the cross-chain Realitio proxy is actively maintained. + +For the full SafeSnap integration walkthrough, see the [Integration Guide](/developers/products/reality/integration). + +*** + ## How It Works @@ -106,14 +121,14 @@ The system follows a push/pull model. Your DApp pushes a question to Reality.eth A question can be resolved through two paths: -### Happy Path — Consensus Resolution +### Happy Path - Consensus Resolution 1. An answerer submits an answer with a bond 2. No one challenges within the timeout period 3. The answer finalizes automatically 4. Your DApp reads the result via `resultFor(questionID)` -### Unhappy Path — Arbitration Resolution +### Unhappy Path - Arbitration Resolution 1. An answerer submits an answer with a bond 2. Another user posts a counter-answer with a higher bond @@ -161,7 +176,7 @@ The Reality.eth + Kleros oracle powers production systems across multiple catego - **Prediction Markets**: [Seer](https://seer.pm), Polkamarkets/Foreland, and [Omen](https://omen.eth.limo) use it to verify real-world event outcomes - **Optimistic Governance**: The [Zodiac SafeSnap module](https://docs.kleros.io/integrations/types-of-integrations/1.-dispute-resolution-integration-plan/channel-partners/kleros-reality-module#safesnap) implements it for secure DAO proposal execution -- **Content Moderation**: [Moderate / Susie bot](https://kleros.io/moderate) leverages it for decentralized content policy enforcement +- **Content Moderation**: [Moderate / Susie bot](/legacy/retired/moderate) leverages it for decentralized content policy enforcement *** diff --git a/developers/products/reality/smart-contracts.mdx b/developers/products/reality/smart-contracts.mdx index 4ec7078..7b40c9c 100644 --- a/developers/products/reality/smart-contracts.mdx +++ b/developers/products/reality/smart-contracts.mdx @@ -138,7 +138,7 @@ Questions use the Unicode delimiter `␟` (U+241F) to separate fields. The exact // Template 4 (datetime): "When did event X occur?␟history␟en" -// Template 5 (hash) — added in v3.2: +// Template 5 (hash) - added in v3.2: "Does this hash correspond to the document?␟verification␟en" ``` @@ -171,8 +171,8 @@ Answers are returned as `bytes32`. How to decode them depends on the template. Two reserved bytes32 values appear in answers: -- `0xff...ff` (all `f`s) — **Invalid**. The question is unanswerable, ambiguous, or violates the question policy. Always handle this case in your contract. -- `0xff...fe` (all `f`s except the last digit) — **Answered too early**. The question was asked before the underlying event could be resolved. The question can be re-asked once the event has occurred. +- `0xff...ff` (all `f`s) - **Invalid**. The question is unanswerable, ambiguous, or violates the question policy. Always handle this case in your contract. +- `0xff...fe` (all `f`s except the last digit) - **Answered too early**. The question was asked before the underlying event could be resolved. The question can be re-asked once the event has occurred. ```solidity theme={null} bytes32 constant ANSWERED_INVALID = bytes32(type(uint256).max); @@ -284,4 +284,4 @@ The Reality.eth + Kleros system involves several fee types, each with a specific \*When settled by arbitration, the arbitrator specifies who receives the reward. -For full details on each fee — including how the takeover fee equals the previous answerer's bond, and when the 2.5% claim fee burn applies (Reality.eth v2.1+) — see the [Integration Guide → Fees and Payments](/developers/products/reality/integration#fees-and-payments). +For full details on each fee - including how the takeover fee equals the previous answerer's bond, and when the 2.5% claim fee burn applies (Reality.eth v2.1+) - see the [Integration Guide → Fees and Payments](/developers/products/reality/integration#fees-and-payments). diff --git a/developers/products/scout/overview.mdx b/developers/products/scout/overview.mdx new file mode 100644 index 0000000..f4c6792 --- /dev/null +++ b/developers/products/scout/overview.mdx @@ -0,0 +1,64 @@ +--- +title: "Scout" +description: "Community-curated safety information for smart contracts, tokens, and dApps" +--- + +This page documents technical details for Scout. It does not include an integration guide. + +--- + +## What is Scout + +- A frontend interface for the Kleros curated address tag registry ecosystem +- Reached its definitive version in May 2026 - the planned feature set is complete, with focus now on growing the unified database +- Over 2.6 million curated on-chain addresses as of May 2026 +- Registries: Tokens, CDN, ATQ (Address Tags Query), and single-tag registries + +--- + +## Technical architecture + +- Built on Curate smart contracts (Light Curate / GTCR on-chain) +- Data indexed via the GTCR Indexer and Envio HyperIndex +- IPFS uploads go through the Atlas SIWE flow +- Submissions require sign-in at the time of submission; images are persisted in the browser until then +- Submission image size is capped on all registries; the tokens registry enforces a max of 1 MB and a minimum of 128×128 for logos +- ATQ duplicate detection prevents duplicate address tag submissions +- Disputes route to the correct court via JavaScript Court routing +- The evidence section sits outside the submission modal so evidence can be browsed while submitting + +--- + +## Chain support + +Ethereum Mainnet, Linea, Avalanche C-Chain, zkSync, Scroll, Gnosis, Celo, Base, Solana, Arbitrum One, OP Mainnet, MegaETH, Polygon, and PulseChain. + +--- + +## Partners using Scout data + +- OpenScan and RouteScan (block explorers) +- MonarchLend +- MetaMask Snap (Scout Snap v1.3.8) + +--- + +## GTCR Indexer + +- The schema (v0.1.7) includes challenge transaction hashes, challenge dates, and appeal transaction hashes +- An Envio branch is maintained alongside the main branch + +--- + +## Governance + +- KIP-87 created a new Curation Court on Gnosis with hidden voting (June 2026) +- Scout registries are planned to migrate to the new court + +--- + +## Links + +- App: [app.klerosscout.eth.limo](https://app.klerosscout.eth.limo/) +- Repository: [github.com/kleros/scout](https://github.com/kleros/scout) +- GTCR Indexer: [github.com/kleros/gtcr-indexer](https://github.com/kleros/gtcr-indexer) diff --git a/developers/quickstart.mdx b/developers/quickstart.mdx index c506f8b..bc62369 100644 --- a/developers/quickstart.mdx +++ b/developers/quickstart.mdx @@ -3,6 +3,13 @@ title: "Quick Start" description: "Integrate Kleros arbitration in your smart contract" --- +Kleros arbitration can be integrated on either protocol version: + +- **V1** uses the ERC-792 arbitration standard (`IArbitrable` / `IArbitrator`) on Ethereum Mainnet and Gnosis Chain. See [ERC-792](/developers/arbitrable-apps/erc-792) and [ERC-1497](/developers/arbitrable-apps/erc-1497) for the full V1 standards. +- **V2** uses `IArbitrableV2` / `IArbitratorV2` on Arbitrum, with dispute templates and cross-chain support. + +The steps below show both. Pick the version that matches the network you are deploying to. For contract addresses, see [Deployment Addresses](/reference/contracts/deployment-addresses-v1). + ## Installation @@ -36,7 +43,10 @@ Always verify addresses on the [official repository](https://github.com/kleros/k ## Minimal Integration -### Step 1: Implement IArbitrableV2 +### Step 1: Implement the arbitrable interface + + + ```solidity // SPDX-License-Identifier: MIT @@ -86,6 +96,57 @@ contract MyArbitrable is IArbitrableV2 { } ``` + + + +```solidity +// SPDX-License-Identifier: MIT +pragma solidity ^0.7.0; + +import "@kleros/erc-792/contracts/IArbitrable.sol"; +import "@kleros/erc-792/contracts/IArbitrator.sol"; +import "@kleros/erc-792/contracts/erc-1497/IEvidence.sol"; + +contract MyArbitrable is IArbitrable, IEvidence { + IArbitrator public arbitrator; + + mapping(uint256 => bool) public resolved; + + constructor(IArbitrator _arbitrator) { + arbitrator = _arbitrator; + } + + function createDispute( + bytes memory _extraData, + string memory _metaEvidence + ) public payable returns (uint256 disputeID) { + uint256 cost = arbitrator.arbitrationCost(_extraData); + require(msg.value >= cost, "Insufficient fee"); + + // numberOfChoices (e.g., 2 for binary) + court params in _extraData + disputeID = arbitrator.createDispute{value: cost}(2, _extraData); + + emit MetaEvidence(disputeID, _metaEvidence); + emit Dispute(arbitrator, disputeID, disputeID, disputeID); + } + + function rule(uint256 _disputeID, uint256 _ruling) external override { + require(msg.sender == address(arbitrator), "Only arbitrator"); + require(!resolved[_disputeID], "Already resolved"); + + resolved[_disputeID] = true; + + // Execute your business logic based on _ruling + // 0 = refused to rule, 1+ = actual ruling choices + + emit Ruling(arbitrator, _disputeID, _ruling); + } +} +``` + + + + ### Step 2: Encode Extra Data The `extraData` parameter specifies which court and how many jurors: @@ -144,7 +205,7 @@ Register templates on-chain or reference via IPFS URI. - Deploy to testnet first. Faucets available at [arbitrum.io/faucet](https://arbitrum.io/faucet) + Deploy to testnet first. Get Arbitrum Sepolia ETH from a public faucet such as the [Arbitrum faucets list](https://docs.arbitrum.io/for-devs/dev-tools-and-resources/chain-info) Testnet PNK is available from the Kleros faucet diff --git a/developers/subgraph/endpoints.mdx b/developers/subgraph/endpoints.mdx index 7094135..9f84bf5 100644 --- a/developers/subgraph/endpoints.mdx +++ b/developers/subgraph/endpoints.mdx @@ -7,8 +7,12 @@ description: "GraphQL endpoints for all Kleros V2 and V1 subgraphs" All Kleros subgraphs are deployed on The Graph. Use these endpoints to query Kleros data via GraphQL. + +**Infrastructure:** Subgraphs were migrated from Alchemy to Goldsky following Alchemy's subgraph service shutdown (December 2025–January 2026). The core subgraph 0.18.1 and DRT subgraph 0.14.0 were deployed on Goldsky (November 2025), and the GTCR Indexer reached v0.1.7 with an Envio branch (April 2026). Some applications use Envio HyperIndex as the primary indexer with a subgraph as fallback. + + -Subgraph endpoints on the decentralized network require a **Graph API key**. Get one at [thegraph.com/studio](https://thegraph.com/studio). In template mappings you will see `{{{graphApiKey}}}` — this is injected at runtime by the Kleros SDK. +Subgraph endpoints on the decentralized network require a **Graph API key**. Get one at [thegraph.com/studio](https://thegraph.com/studio). In template mappings you will see `{{{graphApiKey}}}` - this is injected at runtime by the Kleros SDK. --- @@ -31,7 +35,7 @@ Subgraph endpoints on the decentralized network require a **Graph API key**. Get https://gateway.thegraph.com/api/{YOUR_API_KEY}/subgraphs/id/{SUBGRAPH_ID} ``` -Get the `SUBGRAPH_ID` (deployment hash) from the Studio pages linked above — it is shown on the subgraph's Overview tab. +Get the `SUBGRAPH_ID` (deployment hash) from the Studio pages linked above - it is shown on the subgraph's Overview tab. ### Dispute Template Registry Subgraph @@ -62,7 +66,7 @@ Curate V2 subgraph is under active development. Check the [curate-v2 repository] --- -## V1 Subgraphs (Legacy) +## V1 Subgraphs These index V1 Kleros products still in active use. @@ -83,7 +87,7 @@ You can also query PoH V1 directly: call `isRegistered(address)` on `0xC5E9dDebb ### Other V1 Products -For Escrow V1, Linguo, Tokens, and other legacy apps, see the [Kleros subgraph list on GitHub](https://github.com/orgs/kleros/repositories?q=subgraph). +For Escrow V1, Linguo, Tokens, and other V1 apps, see the [Kleros subgraph list on GitHub](https://github.com/orgs/kleros/repositories?q=subgraph). --- diff --git a/developers/subgraph/queries.mdx b/developers/subgraph/queries.mdx index 1d26cd9..e0656bc 100644 --- a/developers/subgraph/queries.mdx +++ b/developers/subgraph/queries.mdx @@ -269,7 +269,7 @@ Alternatively, call `isRegistered(address)` directly on the PoH contract at `0xC Full list of subgraph URLs - + Full Light Curate developer guide
\ No newline at end of file diff --git a/docs.json b/docs.json index 2e0cfb4..13992e8 100644 --- a/docs.json +++ b/docs.json @@ -14,10 +14,6 @@ }, "navbar": { "links": [ - { - "label": "Help Center", - "href": "https://help.kleros.io" - }, { "label": "Blog", "href": "https://blog.kleros.io" @@ -26,7 +22,7 @@ "primary": { "type": "button", "label": "Launch Court", - "href": "https://v2.kleros.builders/" + "href": "https://court.kleros.io/" } }, "navigation": { @@ -57,12 +53,7 @@ "light": "#5c05e1", "dark": "#5c05e1" }, - "href": "https://kleros.builders" - }, - { - "anchor": "Help Center", - "icon": "circle-question", - "href": "https://help.kleros.io" + "href": "https://kleros.io" }, { "anchor": "GitHub", @@ -78,7 +69,10 @@ "groups": [ { "group": "Welcome", - "pages": ["welcome/introduction", "welcome/faq"] + "pages": [ + "welcome/introduction", + "welcome/faq" + ] }, { "group": "Kleros Court", @@ -90,19 +84,56 @@ "court/architecture" ] }, - { "group": "Products", "pages": [ "products/overview", "products/curate", - "products/stake curate", "products/escrow", "products/governor", - "products/scout", + { + "group": "Scout", + "pages": [ + "products/scout", + "products/scout-earn", + "products/scout-partnerships", + "products/scout-snap" + ] + }, "products/reality", "products/proof-of-humanity", - "products/foresight" + "products/foresight", + { + "group": "Retired Products", + "pages": [ + "legacy/retired/moderate", + "legacy/retired/linguo", + "legacy/retired/tokens" + ] + } + ] + }, + { + "group": "Tutorials", + "pages": [ + { + "group": "Juror Guide", + "pages": [ + "tutorials/juror-tutorial-v1", + "tutorials/juror-tutorial-v2" + ] + }, + "tutorials/escrow-tutorial", + "tutorials/curate-tutorial", + "tutorials/scout-tutorial", + { + "group": "Proof of Humanity", + "pages": [ + "tutorials/poh-register-and-vouch", + "tutorials/poh-remove-and-challenge", + "tutorials/poh-transferring-a-profile" + ] + } ] }, { @@ -112,6 +143,7 @@ "concepts/game-theory", "concepts/sortition", "concepts/tokenomics", + "concepts/pnk-token", "concepts/credible-neutrality" ] }, @@ -135,48 +167,10 @@ { "group": "Enterprise", "pages": [ - "enterprise/enterprise", "enterprise/ecosystem" ] }, - { - "group": "Legacy (V1)", - "pages": [ - "legacy/overview", - "legacy/migration-guide", - { - "group": "Integration", - - "pages": [ - "legacy/integrate/overview", - "legacy/integrate/types-of-integration", - "legacy/integrate/centralized-arbitrator", - "legacy/integrate/dispute-resolver", - "legacy/integrate/zodiac-integration", - - "legacy/integrate/policy-guide" - - ] - }, - - "legacy/court-v1", - "legacy/curate-v1", - "legacy/escrow-v1", - "legacy/governor-v1", - "legacy/resolver-v1", - { - "group": "Retired", - - "pages": [ - "legacy/retired/moderate", - "legacy/retired/linguo", - "legacy/retired/tokens" - ] - } - - ] - }, { "group": "Community & Ecosystem", "pages": [ @@ -187,15 +181,15 @@ ] }, { - "group": "Contributing", + "group": "Contributing", "pages": [ "contributing/overview", "contributing/dev-workflow", "contributing/smart-contract-workflow", "contributing/code-style", "contributing/license" - ] -} + ] + } ] }, { @@ -211,54 +205,61 @@ ] }, { - "group": "Building Arbitrable Apps (V2)", + "group": "Arbitrable Apps", "pages": [ "developers/arbitrable-apps/arbitrable-overview", "developers/arbitrable-apps/arbitrable-guide", + "developers/arbitrable-apps/erc-792", + "developers/arbitrable-apps/erc-1497", + "developers/arbitrable-apps/v1-arbitrable-apps", + "developers/arbitrable-apps/centralized-arbitrator", + "developers/arbitrable-apps/arbitrable-proxy", "developers/arbitrable-apps/arbitrable-testing", "developers/arbitrable-apps/arbitrable-production" ] }, { - "group": "Building on Kleros Products", + "group": "Products", "pages": [ "developers/products/overview", - + "developers/products/court/overview", { - "group": "Curate", - - "pages": [ - "developers/products/curate/overview", - "developers/products/curate/smart-contracts", - "developers/products/curate/integration", - "developers/products/curate/registries" - ] - }, - { - "group": "Escrow", - - "pages": [ - "developers/products/escrow/overview", - "developers/products/escrow/smart-contracts", - "developers/products/escrow/integration" - ] - }, - { - "group": "Proof of Humanity", - "pages": [ - "developers/products/poh/overview", - "developers/products/poh/smart-contracts", - "developers/products/poh/integration" - ] - }, - { - "group": "Reality", - "pages": [ - "developers/products/reality/overview", - "developers/products/reality/smart-contracts", - "developers/products/reality/integration" - ] - } + "group": "Curate", + "pages": [ + "developers/products/curate/overview", + "developers/products/curate/smart-contracts", + "developers/products/curate/curate-classic", + "developers/products/curate/light-curate", + "developers/products/curate/registries" + ] + }, + { + "group": "Escrow", + "pages": [ + "developers/products/escrow/overview", + "developers/products/escrow/smart-contracts" + ] + }, + { + "group": "Proof of Humanity", + "pages": [ + "developers/products/poh/overview", + "developers/products/poh/smart-contracts", + "developers/products/poh/integration" + ] + }, + { + "group": "Reality", + "pages": [ + "developers/products/reality/overview", + "developers/products/reality/smart-contracts", + "developers/products/reality/integration" + ] + }, + "developers/products/foresight/overview", + "developers/products/governor/overview", + "developers/products/scout/overview", + "developers/products/dispute-resolver/overview" ] }, { @@ -266,7 +267,7 @@ "pages": [ "developers/crosschain/vea-bridge", "developers/crosschain/vea-getting-started", - "developers/crosschain/vea-deployment-addresses", + "developers/crosschain/vea-deployment-addresses", "developers/crosschain/l2-integration" ] }, @@ -279,78 +280,66 @@ ] }, { - "group": "Subgraph & Data", - "pages": [ - "developers/subgraph/overview", - "developers/subgraph/endpoints", - "developers/subgraph/queries" - ] -}, - { - "group": "V1 Integration (Legacy)", + "group": "Subgraph & Data", "pages": [ - "developers/legacy/v1-overview", - "developers/legacy/erc-792", - "developers/legacy/erc-1497", - "developers/legacy/v1-arbitrable-apps", - "developers/legacy/migrating-to-v2", - "developers/legacy/arbitrable-proxy", - "developers/legacy/curate-classic", - "developers/legacy/light-curate", - "developers/legacy/v1-deployment-addresses", - "developers/legacy/centralized-arbitrator" + "developers/subgraph/overview", + "developers/subgraph/endpoints", + "developers/subgraph/queries" ] - } - ] - }, + } + ] + }, { "dropdown": "Reference", "icon": "book-bookmark", "groups": [ { - "group": "Overview", - "pages": ["reference/overview"] - }, - { - "group": "Architecture", - "pages": [ - "reference/architecture/v2-architecture", - "reference/architecture/arbitrator-v2", - "reference/architecture/sortition-module-spec", - "reference/architecture/vea-overview" - ] - }, - - { - "group": "Contracts", - "pages": [ - "reference/contracts/deployment-addresses", - "reference/contracts/kleros-core", - "reference/contracts/dispute-kit-classic", - "reference/contracts/sortition-module", - "reference/contracts/gateways", - "reference/contracts/kleros-governor", - "reference/contracts/policy-registry", - "reference/contracts/dispute-template-registry", - "reference/contracts/moderated-evidence-module" - ] - }, - { - "group": "Data Formats", - "pages": [ - "reference/data-formats/dispute-templates", - "reference/data-formats/evidence-format", - "reference/data-formats/policy-format", - "reference/data-formats/court-specification", - "reference/data-formats/cross-chain-evidence" - ] - }, - - { - "group": "SDK", - "pages": ["reference/sdk/kleros-sdk"] - } - ] + "group": "Overview", + "pages": [ + "reference/overview" + ] + }, + { + "group": "Architecture", + "pages": [ + "reference/architecture/v2-architecture", + "reference/architecture/arbitrator-v2", + "reference/architecture/sortition-module-spec", + "reference/architecture/vea-overview" + ] + }, + { + "group": "Contracts", + "pages": [ + "reference/contracts/deployment-addresses", + "reference/contracts/deployment-addresses-v1", + "reference/contracts/kleros-core", + "reference/contracts/dispute-kit-classic", + "reference/contracts/sortition-module", + "reference/contracts/gateways", + "reference/contracts/kleros-governor", + "reference/contracts/policy-registry", + "reference/contracts/dispute-template-registry", + "reference/contracts/moderated-evidence-module" + ] + }, + { + "group": "Data Formats", + "pages": [ + "reference/data-formats/dispute-templates", + "reference/data-formats/evidence-format", + "reference/data-formats/policy-format", + "reference/data-formats/court-specification", + "reference/data-formats/cross-chain-evidence" + ] + }, + { + "group": "SDK", + "pages": [ + "reference/sdk/kleros-sdk" + ] + } + ] }, { "dropdown": "Changelog", @@ -378,7 +367,6 @@ "light": "/logo/Kleros logo_updated.svg", "dark": "/logo/Kleros logo_updated_white.svg" }, - "seo": { "indexing": "all", "metatags": { @@ -404,7 +392,7 @@ "github": "https://github.com/kleros", "linkedin": "https://www.linkedin.com/company/kleros/", "telegram": "https://t.me/kleros", - "website": "https://kleros.builders" + "website": "https://kleros.io" }, "links": [ { @@ -425,23 +413,39 @@ { "label": "Scout", "href": "https://scout.kleros.io" + }, + { + "label": "Escrow", + "href": "https://escrow.kleros.io" + }, + { + "label": "Foresight", + "href": "https://foresight.kleros.io/" + }, + { + "label": "Dispute Resolver", + "href": "https://resolve.kleros.io/" + }, + { + "label": "Vea", + "href": "https://vea.ninja/" + }, + { + "label": "Kleros SafeSnap", + "href": "https://safesnap.kleros.builders/" } ] }, { "header": "Resources", "items": [ - { - "label": "Help Center", - "href": "https://help.kleros.io" - }, { "label": "Blog", "href": "https://blog.kleros.io" }, { "label": "Research", - "href": "/research/overview" + "href": "https://kleros.io/rd-research" } ] }, @@ -450,15 +454,15 @@ "items": [ { "label": "About", - "href": "https://kleros.io/about" + "href": "https://kleros.io/" }, { "label": "Careers", - "href": "https://kleros.io/careers" + "href": "https://wellfound.com/company/kleros" }, { "label": "Brand Assets", - "href": "https://kleros.io/brand" + "href": "https://kleros.io/brand-assets" } ] } @@ -471,4 +475,4 @@ "permanent": true } ] -} +} \ No newline at end of file diff --git a/enterprise/ecosystem.mdx b/enterprise/ecosystem.mdx index ae54548..5e4c435 100644 --- a/enterprise/ecosystem.mdx +++ b/enterprise/ecosystem.mdx @@ -5,7 +5,7 @@ description: "Projects and partners using Kleros products" # Kleros Ecosystem -Kleros has 60+ partners and integrations across DeFi, governance, insurance, curation, and identity. The complete, maintained list of all Kleros ecosystem partners is on the Kleros Notion page. +Kleros has partners and integrations across DeFi, governance, insurance, curation, and identity. The **complete, maintained list of ecosystem partners lives on the Kleros Ecosystem page on Notion** - treat it as the source of truth. The categories below are illustrative examples. Browse the complete, up-to-date Kleros ecosystem on Notion @@ -13,7 +13,28 @@ Kleros has 60+ partners and integrations across DeFi, governance, insurance, cur --- -## Integration Categories +## Dispute Resolution for Web3 Builders + +Kleros protects smart contracts and governance from exploits, failures, and fraud. The primary Web3 use cases are: + +- **Prediction markets**: users challenge market outcomes by depositing funds, disputes escalate through successive rounds with increased deposits, and randomly selected jurors provide transparent resolution +- **DAOs**: governance with on-chain enforcement via SafeSnap +- **DEXes and marketplaces**: curated token lists and buyer-seller dispute resolution +- **DeFi insurance**: impartial adjudication of reimbursement claims + +Why builders integrate Kleros: + +- Decentralized jury selection ensures fairness +- Multiple appeal rounds minimize manipulation risks +- A diverse, global juror pool offers cross-domain expertise + +The product portfolio for Web3 builders spans [Court](/court/overview) (dispute resolution), [Escrow](/products/escrow) (blockchain-secured transaction safeguards, including Escrow V1 and community-built variants [Escrowly](/Community%20&%20Ecosystem/escrowly) and [Lockler](/Community%20&%20Ecosystem/lockler)), [Curate](/products/curate) (trusted Web3 registries and certifications), [Scout](/products/scout) (address and contract insights), [Proof of Humanity](/products/proof-of-humanity) (decentralized identity verification), [Vea](/developers/crosschain/vea-bridge) (cross-chain bridging), and [SafeSnap](/products/reality) (DAO governance with on-chain enforcement). + +For more, see [kleros.io/web3](https://kleros.io/web3). + +--- + +## Integration Categories (examples) ### Kleros-Built Products @@ -69,7 +90,7 @@ Projects consuming Kleros Curate registries: ## Analytics -For court statistics, juror data, staking info, and dispute history, see [KlerosBoard](/Community & Ecosystem/klerosboard) in the Community & Ecosystem section. +For court statistics, juror data, staking info, and dispute history, see [KlerosBoard](/Community%20&%20Ecosystem/klerosboard) in the Community & Ecosystem section. --- diff --git a/enterprise/enterprise.mdx b/enterprise/enterprise.mdx index ca7268b..bf88cff 100644 --- a/enterprise/enterprise.mdx +++ b/enterprise/enterprise.mdx @@ -5,7 +5,31 @@ description: "Integrate Kleros dispute resolution into your company, institution # Kleros Enterprise -In the Kleros context, "Enterprise" refers to the use of Kleros dispute resolution technology by companies, institutions, or governments to resolve disputes within their own platforms or services. The blockchain complexity is abstracted away: neither the organization nor its users need to handle crypto or interact with smart contracts directly. + + Kleros Enterprise, screenshot to be added + + +**Kleros Enterprise** is a neutral dispute resolution system for businesses and governments, designed for speed, fairness, and transparency. Companies, institutions, and governments use Kleros dispute resolution technology to resolve disputes within their own platforms or services. The blockchain complexity is abstracted away: neither the organization nor its users need to handle crypto or interact with smart contracts directly. + + +For the full Kleros Enterprise knowledge base, see the [Kleros Enterprise Knowledge Base on Notion](https://app.notion.com/p/kleros/Kleros-Enterprise-Knowledge-Base-3439a9db4f0881f08c8dd09ea9cdc2a6). + + +--- + +## Why Enterprises Use Kleros + + + + Automate dispute workflows and reduce reliance on costly manual processes + + + An impartial adjudication layer protects reputation and supports regulatory compliance + + + Resolving disputes quickly and fairly increases user satisfaction and long-term loyalty + + --- @@ -17,6 +41,30 @@ Kleros is suited for disputes that are high in volume and low to medium in value --- +## Engagement Models + + + + A four-step process: the parties first attempt mediation; if it fails, the case escalates to Kleros; the arbitration process runs with Kleros jurors; and the outcome is enforced. + + 1. Initiate mediation + 2. Escalate to Kleros + 3. Arbitration process + 4. Enforcement + + + Quick, low-cost arbitration for digital-era contracts, with enforceability under English arbitration law. + + + An appointed arbitrator oversees the proceedings while a Kleros jury handles the substance of the case. + + + Kleros is exploring scalable dispute resolution under Argentina's Defensor del Cliente regime. + + + +--- + ## Due Process Guarantees | Guarantee | How Kleros Provides It | @@ -32,8 +80,9 @@ Kleros is suited for disputes that are high in volume and low to medium in value | Organization | Use Case | | --- | --- | +| **Lemon Cash** | Consumer complaint resolution for a Latin American crypto exchange serving over 2.5 million users, achieving 90% user retention with Kleros | | **MetLife Mexico** | Insurance dispute resolution in a controlled pilot program | -| **Lemon Cash** | Consumer complaint resolution for a Latin American fintech with 3M+ users | +| **Mendoza Supreme Court (Argentina)** | Government solution strengthening citizen trust through transparent and efficient resolution of consumer and community disputes | --- @@ -41,6 +90,7 @@ Kleros is suited for disputes that are high in volume and low to medium in value | Sector | Application | | --- | --- | +| **Finance** | Chargeback and fraud dispute resolution | | **Insurance** | Claims processing and reimbursement dispute adjudication | | **E-commerce** | Buyer-seller disputes, refund arbitration | | **Consumer protection** | Government-backed scalable online dispute resolution | @@ -53,7 +103,7 @@ Kleros is suited for disputes that are high in volume and low to medium in value Kleros works natively with Web3 and DAO ecosystems. Disputes in decentralized communities are resolved without centralized intermediaries, with rulings enforced automatically by smart contracts. -Specific use cases include protocol governance disputes, on-chain moderation, oracle disputes, and enforcement of rules in decentralized platforms. +Specific use cases include protocol governance disputes, on-chain moderation, oracle disputes, and enforcement of rules in decentralized platforms. See the [Ecosystem page](/enterprise/ecosystem) for projects building on Kleros. --- @@ -63,5 +113,7 @@ Specific use cases include protocol governance disputes, on-chain moderation, or integrations@kleros.io - - \ No newline at end of file + + In-depth Kleros Enterprise documentation on Notion + + diff --git a/images/5 phases of a dispute.png b/images/5 phases of a dispute.png new file mode 100644 index 0000000..761be05 Binary files /dev/null and b/images/5 phases of a dispute.png differ diff --git a/images/Appeals.png b/images/Appeals.png new file mode 100644 index 0000000..5de961c Binary files /dev/null and b/images/Appeals.png differ diff --git a/images/Court tree.png b/images/Court tree.png new file mode 100644 index 0000000..571cb5b Binary files /dev/null and b/images/Court tree.png differ diff --git a/images/Handling your first dispute.png b/images/Handling your first dispute.png new file mode 100644 index 0000000..c85038f Binary files /dev/null and b/images/Handling your first dispute.png differ diff --git a/images/Modular Resolution Mechanism.png b/images/Modular Resolution Mechanism.png new file mode 100644 index 0000000..37ade4d Binary files /dev/null and b/images/Modular Resolution Mechanism.png differ diff --git a/images/PNK_hero.png b/images/PNK_hero.png new file mode 100644 index 0000000..73ae70b Binary files /dev/null and b/images/PNK_hero.png differ diff --git a/images/Schelling points.png b/images/Schelling points.png new file mode 100644 index 0000000..95f15ef Binary files /dev/null and b/images/Schelling points.png differ diff --git a/images/Staking PNK.png b/images/Staking PNK.png new file mode 100644 index 0000000..825f141 Binary files /dev/null and b/images/Staking PNK.png differ diff --git a/images/The juror incentive system.png b/images/The juror incentive system.png new file mode 100644 index 0000000..1770067 Binary files /dev/null and b/images/The juror incentive system.png differ diff --git a/images/Three-face selection system.png b/images/Three-face selection system.png new file mode 100644 index 0000000..271b870 Binary files /dev/null and b/images/Three-face selection system.png differ diff --git a/images/Two-phase voting system.png b/images/Two-phase voting system.png new file mode 100644 index 0000000..7dd5b67 Binary files /dev/null and b/images/Two-phase voting system.png differ diff --git a/images/buy-pnk.png b/images/buy-pnk.png new file mode 100644 index 0000000..30a0074 Binary files /dev/null and b/images/buy-pnk.png differ diff --git a/images/challenge-poh.png b/images/challenge-poh.png new file mode 100644 index 0000000..3ecf3fb Binary files /dev/null and b/images/challenge-poh.png differ diff --git a/images/checkstake-v2.avif b/images/checkstake-v2.avif new file mode 100644 index 0000000..c1acf36 Binary files /dev/null and b/images/checkstake-v2.avif differ diff --git a/images/curatev1-hero.png b/images/curatev1-hero.png new file mode 100644 index 0000000..c181f2e Binary files /dev/null and b/images/curatev1-hero.png differ diff --git a/images/deliverydetails.jpeg b/images/deliverydetails.jpeg new file mode 100644 index 0000000..58454e6 Binary files /dev/null and b/images/deliverydetails.jpeg differ diff --git a/images/disputed-poh.png b/images/disputed-poh.png new file mode 100644 index 0000000..067e308 Binary files /dev/null and b/images/disputed-poh.png differ diff --git a/images/escrowtype.png b/images/escrowtype.png new file mode 100644 index 0000000..a54cdf8 Binary files /dev/null and b/images/escrowtype.png differ diff --git a/images/escrowv1-hero.png b/images/escrowv1-hero.png new file mode 100644 index 0000000..59cecfc Binary files /dev/null and b/images/escrowv1-hero.png differ diff --git a/images/evidencedetails-poh.png b/images/evidencedetails-poh.png new file mode 100644 index 0000000..83e90ab Binary files /dev/null and b/images/evidencedetails-poh.png differ diff --git a/images/expired-poh.png b/images/expired-poh.png new file mode 100644 index 0000000..81cb713 Binary files /dev/null and b/images/expired-poh.png differ diff --git a/images/flowdig-poh.png b/images/flowdig-poh.png new file mode 100644 index 0000000..e7ac5ff Binary files /dev/null and b/images/flowdig-poh.png differ diff --git a/images/homepage-escrow.png b/images/homepage-escrow.png new file mode 100644 index 0000000..b373b46 Binary files /dev/null and b/images/homepage-escrow.png differ diff --git a/images/info-poh.png b/images/info-poh.png new file mode 100644 index 0000000..abe115a Binary files /dev/null and b/images/info-poh.png differ diff --git a/images/inreview-poh.png b/images/inreview-poh.png new file mode 100644 index 0000000..6810037 Binary files /dev/null and b/images/inreview-poh.png differ diff --git a/images/joincourt.png b/images/joincourt.png new file mode 100644 index 0000000..01fc3af Binary files /dev/null and b/images/joincourt.png differ diff --git a/images/juror-tutorial.png b/images/juror-tutorial.png new file mode 100644 index 0000000..521d716 Binary files /dev/null and b/images/juror-tutorial.png differ diff --git a/images/kleros-hero.png b/images/kleros-hero.png new file mode 100644 index 0000000..24b3372 Binary files /dev/null and b/images/kleros-hero.png differ diff --git a/images/monitordispute.png b/images/monitordispute.png new file mode 100644 index 0000000..9735145 Binary files /dev/null and b/images/monitordispute.png differ diff --git a/images/mycase.png b/images/mycase.png new file mode 100644 index 0000000..84e5d10 Binary files /dev/null and b/images/mycase.png differ diff --git a/images/mystake.png b/images/mystake.png new file mode 100644 index 0000000..afde47b Binary files /dev/null and b/images/mystake.png differ diff --git a/images/needsvouch-poh.png b/images/needsvouch-poh.png new file mode 100644 index 0000000..73bb3ba Binary files /dev/null and b/images/needsvouch-poh.png differ diff --git a/images/partydetails-escrow.png b/images/partydetails-escrow.png new file mode 100644 index 0000000..6f582b0 Binary files /dev/null and b/images/partydetails-escrow.png differ diff --git a/images/photo-poh.png b/images/photo-poh.png new file mode 100644 index 0000000..9e19a54 Binary files /dev/null and b/images/photo-poh.png differ diff --git a/images/pohregistration.png b/images/pohregistration.png new file mode 100644 index 0000000..caaaa94 Binary files /dev/null and b/images/pohregistration.png differ diff --git a/images/raisedispute-escrow.png b/images/raisedispute-escrow.png new file mode 100644 index 0000000..2116458 Binary files /dev/null and b/images/raisedispute-escrow.png differ diff --git a/images/receiver-escrow.png b/images/receiver-escrow.png new file mode 100644 index 0000000..399572b Binary files /dev/null and b/images/receiver-escrow.png differ diff --git a/images/receiveramount-escrow.png b/images/receiveramount-escrow.png new file mode 100644 index 0000000..d0e1a74 Binary files /dev/null and b/images/receiveramount-escrow.png differ diff --git a/images/registerdone-poh.png b/images/registerdone-poh.png new file mode 100644 index 0000000..0fcb67c Binary files /dev/null and b/images/registerdone-poh.png differ diff --git a/images/relaystate-poh.png b/images/relaystate-poh.png new file mode 100644 index 0000000..18d5a78 Binary files /dev/null and b/images/relaystate-poh.png differ diff --git a/images/revoke-poh.png b/images/revoke-poh.png new file mode 100644 index 0000000..6140ea9e Binary files /dev/null and b/images/revoke-poh.png differ diff --git a/images/revokedeposit-poh.png b/images/revokedeposit-poh.png new file mode 100644 index 0000000..9143d4d Binary files /dev/null and b/images/revokedeposit-poh.png differ diff --git a/images/revokedstatus-poh.png b/images/revokedstatus-poh.png new file mode 100644 index 0000000..f686a48 Binary files /dev/null and b/images/revokedstatus-poh.png differ diff --git a/images/revoketitle-poh.png b/images/revoketitle-poh.png new file mode 100644 index 0000000..9f29a6f Binary files /dev/null and b/images/revoketitle-poh.png differ diff --git a/images/scout-plugin.avif b/images/scout-plugin.avif new file mode 100644 index 0000000..ce3b541 Binary files /dev/null and b/images/scout-plugin.avif differ diff --git a/images/scout-snap.avif b/images/scout-snap.avif new file mode 100644 index 0000000..0838772 Binary files /dev/null and b/images/scout-snap.avif differ diff --git a/images/scout-tutorial.png b/images/scout-tutorial.png new file mode 100644 index 0000000..d57e378 Binary files /dev/null and b/images/scout-tutorial.png differ diff --git a/images/selectcourt-v2.avif b/images/selectcourt-v2.avif new file mode 100644 index 0000000..123d302 Binary files /dev/null and b/images/selectcourt-v2.avif differ diff --git a/images/senderamount-escrow.png b/images/senderamount-escrow.png new file mode 100644 index 0000000..59e10d9 Binary files /dev/null and b/images/senderamount-escrow.png differ diff --git a/images/senderfinal-escrow.png b/images/senderfinal-escrow.png new file mode 100644 index 0000000..2116458 Binary files /dev/null and b/images/senderfinal-escrow.png differ diff --git a/images/senderpayment-escrow.png b/images/senderpayment-escrow.png new file mode 100644 index 0000000..b0b74af Binary files /dev/null and b/images/senderpayment-escrow.png differ diff --git a/images/snap-use.png b/images/snap-use.png new file mode 100644 index 0000000..be6a8cd Binary files /dev/null and b/images/snap-use.png differ diff --git a/images/stakePNK.png b/images/stakePNK.png new file mode 100644 index 0000000..4869ebd Binary files /dev/null and b/images/stakePNK.png differ diff --git a/images/status-poh.png b/images/status-poh.png new file mode 100644 index 0000000..9cc9a3d Binary files /dev/null and b/images/status-poh.png differ diff --git a/images/submitescrow.png b/images/submitescrow.png new file mode 100644 index 0000000..39402b5 Binary files /dev/null and b/images/submitescrow.png differ diff --git a/images/submitevidence.png b/images/submitevidence.png new file mode 100644 index 0000000..d6ed26f Binary files /dev/null and b/images/submitevidence.png differ diff --git a/images/summaryescrow.png b/images/summaryescrow.png new file mode 100644 index 0000000..5810c04 Binary files /dev/null and b/images/summaryescrow.png differ diff --git a/images/timeleft-escrow.png b/images/timeleft-escrow.png new file mode 100644 index 0000000..f9a1084 Binary files /dev/null and b/images/timeleft-escrow.png differ diff --git a/images/transactiondetail.jpeg b/images/transactiondetail.jpeg new file mode 100644 index 0000000..dadfa12 Binary files /dev/null and b/images/transactiondetail.jpeg differ diff --git a/images/transfer-poh.png b/images/transfer-poh.png new file mode 100644 index 0000000..220ce45 Binary files /dev/null and b/images/transfer-poh.png differ diff --git a/images/transferred-poh.png b/images/transferred-poh.png new file mode 100644 index 0000000..86258c5 Binary files /dev/null and b/images/transferred-poh.png differ diff --git a/images/updatestate-poh.png b/images/updatestate-poh.png new file mode 100644 index 0000000..5d3f915 Binary files /dev/null and b/images/updatestate-poh.png differ diff --git a/images/v1-court.png b/images/v1-court.png new file mode 100644 index 0000000..fbf8630 Binary files /dev/null and b/images/v1-court.png differ diff --git a/images/v1-screenshot-placeholder.png b/images/v1-screenshot-placeholder.png new file mode 100644 index 0000000..e69de29 diff --git a/images/v1-screenshot-placeholder.svg b/images/v1-screenshot-placeholder.svg new file mode 100644 index 0000000..b4be652 --- /dev/null +++ b/images/v1-screenshot-placeholder.svg @@ -0,0 +1,8 @@ + + + + + V1 screenshot placeholder + Replace with the V1 interface screenshot + + diff --git a/images/v2-onepager-placeholder.svg b/images/v2-onepager-placeholder.svg new file mode 100644 index 0000000..30437fb --- /dev/null +++ b/images/v2-onepager-placeholder.svg @@ -0,0 +1,7 @@ + + + + One-pager infographic + Visual explainer to be added here + Getting Started with Kleros Court V2 + diff --git a/images/video-poh.png b/images/video-poh.png new file mode 100644 index 0000000..f431b85 Binary files /dev/null and b/images/video-poh.png differ diff --git a/images/vitalik-poh.png b/images/vitalik-poh.png new file mode 100644 index 0000000..649ff78 Binary files /dev/null and b/images/vitalik-poh.png differ diff --git a/images/vouch-poh.png b/images/vouch-poh.png new file mode 100644 index 0000000..15f25cc Binary files /dev/null and b/images/vouch-poh.png differ diff --git a/images/walletconnect-escrow.png b/images/walletconnect-escrow.png new file mode 100644 index 0000000..4068c23 Binary files /dev/null and b/images/walletconnect-escrow.png differ diff --git a/images/winning-poh.png b/images/winning-poh.png new file mode 100644 index 0000000..dc638d6 Binary files /dev/null and b/images/winning-poh.png differ diff --git a/images/withdraw-poh.png b/images/withdraw-poh.png new file mode 100644 index 0000000..04c6f89 Binary files /dev/null and b/images/withdraw-poh.png differ diff --git a/index.mdx b/index.mdx index a7ee738..c0a75be 100644 --- a/index.mdx +++ b/index.mdx @@ -54,7 +54,7 @@ Kleros products are decentralized applications that use Kleros Court for dispute **Decentralized lists & registries** - Create and maintain community-curated registries of anything—tokens, contracts, addresses, or custom data. + Create and maintain community-curated registries of anything-tokens, contracts, addresses, or custom data. **Sybil-resistant identity** @@ -115,10 +115,10 @@ Build trustless applications with decentralized dispute resolution. You want your smart contract to use Kleros Court for dispute resolution. - + The interface your contract needs to implement - + How to handle evidence submission diff --git a/legacy/court-v1.mdx b/legacy/court-v1.mdx index a965b7c..f9b8c85 100644 --- a/legacy/court-v1.mdx +++ b/legacy/court-v1.mdx @@ -1,15 +1,15 @@ --- title: "Court V1" -description: "Kleros Court V1 on Ethereum Mainnet (legacy)" +description: "Kleros Court V1 on Ethereum Mainnet" --- -# Court V1 (Legacy) +# Court V1 - -Court V1 is superseded by [Court V2](/court/overview) on Arbitrum. Use V2 for all new activity. - + +Court V1 is the production-proven protocol on Ethereum L1 and remains active for web3 integrations. A V2 version is available: [Court V2](/court/overview) on Arbitrum. + -Kleros Court V1 was the original decentralized dispute resolution protocol deployed on Ethereum Mainnet in 2018. The core smart contract was **KlerosLiquid**, which combined juror staking, random selection, voting, and dispute management in a single contract. +Kleros Court V1 is the original decentralized dispute resolution protocol deployed on Ethereum Mainnet in 2018. The core smart contract was **KlerosLiquid**, which combined juror staking, random selection, voting, and dispute management in a single contract. --- @@ -49,5 +49,4 @@ V1 had a similar hierarchical court tree to V2, with the General Court as root a - **V1 Court App**: Previously at court.kleros.io (now redirects to V2) - **Contract**: KlerosLiquid on Ethereum Mainnet -- **ERC-792 Standard**: See [ERC-792 documentation](/developers/legacy/erc-792) -- **Migration**: See [Migration Guide](/legacy/migration-guide) \ No newline at end of file +- **ERC-792 Standard**: See [ERC-792 documentation](/developers/arbitrable-apps/erc-792) \ No newline at end of file diff --git a/legacy/curate-v1.mdx b/legacy/curate-v1.mdx index d9aceaa..9aefd51 100644 --- a/legacy/curate-v1.mdx +++ b/legacy/curate-v1.mdx @@ -1,15 +1,15 @@ --- title: "Curate V1" -description: "Kleros Curate V1 Token Curated Registries on Ethereum (legacy)" +description: "Kleros Curate V1 Token Curated Registries on Ethereum" --- -# Curate V1 (Legacy) +# Curate V1 - -Curate V1 is superseded by [Curate V2](/products/curate) on Arbitrum. - + +Curate V1 is production-proven on Ethereum L1 and remains active for web3 integrations. A V2 version is available: [Curate V2](/products/curate) on Arbitrum. + -Curate V1 was the original decentralized registry application deployed on Ethereum Mainnet. It enabled anyone to create and maintain community-curated registries (Token Curated Registries / TCRs) with crypto-economic incentives and Kleros Court dispute resolution. +Curate V1 is the original decentralized registry application deployed on Ethereum Mainnet. It enabled anyone to create and maintain community-curated registries (Token Curated Registries / TCRs) with crypto-economic incentives and Kleros Court dispute resolution. --- @@ -37,4 +37,4 @@ These registries were the data layer behind [Kleros Scout](/products/scout). ## Migration -V2 Curate is deployed on Arbitrum with lower gas costs and the same TCR mechanics. Existing V1 registries remain accessible but new registries should be created on V2. See the [Migration Guide](/legacy/migration-guide). \ No newline at end of file +V2 Curate is deployed on Arbitrum with lower gas costs and the same TCR mechanics. Existing V1 registries remain accessible. \ No newline at end of file diff --git a/legacy/escrow-v1.mdx b/legacy/escrow-v1.mdx index 342f7b8..6b54440 100644 --- a/legacy/escrow-v1.mdx +++ b/legacy/escrow-v1.mdx @@ -1,15 +1,15 @@ --- title: "Escrow V1" -description: "Kleros Escrow V1 on Ethereum (legacy)" +description: "Kleros Escrow V1 on Ethereum" --- -# Escrow V1 (Legacy) +# Escrow V1 - -Escrow V1 is superseded by [Escrow V2](/products/escrow) on Arbitrum. - + +Escrow V1 is production-proven on Ethereum L1 and remains active for web3 integrations. A V2 version is available: [Escrow V2](/products/escrow) on Arbitrum. + -Kleros Escrow V1 was the original decentralized escrow platform on Ethereum Mainnet. It allowed two parties to lock funds in a smart contract, with Kleros Court available as a dispute resolution mechanism if the parties disagreed. +Kleros Escrow V1 is the original decentralized escrow platform on Ethereum Mainnet. It allowed two parties to lock funds in a smart contract, with Kleros Court available as a dispute resolution mechanism if the parties disagreed. --- @@ -26,7 +26,7 @@ Escrow V1 only supports ETH and standard ERC-20 tokens. Non-standard tokens typi - **Rebasing** supply adjustments - **Pausable** transfers that can be frozen by an admin -If you need to use non-standard tokens, migrate to [Escrow V2](/products/escrow), which includes `SafeERC20` handling and automatic safety checks for broader token compatibility. +Non-standard tokens are supported on [Escrow V2](/products/escrow), which includes `SafeERC20` handling and automatic safety checks for broader token compatibility. --- diff --git a/legacy/governor-v1.mdx b/legacy/governor-v1.mdx index 2e95505..9b83a23 100644 --- a/legacy/governor-v1.mdx +++ b/legacy/governor-v1.mdx @@ -1,13 +1,13 @@ --- title: "Governor V1" -description: "Kleros Governor V1 on Ethereum (legacy)" +description: "Kleros Governor V1 on Ethereum" --- -# Governor V1 (Legacy) +# Governor V1 - -Governor V1 is superseded by [Governor V2](/products/governor) on Arbitrum. - + +Governor V1 is production-proven on Ethereum L1 and remains active for web3 integrations. A V2 version is available: [Governor V2](/products/governor) on Arbitrum. + Kleros Governor V1 was deployed on Ethereum Mainnet as part of the transition from Aragon-based governance to fully decentralized governance using Snapshot voting and on-chain execution (see [KIP-30](https://forum.kleros.io/t/kip-30-migrate-governance-to-snapshot/469)). diff --git a/legacy/integrate/zodiac-integration.mdx b/legacy/integrate/zodiac-integration.mdx index 06676ba..434b350 100644 --- a/legacy/integrate/zodiac-integration.mdx +++ b/legacy/integrate/zodiac-integration.mdx @@ -15,7 +15,7 @@ This guide covers how to make your DAO governance fully decentralized using Gnos | --- | --- | | [Gnosis Safe](https://gnosis-safe.io/) | Multi-signature wallet managing DAO treasury and contracts | | [Snapshot](https://snapshot.org/) | Off-chain vote signaling platform | -| [Zodiac Reality Module](https://gnosis.github.io/zodiac/docs/tutorial-module-reality/get-started) | Enables trustless on-chain execution of off-chain votes using Reality.eth | +| [Zodiac Reality Module](https://zodiac.gnosisguild.org/) | Enables trustless on-chain execution of off-chain votes using Reality.eth | | [Kleros Court](https://court.kleros.io) | Arbitrates disputed proposals via the Reality.eth-Kleros proxy | This creates a separation of powers: token holders vote (legislative), the multisig executes (executive), and Kleros arbitrates disputed proposals (judiciary). @@ -31,8 +31,8 @@ This creates a separation of powers: token holders vote (legislative), the multi ### Steps -1. **Set up Zodiac Reality Module** following the [Zodiac documentation](https://gnosis.github.io/zodiac/docs/tutorial-module-reality/get-started). When setting parameters, select **Kleros** in the arbitrator field. -2. **Add the SafeSnap plugin to Snapshot** following the [Snapshot integration guide](https://gnosis.github.io/zodiac/docs/tutorial-module-reality/integrate-snapshot). +1. **Set up Zodiac Reality Module** following the [Zodiac documentation](https://zodiac.gnosisguild.org/). When setting parameters, select **Kleros** in the arbitrator field. +2. **Add the SafeSnap plugin to Snapshot** following the [Snapshot integration guide](https://zodiac.gnosisguild.org/). 3. **Test proposals**: Create executable proposals on Snapshot and process them after voting ends. @@ -84,7 +84,7 @@ After this, the only way to interact with the DAO's Safe is through governance p ## Resources - + Full Zodiac setup guide diff --git a/legacy/migration-guide.mdx b/legacy/migration-guide.mdx deleted file mode 100644 index 6f8f408..0000000 --- a/legacy/migration-guide.mdx +++ /dev/null @@ -1,91 +0,0 @@ ---- -title: "Migration Guide" -description: "How to migrate from Kleros V1 to V2" ---- - -# Migration Guide: V1 to V2 - -This guide covers the key differences between Kleros V1 and V2 and what changes are needed for jurors, developers, and users migrating to the new protocol. - ---- - -## For Jurors - -### What Changed - -| Aspect | V1 (Ethereum) | V2 (Arbitrum) | -|--------|---------------|---------------| -| **Network** | Ethereum Mainnet (+ xDAI) | Arbitrum One | -| **PNK Staking** | PNK stays in wallet | PNK transfers to KlerosCore contract | -| **Gas Costs** | High (Ethereum gas) | Low (Arbitrum gas) | -| **Minimum Stake** | Varies (e.g., 1,000 PNK for Onboarding) | Varies per court (check live court UI) | -| **Vote Privacy** | Basic commit-reveal | Commit-reveal (Shutter encryption in development) | - -### Migration Steps - - - - Use the [Arbitrum Bridge](https://bridge.arbitrum.io) or a cross-chain bridge to move PNK from Ethereum to Arbitrum One. - - - You need a small amount of ETH on Arbitrum for transaction fees. Bridge or send ETH to your Arbitrum address. - - - Visit [court.kleros.io](https://court.kleros.io), connect your wallet on Arbitrum, and stake PNK in your chosen court. You will need to approve PNK spending first. - - - - -In V2, staking PNK **transfers tokens to the KlerosCore contract**. This is different from V1 where PNK remained in your wallet. Your staked PNK is still yours and can be unstaked, but it is held by the contract while staked. - - ---- - -## For Developers - -### Key Architecture Changes - -V2 significantly simplifies integration compared to V1: - -| Responsibility | V1 | V2 | -|---------------|----|----| -| **Evidence handling** | Arbitrable contract | Handled by Court | -| **Appeal logic** | Arbitrable contract | Handled by Court | -| **Crowdfunding appeals** | Complex arbitrable logic | Built into Court | -| **Dispute creation** | Direct call to arbitrator | Direct call to KlerosCore | -| **Ruling reception** | Same (`rule()` callback) | Same (`rule()` callback) | - -The core change for developers: **evidence submission and appeal management are now handled entirely by the Court**. Your arbitrable contract no longer needs to implement these. - -### Interface Changes - -V1 used the **ERC-792** arbitration standard. V2 uses an updated interface: - -- `IArbitrableV2` replaces `IArbitrable` -- `DisputeTemplate` replaces `MetaEvidence` for defining dispute context -- Evidence is submitted directly to the Court, not logged by the arbitrable -- `extraData` encoding includes court ID and number of jurors - -For detailed integration guidance, see the [Developers section](/developers/overview). - -### Cross-Chain Support - -V2 supports disputes from any EVM chain via the **VEA bridge**. If your application is on Ethereum Mainnet or another chain, disputes can be bridged to Arbitrum for resolution, with rulings bridged back. Applications natively on Arbitrum interact directly with KlerosCore without bridging. - ---- - -## For Product Users - -Most Kleros products now have V2 versions: - -- **Court**: Use [court.kleros.io](https://court.kleros.io) (V2 on Arbitrum) -- **Escrow**: Use [escrow.kleros.io](https://escrow.kleros.io) (V2 on Arbitrum) -- **Curate**: Use [curate.kleros.io](https://curate.kleros.io) (V2 on Arbitrum) - -Products that still use V1 (Scout, Reality, PoH) will provide migration paths when their V2 versions are ready. - ---- - -## Need Help? - -For migration support, contact the Kleros team at **integrations@kleros.io** or ask in the [Discord](https://discord.gg/kleros). \ No newline at end of file diff --git a/legacy/overview.mdx b/legacy/overview.mdx index 23c0bdf..6fa2b98 100644 --- a/legacy/overview.mdx +++ b/legacy/overview.mdx @@ -1,27 +1,27 @@ --- -title: "Legacy (V1) Overview" +title: "V1 Protocol Overview" description: "Documentation for Kleros V1 products and retired applications" --- -# Legacy (V1) Documentation +# V1 Protocol Documentation -This section documents Kleros V1 products and retired applications. These systems are either superseded by V2 equivalents or have been discontinued. +This section documents the Kleros V1 protocol and its products, along with retired applications. V1 is the production-proven protocol on Ethereum L1 and remains active for web3 integrations. - -**For new users and integrations**, use [Kleros V2](/court/overview) on Arbitrum. V1 documentation is maintained for reference and for existing integrations that have not yet migrated. - + +Each V1 product below has a V2 version available on Arbitrum. + --- -## V1 Products (Superseded by V2) +## V1 Products -| Product | V1 Status | V2 Replacement | -|---------|-----------|----------------| -| [Court V1](/legacy/court-v1) | Active but deprecated | [Court V2](/court/overview) on Arbitrum | -| [Curate V1](/legacy/curate-v1) | Active but deprecated | [Curate V2](/products/curate) on Arbitrum | -| [Escrow V1](/legacy/escrow-v1) | Active but deprecated | [Escrow V2](/products/escrow) on Arbitrum | -| [Governor V1](/legacy/governor-v1) | Active but deprecated | [Governor V2](/products/governor) on Arbitrum | -| [Resolver V1](/legacy/resolver-v1) | Deprecated | Integrated into Court V2 interface | +| Product | Status | V2 version | +|---------|--------|------------| +| [Court V1](/legacy/court-v1) | Production | [Court V2](/court/overview) on Arbitrum | +| [Curate V1](/legacy/curate-v1) | Production | [Curate V2](/products/curate) on Arbitrum | +| [Escrow V1](/legacy/escrow-v1) | Production | [Escrow V2](/products/escrow) on Arbitrum | +| [Governor V1](/legacy/governor-v1) | Production | [Governor V2](/products/governor) on Arbitrum | +| [Resolver V1](/legacy/resolver-v1) | Integrated into Court V2 | Integrated into Court V2 interface | --- @@ -37,16 +37,10 @@ These products are no longer actively maintained: --- -## Migration to V2 +## What V2 Changes -If you are running an existing V1 integration, see the [Migration Guide](/legacy/migration-guide) for steps to upgrade to V2. - -Key V2 advantages over V1: - -- Deployed on Arbitrum with significantly lower gas costs +- Deployed on Arbitrum instead of Ethereum L1 - Modular dispute kit architecture - Cross-chain support via VEA bridge -- Simplified integration (evidence and appeals handled by the Court, not the arbitrable) -- Enhanced vote privacy (Shutter integration in development) - -For migration support, contact the team at **integrations@kleros.io**. \ No newline at end of file +- Evidence and appeals handled by the Court rather than the arbitrable contract +- Vote privacy through Shutter integration (in development) \ No newline at end of file diff --git a/legacy/resolver-v1.mdx b/legacy/resolver-v1.mdx index 74d379c..7f06e12 100644 --- a/legacy/resolver-v1.mdx +++ b/legacy/resolver-v1.mdx @@ -1,9 +1,9 @@ --- title: "Resolver V1" -description: "Kleros Dispute Resolver V1 (legacy now integrated into Court V2)" +description: "Kleros Dispute Resolver V1 (now integrated into Court V2)" --- -# Resolver V1 (Legacy) +# Resolver V1 Resolver V1 was a standalone application. Its functionality is now integrated directly into the [Court V2](/court/overview) interface. diff --git a/legacy/retired/tokens.mdx b/legacy/retired/tokens.mdx index 2ff2bc5..c09dba5 100644 --- a/legacy/retired/tokens.mdx +++ b/legacy/retired/tokens.mdx @@ -15,4 +15,4 @@ The Tokens interface has been retired. Token registry functionality is now part ## Current Replacement -Token registry functionality now lives within [Kleros Curate](/products/curate), which provides a more flexible and general-purpose framework for creating any type of curated registry — including token lists, address tags, and more. Token data curated through Curate is displayed in [Kleros Scout](/products/scout). \ No newline at end of file +Token registry functionality now lives within [Kleros Curate](/products/curate), which provides a more flexible and general-purpose framework for creating any type of curated registry - including token lists, address tags, and more. Token data curated through Curate is displayed in [Kleros Scout](/products/scout). \ No newline at end of file diff --git a/products/curate.mdx b/products/curate.mdx index bd49d6f..bfadf00 100644 --- a/products/curate.mdx +++ b/products/curate.mdx @@ -4,22 +4,28 @@ description: Decentralized lists and registries powered by crypto-economic incen --- - Kleros Curate Interface + Kleros Curate Interface # Curate -V2 - -**Curate** is a decentralized application for creating and maintaining community-curated registries. Anyone can submit items to a list, and anyone can challenge incorrect or malicious submissions—with disputes resolved by Kleros Court. +**Curate** is a decentralized application for creating and maintaining community-curated registries. Anyone can submit items to a list, and anyone can challenge incorrect or malicious submissions-with disputes resolved by Kleros Court. Think of it as Wikipedia for structured data, but with economic skin in the game. Submitters stake a deposit that they lose if their submission is successfully challenged. Challengers risk their own deposit if the submission turns out to be valid. This creates a self-sustaining system where participants are economically incentivized to maintain accurate registries. Curate powers critical infrastructure across Web3: token lists that wallets use to display assets, address tags that block explorers use to label contracts, and security registries that help users avoid scams. - - Looking for V1 documentation? See [Curate V1 (Legacy)](/legacy/curate-v1). - +--- + +## Curate Variants + +Curate is a family of three variants. All three use the V1 Kleros Court for dispute resolution. + +- **Classic Curate** (V1) - a full Token-Curated Registry (TCR) supporting complex schemas. Best for high-value registries with custom fields. Migrated to Gnosis Chain. +- **Light Curate** (V1) - a simplified TCR built for higher volume and lower gas costs. On Gnosis Chain. +- **Stake Curate** (V1 infrastructure) - continuous verification with permanent deposits, on Gnosis Chain. Deployed mid-August 2025; first implementation with DAMM Capital (September 2025). See [Stake Curate](/products/stake%20curate). + + --- @@ -136,14 +142,23 @@ This creates a self-policing system where bad actors are economically punished. ## Registry Types -Curate supports two registry architectures: +Curate offers three variants across the two protocol versions: -| Type | Best For | Gas Costs | Flexibility | -|------|----------|-----------|-------------| -| **Curate** (full) | High-value registries with complex schemas | Higher | Maximum | -| **Light Curate** | Simple registries, higher volume | Lower | Standard schemas | +| Variant | Version | Best For | Gas Costs | Flexibility | +|---------|---------|----------|-----------|-------------| +| **Classic Curate** (full) | V1 | High-value registries with complex schemas | Higher | Maximum | +| **Light Curate** | V1 | Simple registries, higher volume | Lower | Standard schemas | +| **Stake Curate** | V1 infra | Continuous verification with permanent deposits | - | See [Stake Curate](/products/stake%20curate) | -Most new registries use **Light Curate** for cost efficiency. Full Curate is used when you need custom fields or complex acceptance criteria. +Among the V1 variants, most registries use **Light Curate** for cost efficiency. Classic Curate is used when you need custom fields or complex acceptance criteria. + +--- + +## Current Status + +As of the May 2026 development update, Curate V2 aligned its evidence query with the kleros-core schema migration and removed an unused evidence hook. Work is in progress to integrate a shared file-viewer component. + +Follow development on the [Kleros blog - developer updates](https://blog.kleros.io/tag/developer/). --- @@ -151,12 +166,11 @@ Most new registries use **Light Curate** for cost efficiency. Full Curate is use - + **Step-by-step guides** Learn how to submit items, challenge submissions, and earn rewards. - - → Help Center + @@ -191,7 +205,7 @@ Most new registries use **Light Curate** for cost efficiency. Full Curate is use Curate V2 deployment addresses - + Guide to deploying your own registry \ No newline at end of file diff --git a/products/escrow.mdx b/products/escrow.mdx index 0c278d5..fbd4897 100644 --- a/products/escrow.mdx +++ b/products/escrow.mdx @@ -6,17 +6,55 @@ sidebarTitle: "Escrow" --- -Kleros Escrow Interface +Kleros Escrow Interface # Escrow - -**V2** - Looking for V1 documentation? See [Escrow V1 (Legacy)](/legacy/escrow-v1). - - **Kleros Escrow** is a decentralized escrow platform that secures blockchain transactions between untrusted parties. It combines smart contract automation with Kleros' decentralized arbitration system to provide trustless transaction security for digital commerce. -Traditional online transactions require trust between strangers, creating opportunities for fraud and disputes. Kleros Escrow eliminates this trust requirement by securing funds in smart contracts, allowing structured settlement negotiations, and delivering decentralized arbitration through Kleros Court when agreements fail. +Traditional online transactions require trust between strangers, creating opportunities for fraud and disputes. Kleros Escrow eliminates this trust requirement by securing funds in smart contracts and delivering decentralized arbitration through Kleros Court when agreements fail. + +--- + +## V1 - Production Protocol + +Escrow V1 runs on Ethereum Mainnet. Two parties lock funds in a smart contract, with Kleros Court available as the dispute resolution mechanism if they disagree. + + + +- **Network**: Ethereum Mainnet +- **Model**: Two-party escrow with basic settlement +- **Tokens**: ETH and standard ERC-20 tokens (non-standard tokens such as USDT are not supported) +- **Evidence & appeals**: Handled by the escrow contract + +--- + +## V2 - Next-Gen Upgrade + +Escrow V2 runs on Arbitrum and adds structured settlement negotiation, multi-token support (ETH, USDC, USDT, DAI, or any ERC-20 via `SafeERC20`), and moves evidence and appeal handling to the Court. + + Escrow V1 interface, screenshot to be added + + +--- + +## What Changed in V2 + +| Feature | V1 | V2 | +|---------|----|----| +| Network | Ethereum Mainnet | Arbitrum One | +| Token support | ETH + standard ERC-20 | ETH + any ERC-20 (via SafeERC20) | +| Settlement | Basic | Structured proposal / counter-proposal | +| Evidence & appeals | Handled by escrow contract | Handled by Court | +| Platform fees | None | None | + +--- + +## Current Status + +As of the May 2026 development update, Escrow completed its Atlas IPFS migration, with UX improvements to the agreement upload step. + +Follow development on the [Kleros blog - developer updates](https://blog.kleros.io/tag/developer/). --- @@ -41,7 +79,7 @@ Traditional online transactions require trust between strangers, creating opport - Completely free to use—only pay network gas fees + Completely free to use-only pay network gas fees @@ -113,7 +151,7 @@ Kleros Escrow V2 provides multiple ways to resolve transactions: - The deadline has elapsed - This requires a manual transaction call—it is NOT automatic. Any address can trigger it once conditions are met. + This requires a manual transaction call-it is NOT automatic. Any address can trigger it once conditions are met. diff --git a/products/foresight.mdx b/products/foresight.mdx index 3bba829..deaa92c 100644 --- a/products/foresight.mdx +++ b/products/foresight.mdx @@ -91,13 +91,26 @@ Your profit or loss depends on the difference between what you paid for your tok ### Movie Score Predictions (Session 1) -The first Kleros Foresight experiment asks participants to predict what percentile score a judge will give to movies after watching them. There are 16 movies in the session, but only 5 are selected for evaluation at the end of the trading period. This is a direct implementation of Distilled Human Judgment: the crowd evaluates every item through market prices, but only a small subset needs actual human assessment. +The first Kleros Foresight experiment asks participants to predict what percentile score the judge - Kleros CTO and co-founder **Clément Lesaege** - will give to movies after watching them. There are 16 movies nominated in the session, but only 5 are selected for evaluation at the end of the trading period: the three with the highest market estimates, one chosen at random, and one the judge picks personally. This is a direct implementation of Distilled Human Judgment: the crowd evaluates every item through market prices, but only a small subset needs actual human assessment. Participants need a Web3 wallet on Gnosis Chain with xDAI or sDAI to get started. Verified humans on [Proof of Humanity](/products/proof-of-humanity) or Seer community members can also use monthly Seer credits to participate. -### Upcoming: RealT Property Tokens +A second movie experiment (Round 2) began in June 2026 and runs through July 2026. -A follow-up experiment with [RealT](https://realt.co) is in preparation, applying the same futarchy mechanics to real estate asset evaluation. +--- + +## Current Status + +As of the May 2026 development update, the Foresight interface has shipped: + +- Batched redemption of positions +- A corrected redemption-value calculation with a pre-check +- On-chain price fetch for markets that lack a subgraph entry +- Email notifications for market resolution + +Round 2 of the movie experiment launched in June 2026 and runs through July 2026. + +Follow development on the [Kleros blog - prediction markets](https://blog.kleros.io/tag/prediction-markets/). --- diff --git a/products/governor.mdx b/products/governor.mdx index 2777afa..9f1174c 100644 --- a/products/governor.mdx +++ b/products/governor.mdx @@ -6,7 +6,6 @@ description: "Decentralized governance execution with dispute resolution for con # Governor Kleros Governor Interface -**V2** Looking for V1 documentation? See [Governor V1 (Legacy)](/legacy/governor-v1). **Kleros Governor** enables DAOs and on-chain organizations to execute governance decisions with a built-in dispute resolution backstop. It uses an optimistic execution model: anyone can submit a list of transactions to be executed, and if no one challenges it, the transactions go through. If multiple competing lists are submitted, Kleros Court resolves the conflict. @@ -14,6 +13,27 @@ Governor is the mechanism Kleros itself uses to manage protocol parameters, cour --- +## V1 - Production Protocol + +Governor V1 runs on Ethereum Mainnet. It was deployed as part of the transition to fully decentralized governance using Snapshot voting and on-chain execution (see [KIP-30](https://forum.kleros.io/t/kip-30-migrate-governance-to-snapshot/469)). It uses the same optimistic execution model as V2, with a simpler implementation: + + + +1. A governance vote passes on Snapshot +2. Anyone submits a transaction list to Governor implementing the approved changes +3. During the submission period, others can submit competing lists +4. If only one list is submitted, it executes automatically +5. If multiple lists are submitted, a Kleros Court dispute determines the correct one +6. After resolution, the winning list's transactions are executed on-chain + +--- + +## V2 - Next-Gen Upgrade + +Governor V2 runs on Arbitrum and keeps the same optimistic execution model. The sections below describe the V2 implementation. + +--- + ## Key Capabilities diff --git a/products/overview.mdx b/products/overview.mdx index 3364e06..bb68554 100644 --- a/products/overview.mdx +++ b/products/overview.mdx @@ -8,23 +8,22 @@ description: Kleros products and their protocol versions Kleros provides a suite of decentralized applications, all powered by Kleros Court for dispute resolution. This page gives an overview of each product and its current protocol version. Kleros Interface - - **Kleros V2** is the latest version of the Kleros protocol, featuring improved scalability, lower gas costs, and enhanced dispute resolution mechanics. Most products have migrated or are migrating to V2. - - --- ## Protocol Version Guide -| Product | Protocol Version | Status | -|---------|-----------------|--------| -| [Court](/court/overview) | **V2** | ✅ Live | -| [Curate](/products/curate) | **V2** | ✅ Live | -| [Escrow](/products/escrow) | **V2** | ✅ Live | -| [Governor](/products/governor) | **V2** | ✅ Live | -| [Scout](/products/scout) | V1 | 🔄 V2 coming soon | -| [Reality (Oracle)](/products/reality) | V1 | 🔄 V2 coming soon | -| [Proof of Humanity](/products/proof-of-humanity) | V1 | ⚠️ See note below | +Kleros products run on two protocol versions. **V1** is the production-proven protocol on Ethereum L1; **V2** is the next-generation upgrade on Arbitrum L2. The table below shows where each product stands today. + +| Product | Available on | Notes | +|---------|--------------|-------| +| [Court](/court/overview) | V1 • V2 | V1 on Ethereum, V2 on Arbitrum | +| [Curate](/products/curate) | V1 • V2 | Classic (V1), Light (V1), Stake Curate (V1 infra) | +| [Escrow](/products/escrow) | V1 • V2 | V2 adds settlement negotiation and multi-token support | +| [Governor](/products/governor) | V1 • V2 | Optimistic execution on both versions | +| [Scout](/products/scout) | V1 | Frontend reading from V1 Curate registries | +| [Reality (Oracle)](/products/reality) | V1 | Kleros arbitration backstop for Reality.eth | +| [Proof of Humanity](/products/proof-of-humanity) | V1 | See note below | +| [Foresight](/products/foresight) | V2 | Experimental prediction-market platform | **Proof of Humanity note:** PoH has its own "V2" product upgrade (cross-chain support, improved UX), but it still uses the **Kleros V1 protocol** for dispute resolution. Don't confuse "PoH 2.0" (the product) with "Kleros V2" (the protocol). @@ -32,9 +31,7 @@ Kleros provides a suite of decentralized applications, all powered by Kleros Cou --- -## V2 Products - -These products run on the latest Kleros V2 protocol. +## Production Products @@ -53,8 +50,8 @@ These products run on the latest Kleros V2 protocol. Create and maintain community-curated lists with economic incentives and dispute resolution. + - Classic Curate (V1), Light Curate (V1), Stake Curate (V1 infra) - Token lists, address tags, contract registries - - Challenge incorrect submissions - Query registry data via subgraph @@ -78,24 +75,12 @@ These products run on the latest Kleros V2 protocol. - Integration with Snapshot - - ---- - -## V1 Products (V2 Migration Planned) - -These products currently use Kleros V1 and will migrate to V2. - - - **Contract & token verification** Community-curated safety information for smart contracts, tokens, and dApps. Integrates with MetaMask Snaps. - - Scout is a **frontend application** that displays data from Curate registries. V2 support will come when the underlying registries migrate. - + Scout is a frontend that reads from Curate registries. @@ -108,66 +93,67 @@ These products currently use Kleros V1 and will migrate to V2. - Kleros as arbitration backstop + + **Sybil-resistant identity registry** + + A registry of verified humans combining video verification, social vouching, and dispute resolution. + + Uses the Kleros V1 protocol for dispute resolution. + + + + **Prediction-market decision making** + + Prediction market platform built on Seer, with Kleros Court as the backstop for contested outcomes. + + Experimental + + --- -## V1 Protocol Products - - - **Sybil-resistant identity registry** - - A registry of verified humans combining video verification, social vouching, and dispute resolution. - - - **Important:** Proof of Humanity uses the **Kleros V1 protocol** for dispute resolution—even the "PoH 2.0" product version. The "2.0" refers to product improvements (cross-chain support, better UX), not the underlying Kleros protocol version. - - - - Register as a verified human - - Vouch for others - - Challenge suspicious registrations - - Cross-chain profile support (Ethereum, Gnosis Chain) - +## Curate Variants + +Curate is a family of three variants: + +- **Classic Curate** (V1) - full Token-Curated Registry with complex schemas +- **Light Curate** (V1) - simplified TCR for higher volume +- **Stake Curate** (V1 infrastructure) - continuous verification with permanent deposits + +See [Curate](/products/curate) for details. --- -## Legacy & Retired Products +## V1 Product Versions -These products are documented in the [Legacy section](/legacy/overview). +The V1 versions of these products remain in production. Each product page above covers its V1 details first, then what changed in V2. -| Product | Status | Notes | -|---------|--------|-------| -| [Court V1](/legacy/court-v1) | Legacy | Superseded by Court V2 | -| [Resolver V1](/legacy/resolver-v1) | Legacy | Standalone app, now integrated into Court V2 | -| [Curate V1](/legacy/curate-v1) | Legacy | Superseded by Curate V2 | -| [Escrow V1](/legacy/escrow-v1) | Legacy | Superseded by Escrow V2 | -| [Governor V1](/legacy/governor-v1) | Legacy | Superseded by Governor V2 | -| [Moderate](/legacy/retired/moderate) | Retired | Telegram moderation bot | -| [Linguo](/legacy/retired/linguo) | Retired | Translation marketplace | -| [Tokens](/legacy/retired/tokens) | Retired | Replaced by Curate token registry | +| Product | V2 version | +|---------|-----------| +| [Court V1](/legacy/court-v1) | [Court V2](/court/overview) available | +| [Resolver V1](/legacy/resolver-v1) | Integrated into the Court V2 interface | +| [Curate V1](/legacy/curate-v1) | [Curate V2](/products/curate) available | +| [Escrow V1](/legacy/escrow-v1) | [Escrow V2](/products/escrow) available | +| [Governor V1](/legacy/governor-v1) | [Governor V2](/products/governor) available | --- -## Choosing Between V1 and V2 - -**For new integrations:** Always use V2 products when available. V2 offers: -- Lower gas costs -- Improved dispute resolution mechanics -- Better scalability -- Active development and support +## Retired Products -**For existing V1 integrations:** See the [Migration Guide](/legacy/migration-guide) for steps to upgrade. +These products are no longer actively maintained. They are listed under **Retired Products** in the sidebar. -**For V1-only products (Scout, Reality, PoH):** Continue using V1 for now. Migration guides will be provided when V2 support is available. +| Product | Description | Status | +|---------|-------------|--------| +| [Moderate](/legacy/retired/moderate) | Telegram moderation bot | Retired | +| [Linguo](/legacy/retired/linguo) | Translation marketplace | Retired | +| [Tokens](/legacy/retired/tokens) | Token submission interface | Replaced by Curate token registry | --- ## Next Steps - - Step-by-step guides in the Help Center - Integration guides for developers diff --git a/products/scout-earn.mdx b/products/scout-earn.mdx new file mode 100644 index 0000000..43cd262 --- /dev/null +++ b/products/scout-earn.mdx @@ -0,0 +1,40 @@ +--- +title: "Earn with Scout" +description: "Earn rewards by adding new entries to Scout registries and verifying submissions from other users" +--- + +# Earn with Kleros Scout + +Kleros Scout incentivizes contributors to maintain accurate registries. You can earn rewards both by adding new items to the lists and by verifying assets submitted by other users. + +--- + +## Two Ways to Earn + +### 1. Challenges and Bounties + +You can earn by identifying problematic submissions. Stake a deposit to challenge an entry that violates the registry rules; if you win the dispute through Kleros Court, you earn a portion of the submitter's deposit as a bounty. + + +Incorrect challenges result in losing your own deposit. Always verify the registry policy before challenging. + + +### 2. Reward Programs + +Kleros and partner projects run periodic campaigns to reward contributors for adding high-quality entries. Monthly incentive updates (pools, eligible chains, and parameters) are published on the blog. Monitor these channels for active campaigns: + +- The [Kleros Scout blog posts](https://blog.kleros.io/tag/kleros-scout/) - monthly incentive program updates +- The [Kleros Scout interface](https://app.klerosscout.eth.limo/) + +--- + +## Getting Started + + + + Learn how to submit and challenge entries step by step + + + Understand the registries behind Scout + + diff --git a/products/scout-partnerships.mdx b/products/scout-partnerships.mdx new file mode 100644 index 0000000..f78319d --- /dev/null +++ b/products/scout-partnerships.mdx @@ -0,0 +1,43 @@ +--- +title: "Scout Partnerships" +description: "Retrieve and integrate community-curated data from Scout registries into your platform" +--- + +# Scout Partnerships + +Just as anyone can submit, verify, and challenge entries, anyone can retrieve and integrate data from Scout registries into their platforms. Major Web3 platforms already leverage Kleros Scout data, including **Ledger** and **Etherscan** as direct integrators, and **MetaMask** through a dedicated Snap. + +--- + +## Why Integrate Scout Data + +- **Enhanced user confidence** through verified contract information +- **Improved transaction completion rates** via real-time, verifiable insights +- **Transparent, tamper-proof data** sourced on-chain from decentralized registries +- **Fraud prevention** for your users +- **Reduced legal liability** through demonstrated due diligence +- **Seamless integration** without operational disruption + +--- + +## Integration Methods + +**Direct display.** Partners like Ledger and Etherscan display Scout data directly on their platforms, such as address tags and token information. + +**MetaMask Snap.** A dedicated plugin provides real-time information about the specific contract or address during the transaction, directly in the MetaMask wallet. See [Scout MetaMask Snap](/products/scout-snap). + + + + +--- + +## Get in Touch + + + + Scout architecture and data indexing for developers + + + Contact the team on Telegram + + diff --git a/products/scout-snap.mdx b/products/scout-snap.mdx new file mode 100644 index 0000000..93395c5 --- /dev/null +++ b/products/scout-snap.mdx @@ -0,0 +1,80 @@ +--- +title: "Scout MetaMask Snap" +description: "Community-curated contract insights directly in your MetaMask wallet" +--- + + + + +# Kleros Scout MetaMask Snap + +Kleros Scout is available as a **MetaMask Snap** that enables safer contract interactions by delivering community-curated insights about the contracts you interact with on the blockchain. With each transaction, a tab displays insights about the contract being interacted with. + +The Snap provides metadata from three decentralized registries: + +- [**Address Tags Registry**](https://curate.kleros.io/tcr/100/0x66260C69d03837016d88c9877e61e08Ef74C59F2): verified project names and contract tags +- [**Contract-Domain Name Registry**](https://curate.kleros.io/tcr/100/0x957A53A994860BE4750810131d9c876b2f52d6E1): verified contract-to-domain pairings +- [**Tokens Registry**](https://curate.kleros.io/tcr/100/0xeE1502e29795Ef6C2D60F8D7120596abE3baD990): ERC-20 token information + +--- + +## Installation + + + + Install directly from the [official MetaMask Snaps Directory](https://snaps.metamask.io/snap/npm/kleros/scout-snap/), or search for `@kleros/scout-snap`. + + + Approve the Snap installation in MetaMask. Insights then appear automatically in a transaction tab whenever you interact with a contract. + + + + + + + +--- +## How to use the Snap's features? +Once you install the Kleros Scout Snap, with every txn/contract interaction, you will see a tab which provides you with insights around the same. Upon installation, If you see this, you are already using community curated contract insights for secure dapp interaction - the most important feature of the Kleros Scout Snap. + + + + +--- +## Limitations + +The Snap explicitly does **not**: + +- Endorse any contract interaction +- Use centralized whitelisting: all data is community-curated +- Guarantee 100% accuracy or accept liability for insights + +--- + +## Knowledge Base + + + + Kleros Curate is a decentralized dApp used to create open curated registries. Financial incentives and dispute resolution maintain the quality and policy compliance of every entry. + + + Community members submit items with deposits, and anyone can challenge a submission during a vetting period. Unchallenged entries are approved; challenged ones go to Kleros jurors for resolution. No single party controls the registry. + + + Centralized parties have financial incentives to whitelist tokens or manage address tags for profit, which creates vulnerabilities to phishing and manipulation. Decentralized, community-secured data removes that single point of failure. + + + Yes, community submissions are encouraged. See the [Scout Tutorial](/tutorials/scout-tutorial) for step-by-step guides to making submissions to the three security metadata registries. + + + Two things: incentives (Kleros runs regular programs rewarding active submitters, see [Earn with Scout](/products/scout-earn)) and community benefit (there is minimal risk in submitting known-safe contracts you have used, and doing so protects thousands of users). + + + +--- + +## Support + +- Telegram support group: [t.me/KlerosCurate](http://t.me/KlerosCurate) +- Email: support@kleros.io +- Typical response time: 24-48 hours diff --git a/products/scout.mdx b/products/scout.mdx index 0ff3bc0..ec5fdd4 100644 --- a/products/scout.mdx +++ b/products/scout.mdx @@ -6,7 +6,7 @@ description: "Community-curated safety information for smart contracts, tokens, # Scout Kleros Scout Interface -Scout currently uses **V1 Curate registries**. Scout V2 redesign (frontend) is complete, with underlying registry migration to V2 planned. +Scout is part of the [Curate](/products/curate) product family - it is a frontend that reads from Curate registries. It currently uses **V1 Curate registries**. The Scout V2 frontend redesign is complete, with underlying registry migration to V2 planned. **Kleros Scout** is a frontend application that displays community-curated safety and metadata information for smart contracts, tokens, and dApps. It aggregates data from multiple [Curate](/products/curate) registries to give users a unified view of address tags, contract labels, and token information. @@ -40,7 +40,7 @@ Scout itself does not manage submissions or disputes those happen in [Curate](/p **Token Registry**: Curated list of verified ERC-20 tokens with metadata (name, symbol, logo, decimals). -**CDN Registry**: Stores additional metadata like project logos and descriptions served to dApps. +**Contract Domain Names (CDN)**: Stores additional metadata like project logos and descriptions served to dApps. ### Integrations @@ -69,6 +69,14 @@ Check the [Kleros Blog](https://blog.kleros.io) for the latest monthly Scout inc --- +## Current Status + +As of the May 2026 development update, Scout reached its definitive version with **2.6M+ curated addresses** shown on the homepage. Recent work includes completing the Atlas IPFS migration (submissions and evidence now go through the Atlas SIWE flow), adding ATQ duplicate detection, and adding the JavaScript Court to the disputes view. + +Follow development on the [Kleros blog - developer updates](https://blog.kleros.io/tag/developer/). + +--- + ## What's Next? diff --git a/products/stake curate.mdx b/products/stake curate.mdx index 1bbdf65..05c93c6 100644 --- a/products/stake curate.mdx +++ b/products/stake curate.mdx @@ -5,6 +5,10 @@ description: "Continuous verification through permanent economic incentives" # Stake Curate + +Stake Curate is part of the [Curate](/products/curate) product family. It uses V1 Kleros Court on Gnosis Chain for dispute resolution. + + **Stake Curate** is a verification tool that provides continuous compliance monitoring through permanent economic incentives. Unlike traditional Curate where deposits are returned after verification, Stake Curate locks deposits indefinitely creating ongoing incentives for both submitters to stay compliant and challengers to monitor quality. diff --git a/reference/architecture/sortition-module-spec.mdx b/reference/architecture/sortition-module-spec.mdx index 49e95ca..40e7801 100644 --- a/reference/architecture/sortition-module-spec.mdx +++ b/reference/architecture/sortition-module-spec.mdx @@ -10,7 +10,7 @@ The Sortition Module handles juror selection through weighted random draws based ## Phase System 1. **Staking Phase**: Jurors update stakes. Stake changes take effect **immediately** and update the sortition sum tree in real-time. -2. **Generating Phase**: Random number requested from RNG source. Stake changes submitted during this phase are **delayed** — they will not affect the current drawing round. +2. **Generating Phase**: Random number requested from RNG source. Stake changes submitted during this phase are **delayed** - they will not affect the current drawing round. 3. **Drawing Phase**: Jurors drawn using the random number and stake weights from the end of the Staking phase. Stake changes remain delayed. diff --git a/developers/legacy/v1-deployment-addresses.mdx b/reference/contracts/deployment-addresses-v1.mdx similarity index 66% rename from developers/legacy/v1-deployment-addresses.mdx rename to reference/contracts/deployment-addresses-v1.mdx index 0b0d12a..f838f08 100644 --- a/developers/legacy/v1-deployment-addresses.mdx +++ b/reference/contracts/deployment-addresses-v1.mdx @@ -1,13 +1,19 @@ --- -title: V1 Deployment Addresses -description: Contract addresses for Kleros V1 deployments on Ethereum, Gnosis Chain, and testnets +title: Deployment Addresses V1 +description: Contract addresses for Kleros V1 deployments, organized by product --- -These are V1 (KlerosLiquid) deployment addresses. For V2 (KlerosCore on Arbitrum), see [V2 Deployment Addresses](/reference/contracts/deployment-addresses). +This page lists the V1 (KlerosLiquid) contract addresses, organized by product. For V2 (KlerosCore on Arbitrum) addresses, see the [Deployment Addresses](/reference/contracts/deployment-addresses) reference page. For cross-chain infrastructure, see [Vea Deployment Addresses](/developers/crosschain/vea-deployment-addresses). + + +Base and Arbitrum Vea routes were deployed in June 2026. The `veashi-sdk` is available on npm as `@kleros/veashi-sdk` v0.0.2. + --- -## Ethereum Mainnet (Chain ID: 1) +## Court + +### V1 (Ethereum Mainnet, Chain ID 1) | Contract | Address | | --- | --- | @@ -20,22 +26,73 @@ These are V1 (KlerosLiquid) deployment addresses. For V2 (KlerosCore on Arbitrum | Governor (poh.eth) | `0x327a29fcE0a6490E4236240Be176dAA282EcCfdF` | | Governor (ubi-voting.eth) | `0x7510c77163683448b8Dc8fe9e019d9482Be1ed2b` | | Governor (fork-dao.eth) | `0xf7dE5537eCD69a94695fcF4BCdBDeE6329b63322` | -| ArbitrableProxy | `0x99489d7bb33539f3d1a401741e56e8f02b9ae0cf` | | Transaction Batcher | `0x82458d1c812d7c930bb3229c9e159cbabd9aa8cb` | | RNGenerator | `0x90992fb4E15ce0C59aEFfb376460Fda4Ee19C879` | -| Escrow (ETH) | `0x0d67440946949FE293B45c52eFD8A9b3d51e2522` | + +### V1 (Gnosis Chain, Chain ID 100) + +| Contract | Address | +| --- | --- | +| xKlerosLiquid | `0x9C1dA9A04925bDfDedf0f6421bC7EEa8305F9002` | +| wrappedPNK (stPNK) | `0xcb3231aBA3b451343e0Fddfc45883c842f223846` | +| PolicyRegistry | `0x9d494768936b6bDaabc46733b8D53A937A6c6D7e` | +| KlerosLiquid/PNK ProxyAdmin | `0xD1a711a863aFB85D1b4E721DcB3e48C477E46475` | +| KlerosLiquid Extra Views | `0xFA71f907B48f27d22f670d9E446f8137b0769e4B` | +| SortitionSumTreeFactory | `0x7AE716d9935F41F173D944FE6557c1e117d561E9` | +| Transaction Batcher | `0x6426800F8508b15AED271337498fa5e7D0794d46` | + +### V2 (Arbitrum) + +See [Deployment Addresses](/reference/contracts/deployment-addresses) for KlerosCore, SortitionModule, and other V2 contracts. + +--- + +## Curate + +### V1 (Ethereum Mainnet) + +| Contract | Address | +| --- | --- | | ArbitrableTokenList (T2CR) | `0xebcf3bca271b26ae4b162ba560e243055af0e679` | | ArbitrableAddressList (Ethfinex) | `0x916deab80dfbc7030277047cd18b233b3ce5b4ab` | | ArbitrableAddressList (ERC20) | `0xCb4Aae35333193232421E86Cd2E9b6C91f3B125F` | -| Proof of Humanity | `0xC5E9dDebb09Cd64DfaCab4011A0D5cEDaf7c9BDb` | -| KlerosConnector for Unslashed | `0xe0e1bc8C6cd1B81993e2Fcfb80832d814886eA38` | -| UBI Pool | `0xa27bfea336bc7058ff1297eeff2732389f8b208f` | -| UBI ProxyAdmin | `0x2b59500ad441bf5accf8ff89449552b6487132e0` | -### Realitio Arbitration Proxies (Ethereum) +### V1 LGTCR Registries (Gnosis Chain) + +These registries power Kleros Scout and are consumed by block explorers for address tagging. + +| Contract | Address | +| --- | --- | +| LGTCR Tokens | `0x70533554fe5c17CAf77fE530f77eAB933B92af60` | +| LGTCR Address Tags | `0x66260C69d03837016d88c9877e61e08Ef74C59F2` | +| LGTCR Contract Domain Names | `0x957A53A994860BE4750810131d9c876b2f52d6E1` | + +### V2 (Arbitrum) + +See [Deployment Addresses](/reference/contracts/deployment-addresses). + +--- + +## Escrow + +### V1 (Ethereum Mainnet) + +| Contract | Address | +| --- | --- | +| Escrow (ETH) | `0x0d67440946949FE293B45c52eFD8A9b3d51e2522` | + +### V2 (Arbitrum) + +See [Deployment Addresses](/reference/contracts/deployment-addresses). + +--- + +## Reality / Oracle (SafeSnap) Used for Reality.eth + Kleros oracle integration and Safe Zodiac governance. +### Ethereum Mainnet + | Contract | Address | | --- | --- | | Realitio Arbitrator Proxy (original, no appeals) | `0xd47f72a2d1d0e91b0ec5e5f5d02b2dc26d00a14d` | @@ -45,49 +102,44 @@ Used for Reality.eth + Kleros oracle integration and Safe Zodiac governance. | Realitio Cross-chain xDAI Foreign Proxy (Realitio 2.1) | `0x79d0464ec27f67663dadf761432fc8dd0aea3d49` | | Realitio Cross-chain Polygon Foreign Proxy | `0x776e5853e3d61b2dfb22bcf872a43bf9a1231e52` | ---- - -## Gnosis Chain (Chain ID: 100) +### Gnosis Chain | Contract | Address | | --- | --- | -| xKlerosLiquid | `0x9C1dA9A04925bDfDedf0f6421bC7EEa8305F9002` | -| wrappedPNK (stPNK) | `0xcb3231aBA3b451343e0Fddfc45883c842f223846` | -| PolicyRegistry | `0x9d494768936b6bDaabc46733b8D53A937A6c6D7e` | -| KlerosLiquid/PNK ProxyAdmin | `0xD1a711a863aFB85D1b4E721DcB3e48C477E46475` | -| KlerosLiquid Extra Views | `0xFA71f907B48f27d22f670d9E446f8137b0769e4B` | -| SortitionSumTreeFactory | `0x7AE716d9935F41F173D944FE6557c1e117d561E9` | -| Transaction Batcher | `0x6426800F8508b15AED271337498fa5e7D0794d46` | +| Realitio Cross-Chain xDAI Home Proxy | `0x29f39de98d750eb77b5fafb31b2837f079fce222` | +| Realitio v2.1 with Appeals (for Moderate) | `0xe04f5791d671d5C4e08ab49b39807087B591ea3e` | +| Realitio Cross-chain xDAI Home Proxy (2.1) - Omen | `0xe40DD83a262da3f56976038F1554Fe541Fa75ecd` | + +--- -### Realitio Cross-Chain Proxies (Gnosis Chain) +## Proof of Humanity + +### V1 (Ethereum Mainnet) | Contract | Address | | --- | --- | -| Realitio Cross-Chain xDAI Home Proxy | `0x29f39de98d750eb77b5fafb31b2837f079fce222` | -| Realitio v2.1 with Appeals (for Moderate) | `0xe04f5791d671d5C4e08ab49b39807087B591ea3e` | -| Realitio Cross-chain xDAI Home Proxy (2.1) — Omen | `0xe40DD83a262da3f56976038F1554Fe541Fa75ecd` | +| Proof of Humanity | `0xC5E9dDebb09Cd64DfaCab4011A0D5cEDaf7c9BDb` | +| UBI Pool | `0xa27bfea336bc7058ff1297eeff2732389f8b208f` | +| UBI ProxyAdmin | `0x2b59500ad441bf5accf8ff89449552b6487132e0` | -### LGTCR Registries (Gnosis Chain) +--- -These registries power Kleros Scout and are consumed by block explorers (Etherscan, Scout) for address tagging. +## Arbitrable Contracts and Integrations | Contract | Address | | --- | --- | -| LGTCR Tokens | `0x70533554fe5c17CAf77fE530f77eAB933B92af60` | -| LGTCR Address Tags | `0x66260C69d03837016d88c9877e61e08Ef74C59F2` | -| LGTCR Contract Domain Names | `0x957A53A994860BE4750810131d9c876b2f52d6E1` | +| ArbitrableProxy (Ethereum) | `0x99489d7bb33539f3d1a401741e56e8f02b9ae0cf` | +| KlerosConnector for Unslashed (Ethereum) | `0xe0e1bc8C6cd1B81993e2Fcfb80832d814886eA38` | --- ## V1 Subcourt IDs (Ethereum Mainnet) -The General Court ID is `0` on V1 (different from V2 where General Court is ID `1`). +The General Court ID is `0` on V1 (different from V2, where the General Court is ID `1`). Check current subcourt IDs and parameters on [KlerosBoard](https://klerosboard.com/). ---- - -## Generating extraData +### Generating extraData To specify a subcourt and juror count in V1: @@ -99,9 +151,3 @@ const generateArbitratorExtraData = (subcourtID, noOfVotes) => generateArbitratorExtraData(0, 3); // "0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000003" ``` - ---- - -## Further Reading - -- [V2 Deployment Addresses](/reference/contracts/deployment-addresses) — KlerosCore, SortitionModule, and V2 contracts on Arbitrum diff --git a/reference/contracts/deployment-addresses.mdx b/reference/contracts/deployment-addresses.mdx index 2d5b624..60f541f 100644 --- a/reference/contracts/deployment-addresses.mdx +++ b/reference/contracts/deployment-addresses.mdx @@ -5,7 +5,7 @@ description: Smart contract addresses for Kleros V2 on all supported networks # Deployment Addresses -Always verify addresses against the [official kleros-v2 repository](https://github.com/kleros/kleros-v2/tree/master/contracts/deployments) before use. Addresses change with protocol upgrades. All core contracts use the UUPS proxy pattern — proxy addresses remain stable across upgrades. +Always verify addresses against the [official kleros-v2 repository](https://github.com/kleros/kleros-v2/tree/master/contracts/deployments) before use. Addresses change with protocol upgrades. All core contracts use the UUPS proxy pattern - proxy addresses remain stable across upgrades. ## Arbitrum One (Chain ID: 42161) @@ -48,7 +48,7 @@ Always verify addresses against the [official kleros-v2 repository](https://gith | Contract | Address | | --- | --- | -| Pinakion (PNK) — bridged | `0x330bD769382cFc6d50175903434CCC8D206DCAE5` | +| Pinakion (PNK) - bridged | `0x330bD769382cFc6d50175903434CCC8D206DCAE5` | ### Gated Court Eligibility (SBT) Contracts @@ -84,7 +84,7 @@ These soulbound token contracts are used as eligibility gates for specific court | PNK Token (L1) | `0x93ED3FBe21207Ec2E8f2d3c3de6e058Cb73Bc04d` | | PinakionV2 (ERC-20 upgraded) | See [Sepolia testnet](#ethereum-sepolia-chain-id-11155111--testnet) for the V2 token contract | -For full V1 contract addresses on Ethereum (KlerosLiquid Court, PolicyRegistry, ArbitrableProxy, Realitio proxies, T2CR, Proof of Humanity, Governors, etc.), see [V1 Deployment Addresses](/developers/legacy/v1-deployment-addresses). +For full V1 contract addresses on Ethereum (KlerosLiquid Court, PolicyRegistry, ArbitrableProxy, Realitio proxies, T2CR, Proof of Humanity, Governors, etc.), see [V1 Deployment Addresses](/reference/contracts/deployment-addresses-v1). --- @@ -94,11 +94,11 @@ For full V1 contract addresses on Ethereum (KlerosLiquid Court, PolicyRegistry, | --- | --- | | Realitio Cross-Chain Polygon Home Proxy | `0x5AFa42b30955f137e10f89dfb5EF1542a186F90e` | -Paired with the Realitio Cross-chain Polygon Foreign Proxy on Ethereum (see [V1 Deployment Addresses](/developers/legacy/v1-deployment-addresses)). Used by Polkamarkets and other Polygon prediction markets. +Paired with the Realitio Cross-chain Polygon Foreign Proxy on Ethereum (see [V1 Deployment Addresses](/reference/contracts/deployment-addresses-v1)). Used by Polkamarkets and other Polygon prediction markets. --- -## Arbitrum Sepolia (Chain ID: 421614) — Official Testnet +## Arbitrum Sepolia (Chain ID: 421614) - Official Testnet ### Core Contracts @@ -149,7 +149,7 @@ Paired with the Realitio Cross-chain Polygon Foreign Proxy on Ethereum (see [V1 --- -## Ethereum Sepolia (Chain ID: 11155111) — Testnet +## Ethereum Sepolia (Chain ID: 11155111) - Testnet | Contract | Address | | --- | --- | @@ -157,7 +157,7 @@ Paired with the Realitio Cross-chain Polygon Foreign Proxy on Ethereum (see [V1 --- -## Chiado / Gnosis Testnet (Chain ID: 10200) — Official Testnet +## Chiado / Gnosis Testnet (Chain ID: 10200) - Official Testnet | Contract | Address | | --- | --- | @@ -178,6 +178,6 @@ Paired with the Realitio Cross-chain Polygon Foreign Proxy on Ethereum (see [V1 ## Notes - **Proxy vs Implementation**: All core contracts use the UUPS proxy pattern. Always interact with the **proxy** address. Implementation addresses are only needed for direct ABI inspection. -- **Testnet parameters**: Testnet court parameters (minStake, feeForJuror, timesPerPeriod) differ significantly from mainnet — see [Court Hierarchy](https://github.com/kleros/docs/blob/main/court/court-hierarchy) for details. +- **Testnet parameters**: Testnet court parameters (minStake, feeForJuror, timesPerPeriod) differ significantly from mainnet - see [Court Hierarchy](/court/court-hierarchy) for details. - **Dispute Kits**: The General Court on Arbitrum One supports all four kits (Classic, Shutter, Gated, GatedShutter). The active kit for a dispute is determined by the `extraData` passed at dispute creation. - **Canonical source**: Always cross-reference with [kleros-v2/contracts/deployments](https://github.com/kleros/kleros-v2/tree/master/contracts/deployments) for the most up-to-date addresses. diff --git a/reference/contracts/gateways.mdx b/reference/contracts/gateways.mdx index 3b6dff9..c6bb94b 100644 --- a/reference/contracts/gateways.mdx +++ b/reference/contracts/gateways.mdx @@ -42,7 +42,7 @@ Pays the relayer's fee after a ruling has been delivered. ### Governance Methods (Governor Only) #### `changeCourtJurorFee(uint96 _courtID, uint256 _feeForJuror)` -Updates the per-juror fee stored in the ForeignGateway for a specific court. This must be called to keep gateway fees in sync when KlerosCore court fees change on Arbitrum. **Fee drift is a known operational risk** — if this is not updated after a governance change to `feeForJuror` on Arbitrum, arbitration cost on the foreign chain will be incorrect. +Updates the per-juror fee stored in the ForeignGateway for a specific court. This must be called to keep gateway fees in sync when KlerosCore court fees change on Arbitrum. **Fee drift is a known operational risk** - if this is not updated after a governance change to `feeForJuror` on Arbitrum, arbitration cost on the foreign chain will be incorrect. #### `changeVea(address _veaOutbox, uint256 _gracePeriod)` Updates the Vea outbox address. Supports a grace period for deprecated bridge transitions. diff --git a/reference/contracts/kleros-core.mdx b/reference/contracts/kleros-core.mdx index 4686325..3569be8 100644 --- a/reference/contracts/kleros-core.mdx +++ b/reference/contracts/kleros-core.mdx @@ -33,10 +33,10 @@ Returns the current ruling and its status: |--------|------|-------------| | `ruling` | `uint256` | Current winning option. `0` means "Refuse to Arbitrate" or no majority yet. | | `tied` | `bool` | `true` when two or more options have equal votes. A tied dispute will default to ruling `0` if the appeal period expires without resolution. Always design your contracts to handle ruling `0` explicitly. | -| `overridden` | `bool` | `true` when the parent court changed the ruling on appeal. Useful for monitoring or analytics — the final `rule()` callback on your arbitrable contract already reflects the overridden value. | +| `overridden` | `bool` | `true` when the parent court changed the ruling on appeal. Useful for monitoring or analytics - the final `rule()` callback on your arbitrable contract already reflects the overridden value. | ### `setStake(uint96 _courtID, uint256 _newStake)` -Juror staking — requires prior PNK approval. In the Neo deployment, staking also requires the juror to hold the `KlerosV2NeoEarlyUser` NFT. +Juror staking - requires prior PNK approval. In the Neo deployment, staking also requires the juror to hold the `KlerosV2NeoEarlyUser` NFT. ## Initialization Parameters @@ -45,12 +45,12 @@ The contract is initialized with the following key parameters (relevant for inte | Parameter | Description | |---|---| | `_governor` | Address with full governance rights (pause, upgrade, parameter changes) | -| `_guardian` | Emergency address — can pause only | +| `_guardian` | Emergency address - can pause only | | `_pinakion` | PNK token contract address | | `_jurorProsecutionModule` | Address authorized to trigger juror penalty execution outside normal dispute flow | | `_disputeKit` | Initial dispute kit registered on the root court | | `_sortitionModuleAddress` | SortitionModule contract address | -| `_wNative` | Wrapped native token address (WETH on Arbitrum) — used for ERC-20 fee conversions | +| `_wNative` | Wrapped native token address (WETH on Arbitrum) - used for ERC-20 fee conversions | ## Governance Roles @@ -72,7 +72,7 @@ arbitrator.createDispute(choices, extraData, feeToken, cost); ``` -ERC-20 fee support is only available when interacting directly with KlerosCore on Arbitrum. The `ForeignGateway` (used for cross-chain arbitration from Ethereum/Gnosis) does **not** support ERC-20 fees — only ETH is accepted through the gateway. +ERC-20 fee support is only available when interacting directly with KlerosCore on Arbitrum. The `ForeignGateway` (used for cross-chain arbitration from Ethereum/Gnosis) does **not** support ERC-20 fees - only ETH is accepted through the gateway. ## Dispute Kits diff --git a/reference/contracts/kleros-governor.mdx b/reference/contracts/kleros-governor.mdx index a82b142..e29c940 100644 --- a/reference/contracts/kleros-governor.mdx +++ b/reference/contracts/kleros-governor.mdx @@ -41,4 +41,4 @@ Trigger the approval process. If one list: approve it. If multiple: create a dis | `ListSubmitted` | Transaction list submitted | | `Ruling` | Dispute resolved, winning list determined | -[View Source](https://github.com/kleros/kleros-v2/blob/dev/contracts/src/arbitration/KlerosGovernor.sol) \ No newline at end of file +[View Source](https://github.com/kleros/governor-v2) \ No newline at end of file diff --git a/reference/contracts/moderated-evidence-module.mdx b/reference/contracts/moderated-evidence-module.mdx index b0ae600..0095b13 100644 --- a/reference/contracts/moderated-evidence-module.mdx +++ b/reference/contracts/moderated-evidence-module.mdx @@ -18,4 +18,4 @@ Provides spam protection for evidence submission through a bonded challenge mech Particularly useful for disputes on Arbitrum where gas costs are low enough that malicious actors could flood a dispute with irrelevant evidence to confuse jurors. -[View Source](https://github.com/kleros/kleros-v2/blob/dev/contracts/src/evidence/ModeratedEvidenceModule.sol) \ No newline at end of file +[View Source](https://github.com/kleros/kleros-v2/blob/dev/contracts/src/arbitration/evidence/ModeratedEvidenceModule.sol) \ No newline at end of file diff --git a/reference/contracts/sortition-module.mdx b/reference/contracts/sortition-module.mdx index 07821a6..4229949 100644 --- a/reference/contracts/sortition-module.mdx +++ b/reference/contracts/sortition-module.mdx @@ -34,4 +34,4 @@ Updates a juror's stake in the sum tree. Uses a sortition sum tree where each leaf represents a juror's stake in a court. Drawing probability is proportional to stake: a juror with 10% of total staked PNK in a court has a 10% chance of being drawn for each juror slot. -[View Source](https://github.com/kleros/kleros-v2/blob/dev/contracts/src/arbitration/SortitionModuleBase.sol) \ No newline at end of file +[View Source](https://github.com/kleros/kleros-v2/blob/dev/contracts/src/arbitration/SortitionModule.sol) \ No newline at end of file diff --git a/reference/data-formats/dispute-templates.mdx b/reference/data-formats/dispute-templates.mdx index 70a837e..8bb8fad 100644 --- a/reference/data-formats/dispute-templates.mdx +++ b/reference/data-formats/dispute-templates.mdx @@ -1,6 +1,6 @@ --- title: "Dispute Templates" -description: "Full specification for dispute templates and data mappings — what jurors see and how template variables are populated from on-chain data" +description: "Full specification for dispute templates and data mappings - what jurors see and how template variables are populated from on-chain data" --- Dispute templates define the question, answer options, and metadata presented to jurors. They are registered on-chain via the `DisputeTemplateRegistry` contract and can contain dynamic placeholders populated at dispute-creation time via the data mappings system. @@ -85,18 +85,18 @@ Answer IDs are hex-encoded ruling values: | ID | Meaning | |---|---| -| `"0x00"` | **Always reserved for "Refuse to Arbitrate / Invalid"** — jurors use this when the dispute is malformed or unanswerable | +| `"0x00"` | **Always reserved for "Refuse to Arbitrate / Invalid"** - jurors use this when the dispute is malformed or unanswerable | | `"0x01"` | First substantive answer | | `"0x02"` | Second substantive answer | | `"0x03"`, ... | Additional answers | -The `0x00` ruling is handled specially by KlerosCore — if a majority selects it, no party is considered to have won. +The `0x00` ruling is handled specially by KlerosCore - if a majority selects it, no party is considered to have won. --- ## Pre-dispute Evidence (`extraEvidences`) -The `extraEvidences` field lets arbitrable contracts surface evidence that was submitted **before the dispute was created** — such as a requester's registration submission or a challenger's objection — directly in the Kleros Court UI. Without this field, jurors would need to navigate to the arbitrable app separately to find that evidence. +The `extraEvidences` field lets arbitrable contracts surface evidence that was submitted **before the dispute was created** - such as a requester's registration submission or a challenger's objection - directly in the Kleros Court UI. Without this field, jurors would need to navigate to the arbitrable app separately to find that evidence. ### Schema @@ -154,13 +154,13 @@ The `requesterEvidence` and `challengerEvidence` variables are populated by a `f ## Data Mappings -The `templateDataMappings` parameter is a **JSON array** that defines how template `{{variable}}` placeholders are populated from external data sources at dispute creation time. The system resolves mappings sequentially — later mappings can reference values populated by earlier ones. +The `templateDataMappings` parameter is a **JSON array** that defines how template `{{variable}}` placeholders are populated from external data sources at dispute creation time. The system resolves mappings sequentially - later mappings can reference values populated by earlier ones. Each mapping object has a `type` field that determines its structure, plus `seek` (list of data paths to extract) and `populate` (list of template variable names to fill, in the same order as `seek`). ### Mapping Types -#### 1. `graphql` — Subgraph Query +#### 1. `graphql` - Subgraph Query Fetches data from a TheGraph subgraph endpoint. @@ -197,7 +197,7 @@ Fetches data from a TheGraph subgraph endpoint. - `seek`: Dot-notation paths into the GraphQL response data. - `populate`: Template variable names to set, positionally matching `seek`. -#### 2. `fetch/ipfs/json` — IPFS JSON Fetch +#### 2. `fetch/ipfs/json` - IPFS JSON Fetch Retrieves a JSON file from IPFS and extracts fields. @@ -214,7 +214,7 @@ Retrieves a JSON file from IPFS and extracts fields. - `seek`: JSON field paths within the fetched document. - `populate`: Template variable names to fill. -#### 3. `abi/call` — Smart Contract Call +#### 3. `abi/call` - Smart Contract Call Calls a view function on a contract and extracts return values. @@ -237,7 +237,7 @@ Calls a view function on a contract and extracts return values. - `seek`: Indices (as strings) into the returned tuple, or named return values. - `populate`: Template variable names to fill. -#### 4. `abi/event` — On-Chain Event Data +#### 4. `abi/event` - On-Chain Event Data Extracts data from a previously emitted on-chain event. @@ -258,7 +258,7 @@ Extracts data from a previously emitted on-chain event. - `seek`: Event parameter names to extract. - `populate`: Template variable names to fill. -#### 5. `json` — Hardcoded Values +#### 5. `json` - Hardcoded Values Injects hardcoded values directly into template variables. @@ -375,7 +375,7 @@ With mappings: ] ``` -### Curate V2 — Registration +### Curate V2 - Registration Registration and removal disputes use **separate templates** with inverted answer logic. For registration, accepting means the item should be added; for removal, accepting means the item should be removed. @@ -403,7 +403,7 @@ Registration and removal disputes use **separate templates** with inverted answe } ``` -**Removal template** uses inverted semantics — `0x01` means "yes, remove": +**Removal template** uses inverted semantics - `0x01` means "yes, remove": ```json { @@ -474,7 +474,7 @@ If the template is large, store it on IPFS and pass its URI as `_templateUri` in ### Updating Templates -Use `changeDisputeTemplate()` (available on arbitrable contracts like Escrow) to update the template after deployment — new disputes will use the updated template while old ones retain the original `templateId` snapshot. +Use `changeDisputeTemplate()` (available on arbitrable contracts like Escrow) to update the template after deployment - new disputes will use the updated template while old ones retain the original `templateId` snapshot. ```solidity escrow.changeDisputeTemplate(newTemplateJSON, newMappingsJSON); diff --git a/reference/data-formats/policy-format.mdx b/reference/data-formats/policy-format.mdx index e2cd649..459ceb6 100644 --- a/reference/data-formats/policy-format.mdx +++ b/reference/data-formats/policy-format.mdx @@ -1,12 +1,12 @@ --- title: "Policy Format" -description: "Court policy and dispute policy specification — rules and guidelines for jurors" +description: "Court policy and dispute policy specification - rules and guidelines for jurors" --- Kleros uses two kinds of policy documents: -1. **Court policies** — define the general rules for a specific Kleros court. Registered in the `PolicyRegistry` contract and displayed to jurors in every dispute in that court. -2. **Dispute policies** — define the specific rules for a particular arbitrable app. Referenced via `policyURI` in the dispute template. Jurors are expected to read both. +1. **Court policies** - define the general rules for a specific Kleros court. Registered in the `PolicyRegistry` contract and displayed to jurors in every dispute in that court. +2. **Dispute policies** - define the specific rules for a particular arbitrable app. Referenced via `policyURI` in the dispute template. Jurors are expected to read both. Both are JSON files stored on IPFS. @@ -17,7 +17,7 @@ Both are JSON files stored on IPFS. ```json { "name": "General Court Policy", - "description": "Rules for the General Court — handles disputes not covered by specialized courts.", + "description": "Rules for the General Court - handles disputes not covered by specialized courts.", "summary": "The General Court is the court of last resort for disputes without a specialized subcourt. Jurors should apply reasonable judgment to the facts presented.", "requiredFields": [ { @@ -64,9 +64,9 @@ A well-written dispute policy should include: "version": "1.0", "description": "Rules for resolving escrow payment disputes on Escrow V2.", "rulingCriteria": { - "0": "Refuse to Arbitrate — The dispute is invalid, the question is unanswerable, or critical evidence is missing.", - "1": "Refund the Buyer — The seller failed to deliver the goods or services as described.", - "2": "Pay the Seller — The seller fulfilled their obligations as described in the transaction terms." + "0": "Refuse to Arbitrate - The dispute is invalid, the question is unanswerable, or critical evidence is missing.", + "1": "Refund the Buyer - The seller failed to deliver the goods or services as described.", + "2": "Pay the Seller - The seller fulfilled their obligations as described in the transaction terms." }, "edgeCases": [ "If delivery is partial, consider whether it materially meets the contract terms.", @@ -91,7 +91,7 @@ Dispute templates may include a `specification` field referencing the KIP (Klero } ``` -This is informational — it helps auditors and integrators understand which standard governs the template's structure. Reality V2 uses this to link to the Reality.eth arbitration spec. +This is informational - it helps auditors and integrators understand which standard governs the template's structure. Reality V2 uses this to link to the Reality.eth arbitration spec. --- @@ -113,7 +113,7 @@ To read the current policy for a court: ## Tips for Writing Good Policies -- Write for a general audience — jurors are not legal experts or domain specialists +- Write for a general audience - jurors are not legal experts or domain specialists - Use concrete examples for each ruling option - Specify exactly what evidence is sufficient to shift the ruling - Avoid ambiguous language like "reasonable" without defining what it means in your context diff --git a/reference/sdk/kleros-sdk.mdx b/reference/sdk/kleros-sdk.mdx index b30aca0..e1b8860 100644 --- a/reference/sdk/kleros-sdk.mdx +++ b/reference/sdk/kleros-sdk.mdx @@ -27,7 +27,7 @@ The SDK lives at [github.com/kleros/kleros-v2](https://github.com/kleros/kleros- ### Dispute Template Population -The SDK resolves `templateDataMappings` to populate `{{variable}}` placeholders in dispute templates. This is the primary use case — run mappings client-side to display rich dispute context. +The SDK resolves `templateDataMappings` to populate `{{variable}}` placeholders in dispute templates. This is the primary use case - run mappings client-side to display rich dispute context. ```typescript import { populateTemplate } from "@kleros/kleros-sdk"; @@ -116,4 +116,4 @@ await setStake(walletClient, { ## Source -[GitHub — kleros/kleros-v2/kleros-sdk](https://github.com/kleros/kleros-v2/tree/dev/kleros-sdk) \ No newline at end of file +[GitHub - kleros/kleros-v2/kleros-sdk](https://github.com/kleros/kleros-v2/tree/dev/kleros-sdk) \ No newline at end of file diff --git a/research/papers.mdx b/research/papers.mdx index 76973db..8726e63 100644 --- a/research/papers.mdx +++ b/research/papers.mdx @@ -9,11 +9,11 @@ description: "Published academic work by and about Kleros" **Kleros White Paper** (2018) The original protocol design paper describing the core Kleros mechanism, juror selection, and incentive system. -[Read the White Paper →](https://kleros.io/whitepaper.pdf) +[Read the White Paper →](https://kleros.io/static/whitepaper.pdf) **Kleros Yellow Paper** (2021) The comprehensive formal specification of Kleros V2, covering court trees, modular dispute kits, cross-chain architecture, voting systems, incentive mechanisms, and attack resistance analysis. -[Read the Yellow Paper →](https://kleros.io/yellowpaper.pdf) +[Read the Yellow Paper →](https://kleros.io/static/yellowpaper.pdf) --- @@ -43,7 +43,7 @@ The comprehensive formal specification of Kleros V2, covering court trees, modul **"Dispute Revolution: The Kleros Handbook of Decentralized Justice"** (2019) A compilation of research in computer science, cryptoeconomics, law, and business, covering the theory and practice of decentralized dispute resolution. -[Download →](https://kleros.io/book) +[Download →](https://drive.google.com/file/d/13sYn15awssVulSAiA2LOOdpQFI4_6ZIv/view) --- diff --git a/tutorials/curate-tutorial.mdx b/tutorials/curate-tutorial.mdx new file mode 100644 index 0000000..54f398a --- /dev/null +++ b/tutorials/curate-tutorial.mdx @@ -0,0 +1,75 @@ +--- +title: "Curate Tutorial" +description: "Create a curated list, register it, and submit or challenge items" +--- + +# Curate Tutorial + +This tutorial walks through creating a decentralized list on Kleros Curate, registering it in the List of Lists, and submitting or challenging items. + +Curate lists are deployed as smart contracts. The platform uses a hierarchical structure where top-level lists can contain sublists. + +--- + +## Create a List + +Access the list creation page via the **Create a List** header button. + + + + - **Title**: the name of your list (for example, "Hip Hop Legends") + - **Description**: a brief overview of the list's purpose + - **Acceptance criteria**: a critical piece of information specifying what submissions are accepted or rejected + - **Item name**: the label for individual submissions (for example, "Hip Hop Legend") + - **Deposit settings**: a slider-based configuration balancing submission cost against quality control + - **Court selection**: choose the arbitration court based on the list's complexity and value + + + Power users can set each deposit individually: + + - Submission deposit + - Removal deposit + - Challenge submission deposit + - Challenge removal deposit + + + Add custom fields for submissions (text, images, and other types). Enable **Index** on a field to make it searchable. + + + An optional tiered system allows submissions to earn additional badges based on specific criteria. + + + Pay the contract deployment fees via your wallet to launch the list. + + + + +--- + +## Register in the List of Lists + +Submit your deployed list to the main Registry by clicking **Submit List** and paying a confirmation deposit. This makes it visible on the Curate homepage. + +--- + +## Submit & Challenge Items + +- **Submissions**: users deposit funds to add items to a list. The deposit is returned if the item is accepted. +- **Challenges**: anyone can dispute a submission by describing how it violates the list's policy. Kleros jurors arbitrate the dispute, and the winner receives the loser's deposit (minus arbitration fees). + + +Write your acceptance criteria carefully before deploying. Jurors rule on challenges based on your list's policy, so ambiguous criteria lead to unpredictable outcomes. + + +--- + +## What's Next? + + + + How Curate works and its variants + + + Curate smart contracts and integrator standards + + diff --git a/tutorials/escrow-tutorial.mdx b/tutorials/escrow-tutorial.mdx new file mode 100644 index 0000000..3074846 --- /dev/null +++ b/tutorials/escrow-tutorial.mdx @@ -0,0 +1,204 @@ +--- +title: "Escrow Tutorial" +description: "Step-by-step guide to creating, executing, and disputing an escrow transaction" +--- + +# Escrow Tutorial + +This tutorial walks through a complete escrow transaction on [Kleros Escrow V1](https://escrow-v1.kleros.builders/): creating a payment, executing or settling it, and raising a dispute if things go wrong. + + +This tutorial covers the Escrow V1 application on Ethereum Mainnet. For the differences between Escrow V1 and V2, see the [Escrow product page](/products/escrow). + + +--- + +## Step 1: Initiate a Payment + + + + Visit [escrow-v1.kleros.builders](https://escrow-v1.kleros.builders/) and connect your wallet (Rabby, MetaMask, or WalletConnect). Make sure you have ETH for transaction fees and the payment amount. From the homepage you can create, search, or review transactions. + + + + + + Click the **Create Transaction** button in the top right. You deposit funds into escrow, where they remain secure until one of the following happens: + + - You manually release them + - The receiver refunds them + - A dispute is resolved by Kleros Court + - The expiry date passes + + + + + + Two transaction types are available: + + - **Cryptocurrency Transaction**: trade or exchange crypto assets, useful for cross-blockchain exchanges (for example, ETH on Ethereum for SOL on Solana). Disputes go to the Blockchain Non-Technical Court. + - **General Service Transaction**: pay for services with custom terms and document uploads. Disputes go to the General Court. + + + + + + + +--- + +## Step 2: Submit the Payment + + + + - **Title**: describe the transaction (for example, "Marketing Mission with John D.") + - **Receiver's Ethereum address**: the wallet receiving the funds + - **Amount and unit**: ETH or an ERC-20 token + + The default token options are ETH and PNK. To use another token, enter its contract address in the "Add custom token" field. + + + Non-standard ERC-20 tokens such as USDT, BNB, and OMG are not supported in Escrow V1. + + + + + + + + Provide a detailed description of the service or product. This description is crucial for dispute resolution. + + The timeline works as follows: + + 1. **Service period**: from creation to the delivery deadline. Either party can release, refund, or dispute at any time. + 2. **Buffer period**: a fixed 7 days after the deadline, serving as a review and dispute window. + 3. **Escrow expiry**: 7 days after the deadline, either party can execute the transaction. + + For example: a transaction created on December 17 with a delivery deadline of January 16 expires on January 23. + + + + + + + Optionally upload a PDF agreement, or include the terms in the description. Jurors rely on this document if a dispute arises, so specify clearly: + + - The parties involved + - The nature of the service or good + - Specific deliverables + - Acceptance criteria + - Engagement conditions + + + Review everything in the Preview step: receiver address, amount, and deadline. Click **Create Escrow**, confirm the blockchain transaction (deposit plus gas fees), and you are redirected to the payment page. + + + + + + + +--- + +## Step 3: Execute the Payment + +After creation, both parties see a transaction summary with their available actions. + + + + + +### As the payment sender + +- **Make payment**: release funds to the receiver, in full or partially. Pay the full amount when the service or product was delivered as agreed. Pay a partial amount to settle a disagreement without a dispute; the remainder stays in escrow and can still be disputed. +- **Raise dispute**: click if you are unsatisfied with the delivery. You are shown the arbitration cost (for example, 0.03 ETH) and deposit the fee to initiate. The fee is refunded if you win. + + + + +### As the payment receiver + +- **Reimburse**: return funds to the sender, in full or partially. Reimburse the full amount if you cannot complete the delivery. Reimburse partially to keep payment for work completed; the remainder goes to you and the transaction closes. +- **Raise dispute**: click if the sender refuses payment despite you completing the terms. The arbitration cost and process are the same for both parties. + + + + + +### Settlements through partial payments + +There is no separate settlement mode. When both parties agree to a compromise, one of them makes a partial payment or reimbursement: + +- **Sender initiates**: the sender pays a partial amount (for example, 0.7 of 1 ETH). It goes immediately to the receiver; 0.3 ETH remains in escrow. The receiver can accept, dispute the remainder, or reimburse some or all of it. +- **Receiver initiates**: the receiver refunds a partial amount (for example, 0.4 of 1 ETH). It returns to the sender; 0.6 ETH remains. + + +A partial payment or reimbursement transfers immediately and permanently. That amount cannot be recovered, even if a dispute arises later over the remainder. + + +Best practices for settlements: + +- Document the settlement agreement in writing +- Get the other party's confirmation of the settlement terms +- Save all communication as potential dispute evidence + +--- + +## Step 4: Raise a Dispute + + + + Either party clicks **Raise Dispute** and pays the arbitration fee (refunded if you win). The other party then has a limited time to pay their side of the fees; the interface shows the remaining time. + + If the other party fails to pay their side of the fees, the first paying party automatically wins. + + + + + + + + + + + + + + + Submit evidence through the [Kleros Dispute Resolver](https://resolve.kleros.io/), not through the Escrow frontend: + + 1. Go to resolve.kleros.io and connect your wallet + 2. Find and open your dispute + 3. Add your evidence and arguments + + Evidence tips: + + - Reference the original agreement document and its specific terms + - Add communication logs, proof of delivery, photos, and screenshots + - Use PDFs with EXIF data stripped if you want to stay anonymous + - Be clear and concise + + + Track progress on the Escrow payment page (current status) and on resolve.kleros.io (detailed case information and voting status). + + - **First ruling**: unsatisfied parties can appeal. Appeals bring more jurors and additional evidence rounds, and appeal fees must be paid within the appeal period. + - **Final ruling**: after no appeals remain, the winning party withdraws the funds and receives their arbitration fees back. + + + + + + + +--- + +## What's Next? + + + + Learn how Kleros Escrow works, V1 and V2 + + + Escrow smart contracts and technical documentation + + diff --git a/tutorials/juror-tutorial-v1.mdx b/tutorials/juror-tutorial-v1.mdx new file mode 100644 index 0000000..533cc81 --- /dev/null +++ b/tutorials/juror-tutorial-v1.mdx @@ -0,0 +1,86 @@ +--- +title: "Juror Tutorial (V1)" +description: "How to use Kleros Court as a juror: get PNK, stake in a court, and vote on cases" +--- + +# Juror Tutorial (V1) + +This tutorial explains how to become a juror on **Kleros Court V1** at [court.kleros.io](https://court.kleros.io/) (Ethereum Mainnet and Gnosis Chain). For the next-generation court on Arbitrum, see the [V2 Juror Tutorial](/tutorials/juror-tutorial-v2). No signup or personal information is required: you only need the right tools and skills. + +--- + +## Tooling + +You need: + +- A Web3 wallet such as MetaMask +- PNK tokens +- ETH for gas fees + +The fastest way to obtain PNK is directly from the [Buy PNK page of the Court](https://court.kleros.io/tokens) or from one of the exchanges listed there. + + + + +--- + +## Staking and Cases + +Match your expertise to the appropriate court: + +- **Onboarding Court**: for beginners +- **Blockchain Non-Technical Court**: for basic blockchain knowledge +- **English Court**: for language expertise + + + + Navigate to [court.kleros.io](https://court.kleros.io/). + + + Click **Courts**, then **Join a Court**. Browse the court tree to view each court's description and requirements. + + + + + + Select a court and click the blue **Stake** button. Enter the amount of PNK you want to stake. The minimum varies by court: for example, 1,000 PNK for the Onboarding Court and 1,600 PNK for the Curation Court. Confirm the transaction and pay the gas fees. + + + + + + Higher stakes increase your chances of being drawn as a juror. Once drawn, your cases appear in **My Cases**, where you review the evidence and vote. + + + + + + + + Staking and Cases + + + +Once you stake in a court, you are automatically staked in all courts above it up to the General Court, for appeal purposes. + + + +Review the court policies carefully before voting. Jurors who vote incoherently with the final ruling lose a portion of their staked PNK. + + + + + + +--- + +## What's Next? + + + + The full dispute lifecycle, from creation to execution + + + Understand court structure and specialization + + diff --git a/tutorials/juror-tutorial-v2.mdx b/tutorials/juror-tutorial-v2.mdx new file mode 100644 index 0000000..26adb1f --- /dev/null +++ b/tutorials/juror-tutorial-v2.mdx @@ -0,0 +1,250 @@ +--- +title: "Juror Tutorial (V2)" +description: "Become a juror on Kleros Court V2: set up on Arbitrum, get PNK, stake, handle your first dispute, and claim rewards" +--- + +# Juror Tutorial (V2) + +This tutorial walks you through participating as a juror on **Kleros Court V2** at [v2.kleros.builders](https://v2.kleros.builders/), the next-generation court on Arbitrum. No signup or personal information is required. + + +New to Web3 entirely? The [Complete Beginner's Guide to Kleros Court V2 on Notion](https://kleros.notion.site/Complete-Beginner-s-Guide-to-Kleros-Court-V2-20e9a9db4f08803da1b2c372ed2f2c6e) covers everything from wallet setup and seed-phrase security to your first case, with screenshots for every step. + + +For the V1 court on Ethereum and Gnosis Chain, see the [V1 Juror Tutorial](/tutorials/juror-tutorial-v1). + +--- + +## What You Need + +- A Web3 wallet: **Rabby** (recommended, auto-detects networks) or MetaMask +- **PNK tokens on Arbitrum** +- **ETH on Arbitrum** for transaction fees (keep roughly 20-30% of your budget as an ETH buffer) + + +### Set up Arbitrum One + +Kleros V2 runs on Arbitrum One (Chain ID 42161), a Layer 2 that keeps Ethereum's security with much lower fees. Rabby detects and switches networks automatically. In MetaMask, add the network manually (RPC `https://arb1.arbitrum.io/rpc`, currency ETH, explorer [arbiscan.io](https://arbiscan.io/)) or use [chainlist.org](https://chainlist.org/). + +### Get PNK on Arbitrum + +- **Directly in the Court interface**: use the "Get PNK" option +- **DEXs**: swap ETH for PNK on [Uniswap](https://app.uniswap.org/) while connected to Arbitrum +- **Centralized exchanges**: see the listings on CoinGecko, then bridge to Arbitrum +- If you hold PNK on Ethereum, bridge it via [bridge.arbitrum.io](https://bridge.arbitrum.io/) + +A starting amount of 5,000-10,000 PNK is a reasonable baseline; each court sets its own minimum stake (the General Court minimum is around 2,300 PNK). + +--- + +## Understanding Courts and Parameters + +Courts form a hierarchy: the **General Court** (ID 1) is the root, with specialized courts beneath it (Blockchain, Curation, English Language, and others) and the **Forking Court** (ID 0) reserved for protocol disputes. Staking in a specialized court automatically stakes you in all its parent courts. + +Beginner-friendly courts include the **General Court** and the **English Language Court**. Specialized courts such as **Blockchain Technical**, **Curation**, **Insurance**, and the **Corte de Disputas de Consumo y Vecinidad** (inside Corte General en Español, which serves enterprise cases like Lemon and MetLife) expect specific expertise. + +Each court page shows the parameters that matter to you: + +| Parameter | What it means for you | +| --- | --- | +| **Minimum Stake** | The least PNK you can stake in that court | +| **Alpha** | Fraction of your stake locked when drawn: `pnkAtStakePerJuror = (minStake × alpha) / 10000` | +| **Fee for Juror** | What you earn per coherent vote, in ETH or a whitelisted ERC-20 | +| **Hidden Votes** | Whether the court uses commit-reveal voting | +| **Time per Period** | Duration of the evidence, commit, vote, and appeal phases (periods can end early when no more interactions are needed) | +| **Jurors for Court Jump** | Juror count at which an appealed dispute escalates to the parent court | + + +Always read the court policy before staking or voting in a court. It defines the dispute types, evaluation rules, and required skills, and it is binding for your votes. + + + + One-pager: Court Hierarchy and Parameters, infographic to be added + + +--- + +## Staking Your PNK + + + + Visit [v2.kleros.builders](https://v2.kleros.builders/), click **Connect Wallet**, and approve the connection. Make sure you are on Arbitrum One. + + + Click **Courts**, browse the tree, and open a court to review its policy, minimum stake, fee per juror, and recent cases. + + + + + + Staking requires a standard ERC-20 approval so KlerosCore can use your PNK. You approve each time you increase your stake. + + + Click **Stake**, enter an amount at or above the court minimum, and confirm in your wallet. + + + Confirm your stake appears correctly on your profile. + + + + + + + + + One-pager: Staking Flow in V2, infographic to be added + + +Things to know about V2 staking: + +- **Your PNK transfers to the KlerosCore contract** while staked (in V1 it stayed in your wallet). You can unstake anytime unless it is locked in an active case. +- **You can stake in at most 4 courts** (a gas-efficiency limit), so plan your court selection. +- **Timing matters**: the court cycles through Staking, Generating, and Drawing phases. Stake changes made during the Generating or Drawing phases are recorded but only take effect in the next Staking phase. The UI shows whether your stake is "Current" or "Delayed." + +--- + +## Getting Selected + +Selection is random but stake-weighted: your probability per draw is your stake divided by the court's total stake (5,000 PNK in a court with 100,000 PNK staked gives you a 5% chance per draw). You can be drawn multiple times for the same case; each draw is one vote, and all your votes must be for the same choice. + +When drawn: + +- A portion of your stake is locked as collateral +- The case appears in **My Cases** +- You are notified in the interface (and by email if you enabled notifications in Settings, which is strongly recommended for deadline reminders) + +--- + +## Handling Your First Dispute + + + One-pager: Handling Your First Dispute, infographic to be added + + + + + You receive a notification and your dashboard updates. + + + The case view has these sections: **Title & Description** (what the dispute is about), **Question** (the specific question to answer), **Voting Options**, **Policy** (rules for evaluation), **Evidence** (party submissions), and **Timeline** (current phase and deadlines). + + + The policy is your guide to correct voting. Read it before looking at evidence. + + + Read everything thoroughly, check submission timestamps, verify technical claims, and take notes on key points. Budget real time for this (2-4 hours for a substantial case). + + + The common pattern is: **In favor of Requester** (evidence supports the requester's claim), **In favor of Respondent** (evidence supports the respondent's position), and **Refuse to Arbitrate** (the case is invalid, illegal, or morally unacceptable). + + + See the two voting flows below. + + + Explain your reasoning: a brief case summary, the key evidence you reviewed, the relevant policy sections, and your conclusion. Justifications support Markdown formatting, help jurors in appeal rounds, and create precedent. + + + Either party can appeal by funding fees. If only one side pays the appeal fees, that side automatically wins. + + + Once the ruling is final and executed, rewards become claimable. + + + +### Voting in visible courts + +1. Select your choice +2. Click **Vote** +3. Confirm the transaction +4. Your vote is immediately visible + +### Voting in hidden courts (commit-reveal) + +1. Select your choice +2. Write your justification +3. Click **Commit** (submits a hash of your vote) +4. Wait for the reveal phase +5. Return and click **Reveal** +6. Your vote is now visible + + +In hidden courts, keep your vote secret and remember to return for the reveal phase. Failing to reveal means losing your locked PNK. If a juror reveals early, anyone can report them and claim part of their locked stake. + + +### Common mistakes + +| Mistake | How to avoid it | +| --- | --- | +| Not reading the policy | Always read it before reviewing evidence | +| Voting personal opinion | Follow the policy, not feelings | +| Missing deadlines | Enable notifications and check regularly | +| Forgetting to reveal | Set a reminder for the reveal period | + +Missing a deadline means a stake penalty and being unstaked from all courts. + +--- + +## Rewards and Penalties + +You earn rewards for voting **coherently** with the final outcome: + +- **Arbitration fees** (ETH or whitelisted ERC-20s) paid by the disputing parties, divided among coherent jurors: `jurorReward = (totalFees / numberOfCoherentVotes) × degreeOfCoherence` +- **PNK redistribution** from incoherent jurors: `pnkReward = (totalPenalties / numberOfCoherentVotes) × degreeOfCoherence` + +In the Classic Dispute Kit, coherence is binary: full coherence if your vote matches the final ruling, zero if it differs or you failed to reveal. Incoherent jurors lose a portion of their locked stake and forfeit fee rewards. + +**Worked example**: 5 jurors at 0.05 ETH each (0.25 ETH total), 3 coherent and 2 incoherent. Each coherent juror receives about 0.083 ETH plus a share of the incoherent jurors' PNK. + +**Claiming**: a Kleros bot claims rewards automatically roughly every hour, or claim manually from the case page or rewards dashboard. The UI lets you batch claims to save gas. + + + One-pager: Juror Rewards and Coherence, infographic to be added + + +--- + +## Appeals and Court Jumps + +- Appeal funding follows `feeForJuror × ((nbVotes × 2) + 1)`: the winning side must fund 1× the appeal cost and the challenging side 2×. With 3 jurors at 0.05 ETH, that is 0.35 ETH for the winner and 0.70 ETH for the challenger. +- The challenger can only fund during the **first half** of the appeal period; the winner has the entire period. +- Each appeal round increases the juror count (`n×2 + 1`). When the count reaches the court's `jurorsForCourtJump` threshold (for example, 511), the dispute escalates to the parent court, and juror numbers adjust to the new court's parameters. You may be drawn for jumped cases; expect them to be more complex. + + + One-pager: Appeals and Court Jumps, infographic to be added + + +--- + +## Cross-Chain Disputes + +V2 natively supports disputes originating on other EVM chains (Ethereum, Gnosis Chain, Polygon, Optimism, and more). As a juror, everything happens on Arbitrum: disputes are bridged in, evidence appears unified in the interface, and rulings are bridged back to the origin chain. The process is identical for you regardless of where the dispute came from. + +--- + +## Troubleshooting + +| Problem | What to do | +| --- | --- | +| Wrong network error | Switch to Arbitrum One (Rabby prompts automatically) | +| PNK not visible in wallet | Import the PNK token contract manually; verify the address from official sources | +| Stake transaction fails | Check PNK balance, ETH for gas, and the court minimum | +| Case not in My Cases | Confirm you were drawn, wait for confirmation, refresh | +| Vote deadline passed | Late votes are never accepted; set multiple reminders next time | + +For help: [Discord](https://discord.gg/kleros), [Telegram](https://t.me/kleros), or support@kleros.io. + +--- + +## What's Next? + + + + The complete beginner's walkthrough with screenshots + + + The full dispute lifecycle in V1 and V2 + + + What PNK is and where to get it + + diff --git a/tutorials/poh-register-and-vouch.mdx b/tutorials/poh-register-and-vouch.mdx new file mode 100644 index 0000000..8828352 --- /dev/null +++ b/tutorials/poh-register-and-vouch.mdx @@ -0,0 +1,165 @@ +--- +title: "PoH: Register and Vouch" +description: "Register your profile, get vouched, and vouch for others on Proof of Humanity 2.0" +--- + +# Proof of Humanity Tutorial: Register & Vouch + +This tutorial covers the Proof of Humanity 2.0 registration process: registering your profile, the validation process, and vouching for others. + +To challenge or remove profiles, see the [Remove & Challenge tutorial](/tutorials/poh-remove-and-challenge). + +--- + +## Phase 1: Register Your Profile + + + + Navigate to the [PoH v2 application](https://v2.poh.id/), where you can view recently registered profiles. + + + Click **Connect** in the upper right corner and select your wallet from the popup menu. Review the Proof of Humanity Registry Policy via the Policy button before proceeding. + + + Your wallet address will be publicly linked to your identity. Consider using a new address seeded from an exchange to protect your transaction history. + + + + Once your wallet is connected, the **Register** button appears in the top menu. + + + + + +### Registration information + +Before you start, keep these requirements in mind: + +- One human = one active profile. Duplicate simultaneous submissions face challenges and deposit loss. +- V1 users must claim their previous Humanity ID or register correctly on v2. +- Choose the appropriate action: **Renew** (update an existing v2 profile), **Claim Humanity** (expired v1 profile), or **Revoke** (remove a profile). + + + + Confirm the wallet address to associate, provide your official or commonly known name, and check the consent box acknowledging the permanent wallet-identity link. Click **Next**. + + + + + + Review the photo guidelines and checklist, capture a photo using the app camera (with optional cropping), and click **Ready** when satisfied or **Retake** to change it. + + Browse "Resolved Claim" profiles for examples of accepted submissions. + + + + + + Record a video showing your face clearly and a sign displaying your complete wallet address (printed, written, or on screen), while saying: + + *"I certify that I am a real human and that I am not already registered in this registry"* + + Verify the video meets the checklist requirements before proceeding. + + + + + + + + + Double-check all submitted information and enter the required deposit. The deposit is locked with your submission: it incentivizes challengers and covers arbitration fees. Successful registration returns it; a failed registration means losing it. + + Make sure you have enough xDAI or ETH for the deposit and transaction fees. Submissions are final, with no editing after submission. + + Click **Sign In**, wait for the media upload to complete, and confirm the transaction in your wallet. + + + + + +--- + +## Phase 2: Subscribe to Notifications + +The notification system is under development. Until it launches, check your profile status manually. + +--- + +## Phase 3: Profile Validation (~3-5 days) + +Profiles progress through: **Needs Vouch → In Review → Verified Human**. + + + + +### From Needs Vouch to In Review + +To advance, your profile needs: + +- At least 1 vouch from a person with "Resolved Claim" status who knows you +- Full deposit payment (100%) +- Vouch initiation via **Advance** + +Vouches process sequentially, roughly 3.5 days per person. Multiple simultaneous vouches from one person delay processing for others. If you need to correct something, withdrawal is available only during the vouching phase. + +### From In Review to Verified Human + +A 3.5-day challenge period lets the community verify compliance: + +- **If challenged**: a Kleros Court dispute opens. Provide evidence defending your case. Appeals are available if you disagree with the ruling. +- **If unchallenged**: click **Execute** after 3.5 days to finalize your registration. Any address can submit this transaction. Your deposit is refunded on completion. + +Once verified, you gain the ability to vouch for others. + + + + + + + +--- + +## Phase 4: Vouch for Another Profile + +You must be connected to the app and have "Verified Human" status. + + + + Navigate to the target profile via a shared link or name search. + + + + + + + Click the **Vouch** button on their profile and sign the message from your wallet. + + + + + + +Two vouch types exist: + +- **Vouch**: free, no transaction fees, non-revocable +- **Vouch on-chain**: requires transaction fees, but can be removed while the profile is in the "Needs Vouch" phase + +You can vouch for multiple people, but each vouch counts sequentially: once one person moves to "In Review," your next vouch activates on a first-come, first-served basis. + + +Vouching for sybil or fake submissions risks your own removal from the registry. Vouching for profiles with minor information errors carries no penalty. + + +--- + +## What's Next? + + + + Challenge non-compliant profiles or remove your own + + + Learn how the registry works + + diff --git a/tutorials/poh-remove-and-challenge.mdx b/tutorials/poh-remove-and-challenge.mdx new file mode 100644 index 0000000..13ec603 --- /dev/null +++ b/tutorials/poh-remove-and-challenge.mdx @@ -0,0 +1,128 @@ +--- +title: "PoH: Remove & Challenge" +description: "Challenge non-compliant profiles, remove profiles, and resubmit on Proof of Humanity 2.0" +--- + +# Proof of Humanity Tutorial: Remove & Challenge + +This tutorial covers challenging profiles, removing profiles, and resubmitting profiles in the Proof of Humanity 2.0 registry. + +For registering and vouching, see the [Register & Vouch tutorial](/tutorials/poh-register-and-vouch). + +--- + +## Challenge a Claim + + + + Visit the [PoH app](https://v2.poh.id/) and filter for **In Review** or **Removal Proposed** profiles using the right-side filter. Click individual profiles to verify compliance with the PoH guidelines. Look for deepfakes, inappropriate content, or guideline violations. + + + + + + + Detection tools that can help: + + - [Deepware.ai](https://deepware.ai) + - [Sensity.ai](https://sensity.ai) + - Voice recognition software for computer-generated audio + + + 1. Click the orange **Challenge** button at the top right of the profile + 2. Select the violation reason and provide a justification + 3. Click **Challenge request** and send the transaction + + The challenger deposit is a locked amount of ETH or xDAI that deters frivolous challenges. A successful challenge returns your deposit plus the submitter's deposit (minus arbitration fees). A failed challenge forfeits your deposit. + + + + + + + + + The challenge enters [Kleros Court](/court/overview) for jury voting. Submit evidence from the bottom of the profile page and monitor progress over 5-7 days. Appeal options are available if you disagree with the ruling. + + + + + + + + + + +--- + +## Remove a Profile + +### Remove your own profile (Needs Vouch status) + +Click the **Withdraw** button on your profile page to recover your deposit. + + + + +### Remove registered or Verified Human profiles + +1. Open the profile and click **Revoke** +2. Lock a deposit (reimbursed if the removal succeeds) +3. Optionally submit evidence supporting the revocation + + + + + + + +Example evidence submissions: + +- **Self-removal from the same address**: name it "Self-removal of submission" and confirm your submitter status via the address. +- **Self-removal from a different address**: name it "Self-removal of submission" and include a video recording stating: "I want to revoke my own submission from the Proof of Humanity registry". +- **Malicious submission removal**: name it "Removal of deepfake submission" and include deepfake analysis reports as evidence. + + + + +### Remove in-review profiles + +Use the challenge process described above. + +--- + +## Resubmit a Profile + +### From a new address + +1. Ensure the old profile shows **Revoked** status (check `https://v2.poh.id/PoHID`) +2. Remove it if necessary using the steps above +3. Connect the new address and submit a fresh profile + + + + +### From the same address + +1. Verify the old profile is **Revoked** +2. Remove it if needed +3. Click the **Resubmit Profile** button at the bottom left of the profile + +### Reapply an expired or expiring profile + +Profiles expire two years after registration. Reapply to prove your continued existence and control of the address. + + + +--- + +## What's Next? + + + + Register your own profile on Proof of Humanity + + + Learn how the registry works + + diff --git a/tutorials/poh-transferring-a-profile.mdx b/tutorials/poh-transferring-a-profile.mdx new file mode 100644 index 0000000..9802c62 --- /dev/null +++ b/tutorials/poh-transferring-a-profile.mdx @@ -0,0 +1,64 @@ +--- +title: "PoH: Transferring a Profile" +description: "Transfer your Proof of Humanity profile to another supported chain" +--- + +# Proof of Humanity Tutorial: Transferring a Profile + +Proof of Humanity 2.0 operates on Ethereum Mainnet and Gnosis Chain. A profile can only be active on one chain at a time, but you can transfer it between chains. + + +Make sure you have enough funds to transact on your desired new chain to update or complete the profile transfer. + + +--- + +## Transfer Steps + + + + Navigate to your profile page and select the **Transfer** button. + + + + + + A confirmation prompt appears asking you to verify the transfer action. Confirm the transaction. + + + After the transaction confirms, your profile status becomes **Pending Update**. Connect your wallet to the destination chain, visit your profile, and click **Update state**. + + + + + + Select **Relay State Update** from the prompt and confirm the transaction on the new chain. + + + + + + Once validated, your current profile request shows as **Resolved Claim** with the new network's icon. The previous request status changes to **Transferred**. + + + + + + + + + + + +--- + +## What's Next? + + + + Register your profile on Proof of Humanity + + + Challenge or remove profiles + + diff --git a/tutorials/scout-tutorial.mdx b/tutorials/scout-tutorial.mdx new file mode 100644 index 0000000..7dc1f88 --- /dev/null +++ b/tutorials/scout-tutorial.mdx @@ -0,0 +1,116 @@ +--- +title: "Scout Tutorial" +description: "Submit, challenge, and remove entries in the Kleros Scout registries" +--- + +# Scout Tutorial + +This tutorial is a complete walkthrough of using [Kleros Scout](https://app.klerosscout.eth.limo/): submitting new entries, challenging invalid ones, managing challenged submissions, and removing fraudulent entries. + +--- + +## Submitting a New Entry + + + + Visit the Kleros Scout dApp and select your registry: Tokens, Address Tags, or Contract-Domain Names. + + + Read the registry-specific rules via the **Registry Details** button. Gather the necessary documentation, links, and proof materials before you start. + + + Click **Submit entry** and fill out all required fields accurately, uploading your collected information and evidence. + + + Deposit xDai (or the applicable token) and complete the wallet transaction. + + + Always double-check facts before submitting. If your submission is incorrect, you lose your deposit. + + + + Your entry enters **Registration Requested** status. If no one challenges it during the set timeframe, it is approved into the registry. + + + + + +--- + +## Challenging a Submitted Entry + + + + Browse the registry for entries in **Registration Requested** status that look invalid. + + + Gather links, screenshots, and documents proving the entry violates the registry policy. + + + Open the entry via the **Details** button and press **Challenge Entry**. + + + Provide strong evidence for the Kleros Court review, and confirm with sufficient funds in your wallet. + + + +The entry moves to **Challenged** status and is resolved through Kleros Court. If you win, you earn a portion of the submitter's deposit; if you lose, you forfeit your own. + + + +--- + +## Managing Challenged Submissions + +Whether you are the submitter or the challenger: + + + + Track the submission status once it is marked **Challenged**. + + + Select the entry and click **Submit Evidence** to strengthen your case. + + + Watch evidence updates and dispute deadlines. After the deadline, jurors decide. + + + If you believe the decision was incorrect, appeal options are available. + + + + + +--- + +## Removing Confirmed Fraudulent Entries + + + + Navigate to the relevant registry and open the questionable entry via **Details**. + + + Verify that the entry actually violates the registry's policy requirements. + + + Press **Remove Entry**, complete the form with your evidence, and make sure you have adequate funds for the deposit. + + + Complete the wallet transaction. The entry enters **Removal Request** status, and the outcome is determined by the community (and Kleros Court if challenged). + + + + + +--- + +## What's Next? + + + + Bounties and reward programs for contributors + + + How Scout and its registries work + + diff --git a/welcome/introduction.mdx b/welcome/introduction.mdx index e250877..06ed927 100644 --- a/welcome/introduction.mdx +++ b/welcome/introduction.mdx @@ -48,47 +48,43 @@ The heart of Kleros. Court uses crypto-economic incentives and game theory to cr ## Products -Kleros products are decentralized applications that use Kleros Court for dispute resolution. - - - **Kleros V2 is here.** Most products now support V2, with remaining products migrating soon. See the [Products Overview](/products/overview) for version details. - +Kleros products are decentralized applications that use Kleros Court for dispute resolution. See the [Products Overview](/products/overview) for version details. **Decentralized lists & registries** - Create and maintain community-curated registries of anything—tokens, contracts, addresses, or custom data. + Create and maintain community-curated registries of anything-tokens, contracts, addresses, or custom data. - V2 + V1 • V2 **Secure transactions** Hold funds in escrow with built-in dispute resolution if something goes wrong. - V2 + V1 • V2 **DAO governance** Decentralized governance execution with dispute resolution for contested proposals. - V2 + V1 • V2 **Contract & token verification** Community-curated safety information for smart contracts, tokens, and dApps. - V1 • V2 coming soon + V1 **Reality.eth + Kleros** Crowdsourced oracle with Kleros arbitration as the final backstop for disputed answers. Powers Zodiac/SafeSnap. - V1 • V2 coming soon + V1 **Sybil-resistant identity** @@ -99,10 +95,9 @@ Kleros products are decentralized applications that use Kleros Court for dispute - - Court V1, Resolver, and retired products (Moderate, Linguo, Tokens) are documented in the Legacy section. - - + + Kleros Court Interface + --- ## For Developers @@ -144,7 +139,7 @@ Build trustless applications with decentralized dispute resolution. Ready to deploy? Make sure you've covered everything - + ERC-792 & ERC-1497 for V1 integrations @@ -222,9 +217,6 @@ Kleros is built on peer-reviewed research and collaborates with leading institut ## Need Help? - - Step-by-step guides and troubleshooting - Chat with the community