# Dispute Lifecycle
Source: https://docs.justly.one/how-it-works/dispute-lifecycle
Every dispute in Justly follows a compact five-state lifecycle with bounded deadlines, frozen evidence before voting, and finality independent from callback execution.
Every dispute in Justly follows a deterministic five-state lifecycle.
While tiers may change economic values and timing ranges, the state machine stays the same across the protocol.
***
#### State model
Every dispute moves through these states:
1. `Created`
2. `Evidence`
3. `Commit`
4. `Reveal`
5. `Finished`
This model stays intentionally compact. Operational steps such as juror assignment happen inside a state rather than as separate states.
***
#### 1. `Created`
A dispute starts in `Created` when the integrating protocol opens a case between a **Claimer** and a **Defender**.
At creation time:
* the parties are defined,
* the tier is selected,
* the evidence reference can be set,
* and timing parameters are initialized.
The dispute exists, but adjudication has not started yet.
***
#### 2. Funding and activation
Both sides of the dispute must be fully funded before the dispute can activate.
This means the required economic amounts for the claimer side and defender side must be covered. Those amounts may be paid by the parties themselves or by a sponsor or platform on their behalf.
Until both sides are covered, the dispute remains in `Created`.
Once full funding is complete, the dispute moves to `Evidence`.
***
#### 3. `Evidence`
In `Evidence`, the funded dispute is open for evidence submission.
During this phase:
* the parties can submit evidence references,
* evidence stays off-chain,
* evidence references are recorded on-chain,
* and the record that jurors will later evaluate is formed.
Evidence is only accepted during its allowed window.
When the evidence window closes, the dispute moves to `Commit` and the record is frozen.
***
#### 4. `Commit`
`Commit` is the start of adjudication.
At this point:
* evidence is frozen,
* the voting timer starts,
* juror assignment begins,
* and selected jurors can submit vote commitments.
Juror selection is permissionless to trigger.
If the full target panel is not reached before the selection timeout, the dispute still proceeds with the jurors actually selected.
***
#### 5. `Reveal`
In `Reveal`, jurors who committed votes reveal them.
This phase:
* verifies commitments,
* counts valid reveals,
* and allows the dispute to reach finalization.
The dispute finalizes when either:
* all effective votes have been revealed, or
* the voting deadline passes.
If no effective vote exists, the defender is the default outcome.
***
#### 6. `Finished`
In `Finished`, the ruling is final at the protocol level.
At finalization, Justly:
* stores the final ruling,
* computes juror rewards and penalties,
* and may attempt a callback to the integrating protocol.
Callback success is not required for ruling finality.
***
#### Key guarantees
The lifecycle guarantees that:
* a dispute cannot enter adjudication before both sides are fully funded,
* evidence is frozen before voting begins,
* progression is bounded by deadlines,
* a dispute can finalize with fewer jurors than the target panel,
* and callback failure does not invalidate the ruling.
***
#### Notes on versions
The current live version resolves disputes in a single finalized round.
Appeals are planned for a later version and are not part of the current lifecycle.
# Adversarial Dispute
Source: https://docs.justly.one/how-it-works/dispute-types/adversarial-dispute
Adversarial disputes are Justly's live dispute type for resolving binary conflicts between two opposing parties.
An **adversarial dispute** resolves a conflict between two opposing parties through neutral human judgment and on-chain execution.
It is the primary dispute type supported in the current version of Justly.
***
### Overview
An adversarial dispute involves:
* a **Claimer**, who initiates the case,
* a **Defender**, who responds to it,
* and a panel of jurors who evaluate the evidence.
Both sides of the dispute must be fully funded before adjudication starts.
Those amounts may be paid by the parties themselves or by a sponsor or platform on their behalf.
Jurors evaluate the record and produce a binary outcome.
If no effective vote exists at finalization, the defender is the default outcome.
***
### When to use an adversarial dispute
Adversarial disputes are suitable when:
* responsibility or fault is contested,
* the outcome is binary,
* and a clear winner must be determined.
Typical use cases include:
* marketplaces and peer-to-peer transactions,
* freelancer and contractor platforms,
* fintech and payment disputes,
* and protocol-level human arbitration.
***
### Participants
#### Claimer
The claimer is the party that initiates the dispute.
The claimer is responsible for:
* opening the dispute,
* submitting evidence during the evidence window,
* and ensuring the claimer side of the dispute is funded.
***
#### Defender
The defender is the party responding to the claim.
The defender is responsible for:
* submitting counter-evidence during the evidence window,
* and ensuring the defender side of the dispute is funded.
***
#### Jurors
Jurors are independent participants selected through protocol-defined assignment.
Jurors:
* review the evidence,
* commit and reveal votes,
* and are economically incentivized to vote coherently.
Jurors are never parties to the dispute.
***
### Dispute flow
1. The dispute is created in `Created`.
2. Both sides are fully funded.
3. The dispute moves to `Evidence` and evidence can be submitted.
4. Evidence closes and the dispute moves to `Commit`.
5. Juror assignment begins and selected jurors commit votes.
6. The dispute moves to `Reveal` and jurors reveal votes.
7. The dispute finalizes in `Finished`.
All steps follow predefined rules enforced by smart contracts.
***
### Appeals
The current live version resolves adversarial disputes in a single finalized round.
Appeals are planned for a later version and are not part of the current implementation.
***
### Guarantees
Adversarial disputes in Justly provide:
* **Neutrality**: jurors are independent and randomly assigned.
* **Economic alignment**: incentives reward coherent voting and penalize incoherence.
* **Deterministic execution**: outcomes are enforced by smart contracts.
* **Predictable structure**: all rules are defined upfront by the protocol.
Justly does not interpret evidence, influence jurors, or intervene in outcomes.
***
### Status
**Live (Current Implementation)**
# Decision Dispute
Source: https://docs.justly.one/how-it-works/dispute-types/decision-dispute
Not all judgments involve a conflict between two opposing parties.
Not all judgments involve a conflict between two opposing parties.
Some situations require a **collective human decision** to validate whether an action, proposal, or outcome should be accepted or rejected.
**Decision disputes** are designed for these cases.
***
### Overview
A decision dispute enables **structured collective judgment** over a proposal or action.
Instead of resolving a conflict between two parties, jurors evaluate whether a submitted proposal is **valid, acceptable, and well-defined** according to predefined rules.
The outcome is enforced automatically on-chain.
***
### When to use a Decision Dispute
Decision disputes are suitable when:
* no direct adversarial conflict exists,
* a proposal must be validated by human judgment,
* or automated rules are insufficient or ambiguous.
Typical use cases include:
* governance and protocol decisions,
* validation of sensitive actions,
* structured approval workflows,
* human review of edge cases.
***
### Participants
#### Proposer
The proposer submits a proposal, action, or decision for evaluation.
The proposer:
* defines the proposal to be evaluated,
* deposits a **bond**,
* and accepts the outcome determined by jurors.
The proposer is **never a juror** in their own decision dispute.
***
#### Jurors
Independent participants selected through randomized assignment.
Jurors:
* evaluate the proposal according to the dispute rules,
* vote independently,
* and are economically incentivized to act coherently.
Jurors are not influenced by the proposer and have no special privileges.
***
### Decision Outcomes
Decision disputes produce one of the following outcomes:
#### Accept
The proposal is considered valid and acceptable.
The protocol executes the accepted action or records the decision accordingly.
***
#### Reject
The proposal is considered invalid, poorly defined, or unsuitable for evaluation.
Reject does **not** mean:
> “refund the proposer”
Reject means:
> “the proposal should not be accepted in its current form.”
In this case, the proposer’s bond is used to:
* compensate jurors,
* and cover protocol costs.
This mechanism discourages biased, low-quality, or malformed proposals without giving proposers special influence.
***
### Bond Mechanism
The proposer deposits a bond when opening a decision dispute.
The bond serves to:
* discourage spam or biased proposals,
* align incentives between proposers and jurors,
* and compensate jurors in case of rejection.
If:
* no clear majority is reached,
* or a rejection threshold is met,
the bond may be redistributed according to the dispute rules.
***
### Dispute Flow (High Level)
1. The proposer submits a proposal and deposits a bond.
2. Jurors are assigned to the dispute.
3. Jurors evaluate the proposal and vote.
4. The protocol determines the outcome.
5. The result is executed automatically on-chain.
All steps follow predefined rules enforced by smart contracts.
***
### Guarantees
Decision disputes in Justly provide:
* **Impartial evaluation**: proposers do not influence voting.
* **Economic discipline**: bonds discourage malformed proposals.
* **Transparent execution**: outcomes are enforced on-chain.
* **Predictable structure**: decision rules are defined upfront.
Justly does not interpret proposals or intervene in decisions.
***
### Status
**Planned**
Decision disputes are part of the core protocol design and will be introduced in a future implementation phase.
# Dispute Types
Source: https://docs.justly.one/how-it-works/dispute-types/dispute-types
Justly supports multiple types of human judgment, depending on the nature of the conflict or evaluation being performed.
Justly supports multiple types of human judgment, depending on the nature of the conflict or evaluation being performed.
Each dispute type defines:
* how participants interact,
* how jurors evaluate information,
* and how outcomes are enforced on-chain.
Not all dispute types are available in the current implementation.\
This section describes the live dispute type and the additional dispute types planned for later versions.
| Types | Purpose | Outcome | Status |
| ------------------- | --------------------------------------- | ------------------ | ------------- |
| Adversarial Dispute | *Resolve conflicts between two parties* | *Winner/Loser* | Live |
| Decision Dispute | *Validate proposals or decisions* | *Accept/Reject* | Later version |
| Rating Evaluation | *Evaluate quality or contribution* | *Aggregated Score* | Later version |
### Adversarial Dispute
**Status:** Live (Current Implementation)
Resolves conflicts between two opposing parties: a **Claimer** and a **Defender**.
Jurors evaluate evidence submitted by both sides and vote on a binding outcome that is enforced on-chain.
Used for:
* marketplaces,
* freelancer and contractor platforms,
* fintech and payment disputes,
* peer-to-peer conflicts.
→ *See: Adversarial Dispute*
***
### Decision Dispute
**Status:** Later version
Designed for collective decision-making rather than conflict resolution.
Jurors evaluate whether a proposal or action should be accepted or rejected according to predefined rules.
Used for:
* governance processes,
* protocol-level decisions,
* structured human validation.
→ *See: Decision Dispute*
***
### Rating Evaluation
**Status:** Later version
A collective evaluation mechanism based on structured numerical input rather than binary outcomes.
Jurors provide ratings that are aggregated to measure quality, performance, or contribution.
Used for:
* open-source contribution evaluation,
* content moderation,
* quality and performance scoring,
* reputation systems.
→ *See: Rating Evaluation*
Some dispute types may support additional evaluation rounds under stricter conditions.
***
### Extensibility
Justly is designed as a modular protocol.
Additional dispute types and variations can be introduced over time without changing the core execution or incentive model.
# Rating Evaluation
Source: https://docs.justly.one/how-it-works/dispute-types/rating-evaluation
Not all judgments are about determining a winner.
Not all judgments are about determining a winner.
Some problems require **measuring quality, performance, or contribution** rather than resolving a conflict.
**Rating Evaluation** is Justly’s primitive for these cases: a structured, incentive-aligned system for collective human evaluation.
***
### Overview
Rating Evaluation enables **collective assessment using numerical input**, rather than binary outcomes.
Instead of voting for a winning party, jurors provide **ratings on a predefined scale** (for example, 1-5).\
These ratings are aggregated using robust statistical methods to produce a final evaluation.
The result is enforced or recorded automatically on-chain.
Rating Evaluation is designed to support **subjective or qualitative judgment** while preserving incentive alignment and resistance to manipulation.
***
### When to use Rating Evaluation
Rating Evaluation is suitable when:
* there is no clear winner or loser,
* quality or contribution must be assessed,
* or outcomes exist on a spectrum rather than as binary choices.
Typical use cases include:
* open-source contribution evaluation and reward distribution,
* content moderation and severity assessment,
* marketplace quality scoring,
* performance and deliverable evaluation,
* reputation and feedback systems.
***
### Participants
#### Subject
The subject is the entity being evaluated.
This may be:
* a contribution,
* a piece of content,
* a deliverable,
* or a completed action.
The subject does not participate in voting.
***
#### Jurors
Independent participants selected through randomized assignment.
Jurors:
* review the submitted evidence,
* assign ratings according to the defined scale,
* and are economically incentivized to rate coherently.
Jurors do not coordinate directly and have no privileged information.
***
### Evaluation Method
Jurors submit ratings on a predefined numerical scale.
The protocol aggregates these ratings using a **median-based approach**, which:
* reduces sensitivity to outliers,
* penalizes extreme or incoherent inputs,
* and provides robustness against individual manipulation.
Incentives are adjusted based on **distance from the aggregated result**, rather than absolute correctness.
This creates a system where jurors are rewarded for **coherent judgment**, not for guessing an objective “truth”.
***
### Incentive Design
Rating Evaluation uses **partial incentive adjustment** rather than full slashing.
Jurors whose ratings are closer to the aggregated result retain more of their stake.\
Jurors whose ratings deviate significantly may lose a portion of it.
This design:
* discourages extreme or bad-faith ratings,
* tolerates reasonable disagreement,
* and avoids punishing minor deviations harshly.
***
### Generalization Across Domains
Rating Evaluation is designed as a **general evaluation engine**, not a domain-specific tool.
The protocol separates:
* the **rating engine** (aggregation and incentive logic),
* from the **evidence schema** (what is being evaluated and how).
This allows the same evaluation mechanism to be reused across multiple verticals, with domain-specific evidence formats defined at the integration layer.
***
### Dispute Flow (High Level)
1. An evaluation request is created.
2. Evidence related to the subject is submitted.
3. Jurors are assigned to the evaluation.
4. Jurors submit numerical ratings.
5. Ratings are aggregated and incentives adjusted.
6. The final evaluation is recorded or executed on-chain.
All steps follow predefined rules enforced by smart contracts.
***
### Guarantees
Rating Evaluation in Justly provides:
* **Robust aggregation**: resistance to outliers through median-based methods.
* **Incentive alignment**: partial slashing discourages manipulation.
* **Flexibility**: applicable across multiple evaluation domains.
* **Deterministic execution**: results enforced or recorded on-chain.
Justly does not define what “quality” means; it enforces how collective judgment is aggregated and incentivized.
#### Reward Calculation
To ensure the system is both fair and resistant to manipulation, Justly utilizes a linear loss function based on distance. Each juror's reward multiplier is determined by comparing their individual rating to the final aggregated result (the median).
The applied formula is:
$$
S\_i = 1 - \left( \frac{|r\_i - \tilde{x}|}{D\_{max}} \right)
$$
Where:
* $S\_i$: Juror’s reward score (between 0 and 1).
* $|r\_i - \tilde{x}|$: The absolute distance between the juror’s rating and the median.
* $D\_{max}$: The maximum possible distance within the scale (e.g., 4 on a 1-5 scale).
**Why this design?**
This incentive mechanism was selected for two fundamental reasons:
1. Fairness for Subjective Judgment:
Unlike binary dispute resolution systems - where a minor deviation can lead to a total loss of stake - this formula recognizes that quality assessment is nuanced. If the majority rates a deliverable as a 4 and you rate it as a 3, the system does not treat you as a malicious actor, but as an evaluator with a slightly different perspective. You receive a partial reward (75% on a 1-5 scale) rather than being severely penalized.
2. Resistance to Collusion and Outliers:
By using the median as the system's anchor, the protocol remains extremely robust. Jurors are economically incentivized to seek the "honest consensus," as moving away from what the majority perceives as reasonable results in a proportional financial loss. This compels jurors to be diligent: the more erratic or extreme their rating is relative to the collective judgment, the lower their profit will be.
***
### Status
**Planned**
Rating Evaluation is part of the core protocol design and will be introduced in a future implementation phase.
# Jurors
Source: https://docs.justly.one/how-it-works/jurors
Jurors are independent human participants responsible for resolving disputes in Justly.
Jurors are independent human participants responsible for resolving disputes in Justly.
They act as neutral decision-makers, evaluating evidence and casting votes according to their honest judgment.\
The protocol is designed so that jurors are economically incentivized to vote coherently and independently.
***
#### Who Can Be a Juror
Any eligible participant who meets the protocol’s requirements may act as a juror.
Jurors:
* can be gated by identity and anti-Sybil mechanisms depending on deployment profile,
* participate anonymously with respect to the disputing parties,
* and must actively opt in to each dispute they join.
Jurors cannot participate in disputes in which they are directly involved.
***
#### Role and Responsibilities
Jurors are responsible for:
* reviewing the evidence submitted by both parties,
* applying their own judgment based on the dispute context,
* and submitting a vote within the defined voting phases.
Jurors do not communicate with each other during the dispute and have no visibility into other jurors’ votes until the process concludes.
***
#### Stakes and Economic Exposure
To participate in a dispute, jurors are required to deposit a stake defined by the selected tier.
This stake:
* represents economic exposure to the outcome,
* aligns juror incentives with honest participation,
* and discourages low-effort or malicious behavior.
Staking defines economic exposure and reinforces honest participation.
***
#### Rewards and Penalties
Jurors who vote coherently with the final outcome are rewarded.
Jurors who vote against the final outcome lose part or all of their stake, depending on the dispute type and tier.
This reward and penalty structure:
* reinforces honest decision-making,
* penalizes random or adversarial voting,
* and ensures long-term incentive alignment within the juror pool.
***
#### Independence and Neutrality
Jurors are selected independently and randomly.
The protocol ensures that:
* disputing parties cannot choose their jurors,
* jurors cannot influence assignment or outcomes,
* and all economic flows are enforced automatically by smart contracts.
Jurors do not have discretionary power beyond their individual vote.
***
#### Jurors in the Ecosystem
Jurors are a core component of the Justly ecosystem.
By participating in disputes, jurors:
* help maintain trust in digital platforms,
* contribute to fair and transparent outcomes,
* and earn rewards by providing honest human judgment.
The protocol is designed to scale the juror pool over time while preserving neutrality, reliability, and economic incentives.
# Dispute Tiers
Source: https://docs.justly.one/how-it-works/tiers/dispute-tiers
Each tier defines the juror panel target, juror stake levels, and dispute-side funding amounts exposed to integrators.
Each tier defines a dispute profile with a specific balance of **security level**, **economic cost**, and **resolution speed**.
| Tier | Jurors | Stake per Juror | Stake per Party (Claimer / Defender) | Fixed Fee\* | Security Level |
| ---------- | -------- | --------------- | ------------------------------------ | ----------- | -------------- |
| **Tier 1** | 3 jurors | 1 USD | 4 USD | 3 USD | Low |
| **Tier 2** | 5 jurors | 5 USD | 10 USD | 5 USD | Medium |
| **Tier 3** | 7 jurors | 10 USD | 17 USD | 7 USD | High |
| **Tier 4** | 9 jurors | 20 USD | 29 USD | 9 USD | Very High |
\* **Fixed Fee:** a fixed amount distributed among jurors who vote coherently. This fee is taken from the stake deposited by the parties involved in the dispute.
***
#### Important notes
* All values are expressed in USD, or equivalent stablecoins.
* Both sides of the dispute must be fully funded before the dispute activates.
* Tier values are the public-facing profiles exposed to platforms and integrators.
* Internal protocol configuration may still map these tiers to court or category settings while preserving the same economics.
* Higher tiers increase the cost of attacks, the diversity of judgment, and the overall robustness of the outcome.
* Selecting a tier allows a platform to choose a security level proportional to the value or complexity of the dispute.
# What is a Tier
Source: https://docs.justly.one/how-it-works/tiers/what-is-a-tier
A tier is the public-facing dispute profile that packages juror stakes, arbitration fees, and panel size for platforms integrating Justly.
A **tier** is the public-facing dispute profile for a Justly case. It defines the **security level, cost, and robustness** of a dispute.
It packages the main values a platform or integrator cares about, such as:
* how many jurors are targeted,
* how much jurors stake,
* and the arbitration fee amounts required for each side of the dispute.
Tiers allow the protocol to adapt to different types of conflicts by balancing:
* resolution speed,
* required level of trust,
* and the economic risk assumed by the parties and jurors.
Each dispute is executed within a specific tier, and all rules of the resolution process are determined by that tier.
***
### What changes between tiers
#### 1. Number of jurors
Each tier defines how many human jurors are targeted for a dispute.
* Lower tiers use fewer jurors, enabling faster and lower-cost resolutions.
* Higher tiers use more jurors, increasing diversity of judgment and reducing the likelihood of biased outcomes.
A higher number of jurors increases the robustness of the result against individual errors or adversarial behavior.
***
#### 2. Stakes and fees
Tiers establish the economic values for:
* juror stakes,
* the claimer-side funding requirement,
* and the defender-side funding requirement.
Each side must be fully funded before the dispute activates.
Higher values:
* increase the cost of malicious behavior,
* raise the economic commitment of participants,
* and better align incentives when the value or complexity of the dispute is higher.
***
#### 3. Security level
The security level of a dispute increases as the tier becomes higher.
This is driven by the combination of:
* a larger number of jurors,
* higher economic stakes,
* and a greater total cost required to manipulate the outcome.
Together, these factors make higher tiers more suitable for:
* higher-value disputes,
* more complex cases,
* or situations where an additional level of confidence is required.
***
### Tier system design
Tiers do not exist to segment users, but to **offer security options proportional to the risk of a given conflict**.
For integrators, tiers are the main abstraction exposed through the SDK or API.
* tiers are **fixed and predefined by the protocol**,
* all disputes within the same tier follow exactly the same rules,
* and outcomes are executed automatically and verifiably on-chain.
This design ensures predictable behavior for both individual users and platforms integrating Justly.
# Which tier should I choose?
Source: https://docs.justly.one/how-it-works/tiers/which-tier-should-i-choose
Tier 1 Suitable for low value or simple disputes where speed and cost efficiency are the main priorities. Tier 2 Recommended for standard disputes invo
* **Tier 1**\
Suitable for low-value or simple disputes where speed and cost efficiency are the main priorities.
* **Tier 2**\
Recommended for standard disputes involving moderate value or complexity.
* **Tier 3**\
Designed for higher-value disputes or cases where stronger guarantees and broader juror consensus are required.
* **Tier 4**\
Best suited for complex or high-stakes disputes where maximum robustness and security are needed.
# Voting and Incentives
Source: https://docs.justly.one/how-it-works/voting-and-incentives
Justly uses commit-reveal voting and tier-defined incentives to align honest human judgment with economic outcomes.
This section describes how voting and economic incentives operate in practice within Justly.\
For the theoretical rationale behind these mechanisms, see Security & Game Theory.
Justly uses an incentive-driven voting system designed to align honest human judgment with economic outcomes.
The protocol does not attempt to determine truth algorithmically.\
Instead, it relies on structured human voting combined with economic incentives to converge toward fair and reliable decisions.
***
#### Independent juror participation
Jurors participate independently in each dispute and are evaluated economically on outcome coherence.
Staking aligns incentives by creating meaningful upside for coherent decisions and downside for incoherent behavior.
***
#### Commit-reveal voting
Justly uses a **commit-reveal** voting scheme to protect the integrity of the voting process.
The process is divided into two phases:
* **Commit phase**:\
Selected jurors submit a cryptographic commitment to their vote without revealing its value.
* **Reveal phase**:\
Jurors reveal the vote associated with their commitment.
This mechanism:
* prevents vote copying or coordination,
* encourages independent decision-making,
* and protects jurors from external pressure.
The protocol enforces this process uniformly across disputes.
Shutter-based reveal automation is planned to make the reveal step feel closer to a single-step flow while preserving the same architecture.
***
#### Finalization rule
The dispute finalizes when either:
* all effective votes have been revealed, or
* the voting deadline passes.
If no effective vote exists, the defender is the default outcome.
***
#### Coherent voting
After the valid reveals are counted, the protocol determines the final outcome based on the jurors' votes.
Jurors are considered to have voted **coherently** if their vote aligns with the final outcome.
Coherence is evaluated against the collective result of the dispute, not against an external notion of correctness.
***
#### Rewards
Jurors who vote coherently are rewarded.
Rewards are sourced from:
* predefined dispute fees,
* and penalties applied to incoherent participation.
Rewards are distributed automatically and proportionally according to protocol rules.
***
#### Penalties
Jurors who vote incoherently are penalized.
Penalties may include:
* partial or total loss of the juror's stake,
* depending on the tier and dispute configuration.
Non-participation after selection is treated as incoherence.
This mechanism discourages:
* random voting,
* low-effort participation,
* and strategic manipulation.
***
#### Incentive alignment
The voting and incentive system is designed so that:
* honest voting maximizes expected returns,
* dishonest or careless voting increases economic risk,
* and long-term participation favors consistent, coherent behavior.
Over time, this creates a juror pool that is economically aligned with fair and reliable dispute resolution.
***
#### Automatic enforcement
All rewards, penalties, and fund transfers are enforced automatically by smart contracts.
The protocol does not rely on discretionary intervention, manual arbitration, or centralized control to execute outcomes.
This ensures:
* predictability,
* transparency,
* and neutrality across all disputes.
> Once finalized, outcomes cannot be altered or overridden.
# Introduction to Justly
Source: https://docs.justly.one/index
Justly is a dispute resolution layer built for digital businesses.
Justly is a dispute resolution layer built for digital businesses.
As platforms grow, payments accelerate, and users become global, one challenge inevitably appears: **disputes**.
Marketplace orders go wrong.\
Freelance work is contested.\
Services don’t meet expectations.\
Digital agreements break.
Handling these conflicts internally is **expensive, slow, and risky**.
Support teams don’t scale.\
Manual reviews introduce bias.\
And platforms are forced to act as judge in disputes they didn’t create.
***
### Why Justly Exists
Justly exists to remove that burden.
Instead of building custom dispute processes from scratch, platforms can integrate Justly as a **neutral resolution layer**, handling conflicts externally, fairly, and consistently.
***
### Value for Businesses
Justly helps businesses:
* Resolve disputes without internal arbitration
* Reduce operational and legal overhead
* Improve trust between users
* Scale globally without turning disputes into a bottleneck
***
### Value for Users
For users, Justly creates a system where:
* Disputes are reviewed by independent participants
* Evidence matters more than influence
* Outcomes follow transparent rules rather than opaque policies
***
### Built for Both Sides
Justly is designed to serve both sides naturally.
Platforms integrate it to protect their ecosystem.\
Users engage with it knowing that fairness and accountability are part of the process.
Behind the scenes, Justly relies on **economic incentives and carefully designed coordination mechanisms**. Participants are rewarded for honest decisions, discouraged from bad behavior, and selected independently — ensuring the system remains reliable over time without requiring trust in a single authority.
***
#### Scope at a Conceptual Level
Justly is designed to resolve adversarial disputes arising from digital agreements and payments, where:
* There are clear parties in conflict.
* Value is at stake.
* Outcomes must be enforced automatically.
Resolution, Not Mediation Justly focuses on definitive resolution, not mediation. It is not a general-purpose legal system, a customer support replacement, or a broad governance framework. Its goal is to provide a neutral, enforceable decision layer for digital economies — independent from platforms, jurisdictions, or internal policies.
Transactional Focus & Scale Unlike universal arbitration models, Justly is optimized for high-velocity digital transactions. It focuses on micro to mid-sized disputes where technical efficiency is paramount. It is not intended for:
* High-stakes litigation: Cases of massive financial scale that require traditional legal discovery.
* Complex Human Rights or Ethics: Subjective social or political debates that fall outside the scope of transactional evidence.
The Foundational Model Different dispute types, escalation paths, and specialization layers can be built on top of this core, but all follow the same foundational model: Human Judgment + Economic Incentives + Cryptographic Enforcement.
***
### What This Documentation Covers
This documentation will help you understand:
* When and why Justly makes sense for your product
* How it fits into different business models
* How it can be integrated into existing platforms
* How disputes are handled in a clear, predictable way
***
### Who Justly Is For
If you are building a marketplace, a fintech product, a service platform, or any digital system where agreements and payments matter, Justly is designed to make dispute resolution **simple, fair, and scalable** — without adding friction to your core business.
# AI optimized docs
Source: https://docs.justly.one/overview/ai-optimized-docs
Justly documentation isn’t just written for humans. It’s structured for agents, copilots, and AI models to understand, remix, and build on top of.
Justly documentation isn’t just written for humans. It’s **structured for agents, copilots, and AI models** to understand, remix, and build on top of.
***
Every page in our documentation is written for both:
* **Humans** who want clarity, precision, and examples.
* **Machines** that need structure, consistency, and semantics.
***
**Why It Matters**
The next generation of builders won’t just code — they’ll **prompt**. Trustless Work is optimized for that. Our docs follow an **AI-ready format**, meaning you can:
* Export any page in **Markdown or PDF** for training datasets.
* Feed it directly into your **custom copilot or LLM memory**.
* Let your AI agents read the docs, **reason through flows**, and even **execute API calls** using your keys and roles.
> 🧠 Our goal: make the documentation itself a building block for automation.
**Export & Train**
You can export any section of this documentation into:
* \
**PDF** – for reference and onboarding manuals
* **Markdown (.md)** – for AI ingestion or context injection
* **Prompt blocks** – pre-formatted snippets that can be pasted into GPT, Cursor, or v0.dev
> 💡 Use the SDK subpage under VibeCoding to see live examples of AI prompts generating, debugging, and deploying escrow flows automatically.
***
**Ask the Docs**
The docs themselves are **AI-trained and search-optimized**. That means the search bar understands **natural language and intent** — not just keywords.
Try prompts like:
```
create a dispute flow for a peer-to-peer USDC payment
explain how jurors are selected in a Justly dispute
open a dispute for a wallet payment and submit evidence
```
> The system will reformat your question into a structured query, returning optimized snippets, SDK calls, or workflow examples.
# Dispute Resolution Matters
Source: https://docs.justly.one/overview/dispute-resolution-matters
Trust is not built on the absence of conflict. It is built on knowing what happens when conflict appears .
Trust is not built on the absence of conflict.\
It is built on knowing what happens **when conflict appears**.
In any system where value moves between people—money, work, services, or digital assets—disagreements are inevitable. What defines the quality of that system is not whether disputes exist, but **how they are resolved**.
When there is no clear, fair, and reliable way to handle disputes, trust slowly erodes.
***
### Conflict Is a Feature, Not a Bug
Marketplaces, freelance platforms, payment systems, and on-chain protocols all rely on cooperation between parties that do not know each other.
Sooner or later, questions arise:
* Was the service delivered as agreed?
* Did the work meet expectations?
* Were the rules followed?
* Who should receive the funds?
Ignoring these questions does not make them disappear.\
It only pushes the problem to the edges of the system, where decisions become arbitrary and opaque.
***
### Centralized Resolution Doesn’t Scale Trust
Most digital platforms handle disputes internally:\
support teams, moderators, private policies, manual reviews.
This creates a structural conflict:
* the platform acts as both **judge and interested party**,
* decisions are hard to audit,
* users have little visibility or recourse.
As platforms grow, this model becomes:
* slower,
* more expensive,
* inconsistent,
* and increasingly distrusted.
Users respond by pricing in risk, reducing participation, or leaving altogether.
***
### Without Resolution, Escrow Loses Meaning
Escrow systems are designed to protect both sides of a transaction.\
But without a credible way to decide *who is right* in a dispute, escrow becomes a deadlock.
Funds remain locked.\
Decisions are delayed or politicized.\
The original promise of trustless coordination breaks down.
Dispute resolution is not an add-on to escrow.\
It is what makes escrow work.
***
### The Hidden Cost of Broken Trust
When trust breaks:
* platforms absorb growing support costs,
* honest users subsidize bad actors,
* markets become less efficient,
* innovation slows down.
At scale, the absence of fair dispute resolution forces systems to choose between speed and fairness—often sacrificing both.
***
### Justly’s Perspective
Justly is built on a simple idea:\
**trust emerges when outcomes are predictable, fair, and verifiable.**
By providing a neutral, transparent, and fast dispute resolution layer, Justly allows digital systems to:
* handle conflict without central authority,
* scale transactions without increasing friction,
* and restore confidence where it matters most—at the moment of disagreement.
Trust doesn’t break because people disagree.\
It breaks when there is no reliable way to resolve that disagreement.
# Live Demo: Juror Experience
Source: https://docs.justly.one/overview/live-demo-juror-experience
This page walks through a real dispute resolved on Justly, using the mobile app and real wallets. The goal is simple: show how dispute resolution works in
This page walks through a real dispute resolved on Justly, using the mobile app and real wallets. The goal is simple: show how dispute resolution works in practice, from a juror’s point of view.
### This is a real dispute resolved on Justly, step by step, from a juror’s perspective
The demo was recorded on mainnet.\
To keep it safe and accessible, the amounts used are small, but the mechanics are exactly the same as in real-world disputes.
#### **The dispute**
The dispute shown in the video is **Dispute #9**, titled:
**“Freelance Work Not Paid”**
Two parties are involved:
* **Julio Banegas** (claimant), who states that freelance work was completed but not paid.
* **Micaela Descotte** (defendant), who disputes the claim.
Both sides submitted evidence directly through Justly.\
As a juror, you see the same information any independent reviewer would see: descriptions, attachments, and context.
***
#### **Jurors joining the dispute**
In this demo, the same person participates as a juror using **three different wallets**, each one connected through a separate MetaMask account.
This is done only for demonstration purposes, to clearly show how majority and minority outcomes work.
For each wallet:
1. The juror opts in to the dispute.
2. A small amount of USDC is staked to participate.
3. The dispute appears in the juror’s **current portfolio**, indicating active participation.
At this stage, the juror has skin in the game.
***
#### **Voting phase**
Each wallet votes independently, based only on the evidence presented.
* Wallet #1 votes in favor of **Julio Banegas**
* Wallet #2 votes in favor of **Micaela Descotte**
* Wallet #3 also votes in favor of **Micaela Descotte**
There is no coordination between wallets.\
Each vote is a standalone decision.
After voting, the dispute moves to the juror’s **Inbox**, labeled **“Reveal now”**, indicating that the commit phase has ended and the votes can be revealed.
***
#### **Reveal and outcome**
Once all votes are revealed:
* The system determines the majority decision.
* Jurors who voted with the majority are marked as **winning jurors**.
* Jurors who voted against the majority are marked as **losing jurors**.
In this case:
* The two wallets that voted for **Micaela Descotte** are in the majority.
* The wallet that voted for **Julio Banegas** is in the minority.
***
#### **Rewards and penalties**
After the dispute is resolved:
* Winning jurors receive a **“Rewards pending”** notification.
* They can claim their rewards directly from the app.
* The juror in the minority does not receive a reward.
This mechanism is intentional.
Justly does not reward being loud or early —\
it rewards being **right, relative to the collective judgment**.
***
#### **Why this matters**
This demo highlights the core principles behind Justly:
* Jurors are real participants, not automated rules.
* Decisions are driven by evidence, not authority.
* Economic incentives align behavior without requiring trust.
* Outcomes are enforced automatically.
For platforms, this means disputes can be resolved without internal arbitration.\
For users, it means fairness is not just promised — it is enforced by design.
# What is Justly?
Source: https://docs.justly.one/overview/what-is-justly
Justly is a decentralized, on-demand arbitration protocol for digital platforms that need fast, transparent, and enforceable dispute resolution.
Justly is a **decentralized, on-demand arbitration protocol** designed for digital platforms that need a fast, impartial, and transparent way to resolve disputes.
Unlike traditional systems, which are slow, manual, and centralized, Justly resolves conflicts in **hours** or less through distributed jurors, clear economic incentives, and automatic enforcement of outcomes.
Justly can be integrated into marketplaces, fintechs, wallets, exchanges, service platforms, and Web3 applications without forcing those platforms to act as judge and jury.
***
### A new way to resolve digital disputes
In Justly, every dispute follows a simple and predictable flow:
1. **A dispute is created** between a claimer and a defender.
2. **Both sides are fully funded** before adjudication starts.
3. **Evidence is submitted during a bounded evidence window**.
4. **Jurors review the record and vote** through a commit-reveal flow.
5. **The ruling is finalized automatically** and can be consumed by the integrating platform.
The entire process is designed to minimize friction, remove intermediaries, and provide a clear experience for both end users and platforms.
***
### Real-time resolution, not endless processes
Justly is designed for a **real-time-like resolution model**:
* disputes are intended to resolve quickly,
* deadlines keep progression bounded,
* evidence is frozen before voting starts,
* and finality does not depend on callback success.
This makes Justly viable even for **microtransactions**, where legal systems or traditional customer support processes are economically unfeasible.
***
### Distributed jurors and aligned incentives
Decisions in Justly do not depend on a company, moderator, or centralized authority.
Jurors:
* are selected from the protocol's juror pool,
* participate by staking stablecoins such as USDC,
* earn rewards for coherent participation,
* and are penalized for incoherence or non-participation.
This design incentivizes honest behavior and reduces malicious actions without requiring prior trust between the parties.
***
### Designed for real users
Justly is not built only for blockchain experts.
The system prioritizes:
* **simple, understandable UX**,
* fast onboarding with minimal crypto friction,
* clear interfaces for submitting evidence and understanding verdicts,
* and integration patterns that platforms can expose through APIs or SDKs.
The goal is for any user of a digital platform to use Justly without needing to understand smart contracts.
***
### A protocol, not a closed platform
Justly does not compete with existing platforms. It **empowers them**.
It acts as a neutral dispute resolution layer that can:
* be integrated via SDKs or APIs,
* resolve conflicts tied to online or on-chain value transfer,
* execute decisions programmatically,
* and maintain public traceability and transparency.
In this way, Justly positions itself as infrastructure for the digital economy, where trust is enforced by clear, verifiable rules rather than intermediaries.
***
### In summary
Justly is a lightweight digital justice system that resolves disputes in a way that is:
* ⚡ Fast (typically hours, sometimes minutes)
* ⚖️ Impartial (distributed jurors)
* 🔍 Transparent (verifiable rules and execution)
* 🌍 Global (built for digital payments and stablecoins)
It represents a new approach to resolving online disputes at the speed and scale of the modern digital economy.
> **While Justly is primarily designed for real-time dispute resolution, its incentive and coordination model can be extended to other forms of subjective evaluation—such as contribution assessment and reward allocation in open-source and digital ecosystems.**
# Why Justly?
Source: https://docs.justly.one/overview/why-justly
Digital economies move fast, but dispute resolution has not kept up.
**Digital economies move fast, but dispute resolution has not kept up.**
Most platforms today rely on centralized, opaque, and expensive processes to resolve conflicts. This creates friction, erodes trust, and does not scale, especially for low and mid-value disputes where traditional legal systems are impractical.
**Justly exists to fix that.**
### A neutral layer for digital disputes
Justly is designed as a **neutral, programmable dispute resolution layer** that can be embedded into any digital platform where value is exchanged.
Instead of acting as judge and jury, platforms can delegate dispute resolution to an independent system that is:
* transparent,
* auditable,
* fast,
* and economically aligned through incentives.
### Built for stablecoins and real-world payments
Justly is optimized for **stablecoin-based economies**, where users expect:
* predictable outcomes,
* fast resolutions,
* and minimal volatility.
By using assets like USDC, Justly enables dispute resolution that feels familiar to users while remaining fully on-chain and automated.
### Human judgment, cryptographic guarantees
Not all disputes can be solved by code alone.
Justly introduces **human judgment where it matters**, but enforces outcomes with smart contracts. Jurors are economically incentivized to act honestly, and rulings are finalized automatically without intermediaries.
This creates a system that combines:
* game theory,
* cryptographic enforcement,
* and social consensus.
### Infrastructure, not a vertical product
Justly is not built for a single use case.
It is **infrastructure**:
* reusable across industries,
* adaptable to different dispute profiles through tiers,
* and composable with existing systems.
Marketplaces, fintechs, Web3 protocols, and insurance platforms can all plug into the same dispute resolution core.
### Focused scope today
The current version of Justly is focused on adversarial disputes.
Additional coordination use cases may be explored in later versions, but the live protocol is centered on dispute resolution.
# Current Implementation
Source: https://docs.justly.one/protocol/current-implementation
This page describes what is live in Justly today and how it differs from features planned for later versions.
This page describes the current live implementation.
Other pages may describe later-version features, but this page is the reference for what is live today.
#### Scope
The current implementation focuses on validating the core mechanics of Justly:
* Human juries
* Commit-reveal voting
* Tier-based dispute configuration
* Automated on-chain finalization
* Fast and bounded dispute resolution for online conflicts
All features outside this scope are intentionally excluded from the current version and will be introduced in later versions.
***
#### Supported Dispute Type
**Public adversarial dispute**
The live version supports **public adversarial disputes** between two parties:
* **Claimer**: the party initiating the dispute
* **Defender**: the counterparty
Both parties:
* submit evidence,
* must have their side of the dispute fully funded,
* and accept the outcome enforced by the protocol.
Those required amounts may be paid by the parties themselves or by a sponsor or platform on their behalf.
The dispute is resolved by a group of anonymous human jurors.
***
#### Dispute lifecycle
Each dispute follows a deterministic on-chain lifecycle:
1. **`Created`**\
The dispute is created with the parties, tier, and timing parameters.
2. **`Evidence`**\
Once both sides are fully funded, evidence submission opens.
3. **`Commit`**\
Evidence is frozen, juror assignment starts, and selected jurors submit commitments.
4. **`Reveal`**\
Jurors reveal committed votes.
5. **`Finished`**\
The ruling is finalized, incentives are settled, and an optional callback may be attempted.
Current implementation: once finalized, the outcome is final.
Later version: appeals add escalation rounds as a first-class escalation mechanism.
***
#### Jurors
* Jurors are human participants selected through protocol-defined assignment.
* Identity and anti-Sybil layers are part of the broader roadmap.
* Jurors are pseudonymous to disputing parties.
* Jurors must stake funds to participate.
* Stake size influences selection economics, but rulings are not stake-weighted.
***
#### Liveness and assignment
Justly is designed to keep disputes moving toward finalization even when juror participation is imperfect.
This means:
* juror assignment begins when `Commit` starts,
* the dispute can proceed with fewer selected jurors than the target panel,
* and finalization remains bounded by the voting deadlines.
Selection details may evolve over time, but these liveness guarantees remain part of the architecture.
***
#### Voting and security
* Voting is executed **fully on-chain**.
* A **commit-reveal scheme** is used to prevent vote manipulation.
* Shutter-based reveal automation is planned to improve juror UX while preserving the same protocol flow.
* All state transitions and outcomes are verifiable on-chain.
***
#### Tiers
Tiers are the public-facing dispute profiles exposed to platforms and integrators.
They package the main economic and procedural values a platform cares about, such as juror stake amounts and arbitration fees.
Each tier defines:
* number of jurors,
* juror stake requirements,
* party-side funding requirements,
* and arbitration fee levels.
Internally, live deployments may still map tiers to court or category configuration.
For integrators, tiers remain the simpler abstraction.
***
#### Economics
* Both sides of the dispute must be fully funded before activation.
* Jurors stake funds to vote.
* Jurors who vote coherently are rewarded.
* Jurors who vote incoherently, or fail to complete participation, are penalized according to protocol rules.
* Tier parameters define the main fee and stake values exposed to integrators.
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
* Rating or decision-based disputes
* Automatic reveal via Shutter API integration
These features are planned for later versions.
The live version today is focused on adversarial disputes with a single finalized round.
***
#### Design philosophy
The current implementation prioritizes:
* correctness over completeness,
* reliability,
* and enforceable outcomes over subjective mediation.
This approach allows Justly to validate its core assumptions while preserving a clear path toward later-version features.
# Implementing Justly in Web3 smart contracts
Source: https://docs.justly.one/protocol/implementing-justly-web3-smart-contracts
Integrate Justly as an arbitrator by wiring dispute creation, funding, evidence submission, and ruling consumption through callback or direct reads.
This guide explains how your protocol can integrate Justly directly from smart contracts using the arbitrable-arbitrator model.
Your contract keeps custody of the principal assets. Justly resolves the dispute and returns a ruling. Your contract enforces the final state change.
***
#### Integration model
Use a push model:
* your arbitrable contract owns escrowed funds, locked positions, or claimable balances,
* your contract opens a dispute in Justly when an edge case appears,
* Justly runs the dispute lifecycle and finalizes a ruling,
* and your contract consumes that ruling through callback handling or direct reads.
This keeps your core protocol logic in your contract while outsourcing dispute judgment to Justly.
***
#### Minimal interfaces
Define and depend on interfaces, not concrete implementations, so your integration remains stable if internal protocol contracts evolve.
```solidity theme={null}
interface IArbitrable {
function rule(uint256 disputeId, uint256 ruling) external;
}
interface IJustly {
struct CreateDisputeParams {
address claimer;
address defender;
string category;
string ipfsHash;
uint256 jurorsRequired;
uint256 paySeconds;
uint256 evidenceSeconds;
uint256 commitSeconds;
uint256 revealSeconds;
}
function createDispute(CreateDisputeParams calldata params) external returns (uint256);
function payDispute(uint256 disputeId) external;
function submitEvidence(uint256 disputeId, string calldata ipfsHash) external;
function getDisputeCost(uint256 disputeId) external view returns (uint256);
}
```
Treat this as the minimum surface your protocol needs for dispute integration.
***
#### End-to-end flow
1. **Open dispute from your contract**\
Create a protocol case, lock relevant assets, then call `createDispute(...)`.
2. **Fund dispute**\
Both sides of the dispute must be covered before activation. The parties can fund their own side, and a platform or sponsor can cover one or both sides when your product model requires it.
3. **Submit evidence**\
Parties submit evidence references through `submitEvidence(disputeId, ipfsHash)` during the evidence window.
4. **Wait for ruling**\
Justly handles evidence freeze, voting, reveal, and settlement internally.
5. **Consume the ruling**\
Your integration can receive a callback through `rule(disputeId, ruling)` or read the final ruling directly.
***
#### Ruling semantics
At the integration layer, treat the ruling as binary:
* `0`: defender wins
* `1`: claimer wins
If no effective vote exists at finalization, the defender is the default outcome.
Your contract should map this result to protocol actions, such as:
* release escrow to one side,
* split according to predefined terms,
* or cancel and refund.
Keep this mapping explicit in your state machine.
***
#### Callback and direct reads
Callback is optional from the perspective of finality.
That means:
* a successful callback can notify your contract immediately,
* a direct read can be used as a fallback or primary integration mode,
* and callback failure does not invalidate the ruling.
Your integration should account for this separation between dispute finality and external settlement handling.
***
#### Evidence strategy
Store only compact references on-chain.
Recommended approach:
* put the root case file in `createDispute(..., ipfsHash, ...)`,
* append additional evidence during the evidence window with `submitEvidence(...)`,
* keep your own case metadata keyed by `disputeId` in your contract or indexer.
This gives you low gas overhead and an auditable evidence timeline.
***
#### Security and implementation checklist
* Restrict `rule(...)` so only the Justly arbitrator address can call it.
* Make ruling execution idempotent. A dispute should not settle twice.
* Track `protocolCaseId -> disputeId` and `disputeId -> protocolCaseId` mappings.
* Lock disputed assets before opening a dispute.
* Validate party roles before forwarding calls to `payDispute(...)` and `submitEvidence(...)`.
* Emit protocol-level events for dispute opened, funded, evidence submitted, and ruling applied.
***
#### Practical integration pattern
A production integration usually keeps three layers:
* **Protocol contract**: escrow and final enforcement.
* **Arbitration adapter**: thin wrapper that talks to Justly interfaces.
* **Indexer/back end**: evidence UX, timeline, notifications, and analytics.
This separation keeps your on-chain core small while preserving a full product experience.
***
#### What to version-pin
To protect your integration from contract changes:
* pin the deployed arbitrator address per chain,
* pin the ABI version your adapter uses,
* keep interfaces in your repo and upgrade through explicit release steps.
This lets you evolve safely while preserving deterministic enforcement for users.
# Legal & Compliance Considerations
Source: https://docs.justly.one/protocol/legal-compliance-considerations
Justly is a neutral dispute resolution infrastructure designed to facilitate human judgment and on chain execution. It is not a court, not a legal arbitra
Justly is a neutral dispute resolution infrastructure designed to facilitate human judgment and on-chain execution.\
It is not a court, not a legal arbitrator, and does not provide legal advice.
***
### 1. Role of the Protocol
Justly:
* provides tools for human dispute resolution,
* enforces outcomes programmatically,
* and operates as neutral infrastructure.
Justly does not:
* interpret laws,
* determine legal liability,
* or replace legal systems.
***
### 2. Arbitration vs. Legal Proceedings
Disputes resolved through Justly:
* are not court rulings,
* do not constitute legal judgments,
* and do not replace formal arbitration unless explicitly agreed by the parties.
Justly enables **contractual dispute resolution**, not statutory enforcement.
***
### 3. Jurisdiction and Governing Rules
Justly operates as a decentralized protocol.
Disputes are governed by **protocol-defined rules and smart contract logic**, which act as the primary source of authority for resolution and execution.
Unless an integrating platform explicitly specifies additional legal terms at the application layer, the protocol itself does not define or enforce jurisdictional law.
***
### 4. Jurors and Responsibility
Jurors:
* act as independent participants,
* express personal judgment based on provided evidence,
* and are not agents, employees, or representatives of Justly.
Justly does not endorse, validate, or assume responsibility for individual juror decisions.
***
### 5. Compliance and Integrations
Compliance requirements:
* depend on the integrating platform,
* the applicable jurisdiction,
* and the nature of the underlying transaction.
Justly is designed to integrate with:
* identity and verification solutions,
* KYC/AML providers,
* and compliance frameworks,
when required by integrators or ecosystem rules.
***
### 6. Regulatory Scope
Justly does not:
* custody user funds beyond protocol execution,
* provide financial or legal advice,
* or operate as a regulated financial intermediary.
Responsibility for regulatory compliance remains with:
* platforms integrating Justly,
* or users deploying it in regulated environments.
***
### 7. User Responsibility and “As-Is” Disclaimer
Justly is provided on an **“as-is”** basis.
Outcomes result from:
* independent human judgment,
* and protocol-defined rules executed automatically.
Users and integrators are responsible for:
* assessing whether Justly is appropriate for their use case,
* understanding the economic and operational risks involved,
* and determining how dispute outcomes should be interpreted within their own legal or business context.
***
### 8. Transparency and Auditability
All dispute rules and outcomes are:
* defined upfront,
* enforced by smart contracts,
* and publicly verifiable on-chain.
This transparency supports:
* auditability,
* accountability,
* and regulatory review where applicable.
# Protocol Guarantees
Source: https://docs.justly.one/protocol/protocol-guarantees
Justly is designed to provide enforceable, predictable outcomes in environments where trust breaks down.
Justly is designed to provide enforceable, predictable outcomes in environments where trust breaks down.
Regardless of the dispute type or implementation phase, Justly guarantees:
**1. Neutrality**
* Justly does not interpret evidence.
* Justly does not influence jurors.
* Outcomes are determined exclusively by independent human judgment.
**2. Incentive Alignment**
* Jurors are economically incentivized to act coherently.
* Malicious or incoherent behavior is penalized by design.
* No participant has privileged influence over outcomes.
**3. Deterministic Execution**
* Once a dispute is resolved, outcomes are enforced automatically.
* Funds and actions are executed on-chain.
* No off-chain authority can override results.
**4. Liveness**
* Disputes are designed to reach resolution.
* The protocol prioritizes completion over indefinite stalling.
* No funds can remain locked indefinitely by design.
**5. Transparency and Auditability**
* All dispute rules are defined upfront.
* Outcomes are verifiable.
* Execution is deterministic and inspectable.
# Security & Game Theory
Source: https://docs.justly.one/protocol/security-game-theory
Justly is secure not because it trusts people, but because it aligns incentives .
Justly is secure not because it trusts people, but because it **aligns incentives**.
Instead of relying on centralized authorities, internal support teams, or subjective moderation, Justly uses **game theory** to make honest behavior the most economically rational strategy for all participants.
This is the same principle that powers:
* financial markets,
* prediction markets like Polymarket,
* decentralized arbitration systems like Kleros.
In all these systems, **truth emerges not from goodwill, but from incentives**.
***
### Trust doesn’t scale. Incentives do.
Traditional dispute resolution systems rely on trust:
* trust in companies,
* trust in moderators,
* trust in internal processes.
This model breaks down at scale.
As platforms grow:
* disputes increase,
* operational costs explode,
* decisions become inconsistent,
* users lose trust.
Justly replaces trust in institutions with **trust in economic incentives**.
***
### How Justly uses game theory
Justly is designed so that **dishonest behavior is economically irrational**.
Jurors are not expected to be altruistic.\
They are expected to be rational.
The system rewards jurors who vote coherently with reality and penalizes those who don’t.
#### The core mechanism
1. A dispute is opened.
2. Jurors are randomly selected from a large pool.
3. Each juror stakes value (e.g. USDC) to participate.
4. Jurors independently evaluate the evidence.
5. Jurors submit a vote.
6. The majority decision becomes the verdict.
7. Jurors who voted with the majority are rewarded.
8. Jurors who voted against the majority lose part of their stake.
The result is simple:
> **The most profitable strategy is to vote honestly.**
***
### Why jurors don’t vote randomly or maliciously
From an economic perspective:
* Voting randomly → expected loss.
* Voting maliciously → expected loss.
* Trying to manipulate outcomes → expensive and risky.
* Voting honestly → maximizes expected return.
Collusion is difficult because:
* juror selection is random,
* pools are large,
* coordination costs are high,
* the cost of manipulation often exceeds the dispute value.
At scale, **honesty becomes the dominant strategy**.
***
### Justly works like a market for truth
Justly follows the same logic used by prediction markets such as **Polymarket**.
Polymarket does not verify outcomes manually.\
It relies on participants risking capital on what they believe is correct.
Those who align with reality earn.\
Those who don’t, lose.
Over time, the system converges toward accurate outcomes because **being wrong is costly**.
Justly applies this logic to dispute resolution.
Instead of betting on future events, jurors stake value on:
* what is fair,
* what is correct,
* what best matches the evidence.
This turns dispute resolution into a **market-driven process for discovering truth**.
***
### Why this is safe for companies
From a company’s perspective, Justly provides strong security guarantees:
#### Incentive-aligned decisions
No internal bias. No “judge and party” problem.\
Jurors are economically motivated to decide fairly.
#### Predictable outcomes
Jurors behave rationally under clear incentives, producing consistent results over time.
#### Economic attack resistance
Manipulating outcomes is costly and irrational unless the attacker is willing to lose more than they gain.
#### Auditability and transparency
All decisions, votes, and outcomes are verifiable and traceable.
#### Operational scalability
Dispute resolution scales without growing internal support or arbitration teams.
***
### What Justly does *not* promise
Justly does not claim to:
* eliminate disputes,
* guarantee perfect decisions,
* remove all bad actors.
Instead, Justly guarantees that:
* dishonest behavior is penalized,
* honest behavior is rewarded,
* and the system converges toward fair outcomes over time.
This is the same guarantee provided by markets, insurance systems, and decentralized arbitration.
***
### The key idea
> **Justly is secure for the same reason markets are reliable: incentives beat trust.**
By aligning economic incentives with honest decision-making, Justly enables fast, scalable, and fair dispute resolution — without relying on centralized authority.
***
### Why this matters
As digital platforms scale globally, disputes become inevitable.
Justly doesn’t try to prevent conflict.\
It ensures that conflict **doesn’t break the system**.
By embedding game-theoretic security at the core, Justly becomes a reliable foundation for payments, platforms, governance, and coordination in the digital economy.
# Security Model
Source: https://docs.justly.one/protocol/security-model
Justly is designed as a cryptoeconomic dispute resolution protocol , where security emerges from incentive alignment, economic cost, and transparent execut
Justly is designed as a **cryptoeconomic dispute resolution protocol**, where security emerges from incentive alignment, economic cost, and transparent execution — not from authority or legal enforcement.
This section describes the **security assumptions, guarantees, and limits** of the protocol.
***
### Security Philosophy
Justly does not attempt to determine absolute truth or legal correctness.
Instead, it is designed to ensure that:
* dishonest behavior is economically costly,
* coordinated manipulation is difficult and expensive,
* and honest participation is the most rational strategy over time.
Security in Justly is achieved through **game theory, staking mechanics, and protocol-enforced execution**, not through trust in any centralized actor.
***
### Threats Justly Is Designed to Mitigate
Justly is explicitly designed to mitigate the following classes of attacks:
#### Sybil Attacks
Mitigated through:
* economic staking requirements,
* proof-of-humanity and identity primitives (where enabled),
* and cost proportional to participation.
Creating many identities does not grant proportional influence, only proportional risk.
***
#### Vote Manipulation and Collusion
Mitigated through:
* random juror selection,
* commit–reveal voting,
* incoherent vote slashing,
* and tier-based security escalation.
Collusion requires sustained coordination across multiple rounds and jurors, increasing economic exposure.
***
#### Bribery and Coercion
Mitigated through:
* juror anonymity,
* delayed vote revelation,
* and lack of pre-commitment visibility.
Bribery becomes unreliable because outcomes cannot be verified before execution.
***
#### Low-Quality or Random Voting
Mitigated through:
* loss of stake for incoherent votes,
* rewards only for alignment with final outcomes,
* and long-term negative expectancy for careless behavior.
Jurors who do not evaluate evidence are economically penalized over time.
***
### Incentive Alignment as the Primary Defense
Justly’s primary security mechanism is **incentive alignment**, not identity or reputation alone.
Key properties:
* Jurors are economically exposed to the quality of their decisions.
* Economic exposure scales risk and reward.
* Rewards are only distributed to jurors who align with the final outcome.
This structure discourages whales, favors independent judgment, and aligns rational behavior with protocol integrity.
***
### Tier-Based Security Escalation
Justly supports multiple security levels to match guarantees with dispute risk.
Higher security levels provide:
* broader juror participation,
* higher total economic exposure,
* and increased resistance to manipulation.
This allows users and integrators to choose a security level proportional to the value and complexity of the dispute.
***
### Appeals as a Security Amplifier
Appeals are a planned extension to the Justly design that can increase the cost of incorrect or adversarial outcomes.
In the live contracts today, disputes finalize in a single round once executed.
Appeals are planned for a later version as structured escalation rounds.
Planned appeal rounds:
* increases juror count and economic exposure,
* re-evaluates the dispute under stricter conditions,
* and incentivizes early honest voting.
Appeals are designed to converge outcomes toward coherent judgments without granting unilateral power to any party.
***
### Limits of the System
Justly makes the following guarantees:
* outcomes are enforced exactly as defined,
* rules are transparent and immutable,
* execution is on-chain and verifiable.
Justly does **not** guarantee:
* legal correctness,
* absolute truth,
* or immunity from all forms of coordination under extreme conditions.
Human judgment is inherently probabilistic. Justly guarantees that **dishonesty is costly**, not impossible.
***
### Progressive Security
Security in Justly increases through:
* higher security levels,
* appeals,
* identity primitives,
* and protocol adoption scale.
The protocol is designed to remain secure under realistic conditions and to strengthen as participation grows.
# Frequently Asked Questions
Source: https://docs.justly.one/reference/frequently-asked-questions
This page answers common questions about Justly, how it works, and what guarantees it provides.
This page answers common questions about Justly, how it works, and what guarantees it provides.
Everything you need to know about Justly. If you have more questions, join the Justly community on Telegram: [Official links](https://t.me/justlycommunity).
### General
Can you really trust a decision made by anonymous jurors?
Justly extends the same incentive logic used in cryptoeconomic systems to human judgment.
Jurors are:
* **independent**,
* **randomly assigned**,
* and **economically incentivized** to vote coherently.
Because outcomes affect real value, the system is designed so that **dishonest or low-effort behavior is costly**, while coherent behavior is rewarded.
Is Justly a court or a legal arbitrator?
No. Justly is **neutral dispute resolution infrastructure**.
It is not a court and does not provide legal advice. It enforces outcomes based on protocol rules and smart contract execution.
(See: *Legal & Compliance Considerations*)
What kinds of disputes is Justly built for?
The current version of Justly is optimized for **adversarial disputes** in digital platforms, where:
* disputes are frequent,
* amounts are not large enough for traditional legal processes,
* and fast resolution matters.
Examples include marketplaces, freelancer platforms, and fintech or payment conflicts.
Governance validation and quality evaluation are planned for later versions, not the current implementation.
(See: *Use Cases*)
Is Justly only for Stellar?
No. Justly is designed to be **chain-agnostic**, although it may prioritize specific ecosystems depending on adoption and integration demand.
### How Justly Works
What is a Tier?
A tier is the **public-facing dispute profile** exposed to platforms and integrators.
It packages values such as:
* number of jurors,
* juror stake levels,
* and the arbitration fee amounts required for each side of the dispute.
Higher tiers increase the cost of manipulation by combining:
* more jurors,
* higher stakes,
* and higher total attack cost.
(See: *What is a Tier*)
How long does a dispute take?
Resolution time depends on:
* the selected tier,
* the evidence and voting windows,
* and actual juror participation.
Justly is designed to keep dispute resolution **predictable and bounded**, prioritizing liveness and completion.
(See: *Dispute Lifecycle*)
What happens after the dispute is resolved?
Once the dispute is finalized, the outcome is enforced at the protocol level:
* the ruling is stored,
* juror incentives are settled programmatically,
* and the final state becomes publicly verifiable.
If the integration uses a callback, Justly may attempt it after finalization. Callback failure does not invalidate the ruling.
### Jurors
Are jurors anonymous?
Jurors are pseudonymous participants from the perspective of the disputing parties.
This helps preserve neutrality while allowing jurors to participate economically through staking.
Can parties be jurors in their own dispute?
No. Parties cannot serve as jurors in disputes where they have a direct interest.
This avoids conflicts of interest and preserves neutrality.
What if jurors don't vote or go inactive?
Jurors are expected to participate within defined time windows.
Non-participation after selection is treated as incoherence and can result in protocol-defined penalties.
### Security & Incentives
Can someone "whale" attack Justly by staking a lot?
Stakes affect:
* economic exposure,
* selection economics,
* and rewards or penalties.
Large stakes increase financial exposure, but do not create special control over the final ruling.
(See: *Security Model*)
Can someone bribe jurors?
Bribery is made harder by:
* randomized assignment,
* pseudonymity,
* and incentive alignment.
Because jurors are not known in advance, targeted bribery becomes harder, and dishonest coordination is economically risky.
(See: *Security Model*)
What prevents sybil attacks?
Justly mitigates manipulation through:
* staking requirements,
* randomized juror assignment,
* and economic penalties for incoherent participation.
(See: *Security Model*)
Can Justly be fully trustless if operational tooling is used?
Yes. Operational tooling can help trigger actions or improve UX, but it does not determine rulings.
The protocol guarantees remain the same:
* juror voting determines the ruling,
* state transitions and settlements are enforced by smart contracts,
* and callback failure does not affect finality.
(See: *Security Model*)
### Appeals
Does Justly support appeals?
Not in the current implementation.
Appeals are planned for a later version.
How are appeals funded?
The final funding model for appeals belongs to a later version and is not part of the current implementation.
### Integrations
Do users need to hold a specific token to use Justly?
No. Regular users, such as the claimer and defender, do not need to hold a protocol token.
Justly is designed to work with standard assets, such as stablecoins, used for dispute funding and juror stakes.
Do I need the SDK to integrate Justly?
Not necessarily. Justly can be integrated through direct contract interaction and integration guidelines.
The SDK is useful because it can expose tiers and integration flows in a simpler format, but it is not strictly required.
(See: *Current Implementation*)
How does an integration receive the ruling?
An integrating protocol can consume the ruling in two ways:
* by reading the final ruling directly,
* or through an optional callback flow.
Callback success is not required for finality.
Who is responsible for compliance when integrating Justly?
Compliance depends on the integrating platform, jurisdiction, and transaction type.
Justly is neutral infrastructure and can be combined with identity, KYC, or AML solutions when required.
(See: *Legal & Compliance Considerations*)
### Legal & Responsibility
Who is responsible if a verdict causes economic loss?
Justly is provided "as-is".
Outcomes result from:
* independent human judgment,
* and protocol-defined rules executed on-chain.
Users and integrators are responsible for determining whether Justly is appropriate for their use case and risk tolerance.
(See: *Legal & Compliance Considerations*)
Are Justly rulings legally binding?
Justly outcomes are **programmatically binding** because parties opt into on-chain enforcement.
They are not court rulings and do not automatically constitute legal judgments unless an integrator explicitly frames them within a legal agreement at the application layer.
# Code Quality Evaluation and OSS Reward Distribution
Source: https://docs.justly.one/use-cases/code-quality-oss-reward-distribution
Open source projects depend on external contributors. But evaluating contributions fairly is one of the hardest unsolved problems in OSS.
Status: Planned (*Rating-based disputes under design*)
#### The real problem in open-source ecosystems
Open-source projects depend on external contributors.\
But **evaluating contributions fairly** is one of the hardest unsolved problems in OSS.
Most platforms struggle to answer simple but critical questions:
* Was this pull request actually good?
* Did it improve the project long-term?
* How much should this contribution be rewarded?
* Should this code be merged, revised, or rejected?
At scale, these decisions become inconsistent, subjective, and conflict-prone.
***
#### Why current evaluation methods fail
**1. Quantitative metrics don’t measure quality**
Common signals like:
* lines of code,
* number of commits,
* issue count,
* activity frequency,
**do not reflect real value**.
A small, well-designed fix can be worth more than hundreds of lines of code.
***
**2. Maintainer-only evaluation does not scale**
Relying solely on maintainers:
* creates bottlenecks,
* introduces bias,
* burns out core teams,
* discourages contributors.
In many projects, maintainers become:
* judges,
* gatekeepers,
* and conflict managers.
This is unsustainable.
***
**3. Pure AI-based evaluation breaks in real-world codebases**
Some platforms experimented with AI-based PR evaluation.
A real example:
* Platforms like **OnlyDust** tested automated or AI-assisted evaluation of contributions.
* While useful for surface-level analysis, these systems failed when:
* evaluating smart contracts,
* judging protocol-level logic,
* understanding security implications,
* reviewing unfamiliar languages or paradigms.
AI models:
* misjudge intent,
* misunderstand context,
* fail at domain-specific reasoning,
* and confidently score incorrect or risky code.
This creates **false signals** and undermines trust.
***
#### Why human judgment is unavoidable
Code quality is not just correctness.
It includes:
* architectural fit,
* security assumptions,
* readability,
* long-term maintainability,
* alignment with project goals.
These dimensions require **human judgment**.
But centralized human judgment does not scale either.
***
#### The missing layer: decentralized, incentivized code evaluation
Justly introduces a new primitive:\
**distributed human evaluation with economic incentives**.
Instead of:
* one maintainer deciding,
* or a black-box AI scoring,
Justly uses:
* multiple independent reviewers,
* clear evaluation criteria,
* economic stakes to discourage bad judgments.
***
#### How Justly works for code evaluation
Typical flow:
1. A contributor submits a pull request.
2. The PR enters an evaluation phase.
3. Jurors stake stablecoins (e.g. USDC) to participate.
4. Jurors review:
* code quality,
* correctness,
* security implications,
* adherence to project standards.
5. Each juror assigns a quality score or verdict.
6. Scores are aggregated.
7. Outcomes are executed automatically:
* merge,
* request changes,
* reject,
* distribute rewards.
Poor or dishonest evaluations are economically penalized.
***
#### Example: smart contract contribution
**Scenario**
* A contributor submits a smart contract PR.
* The code compiles and passes tests.
* An AI reviewer gives it a high score.
* Maintainers feel unsure about edge cases and security assumptions.
With Justly:
* Jurors with relevant expertise review the contract.
* They evaluate:
* attack surfaces,
* economic exploits,
* logic soundness.
* The PR receives a weighted quality score.
* Rewards and merge decisions reflect real risk and value.
This avoids:
* blind trust in automation,
* single-point human failure.
***
#### Example: OSS reward distribution
**Problem**
An OSS platform has a fixed monthly reward pool.\
Multiple contributors submit PRs of varying quality.
Without Justly:
* rewards are distributed arbitrarily,
* maintainers decide behind closed doors,
* contributors feel underpaid or ignored.
With Justly:
* each merged PR is scored by jurors,
* rewards scale with contribution quality,
* incentives align with long-term project health.
***
#### Why stablecoin staking matters
Using stablecoins (like USDC):
* removes token volatility,
* avoids speculation,
* keeps incentives neutral.
Jurors are rewarded for:
* accuracy,
* alignment with consensus,
* honest evaluation.
Not for hype or volume.
***
#### Benefits for OSS platforms
**For maintainers**
* Reduced evaluation burden.
* Less conflict with contributors.
* More consistent decisions.
* Better security outcomes.
**For contributors**
* Fair recognition of work.
* Transparent evaluation.
* Clear incentive alignment.
**For ecosystems**
* Higher code quality.
* Reduced gaming of metrics.
* Stronger long-term sustainability.
***
#### Beyond pull requests
The same mechanism applies to:
* issue prioritization,
* bug severity scoring,
* grant allocation,
* retroactive funding,
* roadmap impact evaluation.
Any process that requires **judging quality, not quantity**.
***
#### The takeaway
Open-source fails when:
* effort is rewarded instead of impact,
* evaluation is opaque,
* incentives are misaligned.
Justly transforms code evaluation into:
* a transparent process,
* backed by economic accountability,
* scalable across ecosystems.
***
*Code quality evaluation is expected to leverage **rating-based disputes** and may utilize **Tier 2 or higher** to ensure sufficient diversity of judgment.*
See [Dispute tiers](/how-it-works/tiers/dispute-tiers).
# Content Moderation and Platform Disputes
Source: https://docs.justly.one/use-cases/content-moderation-platform-disputes
Any platform that allows users to publish content eventually faces disputes around moderation.
Status: Planned (*Enabled through adversarial disputes with predefined rulesets*)
#### The real problem with content moderation
Any platform that allows users to publish content eventually faces disputes around moderation.
This includes:
* social networks,
* creator platforms,
* marketplaces with reviews,
* community forums,
* DAO governance platforms,
* collaborative knowledge bases.
And the problem is not *whether* disputes happen —\
it’s **who decides** and **how**.
***
#### Real-world moderation disputes
These situations are extremely common:
* A creator claims their content was unfairly removed.
* A user is banned for “policy violations” they don’t fully understand.
* A review is flagged as abusive, but the author says it’s legitimate.
* A post is reported as misinformation, but evidence is disputed.
* A DAO proposal is removed or censored due to governance conflicts.
Each case has:
* subjective interpretation,
* contextual nuance,
* reputational and economic impact.
***
#### Why centralized moderation breaks trust
Most platforms rely on:
* internal moderators,
* opaque guidelines,
* automated filters,
* or ad-hoc admin decisions.
This creates structural issues:
* ❌ **Platforms act as judge and executioner**
* ❌ **Decisions are opaque**
* ❌ **Appeals are limited or non-existent**
* ❌ **Bias accusations are inevitable**
* ❌ **Moderation does not scale fairly**
Even when moderation is well-intentioned, users often feel:
* censored,
* unheard,
* arbitrarily punished.
Over time, this erodes platform trust.
***
#### Automation alone is not enough
Automated moderation:
* is fast,
* is cheap,
* is necessary at scale.
But it fails in:
* edge cases,
* context-heavy disputes,
* nuanced human judgment.
Pure automation leads to:
* false positives,
* unjust bans,
* content chilling effects.
Pure human moderation:
* does not scale,
* is expensive,
* introduces bias.
Platforms need a **third layer**.
***
#### The missing layer: neutral, scalable adjudication
This is where Justly fits naturally.
Justly provides:
* independent dispute resolution,
* transparent decision-making,
* human judgment without centralized power,
* enforceable outcomes.
Not every moderation decision goes to Justly —\
only **contested or high-impact cases**.
***
#### How Justly integrates with moderation systems
Typical flow:
1. Content is flagged or moderated.
2. A user disputes the decision.
3. The case is escalated to Justly.
4. Evidence is submitted:
* platform rules,
* content context,
* prior behavior,
* moderation rationale.
5. Independent jurors evaluate the case.
6. A ruling is issued.
7. The platform enforces the outcome automatically.
The platform no longer acts as the final authority.
***
#### Example: creator platform dispute
* A video is removed for “policy violation”.
* The creator claims fair use and educational intent.
* The platform’s automated system rejects the appeal.
With Justly:
* the creator submits context and references,
* jurors evaluate intent, rules, and proportionality,
* the ruling determines:
* content restoration,
* partial restrictions,
* or justified removal.
The decision is transparent and auditable.
***
#### Example: DAO or community moderation
* A proposal is removed for being “spam” or “off-topic”.
* The proposer disputes political or personal bias.
Justly enables:
* neutral evaluation by jurors,
* rule-based judgments,
* legitimacy without centralized censorship.
This is especially critical for:
* DAOs,
* open communities,
* governance-heavy platforms.
***
#### Benefits for platforms
**For the platform**
* Reduced moderation liability.
* Clear separation between rules and enforcement.
* Scalable handling of edge cases.
* Fewer accusations of censorship or favoritism.
**For users**
* Real appeal mechanisms.
* Transparent outcomes.
* Confidence that disputes are judged fairly.
***
#### Content moderation needs legitimacy, not just rules
Rules alone don’t create trust.\
**Legitimate enforcement does.**
Justly transforms moderation from:
* opaque authority → transparent process,
* centralized power → distributed judgment.
***
#### The takeaway
Content moderation fails when:
* users feel silenced,
* decisions feel arbitrary,
* appeals go nowhere.
Justly ensures that:
* moderation remains scalable,
* disputes remain resolvable,
* platforms remain trusted.
***
*Moderation-related disputes are commonly suited for **Tier 1 or Tier 2**, where rapid resolution and consistent enforcement are critical.*
See [Dispute tiers](/how-it-works/tiers/dispute-tiers).
# Fintechs, Wallets, and Payment Platforms
Source: https://docs.justly.one/use-cases/fintech-wallets-payment-platforms
Fintech and payment platforms handle millions of transactions between users who don’t know each other . Disputes are not edge cases — they are an inevitab
Status: Live (Public Adversarial Dispute)
#### The real problem (not a theoretical one)
Fintech and payment platforms handle **millions of transactions between users who don’t know each other**.\
Disputes are not edge cases — they are an inevitable byproduct of digital payments.
Common real-world scenarios include:
* A user claims *“I sent the payment, but the service was never delivered”*
* A merchant claims *“the payment was received and the service was provided”*
* A peer-to-peer transfer is marked as incorrect or unintended
* A user disputes a charge after receiving a product or service
* Cross-border payments generate misunderstandings due to timing, FX, or settlement differences
These issues occur **daily**, especially at scale.
***
#### How disputes are handled today (and why this doesn’t scale)
Most fintechs and wallets rely on **centralized dispute handling**:
1. The platform freezes the transaction.
2. A dispute or chargeback process is initiated.
3. Internal teams:
* review transaction logs,
* analyze user communications,
* apply internal policies.
4. The platform decides whether to reverse or settle the payment.
This approach introduces structural problems:
* ❌ **The platform is judge and party**\
It controls the funds and the outcome.
* ❌ **High operational and compliance costs**\
Each dispute requires manual review and regulatory oversight.
* ❌ **Slow resolution times**\
Chargebacks and disputes can take days or weeks.
* ❌ **Limited transparency**\
Users don’t understand how or why decisions are made.
As transaction volume grows, these processes become **increasingly expensive and fragile**.
***
#### The key insight: payments without neutral resolution erode trust
Payments are only truly final when users trust the system.
Without a fair dispute mechanism:
* users hesitate to send money,
* merchants face uncertainty,
* platforms absorb reputational and financial risk.
Traditional chargeback systems:
* are slow,
* favor certain parties,
* and don’t work well for instant or cross-border payments.
👉 **Fast payments require equally fast and fair dispute resolution.**
***
#### How Justly fits into fintech and payment flows
Justly integrates as a **neutral dispute resolution layer on top of payment rails**.
A typical flow:
1. A payment is executed and optionally held in escrow.
2. A dispute is opened if one party challenges the transaction.
3. Both sides submit evidence:
* transaction details,
* service confirmation,
* messages or receipts.
4. **Independent jurors** evaluate the case.
5. A ruling is reached based on predefined criteria.
6. Funds are released, refunded, or reassigned automatically.
Justly operates:
* independently from the platform,
* transparently and on-chain,
* without replacing existing payment infrastructure.
***
#### A concrete (very realistic) example
**Peer-to-peer payment dispute**
* Amount: 200 USDC
* Sender claims: *“I paid for a service that was never delivered”*
* Receiver claims: *“The service was provided as agreed”*
With Justly:
* Both parties submit:
* payment proof,
* conversation history,
* any service confirmation.
* Jurors assess:
* Was the payment conditional?
* Was the service delivered?
* A vote is taken.
* Funds are reassigned automatically according to the ruling.
The wallet or fintech platform **does not intervene directly**.
***
#### Clear benefits for fintechs and wallets
**For the platform**
* Lower dispute handling and chargeback costs.
* Reduced regulatory and reputational risk.
* Transparent, auditable dispute outcomes.
* Better scalability as transaction volume grows.
**For users**
* Increased confidence when sending payments.
* Fair handling of payment conflicts.
**For merchants and recipients**
* Protection against abusive chargebacks.
* Predictable, rule-based outcomes.
***
#### Why this matters
Without effective dispute resolution:
* instant payments feel risky,
* user trust declines,
* platforms become bottlenecks.
With Justly:
* disputes become structured and manageable,
* trust scales with transaction volume,
* payment systems remain fast without sacrificing fairness.
***
*Payment-related disputes are usually resolved using **Tier 1 or Tier 2**, prioritizing speed and predictable resolution times.*
See [Dispute tiers](/how-it-works/tiers/dispute-tiers).
# Freelancer and Contractor Platforms
Source: https://docs.justly.one/use-cases/freelancer-contractor-platforms
On freelancer and contractor platforms, disputes are not rare edge cases — they are a built in consequence of how digital work operates.
Status: Live (Public Adversarial Dispute)
#### The real problem (not a theoretical one)
On freelancer and contractor platforms, disputes are **not rare edge cases** — they are a built-in consequence of how digital work operates.
Real, everyday situations include:
* A client claims *“the work doesn’t match the original scope”*
* A contractor responds *“the scope changed during the project”*
* A client withholds payment arguing **poor quality**
* A freelancer claims the work was delivered and approved
* Deliverables are submitted, but expectations were never clearly documented
These conflicts happen **constantly**, especially in remote, asynchronous work environments.
***
#### How disputes are handled today (and why this doesn’t scale)
Most freelancer platforms resolve disputes through centralized mediation:
1. The platform holds the payment.
2. A dispute is opened through support.
3. A platform agent:
* reviews messages and files,
* interprets terms of service,
* makes a subjective decision.
4. Funds are released based on that decision.
This model creates structural issues:
* ❌ **The platform acts as judge and party**\
It decides over user funds while protecting its own interests.
* ❌ **High operational overhead**\
Each dispute requires manual review by trained staff.
* ❌ **Subjective and inconsistent rulings**\
Similar cases can result in different outcomes.
* ❌ **Slow resolution times**\
Disputes can take days or weeks to resolve.
As a result:
* freelancers feel unprotected,
* clients feel decisions are arbitrary,
* trust in the platform erodes.
***
#### The key insight: escrow alone doesn’t resolve human disagreement
Freelancer platforms often rely on **payment escrow**:
* clients pay upfront,
* funds are locked,
* funds are released upon completion.
But when there’s a disagreement, escrow alone isn’t enough.
The critical question becomes:
> Was the work actually delivered as agreed?
Without a clear, fair way to answer this:
* payments get stuck,
* decisions feel arbitrary,
* disputes escalate emotionally.
👉 **Human judgment is unavoidable in creative and knowledge work.**\
Justly provides a structured way to apply it.
***
#### How Justly resolves disputes for freelancer platforms
Justly integrates as a **neutral, external arbitration layer**.
A typical flow:
1. The client funds the escrow.
2. Work is delivered.
3. A dispute is opened if there’s disagreement.
4. Both parties submit evidence:
* original brief or contract,
* deliverables,
* communication history.
5. **Independent jurors** review the case.
6. Jurors vote based on predefined rules.
7. Funds are released automatically according to the ruling.
The platform:
* does not decide the outcome,
* does not mediate manually,
* does not bear subjective responsibility.
***
#### A concrete (very realistic) example
**Freelance development contract**
* Payment: 800 USDC
* Client claims: *“the feature doesn’t meet requirements”*
* Developer claims: *“the requirements changed after delivery”*
With Justly:
* Both submit:
* the original specification,
* the delivered code,
* Git commits and messages.
* Jurors evaluate:
* Was the scope clearly defined?
* Does the delivery meet the original agreement?
* A vote is taken.
* Funds are distributed automatically based on the verdict.
No platform intervention is required.
***
#### Clear benefits for freelancer platforms
**For the platform**
* Reduced support and mediation costs.
* Fewer escalations and legal risks.
* Transparent, auditable decisions.
* Better scalability as the platform grows.
**For clients**
* Confidence to fund work upfront.
* Fair evaluation of deliverables.
**For freelancers**
* Protection against unfair non-payment.
* Clear, predictable dispute outcomes.
***
#### Why this matters
Without fair dispute resolution:
* high-quality freelancers leave,
* clients hesitate to prepay,
* the platform’s reputation suffers.
With Justly:
* disputes stop being platform-breaking events,
* and become a manageable, trust-preserving process.
***
*Disputes between freelancers and clients are commonly handled through **Tier 2 or Tier 3**, balancing cost efficiency with stronger economic guarantees.*
See [Dispute tiers](/how-it-works/tiers/dispute-tiers).
# Governance and Collective Decision-Making
Source: https://docs.justly.one/use-cases/governance-collective-decision-making
Justly is not only useful when disputes arise over payments or services. It also applies when collective decisions break down .
Status: Planned (*Decision disputes with enforceable outcomes*)
Justly is not only useful when disputes arise over payments or services.\
It also applies when **collective decisions break down**.
Governance systems — whether in DAOs, protocols, platforms, or digital communities — are built on rules, votes, and incentives. But real-world governance is messy: not every situation can be resolved by a simple on-chain vote or predefined logic.
Justly acts as a **human arbitration and coordination layer** for governance systems when rules alone are not enough.
***
### The real problem with governance systems
Most governance frameworks assume that:
* rules are clear,
* proposals are well-defined,
* voters behave rationally,
* outcomes are final.
In practice, this often fails.
Common real-world governance issues include:
* Disputes over whether a proposal was implemented correctly
* Conflicts about ambiguous rules or edge cases
* Claims that a vote was manipulated, rushed, or unfair
* Disagreements after a decision has already passed
* Minority groups contesting outcomes they believe violate shared principles
* Grant allocations perceived as biased or low-quality
* Parameter changes that negatively affect part of the community
When these conflicts arise, governance systems usually have **no built-in way to resolve them**.
***
### How governance disputes are handled today (and why it fails)
Most projects fall back to one of these options:
1. **Core team decides manually**
* Centralized, opaque, and legitimacy is questioned.
2. **Social consensus on Discord / forums**
* Loud minorities dominate, outcomes are unclear, decisions drag on.
3. **Re-run votes**
* Expensive, slow, and often doesn’t resolve the underlying disagreement.
4. **Ignore the dispute**
* Leads to frustration, forks, or community erosion.
None of these approaches scale.\
None are neutral.\
None provide enforceable outcomes.
***
### Why voting alone is not enough
Voting answers the question:
> “What do the majority want?”
But it does **not** answer:
* “Was the proposal executed correctly?”
* “Does this decision violate previously agreed rules?”
* “Is this grant actually delivering value?”
* “Is this behavior aligned with the protocol’s intent?”
Governance systems need a **dispute resolution layer**, just like escrows need arbitration.
***
### How Justly fits into governance systems
Justly integrates as a **post-vote and edge-case resolution layer**.
It does not replace:
* DAO voting,
* governance frameworks,
* protocol rules.
It activates **when those systems fail to produce a clear or accepted outcome**.
#### High-level flow
1. A governance decision is made (vote, proposal, rule).
2. A dispute arises about:
* interpretation,
* execution,
* fairness,
* or impact.
3. A dispute is opened in Justly.
4. Evidence is submitted:
* proposal text,
* voting results,
* implementation details,
* prior rules or precedents.
5. Independent jurors evaluate the case.
6. A verdict is reached.
7. The outcome:
* resolves the dispute socially,
* and can optionally trigger on-chain actions.
***
### Concrete governance use cases
#### 1. DAO proposal execution disputes
**Example**
A DAO approves a proposal to fund a project.\
After execution, part of the community claims the implementation deviates from what was voted.
Justly allows jurors to evaluate:
* the original proposal,
* what was delivered,
* whether the execution matches intent.
The verdict determines whether funds are released, clawed back, or execution is considered valid.
***
#### 2. Grant allocation and evaluation
Many DAOs struggle with:
* subjective grant approvals,
* favoritism,
* low-quality outcomes.
With Justly:
* grant recipients can be evaluated post-delivery,
* jurors assess whether milestones were met,
* future funding or reputation adjusts based on verdicts.
This introduces **accountability without central committees**.
***
#### 3. Parameter changes and protocol disputes
Changes to fees, limits, or economic parameters often create winners and losers.
When disputes arise:
* Justly can be used to evaluate whether changes violate prior commitments,
* or whether emergency rollbacks are justified.
This reduces emotional governance fights and adds structured resolution.
***
#### 4. Community rule enforcement
Governance is not only about money.
Disputes may involve:
* code of conduct violations,
* moderation decisions,
* abuse of governance processes.
Justly provides:
* rule-based, auditable evaluation,
* legitimacy beyond “admin decisions”.
***
### Why Justly works for governance
* **Neutrality**\
Jurors are external and economically incentivized to be fair.
* **Legitimacy**\
Decisions are transparent and based on shared rules.
* **Enforceability**\
Outcomes can trigger on-chain logic or funding decisions.
* **Scalability**\
No need for governance councils or endless debates.
* **Human judgment where it matters**\
Without breaking decentralization.
***
### The bigger picture
Governance systems fail not because rules are bad,\
but because **rules cannot anticipate every situation**.
Justly provides the missing layer:
> A structured way for humans to resolve disagreements\
> without central authority\
> and with real consequences.
This makes governance systems **resilient**, not just decentralized.
***
*Governance disputes may rely on **Tier 3 or Tier 4** to provide stronger legitimacy and resistance to manipulation.*
See [Dispute tiers](/how-it-works/tiers/dispute-tiers).
# Marketplaces (E-commerce, P2P, Services)
Source: https://docs.justly.one/use-cases/marketplaces
The real problem (not a theoretical one)
Status: Live (Public Adversarial Dispute)
The real problem (not a theoretical one)
In any marketplace where buyers and sellers **don’t know each other**, disputes are **not an edge case** — they are a normal part of the system.
Common, real-world examples:
* A buyer says *“the product never arrived”*
* The seller replies *“it was delivered, here’s the tracking”*
* A customer pays for a service (design, repair, delivery) and claims it **doesn’t meet the agreement**
* The provider claims they **did deliver as agreed** and the buyer is requesting an unfair refund
* A product arrives but:
* it doesn’t match the description,
* it’s damaged,
* or it arrives later than promised
These situations happen **every day**, even on large marketplaces.
***
#### How disputes are handled today (and why this doesn’t scale)
Most marketplaces resolve disputes in roughly the same way:
1. Funds are held by the platform.
2. The user opens a support ticket.
3. A support agent:
* reads messages,
* reviews screenshots,
* interprets internal rules.
4. The platform makes a decision and releases the funds.
This approach creates several structural problems:
* ❌ **The platform acts as judge and party**\
It decides over funds it doesn’t own, while its own reputation is at stake.
* ❌ **High operational costs**\
Every dispute requires human time and review.
* ❌ **Opaque decisions**\
Users don’t clearly understand why a decision was made.
* ❌ **Poor scalability**\
More users → more disputes → more support → higher costs.
As a result, many marketplaces:
* limit refunds,
* systematically favor one side,
* or simply ban users.
This **breaks trust**.
***
#### The key insight: escrow without arbitration doesn’t work
Many marketplaces rely on an **escrow model**:
* the buyer pays,
* funds are locked,
* funds are released if everything goes well.
But when a conflict arises, a critical question appears:
> Who decides who is right?
Without a clear answer:
* funds remain stuck,
* decisions become arbitrary,
* escrow loses its purpose.
👉 **Arbitration is what makes escrow work.**
This is exactly the insight Kleros addressed — and what Justly applies in a more modern, fast, and UX-friendly way.
***
#### How Justly solves this for marketplaces
Justly integrates as an **external dispute resolution layer**.
A simple flow:
1. The buyer pays → funds are locked in escrow.
2. The transaction proceeds normally.
3. If a conflict arises:
* either party can open a dispute via Justly.
4. Evidence is submitted:
* product description,
* messages,
* receipts,
* deliverables.
5. A group of **independent jurors** evaluates the case.
6. Jurors vote based on clear rules.
7. The final ruling:
* releases funds to the buyer **or**
* releases funds to the seller.
All of this happens:
* without the platform making the decision,
* without internal human support,
* with transparent, verifiable rules.
***
#### A concrete (very realistic) example
**Design services marketplace**
* Price: 150 USDC
* The client claims: *“the design doesn’t meet the agreed scope”*
* The designer claims: *“I delivered exactly what was requested”*
With Justly:
* Both parties submit:
* the original brief,
* the delivered design,
* the conversation history.
* Jurors evaluate:
* Was the brief respected?
* Is the delivered quality reasonable?
* A vote is taken.
* Funds are released automatically according to the ruling.
The platform **does not intervene**.
***
#### Clear benefits for the marketplace
**For the platform**
* Lower support costs.
* Reduced legal exposure.
* Auditable, consistent decisions.
* Scalability without added friction.
**For buyers**
* Confidence to pay upfront.
* Real protection in disputes.
**For sellers**
* Protection against abusive claims.
* Clear rules from the start.
***
#### Why this matters (strategic importance)
Without fair dispute resolution:
* users lose trust,
* prices increase to cover risk,
* or users leave the platform.
With Justly:
* conflict stops being an existential threat,
* and becomes a normal, solvable part of the system.
***
*Most marketplace disputes are typically resolved using **Tier 1 or Tier 2**, depending on transaction value and platform risk tolerance.*
See [Dispute tiers](/how-it-works/tiers/dispute-tiers).
# Micro-insurance and Micro-claims
Source: https://docs.justly.one/use-cases/micro-insurance-micro-claims
small financial losses, short term risks, high frequency events, users with limited access to traditional insurance.
Status: Planned (*Enabled through adversarial disputes with predefined rulesets*)
#### The core problem with micro-insurance
Micro-insurance is designed to cover:
* small financial losses,
* short-term risks,
* high-frequency events,
* users with limited access to traditional insurance.
But there’s a paradox:
> The smaller the claim, the harder it is to resolve fairly.
Why?
* Traditional claim reviews are expensive.
* Human adjusters don’t scale for $20–$300 claims.
* Automation alone can’t handle edge cases.
* Users feel ignored or unfairly rejected.
As a result, many micro-insurance systems either:
* auto-approve everything (risking abuse), or
* auto-reject everything unclear (destroying trust).
***
#### Real-world micro-claim scenarios
These cases happen every day:
* Flight delay insurance with disputed delay times.
* Delivery insurance for lost or damaged packages.
* Weather-based insurance with unclear local impact.
* Device insurance with ambiguous damage causes.
* Gig-economy insurance for short jobs or shifts.
* Parametric insurance where conditions partially trigger.
Each claim is small —\
but **the trust impact is huge**.
***
#### Why traditional insurance logic breaks down
For micro-claims:
* Manual review costs more than the payout.
* Centralized decisions feel opaque.
* Appeals are slow or non-existent.
* Users assume bias toward the insurer.
This creates a toxic loop:
* Low trust → high churn
* High churn → stricter automation
* Stricter automation → more rejected claims
***
#### The missing layer: scalable, neutral judgment
Micro-insurance doesn’t need **perfect accuracy**.\
It needs **fair, explainable decisions at low cost**.
Justly introduces a middle layer between:
* fully automated payouts, and
* expensive human adjusters.
A layer where:
* disputes are rare but resolvable,
* decisions are transparent,
* costs stay proportional to claim size.
***
#### How Justly fits into micro-insurance systems
Justly acts as an **on-demand dispute resolver**.
Typical flow:
1. A claim is submitted.
2. The system auto-processes it.
3. If the claim is disputed, it is escalated to Justly.
4. Evidence is submitted (photos, receipts, timestamps, sensor data).
5. Independent jurors review the case.
6. A ruling is issued.
7. The payout contract executes the decision automatically.
No claims agents.\
No back-and-forth emails.\
No black-box decisions.
***
#### Example: delivery micro-insurance
* A user insures a package for \$50.
* The package arrives damaged.
* The insurer’s system flags the claim as “unclear”.
Instead of rejecting it:
* The dispute is sent to Justly.
* The user submits photos and delivery timestamps.
* Jurors evaluate whether the damage matches transit issues.
* The ruling:
* approves full payout,
* approves partial payout,
* or rejects the claim with justification.
The result is enforced automatically.
***
#### Example: parametric weather insurance
* A farmer has micro-insurance for rainfall.
* Sensors report borderline data.
* The claim is disputed due to conflicting sources.
Justly allows:
* evidence from multiple oracles,
* local context evaluation,
* human interpretation where automation fails.
This avoids:
* blind oracle dependence,
* rigid yes/no logic.
***
#### Why this matters for insurers and protocols
**For insurers**
* Lower operational costs.
* Reduced fraud without blanket rejections.
* Higher user trust and retention.
**For users**
* A real chance to contest unfair outcomes.
* Transparent decisions.
* Faster resolutions.
**For on-chain insurance protocols**
* Removes reliance on admin intervention.
* Enforces rulings trustlessly.
* Keeps systems decentralized under stress.
***
#### Micro-claims need proportional justice
Big insurance can afford:
* lawyers,
* adjusters,
* long processes.
Micro-insurance can’t.
Justly enables:
* **low-cost justice for low-value claims**,
* without sacrificing fairness or decentralization.
***
#### The takeaway
Micro-insurance fails when disputes are ignored.\
It scales when disputes are **cheap, fair, and enforceable**.
Justly makes micro-claims:
* economically viable,
* socially fair,
* technically enforceable.
***
*Micro-claims are typically resolved using **Tier 1**, enabling fast and cost-effective evaluations that would be impractical in traditional insurance systems.*
See [Dispute tiers](/how-it-works/tiers/dispute-tiers).
# Use Cases
Source: https://docs.justly.one/use-cases/overview
Justly is designed as a reusable dispute resolution infrastructure , adaptable to multiple industries where digital payments exist and low to medium value
Justly is designed as a **reusable dispute resolution infrastructure**, adaptable to multiple industries where digital payments exist and low-to-medium value conflicts are frequent.
Instead of building custom dispute logic for every product or protocol, Justly provides a **neutral, fast, and programmable layer** that can be embedded wherever trust breaks down.
Below is a high-level overview of the main use cases.\
Each one is explored in depth in its own section.
***
### 1. Marketplaces (E-commerce, P2P, Services)
Marketplaces constantly deal with disputes between buyers and sellers over delivery, quality, or terms.\
Justly enables platforms to resolve these conflicts quickly and transparently without acting as judge and party.
**Core value:** faster resolutions, lower support costs, increased trust between participants.
***
### 2. Freelancer and Contractor Platforms
Disputes over scope, quality, and payments are common in freelance work, especially for small or medium amounts.\
Justly allows these conflicts to be resolved fairly in hours, and often in minutes under strong juror liquidity, without legal friction or centralized arbitration.
**Core value:** reduced friction, faster payouts, higher user retention.
***
### 3. Fintechs, Wallets, and Payment Platforms
Payment platforms face frequent disputes related to chargebacks, incorrect transfers, or peer-to-peer disagreements.\
Justly acts as a neutral dispute layer on top of payment flows, with verifiable and auditable outcomes.
**Core value:** fewer chargebacks, reduced fraud, stronger perception of fairness.
***
### 4. Web3 Platforms and On-chain Protocols
Even in decentralized systems, human disagreements still exist.\
Justly provides a human arbitration fallback that can trigger on-chain logic when smart contracts alone are not enough.
**Core value:** increased social security for protocols and better UX for non-technical users.
***
### 5. Micro-insurance and Micro-claims
Traditional insurance systems cannot profitably handle small claims.\
Justly makes real-time, low-cost evaluation possible through distributed juries and automated execution.
**Core value:** viable micro-insurance models with transparent outcomes.
***
### 6. Content Moderation and Platform Disputes
Centralized moderation often leads to distrust and backlash.\
Justly enables distributed, rule-based evaluation of moderation decisions with social legitimacy.
**Core value:** verifiable moderation and reduced perception of censorship.
***
### 7. Code Quality Evaluation and OSS Reward Distribution
Measuring the real value of code contributions is hard, and traditional metrics fail.\
Justly enables collective evaluation of code quality and impact, aligning rewards, merges, and funding with real contribution value.
**Core value:** merit-based rewards, better incentive alignment, healthier OSS ecosystems.
***
### 8. Governance and Collective Decision-Making
Governance systems often fail when rules are ambiguous, execution is contested, or outcomes are socially disputed.
Justly acts as a **post-vote and edge-case resolution layer** for DAOs, protocols, and digital communities, providing structured human judgment with enforceable outcomes.
**Core value:** legitimate, scalable governance without central authorities.
***
### Summary
Justly can be integrated into any system where:
* digital payments exist,
* low or mid-value disputes are common,
* speed, fairness, and trust are critical.
Justly is not a vertical product.\
It is **dispute resolution infrastructure for the digital economy**, extensible beyond disputes into broader coordination and quality assessment problems.
# Web3 Platforms and On-chain Protocols
Source: https://docs.justly.one/use-cases/web3-platforms-onchain-protocols
Web3 systems are designed to be trustless , but real world interactions are not.
Status: Live (Public Adversarial Dispute)
#### The real problem in Web3 (beyond ideology)
Web3 systems are designed to be **trustless**, but real-world interactions are not.
On-chain protocols increasingly handle:
* peer-to-peer payments,
* tokenized assets,
* services exchanged for crypto,
* DAO governance actions,
* cross-protocol interactions.
Wherever **value exchange meets human behavior**, disputes inevitably arise.
***
#### Common dispute scenarios in Web3
These are not hypothetical edge cases — they happen daily:
* A DAO member claims funds were misused.
* A service provider receives payment but is accused of not delivering.
* An NFT is sold with disputed attributes or usage rights.
* An escrow contract releases funds incorrectly.
* A protocol upgrade or governance action is challenged.
* A cross-chain or DeFi interaction behaves unexpectedly.
Smart contracts execute perfectly — **but they cannot interpret context**.
***
#### The current workaround: “off-chain judgment”
Most Web3 protocols resolve disputes through:
* Discord discussions
* DAO forum debates
* Multisig discretion
* Core team intervention
* Emergency admin keys
* Social consensus
This creates contradictions:
* ❌ Protocols claim decentralization but rely on trusted actors.
* ❌ Decisions are opaque and socially enforced.
* ❌ Outcomes depend on influence, not rules.
* ❌ Legal and reputational risks accumulate off-chain.
In practice, many “trustless” systems **re-introduce trust through the back door**.
***
#### The key insight: trustless execution needs neutral judgment
Smart contracts are excellent at:
* enforcing rules,
* moving assets,
* executing deterministic logic.
They are **bad at resolving ambiguity**.
Dispute resolution is the missing primitive:
* not for every transaction,
* but for the moments when rules alone are insufficient.
👉 **Without a native dispute layer, decentralization breaks under pressure.**
***
#### How Justly integrates with Web3 protocols
Justly functions as a **protocol-agnostic dispute resolution layer**.
It can be plugged into:
* DAOs,
* DeFi protocols,
* NFT marketplaces,
* on-chain escrow systems,
* cross-protocol workflows.
A typical on-chain flow:
1. A smart contract flags a transaction or state as disputed.
2. The dispute is registered on Justly.
3. Parties submit evidence (on-chain + off-chain references).
4. Independent jurors are selected.
5. Jurors evaluate according to protocol-defined rules.
6. A ruling is returned on-chain.
7. The original contract executes the ruling automatically.
No admins. No emergency keys. No social enforcement.
***
#### Example: DAO treasury dispute
* A DAO allocates 50,000 USDC to a contributor.
* Community members dispute that milestones were not met.
* Funds are escrowed in a smart contract.
* Justly is triggered as the dispute resolver.
Jurors evaluate:
* agreed milestones,
* on-chain activity,
* submitted deliverables.
The ruling:
* releases funds,
* partially refunds,
* or returns them to the DAO treasury.
The DAO does not vote emotionally.\
The contract enforces the outcome.
***
#### Why this matters for Web3 protocols
**For protocol designers**
* Removes reliance on centralized governance interventions.
* Reduces attack surface (admin keys, multisigs).
* Enables cleaner, rule-based protocol design.
**For DAOs**
* Fair handling of internal conflicts.
* Less governance fatigue.
* Clear, enforceable outcomes.
**For users**
* Higher confidence interacting with on-chain systems.
* Protection in ambiguous situations.
***
#### Dispute resolution as a Web3 primitive
Just as:
* oracles connect blockchains to reality,
* bridges connect chains to chains,
👉 **dispute resolution connects code to human context.**
Protocols without it:
* work until something goes wrong.
Protocols with it:
* can safely scale real economic activity.
***
#### The takeaway
Web3 doesn’t fail because smart contracts are weak.\
It fails when **human disputes have nowhere to go**.
Justly provides:
* neutral judgment,
* on-chain enforceability,
* protocol-level trust.
***
*Protocol-level disputes often leverage **Tier 2 or Tier 3**, depending on the value locked and the social impact of the decision.*
See [Dispute tiers](/how-it-works/tiers/dispute-tiers).