Inspired by our learnings from creating human-readable transaction state changes at Blowfish and ERC-6384.

There should be a standardized on-chain read-only method on the same program as the programId associated with the IDL-encoded message called something like human_readable_message(typedData: Buffer) -> string which returns a template string such as Place limit order on {nativeAsset}/{splAsset:sellToken} orderbook for {nativeAssetAmount:buyAmount} at {splAssetPrice:buyPrice}/{nativeAsset} where the variables are in the format {entity:idlProperty} so that all template variables can map to a decoded IDL property but are further specified as a specific kind of entity. The reason for the entity specification is because just looking at the IDL definition (e.g., probability: float32) the wallet has insufficient information on how to render the value — should it be rendered as a decimal or a percentage? The entity mapping gives wallets a clear instruction as to how to render the value.

Doing that above would improve the user experience drastically, and the protocol would not have to worry about proper rendering of entities (incl. decimalized amount conversions, asset names/symbols, etc.) which should be handled by the signing UI.

Wallets would need to:

1. Design React components to render each of the possible entity types listed below:

   • address
   • storageAccount
   • nativeAsset
   • splAsset
   • compressedNftAsset
   • metaplexCoreAsset
   • nativeAssetAmount
   • splAssetAmount
   • date (can render humanized date representation)
   • duration
   • percentage
   • bigInt
   • string
   • bool

   As an example, addresses and accounts could simply be rendered as a link out to an explorer. Assets could be tokenized to include their respective icons in-line and on-hover show a tooltip with more information (e.g., USD price) and if clicked navigate the user to it’s info page. The data could be displayed in the user’s timezone and duration amounts localized. This would make the UI more information dense while still providing the user all the contextual information they need to understand a transaction’s implications.

Design / Prototype

These are designs of using this same basic idea of template strings to augment the rendering transaction state changes in Phantom wallet.

Swaps

Current design:

• Assets aren’t inspectable — i.e., cannot visit on block explorer, can’t see program address, no additional metadata

Proposed design:

• Make assets inspectable — clicking on the asset name/icon pulls up it’s token page.

Approvals

Current Design: