-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Proposal] bridge.flows
standardization
#4828
Comments
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.
This was added because it's included in other tables, such as dex.trades
This may be useful for cross-chain communication if/when it's mapped. Again I believe this was to map to dex.trades
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.
Useful for ranking, and matches 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)
Feels too early to know if this will always be true.
This is why each native bridge should have it's own model (similar to DEXs) Overall thought: |
I haven't kept up too well with the recent and ongoing changes for
I don't see
The schema here says the
Agree, I'm good with keeping this.
Good to keep as it is in dex.trades
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.
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? -- |
dex.trades
andnft.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 abridge.flows
table, but given that only Hop and the Optimism native bridge are included, and it currently has theprod_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:
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.
trace_address
is either hard-coded or empty.sender
is mostly emptyfee_amount
,fee_amount_usd
, andfee_amount_raw
are mostly emptyevt_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:
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!
The text was updated successfully, but these errors were encountered: