-
Notifications
You must be signed in to change notification settings - Fork 312
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CAP-0067 draft - Unified Asset Events #1613
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👏🏻
core/cap-0065.md
Outdated
|
||
## Simple Summary | ||
|
||
Emit transfer events in Classic in the same format as what we see in Soroban so that the movement of assets can be tracked using a single stream of data. In addition to emitting events in Classic, update the events emitted in the Stellar Asset Contract to be semantically correct and compatible with SEP-41. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Classic will need to emit other events also:
Emit transfer events in Classic in the same format as what we see in Soroban so that the movement of assets can be tracked using a single stream of data. In addition to emitting events in Classic, update the events emitted in the Stellar Asset Contract to be semantically correct and compatible with SEP-41. | |
Emit `transfer`, `mint`, `burn`, `clawback`, `set_authorized`, `fee` events in Classic in the same format as what we see in Soroban so that the movement of assets can be tracked using a single stream of data. In addition to emitting events in Classic, update the events emitted in the Stellar Asset Contract to be semantically correct and compatible with SEP-41. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah wait, I didn't add the set_authorized
event to this CAP because it isn't required to track balances. What's the reasoning to include it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, yes, fair enough.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@sisuresh I had a moment above and forgot why we had included set_authorized. I understand it's a bit of an oddity given it's the one operation and event not involving the movement of value.
The why behind including it was that while this looks like we're just solving an issue with tracking balances, we're actually solving a slightly larger story about the things that classic and soroban both do, but then emit data about those happenings in different ways. Set authorized is an event that soroban emits, for something that happens both on soroban and classic, and the event when emitted only for soroban occurrences is a footgun and quite useless for downstream systems if it isn't also emitted for the classic occurences, much the same to transfers.
Co-authored-by: Leigh McCulloch <[email protected]>
|
||
For a movement not involving the issuer: | ||
``` | ||
contract: asset, topics: ["transfer", from:Address, to:Address, sep0011_asset:String], data: amount:i128 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This needs clarity on who from
and to
are, here
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll address this in a follow up
No description provided.