program: allow sol deposit

[2501babe]

svsp maintains 100% capital utilization (no undelegated float), mints tokens immediately on deposit, and charges no fees. this works great for stake deposits, but it has blocked us from accepting sol deposits because of economic attacks related to the immediate mint. ive contemplated various rube goldberg machines to work around this via delayed stake deposits that "feel" like sol deposits (default deposit accounts were one attempt to support such a flow) but this is confusing for devs, let alone users

im one year older and one year wiser now and a lot less dogmatic about the no fees thing. stake deposit will always be free, but sol deposit is a convenience, its fine to charge 5-10bps (edit: too generous) for the service (by underminting tokens thus giving the fee to the pool as a whole)

we do not want to have a reserve account and will never allow sol withdrawal. the design im envisioning is... (edit: deleted because obsolete, 90% of the described functionality landed in ReplenishPool. see 3/31 comment for latest)

also probably deprecate default deposit accounts, the point of that feature was to allow "one click to stake" following a similar sweep-and-delegate flow, just on an individual user basis. the idea was users who regularly add stake to the same validator would get the tokens for their prior epoch delegations at the same time they make a new delegation. but this requires wallets/dapps to implement the flow, and based on conversations since v1.0 was finished, i dont think anyone even really understands it. getting rid of it once we have a superior alternative that requires no outside support makes sense (edit: this has been done and they can be removed anytime)

overall this sounds very similar to multistake, and if we ever do do multistake, it should be easy to ditch the onramp account and swap backends without breaking the instruction interfaces

[2501babe]

note most of the infra for this is going to get done by #107. when we impl this, it will just look like "send the sol to the onramp, mint tokens less the fee, turn the crank." the main thing to scrutinize will be the economics

also the current stake depsit logic mints tokens for active stake only. a nice little bonus might be to use the sol deposit calculations to also mint a few extra tokens to cover the rent we absorb from the Merge

[2501babe]

cavey pointed out that, now that the concept of "mev rewards" is intrinsic to the program, we may want to do balance calculations using non-rent lamports rather than stake because deposit/withdraw dont take prior epoch mev rewards into account. noting it here since DepositSol is the right time to reconsider our token math

[2501babe]

ok i have a final-ish design for this and its not as simple as just add the instruction. my current thinking is, after #581 changes nev to be all non-rent lamports:

• temp migration instruction to grow the SinglePool struct. we want to add an Epoch tracking the most recent DepositSol call and a u64 tracking the total sol deposits in the current epoch. reserve some extra space for a rainy day. this instruction doesnt need to be added to interfaces. it can be permissionless. we should just call it on all pools ourselves to save the hassle
• DepositSol aborts if the onramp doesnt exist and aborts if SinglePool is unembiggened for simplicity. it also requires a fully active pool
• DepositSol uses the new variables on SinglePool to enforce a per-epoch cap on sol deposits, some % of total nev. this is because sol deposits become nev instantly but cannot be withdrawn until the next epoch. so if say a 100b stake pool saw 100b lamport deposits, only 1/2 of tokens are redeemable same-epoch. no funds are lost, it just forces the other half to wait for activation, but we want to treat WithdrawStake as a first-class citizen and DepositSol should not annoy our lovely active-stake-using public. we dont expect this to be a big deal because DepositSol allows instant activation, not instant deactivation. it is highly unlikely that there will be a market volatility event that has users demanding instant _il_liquidity
• we also dont expect this to be a big deal because we will price DepositSol punitively. 10bps is too cheap, especially because absent a cap, an instant-withdrawal user is paying less: if you deposit 100b lamports and withdraw 100b stake you net out at 5bps. im thinking 100bps to start and consider cutting it to 50bps later based on usage patterns
• but then at the end of the day, the rest is trivial. you add sol to the onramp and get tokens with the same calculate_deposit_amount() call less fees

note to self think i want two helpers:

• deposit sol: program, vote, payer, amount. just call. easy/lazy
• deposit sol by proxy: program, vote, payer, arbitrary new keypair, Rent, amount. check rent, xfer to proxy account, call. in line with the overall "wallet signature doesnt touch the program" philosophy

[joncinque]

This also makes sense to me overall.

I'm not totally sold on the deposit SOL limit though -- since SOL deposits are punitive, they make the pool tokens more valuable for all existing holders, which means we shouldn't need to limit SOL deposits.

For example, if there's only 1b staked lamports in the pool, and then someone deposits 100b lamports, then those existing 1b tokens become much more valuable, as if they had already earned staking rewards.

We might just need to add the ability to withdraw from the onramp if the pool account is empty.

[2501babe]

We might just need to add the ability to withdraw from the onramp

yep i had the same idea #583

i was ideologically opposed to a WithdrawSol in the style of stake pool, but i think it actually makes sense if we say there is no reserve, you can only take whatever lamports happen to be free to take