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
There is already an issue mention this idea #2318
But I'm create a dedicated issue as this might be a larger refactoring out of the scope of the issue above.
This issue can also be focused for EVM chains at first.
The way the observer observes the different types of event for inbound/outbound/outbound reverts should be pretty generic for all.
The idea of this issue is to separate the "what" from the "how", and keeping a list of events to observe in a declarative way.
This issue would simplify adding new events for example in the context of supporting the new smart contract design.
The issue is specific for observation, but a similar design could be thought for the signing part. Separating what to sign and how to sign
Considered Outcome
Keeping on the observer package a map/list of the event with cctx type associated (to initiate the inbound/outbound vote), when then have a method to observer the event.
This example is specifically for the new smart contract design.
var map eventMap {
"deposit": [DepositCCTXData], // allow to initiate the inbound vote for a deposit to ZetaChain
"depositAndCall": ...,
"call": ...,
}
...
func Observer(evmClient, eventMap) {
// actual logic parsing the events
}
The text was updated successfully, but these errors were encountered:
Describe the Issue
There is already an issue mention this idea #2318
But I'm create a dedicated issue as this might be a larger refactoring out of the scope of the issue above.
This issue can also be focused for EVM chains at first.
The way the observer observes the different types of event for inbound/outbound/outbound reverts should be pretty generic for all.
The idea of this issue is to separate the "what" from the "how", and keeping a list of events to observe in a declarative way.
This issue would simplify adding new events for example in the context of supporting the new smart contract design.
The issue is specific for observation, but a similar design could be thought for the signing part. Separating what to sign and how to sign
Considered Outcome
Keeping on the observer package a map/list of the event with cctx type associated (to initiate the inbound/outbound vote), when then have a method to observer the event.
This example is specifically for the new smart contract design.
The text was updated successfully, but these errors were encountered: