Trusting the SPL stake pool program

[ruuda]

At the moment, the SPL stake pool program hard-codes its own id (poo1B9L9nR3CrcaziKVYVpRX6A9Y1LAXYasjjfCbApj) in instruction builder functions, so it is difficult to use the crate with a “self-hosted” version of the stake pool program. (Not that difficult though, I’m adding the SPL as a submodule in #90, it would be just one additional commit to our fork to replace the id.)

The stake pool program does not yet exist on mainnet-beta, but it does on the testnet, where its upgrade authority is
2WJLqUYKdkQrbkFz2xffwLFCNDVW2ej2BEaLQLFEKHDb. Assuming the upgrade authority is not going to be sealed initially on mainnet-beta, users would be trusting whoever the upgrade authority is, with their funds.

I think the easiest way forward to reduce the trust surface is if we upload our own version and set the upgrade authority to the same upgrade authority as that of Lido.

[enriquefynn]

Agreed, we can have a function to update the stake pool program id and have it stored in the Lido's state. We should also better discuss these upgrade possibilities, how would we merge the stake pool state if it changes or Lido's

[ruuda]

and have it stored in the Lido's state.

Why? It’s just hard coded in the program at the moment, and I think that is fine. I think we wouldn’t easily be able to change it after we set up the Lido instance, because the stake pool instance's derived accounts then depend on the program address, right?

how would we merge the stake pool state if it changes

By not updating the stake pool if upstream makes a breaking change to the data format without providing a migration path 😬

[joncinque]

Put in solana-labs/solana-program-library#1814 for the instruction constructors

[malikankit]

Resolved. We will be deploying our own version of the stake pool.