-
Notifications
You must be signed in to change notification settings - Fork 17
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
initial compound workflow #80
base: dev
Are you sure you want to change the base?
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.
Nice stuff! Left a few comments.
One thing to note, when referencing other workflows, certain logic may only be applicable to that particular workflow so assess accordingly while copying
|
||
step1 = RunnableStep("confirm_borrow", WorkflowStepUserActionType.tx, f"{self.token} confirm borrow", self.step_1_confirm_borrow) | ||
|
||
steps = [step1] |
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.
For single-step workflow may not be ideal to use MultiStepWorkflow abstraction, since we don't have a single step abstraction yet, you could implement something similar to what we have for the Aave workflow
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.
post_body = route.request.post_data | ||
|
||
# Intercepting below request to modify timestamp to be 5 minutes in the future to simulate block production and allow ENS web app to not be stuck in waiting loop | ||
if "eth_getBlockByNumber" in post_body: |
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.
Is this special handling required for Compound?
I added it for ENS as its logic has a wait time between steps and relied on block production as a trigger to proceed to next step
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.
Not specific to Compound, thought it is common to protocols.
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.
It's special handling for ENS, not sure about Compound, double check and if not needed, you can remove the entire overridden function _forward_rpc_node_reqs
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 rechecked this, Compound is using this function
self.token = workflow_params['token'] | ||
self.amount = workflow_params['amount'] | ||
|
||
step1 = RunnableStep("enable_supply", WorkflowStepUserActionType.tx, f"{self.token} enable supply", self.step_1_enable_supply) |
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.
For supplying tokens, if the token is non-ETH / ERC20 (like USDC, DAI, etc.), generally the user has to first give approval to the protocol to use their tokens so how is that approval step being handled?
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.
So step1 is for enabling the token's use on the platform. After step1 the user will have to approve the transaction from his/her wallet then it proceeds to step2.
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.
Ok , so how is the supply of the native ETH token being handled as that shouldn't require any approval and would only require a single step?
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.
Yea, so if the token is already enabled (if it native ETH or user enabled it before) then the step1 will return "success". See here: https://github.com/yieldprotocol/chatweb3-backend/blob/0b4cb5d3d8acced96062a1fd3244e5e26daba7fc/ui_workflows/compound/compound_repay.py#L78
@harshraj172 Can this PR be refactored to use the new UI abstractions? You can look at Aave supply and borrow modules for reference https://github.com/yieldprotocol/chatweb3-backend/tree/dev/ui_workflows/aave/ui_integration |
Okay @sgzsh269 , I refactor it according to the new UI abstractions. |
UI Workflow for Compound "Borrow", "Repay", "Supply" and "Withdraw".