Current Implementation
The following section describes the scope of the current MVP implementation. Other sections of the documentation describe the full Slice protocol design beyond the current implementation.
Scope
The current implementation focuses on validating the core mechanics of Slice:
Human juries
Economic incentives based on game theory
Automated on-chain execution
Fast and reliable dispute resolution for low-to-medium value conflicts
All features outside this scope are intentionally excluded from the MVP and will be introduced in future phases.
Supported Dispute Type
Public Adversarial Dispute
The MVP supports public adversarial disputes between two parties:
Claimer: the party initiating the dispute
Defender: the counterparty
Both parties:
submit evidence,
stake funds,
and accept the outcome enforced by the protocol.
The dispute is resolved by a group of anonymous human jurors.
Dispute Lifecycle
Each dispute follows a deterministic, on-chain lifecycle:
Dispute Creation A dispute is created by the claimer, specifying the counterparty and dispute parameters.
Funding & Evidence Submission Both parties deposit the required stake and submit evidence (off-chain, referenced on-chain).
Juror Assignment Jurors are selected and assigned to the dispute.
Commit Phase Jurors commit their votes using a commit–reveal scheme.
Reveal Phase Jurors reveal their votes.
Resolution & Execution The protocol determines the winning side and automatically executes:
fund redistribution,
juror rewards,
and penalties.
The outcome is final in the current implementation.
Jurors
Jurors are human participants verified via Proof of Humanity (PoH).
Each juror represents one vote.
Jurors are anonymous to disputing parties.
Jurors must stake funds to participate.
Stake does not affect voting power. It only determines:
potential rewards,
and potential losses.
Matchmaking
Slice uses backend-assisted matchmaking to ensure disputes are resolved reliably and on time. This mechanism exists to:
• ensure disputes always reach the required number of jurors
• avoid stalled or abandoned cases
• provide predictable resolution times for platforms and users Juror selection remains randomized and independent.
The backend only coordinates assignment to guarantee dispute completion. Importantly, the backend cannot:
• influence juror votes
• affect dispute outcomes
• control fund execution
All decisions and transfers are enforced by the protocol and smart contracts. This approach prioritizes liveness, UX, and system reliability while preserving neutrality and incentive alignment.
Voting & Security
Voting is executed fully on-chain.
A commit–reveal scheme is used to prevent vote manipulation.
Shutter-based encryption is used to improve privacy and voting fairness.
All state transitions and outcomes are verifiable on-chain.
Tiers
The MVP introduces four fixed dispute tiers.
Each tier defines:
number of jurors,
juror stake requirements,
party stake requirements,
fixed fees and protocol fees.
Tiers allow the protocol to support different levels of dispute complexity and economic risk while maintaining predictable resolution behavior.
Economics
Both disputing parties stake funds to participate.
Jurors stake funds to vote.
Jurors who vote coherently are rewarded.
Jurors who vote against the final outcome lose their stake.
The protocol charges a fixed fee per dispute and a percentage of the losing juror pool.
All economic flows are enforced automatically by smart contracts.
Limitations of the Current Implementation
The following features are not included in the current implementation:
Appeals or dispute escalation
Private disputes
Category-based disputes
Rating or decision-based disputes
Fully on-chain randomness-only matchmaking
These features are part of the Slice protocol design and will be introduced in future phases.
Design Philosophy
The current implementation prioritizes:
correctness over completeness,
reliability
and enforceable outcomes over subjective mediation.
This approach allows Slice to validate its core assumptions while preserving a clear path toward progressive decentralization and additional dispute types.
Last updated