Open
Description
Currently we are assuming that the dispute kit is at ID 1 in the subgraph code:
- localDisputeID = `1-${disputeID}`;
- disputeKitID = "1";
- Comment about ID 1
- export const DISPUTEKIT_ID = "1";
- classicDispute = new ClassicDispute(`1-${coreDisputeID}`)
- "decide which dispute kit to use"
We already have use-cases to support other dispute kit instance which behave like a Classic DK ("Classic-like").
Things needed
- implement the entities needed (basically check which ones have "Classic" as prefix, check which entities they are inheriting from, and make the equivalent )
- where we are calling this functions, check the extradata to get the dispute kit id, and depending on it, choose the correct entity (this could be done with a function that goes from
disputeKitId
todisputeKitName
, then use that name to dynamically choose the entity)
Then a few changes at the frontend level.
Assumption
All the deployments should have the same DisputeKits structure.
Otherwise if DisputeKit ID 2 is Classic-like on Devnet but not on Testnet, it would require some extra logic.