Following up from an external tg thread with an optional extension to the proposal**: an optional UIMultiplierUpdateCancelled event**
Over at Base, we’ve completed a full EIP-8056 integration to Base’s enshrined B20 asset standard, slated to go live at the next hardfork.
In so doing, we hit one observability gap: when an issuer schedules a UI-multiplier update via the pending-multiplier extension, there’s no signal if that pending update is later cancelled or superseded before it takes effect.
If a more urgent in-kind dividend or stock split takes precedence before the original pending update kicks in, operators must take steps to overwrite the original update with the more urgent one and then reschedule the original, later update.
Using only the current UIMultiplierUpdated event during this shakeup leads to a confusing event trail, liable to be misunderstood by offchain consumers. An indexer that sees the flurry of UIMultiplierUpdatedevents has no concrete avenue to reconstruct the timeline of multiplier updates offchain, conceivably leading the multiplier timeline to silently diverge from the actual occurrences or the operator’s intents.
We’d suggest a single optional event:
// OPTIONAL: emitted when a scheduled UI-multiplier update is cancelled or
// superseded before its effectiveAt.
event UIMultiplierUpdateCancelled(uint256 cancelledMultiplier, uint256 cancelledEffectiveAt);
// Suggested placement: optional event on IScaledUIAmount, alongside TransferWithUIAmount.
Deliberately just an event, no new function, to stay consistent with the spec on two fronts: the cancel mechanism stays implementation-defined (a la setUIMultiplier), and it mirrors the existing optional TransferWithUIAmount event. This suggestion is tailored to fit the spec’s existing shape & design decisions.
A separate point in favor of this suggestion:
BNB’s BEP-677 independently added scheduled-update + overwrite-audit events, and Solana’s original ScaledUiAmount has the same overwrite-a-pending footgun (with a documented two-transaction workaround) and no cancellation signal. The gap (and developers’ choices to fill it) has shown up in multiple implementations of this proposal.
Thanks again and let me know what you think !