Anchor integration

[ruuda]

Background

Integration with Anchor is one of the most requested features. After discussion with the Anchor/Terra team, on a high level it should look like this:

• A program on the Solana side
• Where users can deposit stSOL and receive bSOL
• And users can withdraw stSOL by returning the bSOL
• bSOL should be pegged to SOL 1:1
• The rewards get sent to Anchor users externally. Unlike stSOL, bSOL does not go up in value.
• So sometimes we need to sell some stSOL to make sure that the SOL value of the stSOL managed by the program is nominally equal to the bSOL supply.

Design

• Solana program that manages the bSOL mint, similar to how Solido manages the stSOL mint.
• Deposit and Withdraw instructions.
• A ClaimRewards instruction that reads the exchange rate from the Solido state to determine what the excess stSOL is, and then sells it, and sends the rewards to Terra. Proceeds should be in UST.

Open questions

• How do we sell stSOL? Likely on some AMM that has an stSOL / UST pair. We can create this pair if it doesn’t exist yet. But we need to figure out which AMM is easiest to integrate with programmatically. Ideally it would be one instruction we can call and the swap happens as part of the same transaction.

  • Saber
  • Raydium
  • Orca
  • Mercurial
  • Serum (?)

• What do we do with the proceeds ... how do we send them to Terra?

  • Can we use Wormhole?
  • Can we have a single address that we always send to; is Wormhole like a channel that is always open? Or is more like you have to jump through some hoops to set up a transfer, and you need to do this every time?
  • We need to have a destination address, but Anchor can provide this, once the Anchor side of the integration is done?

• Who calls ClaimRewards? A bot would. Let’s not worry right now about who runs it. If needed we could add it to the solido maintainer, but would be nice if Anchor can do it.

• Are there alternatives to waiting for Wormhole? Is there a bridge between Solana and Terra right now?

Next steps

• Build Solana program that manages a mint and has a Deposit and Withdraw. Let’s put it in this repo so we can reuse a lot of stuff.
• Evaluate the AMMs and see which ones we can easily use to do a swap from a program.
  • [ ] Saber @enriquefynn
  • [ ] Raydium @enriquefynn
  • [ ] Orca @ruuda
  • [ ] Mercurial @ruuda
  • [ ] Serum (?)
• Figure out how Wormhole transfers work.

[ruuda]

Orca swap details

• Orca docs claim they use the SPL token-swap program.
• The SPL token-swap instructions are not documented, but it looks like we can do a swap in a single instruction.
• It would be relatively easy to integrate because we can pull in the token-swap crate as a Cargo dependency.
• If I look at an arbitrary transaction interacting with Orca, it has a lot more going on than just a swap instruction. But maybe this transaction is a bad example, looks like it may be an arbitrageur or some other complex trade.
• This transaction looks more reasonable. It calls Approve on the token program to allow some address to modify the token balance, and then one Orca swap, involving that same address.
• So it looks doable to call this from a program, but we will have to reverse-engineer, and it will be difficult to test.
• Here’s an example transaction that swapped SOL to USDC via SAMO. There are intermediate instructions to initialize an associated token account to hold the SAMO and later to close it, but the two swaps are an SPL token approve and then a swap, so this should be doable.

[ruuda]

Mercurial swap details

• This transaction looks like a swap is a single instruction, plus an SPL token Approve and Revoke instruction.
• I couldn’t find any documentation on their site about the transaction data format or meaning of the accounts, though Solscan does have labels for them.
• However, I did find this on GitHub: https://github.com/mercurial-finance/stable-swap-n-pool-instructions/blob/4fb099b2113cd2de5eeda938c81c1d976658d96a/src/instruction.rs. So it looks like they have a Rust crate to build the instructions, and the accounts are documented :tada: We could pull this in through Cargo.
• We are also in touch with the Mercurial team and I am sure they would be willing to help us out if something is unclear, and there is also a Discord.
• It’s not clear to me if that is the interface for the actual deployed program though.
• Swap program source code does not appear to be public.

[enriquefynn]

Saber

• The code at https://github.com/orgs/saber-hq/repositories is fragmented. The swap code can be found here: https://github.com/saber-hq/stable-swap
• The swap code seems simple, but I couldn't find code for the program implementation (Is it open?!)
• Edit: After asking in discord, I was pointed to the archive branch on github, that seems to have some more information about the code: https://github.com/saber-hq/stable-swap/tree/archive/src

Raydium

• Seems easy to swap tokens with this instruction: https://github.com/raydium-io/raydium-contract-instructions/blob/d95c3f942674541364108cff7fe44fa0f66e0f22/amm_instruction.rs#L75
• We need to find the contract data to get the minimum_amount_out. This is done to avoid high slippage.
• The contract code seems simple to use: https://github.com/raydium-io/raydium-contract-instructions but it's poorly documented and we need to find where does it hold the addresses for the data accounts.

[ruuda]

We need to find the contract data to get the minimum_amount_out

Orca an Mercurial also have this, but I don’t think we need to read the contract data for it. If we set it to a value larger than zero, we should take it as an argument and pass it along. It makes no sense to read the contract state to determine the minimum amount out, because everything will execute in one transaction. No other trades can happen between us reading the state and executing the swap, there can be no slippage. What the minimum_amount_out is useful for, is when you have the webinterface to do a swap, and you are presented with a tentative exchange rate, which might change before your swap executes. The analog in our case would be somebody calling ClaimRewards with some idea of what the exchange rate will be.

[ruuda]

Considerations:

	Orca	Mercurial	Saber	Raydium
Liquidity	0	-1	+1	+1
Integration	+5	+6	+3	+6
Testing	+10	-10	0	-10
Trust	+10	-10	+5	-5
Total	25	-15	9	-8

• Liquidity: Ordered by TVL on defillama.com, but we don't value existing liquidity too much, because we would be setting up a new pool anyway, and we can attract liquidity there.
• Integration: How easy is it for us to call the swap instruction?
  • Orca: Can depend SPL token crate.
  • Mercurial: Have a well-documented crate.
  • Saber: Rust crate exists, but not sure if it is the right one.
  • Raydium: Have well-documented crate.
• Testing: Can we deploy this to a solana-test-validator?
  • Orca: Yes, just SPL token.
  • Mercurial: No, source code not available.
  • Saber: Source code is available, but unclear if it’s the right version.
  • Raydium: No, source code not available.
• Trust: Can we trust that this contract doesn’t steal our funds?
  • Orca: Yes, it’s open source and audited.
  • Mercurial: No, source code not available.
  • Saber: Yes, it’s open source, but unclear if it’s the right source.
  • Raydium: No, source code not available, but it has many users, so there is some reputation.

Conclusion: We’ll go with Orca.

[ruuda]

This was a catch-all tracking issue, but we now have a milestone for the Anchor integration (https://github.com/ChorusOne/solido/milestone/4), with all of the follow-up details, so let’s close this issue.