In the new version of std bounties 2.0, there needs to be an easy way to listen/index events that occur. In std bounties 1.0, this was simple. You could just listen to the deployed contract. This no longer is simple since the new PROXY architecture creates a new contract for every instance of a bounty. In turn, listening for an event does not become so easy (unless you specifically want to listen to the event from an array of ALL addresses in the current factory). Listening for all addresses becomes problematic and requires consistently checking for any new addresses to listen to. As more and more bounties are created, this approach becomes less and less scaleable.
Proposed solution:
The event should not be human readable. This is because a SHA Hash is created from the name of each event along with its argument types. This topic or hash can be used to index/listen for the event theme on chain. However, our event names could easily intersect with other events on other contracts. In order to prevent this confusion, non-human readable event names should be created so we can listen to the event and know it comes from std bounties 2.0
Additionally, topics are created for each argument (first 3) passed into the event. To allow for more flexibility on whoever is listening to the various contracts, we should make sure all events include the ID of the bounty contract in relation to the contract factory. This makes it so you can easily listen to events by ID without having to know the address.
cc: @mbeylin @c-o-l-o-r
In the new version of std bounties 2.0, there needs to be an easy way to listen/index events that occur. In std bounties 1.0, this was simple. You could just listen to the deployed contract. This no longer is simple since the new PROXY architecture creates a new contract for every instance of a bounty. In turn, listening for an event does not become so easy (unless you specifically want to listen to the event from an array of ALL addresses in the current factory). Listening for all addresses becomes problematic and requires consistently checking for any new addresses to listen to. As more and more bounties are created, this approach becomes less and less scaleable.
Proposed solution:
The event should not be human readable. This is because a SHA Hash is created from the name of each event along with its argument types. This topic or hash can be used to index/listen for the event theme on chain. However, our event names could easily intersect with other events on other contracts. In order to prevent this confusion, non-human readable event names should be created so we can listen to the event and know it comes from std bounties 2.0
Additionally, topics are created for each argument (first 3) passed into the event. To allow for more flexibility on whoever is listening to the various contracts, we should make sure all events include the ID of the bounty contract in relation to the contract factory. This makes it so you can easily listen to events by ID without having to know the address.
cc: @mbeylin @c-o-l-o-r