single-validator stake pools

[2501babe]

tldr we are writing a stripped-down stake pool program for the single-validator case that enables liquid staking with no fees and 100% capital efficiency. the pr comments are a mess because it was originally a poc so im going to track work to-be done here

present status: code is done, pending review from jon, then we discuss/make changes and send into preliminary audit

work (no blockers):

• fuzz deposit/withdraw calculations, including how they hold up post-rewards
• port over all program/tests/ code to stake-pool-tests/tests/
• write a build.rs plus whatever yaml files (if needed?) to get the new stuff running on ci
• update cli to work with both programs
• update js to work with both programs

work (pending discussion or upstream changes):

• assign this a vanity address. i dont know what the process is for how we manage program keys, size mainnet program buffers (but we can realloc program accounts now maybe?), pay fees, etc
• click-to-stake instruction(s). this probably depends on the stake program adding multistake accounts. the original idea i had for this was: the user creates and delegates a new stake account and sets withdrawer to the pool authority and staker to their wallet or token account or something. (or we could just alloc a special account. maybe a linked list.) when it activates, anyone can permissionlessly fix Authorized, sweep stake into the pool, and mint tokens to the user. perhaps the user fronts a bounty to incentivize next-epoch merges. with multistake accounts, i believe the flow is much the same, except we track the user via a special account, and the stake is batched in the multistake intake. minting tokens after activation is a design necessity to obviate the need for fees (but again we may have users pay a fee to the minter for timeliness)
• slippage. we may want to take this as an argument to deposit and withdraw. we are not exposed to the "manager frontruns a fee change" attack vector the multi-pool is, but we are exposed to sandwich attacks. in theory with access to stake ≫ pool value, an mever could intercept ~all user deposits. we should at least debate whether this is purely theoretical or an actual plausible attack vector

questions / comments / slander / invective:

• is anyone assigned to the multistake impl? should i be working on this?
• we will need to do some light rework to accomodate multistake accounts. ideally we want every pool to have a multistake and no other stake account. if multistake lands before we deploy, just edit the code to use them and audit again. but if multistake will land after, we want to design a clean upgrade path before we deploy, so that the pools can transition without leaving behind legacy cruft

[mvines]

but if multistake will land after, we want to design a clean upgrade path before we deploy, so that the pools can transition without leaving behind legacy cruft

Assuming multi-stake will land after is probably the right approach. Ideally we can freeze the mono-stake program independently, when it feels right to do so, while also including a mechanism to migrate to a new multi-stake version of the program (perhaps that's just a simple jup.ag-like token swap from the perspective of most users though..)

[2501babe]

first version is now merged in under /stake-pool/single-pool/ and ready for audit! and now on to building out the tests

[2501babe]

im going to leave it as-is for now because we have audits in flux but since they dont share any code it might make sense to relocate spl/stake-pool/single-pool/ to spl/single-pool/` since trent et al suggested a separate cli (and presumbly js) made the most sense, which i agree with (in part because it will make them significantly simpler architecturally)

[joncinque]

We'll probably move all of the stake pool stuff into a separate repo anyway within the next couple of weeks, so we can figure out the right structure at that point. How does that sound?