Current balance in SEP41 events

[orbitlens]

Problem:
There is no straightforward way for downstream systems to validate current SEP41 token balance for any given address without complete history reingestion. Classic trustline balances emit XDR ledger entry changes upon updates, providing a consistent way to ensure that the balance is correct at any given point in time. This also allows "partial" processing (for a subset of addresses) or backfill processing (starting from the latest transaction). With SEP41 tokens, processing every transaction sequentially and doing the balance changes math is the only way to determine correct balance amounts. It poses significant challenges for indexers, especially given that they need to process transactions older than 1 year.

Possible solution:
Extend signature of standard transfer, mint, burn, clawback events to include address balances after update. Definitions of transfer and mint events already have an option to use map in the event body instead of a single i128 amount value. This approach can be utilized for post-update address balances as well. The exact specification and field names is up to debate.

[orbitlens]

Related thread

[leighmcculloch]

More related threads where balances were discussed:

• Tokens emit Balance event #1591
• [CAP-67] Classic Ops emit Transfer/Mint/Burn/Clawback events #1553 (reply in thread)
• [CAP-67] Classic Ops emit Transfer/Mint/Burn/Clawback events #1553 (reply in thread)
• Custom tokens should standardize how balances are stored #1592

[orbitlens]

Thanks for the references. Should have searched before creating the new one. I checked only open discussions.

[chowbao]

I'm in full support of adding balance to events.

iirc no matter what solution we have to have to add balances we'll have the issue that smart contract events are hashed in the ledger so it's really awkward/difficult to change those. It's also awkward/difficult to have all existing SACs and custom contract tokens upgrade to emit the modified/new events. Also note that some smart contracts are not upgradable because there was no path to upgrade built into the contract when the contract was deployed. This may be an oversight from the developer deploying the contract but we should still have some path forward for them if they were SEP-41 compliant but now need to modify their events.