-
Notifications
You must be signed in to change notification settings - Fork 12
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
feat(template): More detailed template. #142
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks promising, thanks!
/// You may want to ignore LP tokens if your protocol emits transfer events for these | ||
/// here. | ||
#[substreams::handlers::map] | ||
fn map_relative_component_balance( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In my experience this part is one of the hardest to do well because it requires a deep understanding of the protocol logic (we had many wrong TVL bugs because of this in the past, almost for each integrated protocol IIRC).
I'm wondering if it makes sense to provide such a logic when it's not fully generic. For example, the code below won't work if they use a "vault pattern" like balancer, ambient or uniswapv4.
Maybe we should instead provide some SDK helpers? This looks very similar to our extract_balance_deltas_from_tx
sdk function overall
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I want to show a concrete example here of how this could be managed. Yes ideally this is handled through protocol events and yes if you can transfer internal balances within a vault this won't work either. I will add this case to the notes on the docs.
But I think it is very valuable to have sth to start off from that actually works.
About extract_balance_deltas_from_tx
do you know where it is used? I would like to limit this one to a set of tokens also in the singleton
case it wouldn't work because we'd need to extract the pool id from the call data...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
extract_balance_deltas_from_tx
is only used in Curve as far as I know. Not 100% sure if any of the currently opened PRs used it, but I think it's quite unlikely
Ok what you proposed sounds good. I was just worried that people would see this and try to make it fit where it can't.
In the singleton case unfortunately we there is no generic way to witness balance changes, it really depends on the protocol's events
/// transfer to the component is detected, it's balanced is increased and if a balance | ||
/// from the component is detected its balance is decreased. | ||
/// | ||
/// ## Note: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Small note that might be worth to add: we usually only account for any token balance that is "active" - meaning used during the swap logic. For example on uniswapv3/4, collected fees aren't taken into account during swaps so we don't account for them
2a6db16
to
e06df46
Compare
Add a more detailed protocol implementation in the template. This should allow more ppl to get started quicker. Additionally more people will follow a predetermined structure
e06df46
to
3b8d4e6
Compare
Separate templates and add one for protocols with only a single contract.
3b8d4e6
to
6e06c05
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Look good to me! 🔥
Add a more detailed protocol implementation in the template. This should allow more ppl to get started quicker. Additionally more people will follow a predetermined structure