[QUESTION, WORKFLOW DISCUSSION] Liquid staking

[janniksam]

So, my project aims to liquid stake donations of my users.

Hatom offers me an endpoint to stake my EGLD and get back HsEGLD. In theory it sounds pretty straight forward to integrate it, but in reality it gives me some unbeatable challenges, which I currently can't solve. I also talked about it to Hatom developers, but they couldn't help me.

What should happen:

1. My users send EGLD to my donation SC.
2. The donation SC liquid stakes the donation and retrieves back information about if it was successful / it failed and how much HsEGLD I received from Hatom.
3. (not really relevant, but for the sake of completeness): When the user wants their money, I will do my magic and send them their donation back, while I keep all the rewards generated during the donation time-frame.

What actually happens:

This is the visualization of what gives me headaches. Imo this is a design flaw of the async call mechanics currently being supported by MVX:

(source: https://t.me/MultiversXDevelopers/112715)

1. My users send EGLD to my donation SC.
2. The donation SC liquid stakes the donation.
3. The Hatom Liquid Staking contract returns early with no useful information.
4. My SC never retrieves the information whether the workflow ended successfully or not and what tokens were sent.
5. I cant calculate the rewards later on, because I can't properly track staked HsEGLD and open EGLD besides having to rely on balances.

Whats your take on this. Can I do anything or can Hatom do anything to make this a reliable workflow?

Thanks in advance!

[lcswillems]

Hi @janniksam

When you delegate to Hatom SC, I think Hatom SC should immediately mint and send HsEGLD back to your SC, without you having to wait for them to delegate.

I think this is the best and simplest way to do it.

[sasurobert]

Hi. You will get the HsEGLD on your contract after the Hatom Liquid Staking contract finishes its own callback. What you can do, it is to monitor the balance of hsEGLD of your contract and update/track the HsEGLD from this kind of monitoring.
At every SC call, you could call an internal function named monitorHSEgld - and update the needed structures according to it. You could monitor eGLD balance as well, so you would see whether asyncCall/callBack failed on Hatom LS contract.

[janniksam]

Thats the only solution I came up with aswell @sasurobert . It seems like a very dirty solution though. And I feel like it will be kinda complicated to monitor, if there are other EGLD piles stored in my SC aswell which are not related to this workflow and also when multiple stakes and unstakes are happening within the same block.

Is there anything Hatom or I can do get notified whenever their delegation is finished, without opening some potential security risks? Couldnt they send my SC an empty & dumb sc_call in their final "on_success_callback" and "on_failed_callback"?

[ffarall]

Hi @janniksam

When you delegate to Hatom SC, I think Hatom SC should immediately mint and send HsEGLD back to your SC, without you having to wait for them to delegate.

I think this is the best and simplest way to do it.

@lcswillems that would generate a security risk for Hatom, since the sEGLD tokens would be minted and sent before knowing if the delegation succeeded. Or do you have some magic way to account for that failure case?

[sasurobert]

The thing you and hatom could do, is the following: when you call delegate on Hatom, you send optional data (function, args) you want to be called back. On callBack of Hatom contract, the contract reads from the storage the previously sent optional data and makes transferESDTExecute with the hsEGLD and the optional data you sent. This way, your contract will be called in the defined endpoint together with the ESDT Transfer

[lcswillems]

@ffarall What would be the security risk? For me, from a security standpoint, it is fine to mint sEGLD even if the EGLD has not been delegated yet.

[janniksam]

One thing @lcswillems mentioned in DM to me this morning could actually work.: Splitting it into two sequential transactions.

1. Let the user convert their EGLD to HsEGLD without interacting with my SC.
2. Then the user sends the HsEGLD to my SC.
3. My SC makes an async call to the Hatoms price function to get the current price for 1 HsEGLD.
4. In the callback my SC will calculate the EGLD value of the donation and saves both the donated HsEGLD and the corresponding EGLD value in the storage.

[janniksam]

Closed, because I found the workaround described above.