Open greenlucid opened 10 months ago
Arbitrable could emit it before calling createDispute
We can't prevent anyone from writing/deploying/running a buggy arbitrable which emits events at the wrong time without respecting the protocol. As long as it doesn't impact the arbitrator it's fine.
Arbitrator frontends could have issues listening to the event
This problem is already solved by the current court implementation
Arbitrators should absorb most of the complexity related to dispute resolution. The least complexity is leaked into the Arbitrable developers, the more scalable and practical of a solution the Arbitrator is.
I agree, that's the intention with the current design.
https://github.com/kleros/kleros-v2/blob/7f8be8eccf53f865fa85cbcab810110f974370d7/contracts/src/arbitration/interfaces/IArbitrableV2.sol#L19
When the
_templateId
or_templateUri
is emitted on the Arbitrable, it creates a dependency thatThese are the errors this could lead to:
createDispute
, leading to indexing issues if indexing solutions (e.g. The Graph) create the data sources before the event can be listened toNot sure what the best approach is, but an alternative could be to change
to:
(same consideration for the native token entry function)
or something to that effect, so that there is an stronger connection to the required dispute context, to the dispute itself. This would remove reliance on the event, and the templateId / templateUri could be propagated to the Arbitrator to handle it internally, cross-chain if necessary.
Note this continues to require the Arbitrable to store data internally, related to the relayed
_templateId
or_templateUri
, and it would be less gas efficient