The PI search used to execute only on chains the user manually added to their local instance.
Now, the search executes on all PI chains from the registry, which will grow quickly.

Searching 20+ chains simultaneously will likely be untenable and we'll need a better solution for this.

Related: #43

Support for delivery checking of pending solana messages

We're running a Hyperlane PI on a custom EVM network (Axon ), whose RPC client is not capable of responding to eth_getLogs { startBlock = 0, endBlock = latest) quickly enough, and fails with a 504 gateway timeout. While we can request the performance improvement of the Axon clients, maybe a better solution would be if Hyperlane explorer could index logs by block ranges of 500-1000 blocks. With an all-blocks query, very popular Mailboxes will fail anyway (imagine 1M+ messages)

There is some limited test coverage but especially as we start to invest in multi-protocol explorer support, the test coverage must be improved

I've added a PI chain, however it's not appearing in the list of supported chains within the Explorer as per the below gif

Then the examples also don't take into account of the new Explorer type (Etherscan)

https://docs.hyperlane.xyz/docs/build-with-hyperlane/explorer/configuring-pi-chains

Instead of the simple blur and replace we have now, instead have the new messages add in and smoothly push older messages down

Support for delivery debugging of pending solana messages

Logo currently shows as ?

From https://discord.com/channels/935678348330434570/961710804011458621/1085799205391568906

Explorer told me that the recipient address is not a contract, but on Goerli network, this address is indeed a HyperERC721 contract "0xcb6ddab87576373cd973c5b6a01def668bb9cd69 "

The actual problem was that the message was reverting on the destination, which it seems was not correctly surfaced to the user. Not sure if there's a bug or what but we should do a quick poke around and see if anything stands out

Problem

• ISM verification is opaque on explorer

Solution

• Leverage https://github.com/hyperlane-xyz/hyperlane-monorepo/tree/main/typescript/sdk/src/ism/metadata to decode metadata passed to mailbox.process by the relayer

Nice to Have

• Render ISM config visually

Removed because destination-based or clauses are causing too much database load
Queries will need to be restructured into multiple requests

Support for delivery debugging of pending cosmos messages

Problem

• Warp route messages are opaque on the explorer

Solution

• Leverage hyperlane-xyz/hyperlane-monorepo#3784 to decode message bodies for warp route messages

Nice to Have

• Fetch warp route from registry and render additional metadata (eg collateral token metadata, chains connected, etc?)

Support for search and display of messages on solana chains

Currently it imports CoreChains from the Registry lib to determine if scraped. It would be better to query the DB for this information.

Once this is done, remove the hard-coded CoreChains list from the registry as it's no longer needed.

https://discord.com/channels/935678348330434570/935678739663192184/1241041835976294442

In response to abuse discussed here: https://discord.com/channels/935678348330434570/1244947293392736387/1244953319391236108

Options include authentication, rate limiting, DDoS protection services, or privatizing the API entirely.

Not 100% sure where the data query came from, but Mitosis was trying to see that Mode <-> Ethereum messages were being delivered using the following explorer links:

Mode -> Eth message: https://explorer.hyperlane.xyz/message/0xdd4bda8543ef00a9ced3d6d8e35dd93fd2d921407b7f17110148fa3cbd0e8349?data=eyJzdGF0dXMiOiJwZW5kaW5nIiwiaWQiOiIzMTc2NTAwIiwibXNnSWQiOiIweGRkNGJkYTg1NDNlZjAwYTljZWQzZDZkOGUzNWRkOTNmZDJkOTIxNDA3YjdmMTcxMTAxNDhmYTNjYmQwZTgzNDkiLCJub25jZSI6MCwic2VuZGVyIjoiMHg1ODcwMDZjNmJhN2NlMjY5OTFiZjdmZDY2OThhNzU2MTU3OGFjNThhIiwicmVjaXBpZW50IjoiMHgzNmZkYTk2NmNmZmZmOGE5Y2RjODE0ZjU0NmRiMGU2Mzc4YmZlZjM1Iiwib3JpZ2luQ2hhaW5JZCI6MzQ0NDMsIm9yaWdpbkRvbWFpbklkIjozNDQ0MywiZGVzdGluYXRpb25DaGFpbklkIjoxLCJkZXN0aW5hdGlvbkRvbWFpbklkIjoxLCJvcmlnaW4iOnsidGltZXN0YW1wIjoxNzE0MDM5NTgxMDAwLCJoYXNoIjoiMHhlOTZjZjIzMmZkMmRhNmVkZGM1NGU1ZGY5NTYyYjU4OGFkMGU3YzQ0MDQ0MWRmNmRiNDZiYWE0ZTYyMDM3YjZmIiwiZnJvbSI6IjB4NTg3MDA2YzZiYTdjZTI2OTkxYmY3ZmQ2Njk4YTc1NjE1NzhhYzU4YSJ9LCJpc1BpTXNnIjp0cnVlfQ==

