Skip to content

Implement on-chain dispute resolution with arbitration voting #344

Open
Open
Implement on-chain dispute resolution with arbitration voting#344
Labels
GrantFox OSSIssue tracked in GrantFox OSSMaybe RewardedIssue may be eligible for a GrantFox rewardOfficial CampaignCampaign: Official CampaignOfficial Campaign | FWC26Campaign: Official Campaign | FWC26complexity: highComplex feature requiring deep knowledge - 200 ptsfeatureNew contract feature or operationgrantfoxIssue for GrantFox program

Description

@Kingsman-99
Kingsman-99
opened on Jul 16, 2026

Overview

Build a full dispute lifecycle into the contract. Any payer on an invoice can open a dispute before release. A configurable set of arbitrators votes to resolve or reject. Funds are frozen during dispute and released/refunded according to the outcome.

Requirements

  • open_dispute(env, invoice_id, payer, reason: String) — opens a dispute, freezes the invoice (cannot release/refund while open)
  • vote_dispute(env, invoice_id, arbitrator, approve: bool) — arbitrator casts a vote; requires the caller to be in the stored arbitrator set
  • resolve_dispute(env, invoice_id) — callable by anyone once quorum is reached; resolves the invoice according to majority vote (approve → release, reject → refund)
  • Dispute state stored under a new dispute_key(invoice_id) storage key
  • Emit DisputeOpened, DisputeVoteCast, DisputeResolved events
  • Admin can configure arbitrator_set and quorum_threshold (e.g. 2-of-3)
  • Write unit tests for: open → vote → resolve (approve path), open → vote → resolve (reject path), duplicate vote rejected, non-arbitrator vote rejected, dispute on non-existent invoice

Acceptance Criteria

  • All three entry points implemented
  • Frozen invoice cannot be released or refunded during open dispute
  • Quorum logic correct for configurable N-of-M threshold
  • Storage snapshot test updated with new dispute_key
  • All existing tests pass
  • cargo test --workspace passes with zero failures
  • cargo clippy --all-targets -- -D warnings produces zero warnings

Definition of Done

All CI checks must pass before the PR is reviewed.

