You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A few months back I made a PR to create fungible.transfers but it got turned down because you guys wanted to build it internally. My main issue with tokens.transfers is that it includes both fungibles and NFTs which given their different implications are basically never analysed together.
For nft transfers i made nft.transfers quite some months ago which is faster to use than tokens.transfers.
What would be cool would be to have materialised fungible.transfers tables including a crosschain one. Including NFTs in the latter would really slow down any analysis using it, and current tokens.transfers tables are slowed down because of NFTs too.
The same can be done with balances tables but i don't use balances tables really anyways since they're more accurate if I make them myself in query (they're missing staking withdrawals, block rewards, uncle rewards, rebase events)
I just checked, tokens.transfers only contains native and erc20 data, not NFT?
Balances do include both tokens and erc20s in 1 schema. We had some discussions about splitting them but decided against it to keep it more maintainable (and the performance gain with splitting was negligible due to the low amount of NFT data in those tables)
tokens.transfers should aim to serve whatever you wanted to do with fungible.transfers, so if there are other shortcomings, we definitely want to know!
Yeah we planned on putting nft transfers in token.transfers but decided never actually did it, and sounds like we shouldn't.
The same can be done with balances tables but i don't use balances tables really anyways since they're more accurate if I make them myself in query (they're missing staking withdrawals, block rewards, uncle rewards, rebase events)
Our balances are not sums of transfers, they are the actual values you'd get from doing eth_call/getBalance against a node. So if there's a value for a block number it should be the correct value. However, there needs to be an event we track so that we can get the value. ETH withdrawals are tracked but not rebase events for specific tokens for example.
A few months back I made a PR to create
fungible.transfers
but it got turned down because you guys wanted to build it internally. My main issue withtokens.transfers
is that it includes both fungibles and NFTs which given their different implications are basically never analysed together.For nft transfers i made nft.transfers quite some months ago which is faster to use than tokens.transfers.
What would be cool would be to have materialised
fungible.transfers
tables including a crosschain one. Including NFTs in the latter would really slow down any analysis using it, and current tokens.transfers tables are slowed down because of NFTs too.The same can be done with balances tables but i don't use balances tables really anyways since they're more accurate if I make them myself in query (they're missing staking withdrawals, block rewards, uncle rewards, rebase events)
what are your thoughts @jeff-dude @aalan3 @0xRobin?
The text was updated successfully, but these errors were encountered: