Update ERC-8056: add optional UIMultiplierUpdateCancelled event

[robriks]

Adds an optional UIMultiplierUpdateCancelled event to ERC-8056, as dscussed on the ERC-8056 thread: comment #15.

Motivated by a full ERC-8056 integration in Base's B20 asset standard.

What it adds

When an issuer schedules a UI multiplier update via the Pending Multiplier extension (newUIMultiplier / effectiveAt), the spec today has no signal if that pending update is later cancelled or superseded before it takes effect. An indexer that observed the scheduling UIMultiplierUpdated has no on-chain way to tell the schedule was withdrawn or replaced, so its projected multiplier timeline can silently diverge from what actually happens on chain.

// OPTIONAL: Emitted when a scheduled UI multiplier update is cancelled or superseded
event UIMultiplierUpdateCancelled(uint256 cancelledMultiplier, uint256 cancelledEffectiveAt);

Deliberately an event only, with no accompanying function:

• The cancellation mechanism stays implementation-specific, consistent with how setUIMultiplier is already left to the issuer.
• It follows the existing TransferWithUIAmount precedent, an optional event on the core interface. Events do not affect interface IDs, so there are no interface ID changes and no new extension interface.
• Zero cost for issuers who never schedule or cancel.

Changes

• Core interface: the optional event.
• The note under the core interface: cancellation is likewise implementation-specific, and implementations that support it SHOULD emit the event.
• Reference implementation: emits the event when a not-yet-effective pending update is superseded, adds a cancelUIMultiplierUpdate() example, and aligns the setUIMultiplier branch boundary with uiMultiplier() (>=) so an update that has just become effective is no longer treated as still pending.
• Rationale: the optional-events note now covers both optional events.

On that last item: uiMultiplier() treats a pending update as effective at currentTime >= _effectiveAt, but setUIMultiplier branched on >. At exactly currentTime == _effectiveAt the update has taken effect yet fell into the "still pending" branch, where it would be discarded and reported with a stale oldMultiplier. Aligning the boundary also keeps the new event from firing for an update that already took effect.

Context

The same gap has surfaced independently elsewhere: BNB's BEP-677 added scheduled-update and overwrite-audit events, and Solana's original ScaledUiAmount has the same overwrite-a-pending behavior with a documented two-transaction workaround and no cancellation signal.

[eip-review-bot]

File ERCS/erc-8056.md

Requires 1 more review from Authors: @cridmann, @gretzke, @tinom9