For detailed information on how UMA’s dispute resolution works, visit their website.
This arbitration policy is a dispute resolution mechanism that uses UMA’s optimistic oracle to verify disputes. Below we share a high-level overview of how the UMA dispute process works.

​
Smart Contract Flow Diagram

UMA Arbitration Flow
1

Raise Dispute

The first step to initiate a dispute against an IP Asset is to call the raiseDispute function on DisputeModule.sol. This function will in turn call assertTruth on UMA’s OptimisticOracleV3.sol. To initiate a dispute the dispute initiator will need to post a bond of at least the minimum bond defined by UMA for the selected currency. Note that this bond will be lost if the dispute is deemed not verifiably correct by the oracle.
UMA will be adjusting the minimum $IP bond size as the IP price fluctuates. The correct way to obtain the current minimum bond size is via getMinimumBond() on OptimisticOracleV3.sol (OOV3), found on our aeneid testnet and mainnet.
After this step, the dispute will be “open” to be countered/appealed by other users. If there is no counter/appeal, UMA rules define that the IP will be considered to be infringing.
DisputeModule.sol
/// @notice Raises a dispute on a given ipId
/// @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 CID 				converted to a bytes32 hash. This is the document with the proof that UMA reviewers will potentially read
/// @param targetTag The target tag of the dispute
/// @param data The data to initialize the policy - here you can do abi.encode of liveness, token address 	and bond amount
/// @return disputeId The id of the newly raised dispute
function raiseDispute(
 address targetIpId,
 bytes32 disputeEvidenceHash,
 bytes32 targetTag,
 bytes calldata data
) external returns (uint256 disputeId);
2

(Optional) Dispute Assertion / Counter Dispute / Make Appeal

After the raiseDispute call there is a period of time called “liveness” in which a counter dispute/appeal can be submitted. The liveness period is split in two parts: (i) the first part of the liveness period in which only the IP owner can counter dispute/appeal and (ii) a second part in which any address can counter dispute/appeal - which can be done by calling disputeAssertion on ArbitrationPolicyUMA.sol. To counter a dispute the caller will need to post a bond of the same amount and currency that was used by the dispute initiator when raising a dispute. Note that this bond will be lost if the original dispute is deemed to be verifiably correct by the oracle.After this step, the dispute is escalated and will be reviewed by external party UMA.
ArbitrationPolicyUMA.sol
/// @notice Allows the IP that was targeted with a dispute to dispute the assertion while providing counter evidence
/// @param assertionId The identifier of the assertion that was disputed
/// @param counterEvidenceHash The hash of the counter evidence
function disputeAssertion(bytes32 assertionId, bytes32 counterEvidenceHash) external;

/// @notice Returns the assertion id for a given dispute id
/// @param disputeId The dispute id
function disputeIdToAssertionId(uint256 disputeId) external view returns (bytes32);
3

(If step 2 happened) UMA Reviewers Judge the Dispute

UMA reviewers judge the dispute. On this step the user just has to wait until the UMA reviewers make the dispute judgement. This step could take 48-96 hours.
4

Settle Assertion

This step is expected to be automatic as UMA runs a bot that calls settleAssertion which in turn distributes the bonds back to the address that wins the dispute.
  1. If nobody submitted a counter dispute then when the liveness period is over, any address can call settleAssertion on UMA’s OptimisticOracleV3.sol.
  2. If somebody has submitted a counter dispute/appeal before the liveness period is over, then the dispute is escalated to UMA reviewers who will judge and make a decision on whether the IP is infringing or not. After the decision has been made, then any address can call settleAssertion on UMA’s OptimisticOracleV3.sol.

​
Dispute Evidence Submission Guidelines

When raising a dispute or making a counter dispute, both parties can submit dispute evidence. Dispute evidence refers to a text document that oracle participants will use & read from to make a judgement on the dispute.

​
Burden of Proof

In all disputes with UMA arbitration policy, the burden of proof lies with the party creating the dispute. This means that the disputer must provide clear, compelling, and verifiable evidence to prove the dispute beyond reasonable doubt. Disputes that do not meet this high bar can be counter-disputed with the disputing party losing their bond.

​
Document Characteristics

As the process is still experimental, we can expect iteration and fine-tuning on the contents/formats of how the evidence should be submitted.
Every document should have the following characteristics:
  • It should be a text document. Can have images or video if necessary.
  • It should be uploaded on IPFS.
  • It should not take the reviewer more than 1 hour to review the dispute evidence document - the reviewer’s time is limited and the evidence could be deemed invalid if it would take too much time to review. Best efforts will be applied to solve a dispute but please keep it concise to have your dispute evidence be valid.
Depending on what the type of the Dispute Tag is, you also need to include in the evidence the “Dispute Evidence Contents of the table below:
Dispute TagDispute Evidence ContentsDispute review process (Human reviewer instructions)
IMPROPER_REGISTRATIONA. Showcase or pointer to the pre-existing IP that is being infringed upon by the disputed IP

B. Proof of public display of the pre-existing IP at an earlier date than the infringing IP (onchain or offchain) and/or instructions on where/how to check it		1. Check if the pre-existing is the same or very similar to the disputed IP using input A
- Mickey Mouse with 1 pixel difference is an infringement
- Mickey Mouse with a new hat is an infringement unless it’s a derivative of the original Mickey Mouse with an appropriate license
2. Check the registration date of the pre-existing IP using input B
3. Confirm that the disputed IP has a later registration date
4. Confirm that the disputed IP is not a derivative of the pre-existing IP

IMPROPER_USAGE

Examples (non-exhaustive):
Territory,
Channels of Distribution,
Expiration,
Irrevocable,
Attribution,
Derivatives,
Limitations on Creation of Derivatives,
Commercial Use,
Sublicensable,
Non-Transferable,
Restriction on Cross-Platform Use		A. PIL term that has been violated

B. Description of the violation

C. Proof of the violation		1. Read the associated PIL term description on the PIL license official document using input A
2. Read the violation description using input B
3. Decide on the veracity of the proof presented by checking on associated platforms when possible using input C

IMPROPER_PAYMENTA. Description of each payment the disputed IP received that should have been shared with its royalty vault and/or its ancestors but it were not

B. Proof of those payments that were not properly shared as royalties		1. Check veracity of the proof of payments by checking on the associated platforms when possible using input A and B
2. If proof of payments are deemed to be real, confirm that the payment has indeed not been made onchain by checking on the blockchain explorer. Payments should be made calling payRoyaltyOnBehalf() function on RoyaltyModule.sol smart contract. In addition, royalty payments must be made within 15 days of when the capital was originally received by the owner/IP who is paying those royalties.

CONTENT_STANDARDS_VIOLATION

No-Hate,
Suitable-for-All-Ages,
No-Drugs-or-Weapons,
No-Pornography		A. The content standard point that has been violated

B. Description of the violation

C. Proof of violation		1. Read the associated content standards description on the official content standards section in the PIL using input A
2. Read the violation description using input B
3. Decide on the veracity of the proof presented by checking on associated platforms when possible using input C