You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 to disputeKitName, 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.
The text was updated successfully, but these errors were encountered:
jaybuidl
changed the title
Subgraph: support for other Dispute Kits at id > 1
Subgraph: support for Classic-like Dispute Kits at id > 1
Apr 9, 2025
Currently we are assuming that the dispute kit is at ID 1 in the subgraph code:
We already have use-cases to support other dispute kit instance which behave like a Classic DK ("Classic-like").
Things needed
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.
The text was updated successfully, but these errors were encountered: