To give more freedom in using Bits, having a Bits escrow system would be great.
RFC0011 ( https://discuss.dev.twitch.tv/t/rfc-0011-extension-entitlement-service/19142 ) introduced that idea but was never implemented.

What would be the possible flows:
- A viewer sends Bits, that are put "on hold"
- The streamer cancels the action asked by the viewers (because the stream is ending for example)
- After some delay, the Bits are refunded to the viewer because the transaction was not validated.

-- Viewers send Bits, that are put "on hold"
- The streamer cancels the action asked by the viewers (because the stream is ending for example)
- The Extension backend send a cancelation order to Twitch, canceling the Bits transaction.
- The Bits are refunded to the viewer because the transaction was not validated.
- If the transaction is not canceled, the Bits are sent to the streamer after the cancelation period expires.

In a practical way, it would be nice to have a way to cancel a Bits transaction before a certain limit of time.
This way we can create experiences that are safer for broadcasters and viewers because they are guaranteed to have the Bits used only when the conditions are met.
We could also use this system to handle server-side errors to refund people that used Bits something went wrong.

As it stands currently today, whether you are building a large scale bot to connect to multiple channels, that is always on (think Streamlabs, StreamElements, etc), or a small bot specific for your channel, or perhaps somewhere in between, the only supported way to connect is via the channel name, which is tied directly to the Twitch username.

The problem that is faced is when one of those connected channel's broadcaster decide to change their username, thus changing the channel name as well, since now what the bot is listening for data on is non-existent. The way this is managed today is by utilizing webhooks to listen for user changes, and the moment a username has been updated, the webhook is notified, and the bot must sever the previous connection and establish a new connection to the new username.

What i propose is providing the capability to also allow connections to a channel based on the Broadcaster ID, being a numeric value that never changes over the lifetime of the twitch account's existence. By allowing this capability, an IRC bot could connect in via the ID, and stay connected, regardless of name changes, which saves on resources from both the bot and Twitch's side.

Good thing is that the data needed (i.e. the broadcaster ID) is already available on the helix endpoints for channels and users, so no modifications to the API would be needed!

The changes (from the outside looking in) would entail accepting a numeric based ID for the connect call, then updates to the IRC infrastructure to support it. I'm certain there could be a bit of finesse in how the data is translated to make the footprint minimal.

Overall gains: Ease of IRC bot management, less load on bot, less load on Twitch (no need for webhooks just for username changes)

Right now, most of the PubSub topics are inconsistent with each other (understandably so). This, however, is focusing on cleaning up some of the ChannelPoints event data that is either unnecessary, redundant, or unclear:

As a note, the information stripped away from the structure is not invalid data, but rather data we likely don't need per message and instead should have a fetch api like manner. One example is the image objects that are likely to never change in the lifetime of a reward. This would save needless encoding as well as any data costs there may be on either side. When discussing ~512 bytes, some people will assume that is not a lot, but when scaling that up to something that people have no monetary requirement to activate, then we are talking about data sizes several magnitudes larger across the site.

Example of new structure concept:

Cleaned up structure:

{

    "Time": string,

    "Id": GUID,

    "Channel": User (see below),

    "Reclaimer": User,

    "UserInput": string,

    "Status": string, -- ONLY If we can receive things other than "FULFILLED"    

    "Reward":{

        "Id": GUID 

        "Name": string

        "Prompt": string

        "Cost": int,

        "MaxLimit": int, -- 0 if no limit is present.

        "CurrentCount": int

    }

}    


User Structure:

{

    "User": {

        "DisplayName": string

        "UserName": string

        "Id": GUID (currently an int encoded as a string)

    },

}