Activity

  1. Kingsman-99
    added
    complexity: highComplex feature requiring deep knowledge - 200 pts
    Maybe RewardedIssue may be eligible for a GrantFox reward
    GrantFox OSSIssue tracked in GrantFox OSS
    Official CampaignCampaign: Official Campaign
    grantfoxIssue for GrantFox program
    featureNew contract feature or operation
    on Jul 16, 2026

  2. nurudeenheroic commented on Jul 16, 2026

    @nurudeenheroic
    nurudeenheroic
    on Jul 16, 2026 – with GrantFox OSS

    Hi! I can handle this issue and ensure it meets the requirements.

  3. grantfox-oss
    added
    Official Campaign | FWC26Campaign: Official Campaign | FWC26
    on Jul 23, 2026

  4. guptakumarranjeet150 commented on Sep 13, 2026

    @guptakumarranjeet150
    guptakumarranjeet150
    on Sep 13, 2026

    Hello! I'd like to work on this issue.

    I can tackle Implement on-chain dispute resolution with arbitration voting. Proposed implementation roadmap:

    • Analysis: Inspect current behavior and edge cases in Stellar-split/split-contracts
    • Implementation: Implement Implement on-chain dispute resolution with arbitration voting with explicit require_auth checks, clean storage layouts, and robust Soroban contract logic.
    • Testing: Add comprehensive unit tests verifying both happy-path invocations and unauthorized revert scenarios.
    • PR: Atomic commit with clean git hygiene and passing CI

    I am ready to start immediately—please assign this to me!

  5. ranjeet150 commented on Sep 14, 2026

    @ranjeet150
    ranjeet150
    on Sep 14, 2026

    Hello @maintainers,

    I would like to resolve this issue. Here is my proposed execution plan:

    • Implementation: Implement Implement on-chain dispute resolution with arbitration voting with explicit require_auth checks, clean storage layouts, and robust Soroban contract logic.
    • Testing & Verification: Add comprehensive unit tests verifying both happy-path invocations and unauthorized revert scenarios.
    • Delivery: Ready to ship a thoroughly tested PR within 12–24 hours with passing CI.

    Ready to deliver a clean, tested PR within 12–24 hours. Please assign!

  6. ZacLou commented on Sep 14, 2026

    @ZacLou
    ZacLou
    on Sep 14, 2026

    I'd like to work on this issue. I have experience with Rust and Soroban smart contracts. I'll implement the full dispute lifecycle:

    1. open_dispute — open dispute, freeze invoice, store dispute state
    2. vote_dispute — arbitrator voting with signature verification
    3. resolve_dispute — resolve based on majority vote, release/refund funds
    4. Dispute state management — new dispute_key(invoice_id) storage
    5. Events — emit DisputeOpened, DisputeVoted, DisputeResolved events

    My approach:

    • Study existing contract patterns in the codebase
    • Implement dispute state machine with proper access control
    • Add comprehensive tests for all dispute scenarios
    • Ensure proper fund freezing during disputes

    Looking forward to assignment.

  7. shobhamerabacha-star commented on Sep 14, 2026

    @shobhamerabacha-star
    shobhamerabacha-star
    on Sep 14, 2026

    Hello! I'd like to work on this issue.

    I would love to take this on. My planned approach:

    • Implement Implement on-chain dispute resolution with arbitration voting with explicit require_auth checks, clean storage layouts, and robust Soroban contract logic.
    • Add comprehensive unit tests verifying both happy-path invocations and unauthorized revert scenarios.

    Looking forward to contributing—please feel free to assign!

  8. rupesh-kumar-sah commented on Oct 3, 2026

    @rupesh-kumar-sah
    rupesh-kumar-sah
    on Oct 3, 2026

    Hello team,

    I looked into Implement on-chain dispute resolution with arbitration voting and have an implementation approach ready.

    Technical outline:

    1. Audit storage layout and state invariants ensuring strict auth guards.
    2. Implement deterministic state transitions with safe checked arithmetic.
    3. Add hermetic unit and regression tests covering authorized, unauthorized, and boundary edge cases.
    4. Profile instruction and CPU/gas limits under Soroban host environment.

    Ready to implement immediately upon assignment. Please feel free to assign!

  9. ravimahatonp commented on Oct 9, 2026

    @ravimahatonp
    ravimahatonp
    on Oct 9, 2026

    Hey team,

    Happy to work on this in split-contracts. I have a clean approach to implement on-chain dispute resolution with arbitration voting and will verify the implementation against existing test suites. Please assign me to this issue if it's available.

  10. huangji6693-max commented on Oct 26, 2026

    @huangji6693-max
    huangji6693-max
    on Oct 26, 2026

    Hi maintainers! I have implemented on-chain dispute resolution with multi-arbitrator voting (open_dispute, vote_dispute, resolve_dispute, set_arbitrators) and submitted PR: #1060

    Summary:

    • Entry Points: open_dispute(env, invoice_id, payer, reason), vote_dispute(env, invoice_id, arbitrator, approve), resolve_dispute(env, invoice_id), and admin configuration set_arbitrators(env, admin, arbitrator_set, quorum_threshold).
    • Storage & Events: Persists ArbitrationDispute under dispute_key(invoice_id) (with updated tests/snapshots/storage_keys.json XDR baseline) and emits DisputeOpened, DisputeVoteCast, and DisputeResolved.
    • Verification: All 6 unit tests covering approve/release path, reject/refund path, duplicate vote rejection, non-arbitrator rejection, non-existent invoice rejection, and dispute freeze pass (cargo test -p split issue_344_tests & cargo test -p split storage_snapshot).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    GrantFox OSSIssue tracked in GrantFox OSSMaybe RewardedIssue may be eligible for a GrantFox rewardOfficial CampaignCampaign: Official CampaignOfficial Campaign | FWC26Campaign: Official Campaign | FWC26complexity: highComplex feature requiring deep knowledge - 200 ptsfeatureNew contract feature or operationgrantfoxIssue for GrantFox program

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions