Closed r3v4s closed 1 week ago
All modified and coverable lines are covered by tests :white_check_mark:
Project coverage is 63.77%. Comparing base (
4f27a57
) to head (36b767a
). Report is 3 commits behind head on master.
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
txtar for all 5 events 36b767af681588917cfa51a28d833daea2714732
@r3v4s
The EIP states 3 event types, none of which are Mint/Burn events; these are all transfer events. Why did you choose this approach?
I have a vague memory we talked about this in the GRC20 package as well; Transfer
should be able to cover all needed actions. What's the benefit of having distinct events for Mint/Burn?
@leohhhn I'm aware of EIP 3 event types, and do remember discussion we talked about GRC20.
And Yes, as you said Transfer
does cover all (mint, burn, transfer) but current GRC20 impls unique type, I just followed it.
IMHO, distinct event name sounds more straightforward.
@leohhhn As @notJoon described in #2749, we can reduce the number of RPC calls by retrieving only the specific event data we need (e.g., Mint
or Burn
). Otherwise, applications have to retrieve all Transfer
events and filter out the necessary data.
@r3v4s @dongwon8247
Sounds good! I remember.
Do you think it would be good to emit the Transfer event as well, to follow the standard? Or should we deviate?
I'm okay doing either if this makes it easier for off-chain services.
@r3v4s @dongwon8247
Sounds good! I remember.
Do you think it would be good to emit the Transfer event as well, to follow the standard? Or should we deviate?
I'm okay doing either if this makes it easier for off-chain services.
For now, I prefer not to(for 2 reasons).
std.Emit
spends gas
Description
Current event(emit) code in p/grc721 really doesn't emits event.
Therefore, modified code to emit the events.
And similar to #2749, made event type for each function to be unique.
Contributors' checklist...
- [ ] Added new tests, or not needed, or not feasible - [ ] Provided an example (e.g. screenshot) to aid review or the PR is self-explanatory - [ ] Updated the official documentation or not needed - [ ] No breaking changes were made, or a `BREAKING CHANGE: xxx` message was included in the description - [ ] Added references to related issues and PRs - [ ] Provided any useful hints for running manual tests