[Proposal] `bridge.flows` standardization

[lgingerich]

dex.trades and nft.trades have become extremely important tables on Dune. Another area which I would like to bring more visibility to is bridge activity. There does currently exist a bridge.flows table, but given that only Hop and the Optimism native bridge are included, and it currently has the prod_exclude tag, I think it's fair to say that it's not being too actively maintained.

There are two items I would like to discuss here:

1. Table schema
2. Tracking perspective of cross-chain transactions

Table Schema

The current bridge.flows schema can be found here.

In my opinion, it largely includes everything I would want to see, but it feels bloated.

• In both of the Hop and Optimism tables, trace_address is either hard-coded or empty.
• sender is mostly empty
• fee_amount, fee_amount_usd, and fee_amount_raw are mostly empty
• evt_index — is this actually useful for anything?
• transfer_id — the schema states that this is a "Unique ID used to tie bridge events together across chains". I'm not sure if this is actually possible to do in all cases.

There may be good reasons to include all of the above, but I'd like to have discussion on this before blindly carrying them along through more spells.

Tracking perspective of cross-chain transactions

Let's consider an example where I want to bridge from Ethereum to Chain_XYZ. Should I use Ethereum or Chain_XYZ tables to track this bridge event?

The best chance of accurately decoding all bridge transactions and getting the most complete data is likely by looking at data from the perspective of which chain the bridge transaction originates from. There's a few immediate reasons I can think of that makes this true:

• Users pay fees on the originating chain, not the receiving chain
• Native bridges do not necessarily emit an event when receiving an incoming bridge transaction.
  • As I started looking into this for the zkSync Era Native Bridge, I've struggled to properly decode ETH bridge events coming into zkSync Era. The only pattern I've identified to be able to potentially track this is to find transactions with a mint event, then a transfer event, where zksync.transactions.data = 0x. This does not feel constrained enough to be confident that it is only getting bridge events. However, it is very simple to track Ethereum -> zkSync bridge events, if tracked from the perspective of Ethereum tables.

One major disadvantage of tracking from the perspective of the originating chain is that there's no guarantee that the funds actually arrive on the receiving chain.

I'm a fan of measuring from the perspective of the originating chain, but there's likely many more pros and cons that I'm not considering.

---

There's a lot to consider here in how to best design this going forward, especially given the major constraint that Dune will only ever support a limited amount of chains.

Tagging people here that are likely to have opinions/advice/knowledge on how to best do this. @MSilb7 @soispoke @henrystats @hildobby @0xRobin @jeff-dude

Thank you in advance for your help!

[MSilb7]

We are querying from the table, so it's not dead. It was attempted to be migrated but the PR got closed in favor or other things and it wasn't picked up.

In both of the Hop and Optimism tables, trace_address is either hard-coded or empty.

This was added because it's included in other tables, such as dex.trades

sender is mostly empty

This may be useful for cross-chain communication if/when it's mapped. Again I believe this was to map to dex.trades

fee_amount, fee_amount_usd, and fee_amount_raw are mostly empty

The OP standard bridge does not charge a fee (I imagine all standard L2 bridges do not), which is why it's empty. But cross-chain bridges will charge LP fees, which I believe to be relevant.

evt_index — is this actually useful for anything?

Useful for ranking, and matches dex.trades

transfer_id — the schema states that this is a "Unique ID used to tie bridge events together across chains". I'm not sure if this is actually possible to do in all cases.

Why is it not possible to have a unique id? I imagine this could also be useful for unifying transactions across chains (i.e. join a message from chain A being received on chain B)

Users pay fees on the originating chain, not the receiving chain

Feels too early to know if this will always be true.

Native bridges do not necessarily emit an event when receiving an incoming bridge transaction

This is why each native bridge should have it's own model (similar to DEXs)

Overall thought: Bridges are SUPER complicated and it would a huge benefit to get some agreed schema and have 3P bridges mapped (there was interest back then). So I'm all for having great mapping for 3P bridges. We can look at Defillama's aggregate data for a ranking on priority.

[lgingerich]

I haven't kept up too well with the recent and ongoing changes for dex.trades, but it does make sense to align this bridge schema with that. Here's the latest schema (link) — not sure if there are any more major changes still being made.

In both of the Hop and Optimism tables, trace_address is either hard-coded or empty.

This was added because it's included in other tables, such as dex.trades

I don't see trace_address in the new dex.trades schema, so I think it's fine to get rid of unless it's actively being used or has a planned use.

sender is mostly empty

This may be useful for cross-chain communication if/when it's mapped. Again I believe this was to map to dex.trades

The schema here says the sender is the "Address of the wallet sending the transfer". Shouldn't this never be null?

fee_amount, fee_amount_usd, and fee_amount_raw are mostly empty

The OP standard bridge does not charge a fee (I imagine all standard L2 bridges do not), which is why it's empty. But cross-chain bridges will charge LP fees, which I believe to be relevant.

Agree, I'm good with keeping this.

evt_index — is this actually useful for anything?

Useful for ranking, and matches dex.trades

Good to keep as it is in dex.trades

Why is it not possible to have a unique id? I imagine this could also be useful for unifying transactions across chains (i.e. join a message from chain A being received on chain B)

Unless a bridge itself passes a unique id with each transaction, I don't know how to reliably match transactions sent on one chain and arriving on another. If I send two bridge transactions of equal value, same token, from the same address, right after each other, the only way to match them cross-chain is based on time ordering, but it's not a guarantee that this correctly matches the transactions. Maybe there's something I'm not considering that does make this possible.

Users pay fees on the originating chain, not the receiving chain

Feels too early to know if this will always be true.

Agree, good point. Now that you say this, I think I remember Wormhole having a fee to claim your funds on the receiving chain.

I didn't think about it initially, but I would also like to include an address field for the bridge contract address. Is one of tx_from, tx_to, sender, or receiver already supposed to handle this?

-- RE: what chain perspective to track events from. Is it necessary that we come to an agreed upon method or can it just be whatever works best for each bridge?