Conversation
sgzsh269
left a comment
sgzsh269
left a comment
There was a problem hiding this comment.
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.
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.
| 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.
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.
Not specific to Compound, thought it is common to protocols.
There was a problem hiding this comment.
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.
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.
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.
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.
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.
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. |
2 participants
UI Workflow for Compound "Borrow", "Repay", "Supply" and "Withdraw".