Soroban Vault Contract

[heytdep]

I have just written a how to tutorial on creating a soroban vault contract (minting and burning shares, depositing, withdrawal). This is the post (just wrote it on my personal blog): https://heytdep.github.io/comp_posts/6)--pub)--Vault-smart-contract-with-Soroban/post.html

Here's the repo of the contract: https://github.com/Xycloo/soroban-vault-contract

This submission was ideated and written along with @itsfederico.

[leighmcculloch]

Hi @heytdep, very nice!

I noticed that the admin has to be involved in deposit, and has to separately supply the deposit amount. If you would like to remove the need for the admin to be involved, check out the token contracts approve and xfer_from functions. The user can call approve, giving the vault contract permission to transfer tokens up to an amount (an allowance) out of their account, then the vault contract can use xfer_from to transfer the users token into the vault inside the deposit function and the vault contract will know how much was deposited.

[heytdep]

Hi @leighmcculloch , thanks for the tip, will definitely explore more the approve and xfer_from invocations! I chose to use this admin-needed approach trying to replicate the behavior of the single offer (or lp) example, were the contract works through an admin and is to be used by another contract (as admin), but I agree that having an allowance and xfering directly from the contract would be better since depositing doesn't necessarily need to involve the admin as withdrawal does.

Will update the code, thanks again for the suggestion.

[heytdep]

@leighmcculloch updated the code and the article, I have also removed the need for the admin in withdrawal which was redundant since when burning shares the code was already making an assertion (also fixed the assertion that only allowed to withdraw < user balance rather than <=).

Let me know!

[rice2000]

@heytdep thanks for this submission, and for revising it based on feedback! We should start reviewing incoming next week, and reaching out about rewards, so stay tuned for that. In the meantime, definitely feel free to keep the convo going, to ask any questions or share any feedback you have, even to submit another entry.

[achallagundla]

Heya Tommaso,
Congratulations! Your contribution to Sorobanathon: First Light has been accepted! 🎉
Your submission may qualify for a reward of 1500 XLM! One last step: to receive that reward, please fill out this form completely and accurately. {You only need to fill this form out once, since you have 2 submissions}

Nice tutorial,, btw! Looking forward to more tutorials!

Please let us know if you have any questions. (You can also message me on discord @ anuxhya)

All the best,
Anuhya

[mootz12]

Hello @heytdep! Great write up!

I noticed a couple things while reviewing the contract:

Auth
I would recommend removing the from argument on the function calls, and instead relying on e.invoker(), to ensure malicious users can't edit state that they don't own. Consider the situation where User1 has deposited some funds into the vault. It appears that anyone can call withdraw and provide the Identifier for User1, when they might not want to withdraw.

Share minting / burning
Clever way to implement this! There is potential for a minor optimization if you consider that the transfer rate from share <-> token doesn't change when minting or burning shares - it only changes when tokens (or shares) are added / removed in isolation (so you can remove the users deposit amount or burn amount from the calculation).

As you mentioned in the write-up, vaults are everywhere in DeFi, so great choice as an example. Maybe next steps could be a ERC-4626 compliant wrapper for the native token contract 👀

[heytdep]

Thanks for taking the time to review this! and good catch on the withdraw method, since the contract was initially meant to work only along with another "orchestrating" contract I had thought about this other contract ensuring that the user invoking the withdrawal had to be the shareholder, but after Leigh's suggestion of using xfer_from the external contract wasn't really needed anymore and I totally forgot that auth part. I'm not so sure about the optimization in the calculation part. For example we have used $\frac{totsupply + x}{totsupply} = \frac{amount + tokenbalance}{tokenbalance}$ where x is the number of shares to calculate the amount of shares to mint. How would go about calculating x here without using the deposited amount of tokens?

Thanks again!

[mootz12]

Of course!

The idea would be to calculate the share <-> token rate (for whichever direction you want to go) first, without having to consider what is being deposited or burned, and deposit or burn tokens at the end.

As an example, this would be the deposit side:

1. tokenToShares = total tokens / total supply (or 1 if total supply is 0)
2. sharesToMint = tokens to deposit * tokenToShares
3. do the deposit and mint the shares

Although it is a very minor improvement, it might allow you to share code if you wanted to create getters for stuff like convertToShares(tokens: BigInt) and things along those lines. At the end of the day it's just another way to do the same thing - both work!

[heytdep]

Got it, thanks for the clear explanation!