kleros/kleros-v2

---
kip: <#>
title: <title>
author: <a comma separated list of the author's or authors' name + GitHub username (in parenthesis), or name and email (in angle brackets).  Example, FirstName LastName (@GitHubUsername), FirstName LastName <foo@bar.com>, FirstName (@GitHubUsername) and GitHubUsername (@GitHubUsername)>
discussions-to: https://forum.kleros.io/c/proposal/<#>
status: <Draft, Last Call, Approved, Final, Abandoned, Rejected>
type: <Core, Parameter, Arbitrable>
created: <yyyy-mm-dd>
requires: <KIP number(s)> # Only required when you reference an KIP in the `Specification` section. Otherwise, remove this field.
---

## Summary

2-5 sentences providing a simplified and layman-accessible explanation of the issue.

## Motivation

The motivation is critical to change the KIP protocol.
It should clearly explain why the existing protocol specification is inadequate with respect to the issue raised.

## Technical Specification

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.

The technical specification should describe the syntax and semantics of the proposed solution for the issue raised.
If a suggestion is proposed, provide sufficient details so that an implementation would be possible (Proof of Concepts are acceptable).

## Rationale

The rationale should flesh out the specification by describing what motivated the design and why particular design decisions were made, as well as any alternative designs that were considered.

## Implementation

An implementation must be completed before any KIP proceeds to “Last Call” status.

## Backwards Compatibility

## Security considerations

All KIPs must include a discussion of the security implications/considerations relevant to the proposed change as well as proposed mitigations. A KIP cannot proceed to “Final” status without a sufficient security review from the core team.