At the moment, the scraper has been writing 20-byte hex addresses to the DB.
As we prepare to support other execution environments, we'll start writing addresses (e.g. for the message sender, recipient, mailbox addresses, etc) as 32 byte hex addresses that are then expected by the UI to correctly format. We make this 32-byte address assumption throughout our protocol already & have logic to format addresses appropriately for each protocol, so I think this is the most natural step forward
The postgresByteaToString function is used and the length isn't checked for addresses - I believe we'll need to move to using some of the utils functions to format these for the chain's protocol type
To begin with, I think we can make this change but continue to assume that only Ethereum chains are shown in the explorer - so really it'd be to handle reading 32 byte addresses but show them as 20 byte addresses
Part of the effort required for Cosmos scraping / explorer -- see https://github.com/hyperlane-xyz/hyperlane-monorepo/issues/3330 for the agent side
At the moment, the scraper has been writing 20-byte hex addresses to the DB.
As we prepare to support other execution environments, we'll start writing addresses (e.g. for the message sender, recipient, mailbox addresses, etc) as 32 byte hex addresses that are then expected by the UI to correctly format. We make this 32-byte address assumption throughout our protocol already & have logic to format addresses appropriately for each protocol, so I think this is the most natural step forward
The
postgresByteaToStringfunction is used and the length isn't checked for addresses - I believe we'll need to move to using some of the utils functions to format these for the chain's protocol typeTo begin with, I think we can make this change but continue to assume that only Ethereum chains are shown in the explorer - so really it'd be to handle reading 32 byte addresses but show them as 20 byte addresses