Introduction

Envision a future where web3 technologies are widely adopted. Where each user engages with multiple Dapps, tokens, and chains as they normally would with typical apps. But instead of a centralized server keeping logs of your past interactions, it’s transparent and on-chain for you to view. In this future, we believe that it is necessary for the user to be able to have full transparency and accessibility of their own transaction history.

While most wallets do already provide users with a list of all the transactions and interactions made, wallets are extremely limited in that they only store the transactions of the wallet’s account. When users inevitably interact with multiple Dapps as well as use different wallet addresses, the flaw of not being able to see an overall picture of the user’s transactions becomes apparent.

Below are the 3 things to be aware of when designing for transparency and accessibility in user transaction history.

Accessibility of Transaction History

In e-commerce, it's quite common to see an order history page as the history page helps drive more conversions for habitual buyers. In your browser, the history page allows you to see what websites you’ve visited in the past and if need be, visit them again.

As you can probably tell, a history page is not just a page with a list of past interactions, it’s a page focused on providing the tools necessary for users to achieve their end goals.

In web3, transactions equal interactions. Whether it is you sending a bit of ETH for staking or using your governance tokens to initiate a proposal, all interactions are recorded on the blockchain ledger. If we want to have a future where transparency is a core constituent, allow users to inspect all transactions they have made with the smart contract from a given address.

Clarity in History Storage

On the other hand, if you are providing a user with their interaction history, then that means that the data of the transaction hashes are stored somewhere. The history can be stored on a database or on the user’s local indexDB.

In the spirit of transparency, you need to clarify to the user where this data is stored, as how it is stored may pose a potential privacy risk.

Tools for Navigation, Search, Export & Delete

Going back to what we’ve discussed previously with the different types of user end goals, you should also provide management tools that support the users in completing their end goals.

If we were to break down the typical goals a user has when visiting the transaction history page, the 2 most common goals would be:

• to view a particular transaction
• to remove records they deem unwanted

Empower the users by making these processes easier with common tools such as a search bar, filter options, the ability to export the history, and if possible the ability to delete certain data from their history list.

Conclusion

A history page is quite straightforward, and designers can pull from patterns that have been used extensively in e-commerce, fintech, browser history, etc.

The difference here with web3 transaction history is once again the principle of transparency. This requires you to think about how users will be using the list of past transactions and provide them with the necessary information and tools.

Keep in mind it's not just about showing past transactions, but also the whole history of interactions a user had.