Eth -> Mode message: https://explorer.hyperlane.xyz/message/0xa61982c88ab45e46733f2f71d64fa9abe76d1aa55b60b96907c0f6035e56fec0?data=eyJzdGF0dXMiOiJwZW5kaW5nIiwiaWQiOiIzMTc2Njc1IiwibXNnSWQiOiIweGE2MTk4MmM4OGFiNDVlNDY3MzNmMmY3MWQ2NGZhOWFiZTc2ZDFhYTU1YjYwYjk2OTA3YzBmNjAzNWU1NmZlYzAiLCJub25jZSI6MjIwOSwic2VuZGVyIjoiMHg1ODcwMDZjNmJhN2NlMjY5OTFiZjdmZDY2OThhNzU2MTU3OGFjNThhIiwicmVjaXBpZW50IjoiMHgxMjU4MmM3YjBmNDNjNmE2NjdjYmFhN2ZhOGIxMTJmN2ZiMWU2OWYwIiwib3JpZ2luQ2hhaW5JZCI6MSwib3JpZ2luRG9tYWluSWQiOjEsImRlc3RpbmF0aW9uQ2hhaW5JZCI6MzQ0NDMsImRlc3RpbmF0aW9uRG9tYWluSWQiOjM0NDQzLCJvcmlnaW4iOnsidGltZXN0YW1wIjoxNzE0MDM5Nzc1MDAwLCJoYXNoIjoiMHgxNTUwMDNlMWFjMzY1MWJlYmY3MjhkMzUwYzVkODM3NjkwODY5OWRjZGIwMDNkYmIzZjg4NzFlMjZiOGE5MTcxIiwiZnJvbSI6IjB4NTg3MDA2YzZiYTdjZTI2OTkxYmY3ZmQ2Njk4YTc1NjE1NzhhYzU4YSJ9LCJpc1BpTXNnIjp0cnVlfQ==

The message content and delivery status isn't shown, however if you remove the data, then all is fine:

Mode -> Eth https://explorer.hyperlane.xyz/message/0xdd4bda8543ef00a9ced3d6d8e35dd93fd2d921407b7f17110148fa3cbd0e8349

Eth -> Mode https://explorer.hyperlane.xyz/message/0xa61982c88ab45e46733f2f71d64fa9abe76d1aa55b60b96907c0f6035e56fec0

We are currently scraping Mode but the explorer does not yet have it in its chain metadata

Chain filtering may be currently broken

Problems to solve:

1. New permissionless deployments from registry
2. Too much testnet traffic in the feed
3. Too many chains in the filter list
4. Needing to press apply is annoying
5. Not clear what filters are active

https://hasura.io/docs/latest/auth/authentication/index/

Currently deciding btwn webhook or JWT

We're scraping mantapacific now and should add it to the UI

Part of the effort required for Cosmos scraping / explorer -- see hyperlane-xyz/hyperlane-monorepo#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 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

Example, mumbai -> goerli:
https://explorer.hyperlane.xyz/message/0xc809f5e01a53782be251ee9e39202ae9382ac541c74812007ea4b91a3df491aa

For some reason the revert reason isn't showing in the explorer, but it shows in the relayer:

ContractError(MiddlewareError(MiddlewareError(MiddlewareError(JsonRpcClientError(JsonRpcError(JsonRpcError { code: 3, message: \"execution reverted\", data: Some(String(\"0x815e1d64\")

Maybe related to the use of custom errors?

Support for delivery checking of pending cosmos messages

Support for search and display of messages on cosmos chains

Need to wrap up rebrand changes and then change hyperlane.xyz DNS settings to get explorer.hyperlane.xyz live