Understanding the Dispute Module in Story Protocol

General
1

I’ve read through the entire documentation of Story Protocol, but I’m still unclear about how the Dispute Module works.

Could someone explain the technical aspects of how this module functions? Also, is there any platform or tool available to simulate dispute scenarios within the ecosystem?

I’d really appreciate a detailed yet easy-to-understand explanation. Thank you!

4 Likes
2

Hey mewww3,

I will try to do a broad sweep on a technical level with the steps involved in a dispute process to hopefully answer your question.

Technical steps walkthrough
There is 1 main smart contract DisputeModule.sol and then each arbitration policy can have their own contracts. For now, only UMA policy is available and the associated contract is ArbitrationPolicyUMA.sol. In the future the idea is that more dispute arbitration policies become available.

Let us go over the steps associated with a dispute in the context of UMA arbitration policy:

  1. Raising a dispute
    Call raiseDispute() on DisputeModule.sol. Pass in the following inputs:
    –
    /// @param targetIpId The ipId that is the target of the dispute
    /// @param disputeEvidenceHash The hash pointing to the dispute evidence - this could be an IPFS bytes32 hash - this is the document with the proof that UMA reviewers will potentially read
    /// @param targetTag The target tag of the dispute - use a whitelisted dispute tag - you can check event logs on the blockchain explorer to see which dispute tags are whitelisted
    /// @param data The data to initialize the policy - here you can do abi.encode of liveness, token address and bond amount
    –
    After this step the dispute will be “open” to be countered by other users. If there is no counter UMA rules define that the IP will be considered to be infringing.

  2. Countering a dispute
    Call disputeAssertion() on ArbitrationPolicyUMA.sol. Pass in the following inputs:
    –
    /// @param assertionId The identifier of the assertion that was disputed
    /// @param counterEvidenceHash The hash of the counter evidence - this can be an IPFS bytes32 hash - this is the document with the counter proof that UMA reviewers will read
    –
    After this step the dispute is escalated and will be reviewed by external party UMA.

  3. UMA judges the dispute
    On this step the user just has to wait until the external party UMA makes the judgement. After the judgement is made anyone can call settleAssertion() on OptimisticOracleV3.sol to conclude the process.

  4. Optional step - Resolve dispute
    If the dispute initiator (address that originally raised the dispute) feels that the subject of the dispute has been resolved with the other party then the dispute initiator can call resolveDispute() on DisputeModule.sol. Pass in the following inputs:
    –
    /// @param disputeId The dispute id
    /// @param data The data to resolve the dispute - can be empty in the context of the ArbitrationPolicyUMA
    –

To simulate this process - at the current moment - you can use the blockchain explorer (equivalent to etherscan) on testnet. The only caveat on testnet is that step 3 needs to be simulated as the external party UMA does not make judgements on testnet. It can nevertheless still be simulated and you can see the steps in code for more detail in the unit tests of the arbitration policy UMA (ArbitrationPolicyUMA.t.sol).

All the above being said, a UX friendly platform to help with the dispute process is in the works. Stay tuned as we will share more updates as that work progresses.

6 Likes
3

thanks a lot for the clarification)

4

Thanks @spablob for great details

5

Wow…thanks for the explanation @spablob. Now I understand it, but one thing I didn’t have was about UMA and also the automatic dispute resolution process. Maybe I need to learn it first…