Introduction
In the forthcoming infinite-LST environment on Solana, there is a point of friction between users and protocols that will only grow worse as LSTs become more numerous and widespread: Users want to hold their favorite LST (for any number of reasons), but it is quite a burden on many Solana protocols to support all LSTs simultaneously (some protocols can’t even support LSTs at all due to differences in yield return). This is where SolAdapter comes in.
SolAdapter is a simple locker for your LSTs. The user can deposit their LST into the SolAdapter and receive SOL in a 1:1* ratio (there is a small fee associated with retrieving the SOL). Their LST of choice is now locked inside the adapter, and to retrieve it they simply return the SOL back to the contract.
Usage
SolAdapter can be used in a number of ways, either on the user’s end or the protocols end to quickly enable infinite LST support on most existing Solana protocols.
Let’s take Tensor for example. Instead of swapping out your LST to native SOL in order to place a bid, losing out on yield as long as the bid is up, one could simply use SolAdapter to retrieve as much SOL as is needed to bid, while still earning yield from the LST.
Benefits
SolAdapter enables retroactive infinite-LST support for all Solana protocols that use native SOL. This would vastly improve the everyday usability of LSTs, expanding the TAM of LSTs greatly. Additionally, SolAdapter would be fairly easy to add to many protocol frontend Sun an easy way. This means users could have a seamless experience where the frontend just accepts your LST and conversion happens under the hood. Finally, each use of the SolAdapter by a user makes use of the infinity pool, creating more swap volume for the core protocol.
SOL Retrieval Mechanism
There are many ways to retrieve the SOL needed to match 1:1, but for the purposes of a baseline proposal, here is the mechanism:
When a user tries to redeem SOL from the adapter, the adapter mints adaptSOL (a representation of the SOL value present inside the adapter), swaps it using the Infinity pool for SOL, then sends that SOL to the user. In order to close the position, the user returns the SOL back into the contract, which is then swapped back to wrapSOL and inserted into the contract. Once the wrapSOL is returned, the original LST is free to be withdrawn from the contract.
Security Measures
The proposed smart contract is fairly simple, but keeping sanctum (and the infinity pool) protected is of top importance and demands extra security. With that in mind, here are a few proposed features that would make interacting with the adapter even safer:
Time Limiter: After a certain period (ex: 6 months), if the contract hasn’t been closed, the contract initiated a force-close, by spending the internal LST to buyback the needed adaptSOL balance and then return any remaining LST tokens to the user. This ensures adaptSOL doesn’t get stuck in the system if a user goes dark.
Infinity Pool Cap: To ensure the unlikely event of a smart contract failure can’t damage the Infinity pool, a cap on the amount of adaptSOL allowed inside the Infinity Pool can be implemented. This helps define an upper limit on the effect an exploit could have.
AdaptSOL Redemption Buffer: For yet another layer of safety to ensure the Infinity Pool can’t be damaged by an exploiter, put all redemption requests into a buffer with a one-day cooldown. This delays the user return experience, but allows observers to check the inflow of withdraw requests that use adaptSOL. If a large spike is observed, or a mismatch between expected and real swaps per account is found, governance can move to halt swaps using adaptSOL until the issue is found
adaptSOL Contract Whitelist: On the infinity pool end, create a whitelist for adaptSOL such that only the SolAdapter contract can interact (deposit/withdraw/swap) with adaptSOL. This prevents all sorts of mimic and loan-based attacks, limiting the scope of any exploit to the adapter itself.