dcaSOL is an LST where your staking yields go to buy any token you choose.
This is a fuss-free way for users to implement a “barbell strategy”, where you continue to have full exposure to SOL, but also slowly increase your exposure to tokens that you like.
wifSOL is one example – your staking yields are used to buy WIF and airdropped to you, so you get your staking yields in WIF rather than SOL. Some have been asking for cloudSOL, jlpSOL, btcSOL etc. – dcaSOL is simply a generalisation of that concept.
dcaSOL will be user-customisable. The user decides what token to buy, and what percentage of SOL to use to buy the token. If the user sets a 0% percentage then the user simply gets airdropped dcaSOL.
The main question I have: is dcaSOL better than creating a new token for each LST e.g. jlpSOL, btcSOL, etc.?
With dcaSOL there will need to be a UI for the user to choose the target token and the percentage. This is in contrast to one-token-per-LST, where the user simply sets and forgets.
One other issue with these token LSTs is how they would work with DeFi. When for example you deposit dcaSOL into a borrow-lend market, it’s not clear who to airdrop the tokens to.
This is because it allows for 3rd party projects to seamlessly create their own Personalised LST w/ low friction to creating one.
Tho friction will be on first creating the UI and backend… was wondering if community is willing to get this going with enough support, will team be wanting to create it or have a external solution that is good enough…
Maybe if we get a discussion going with other defi protocols to see what possible solutions and integrations they are able to come up with (maybe incentivised via CLOUD from treasury?) to partner up …
But yeah I see the issue tho… that SPL within the SOL accnt in the lending protocol might just accrue into the SOL accnt managed by the protocol instead of the user… something to further get more insight on definitely…
Well. Fp beat me to it i was trying to put dcaSOL into words that made sense to everyone other than me.
I think both have uses.
DcaSOL - offers a highly configurable option for everyone. The more configurable the better. Its a heavy lift I imagine for the dev team.
XxxSOL - is still valuable as it offers projects a visible asset associated with their token. It gives teams a new option to use vs launching a token. They can simply use the LST as their governance & split rewards w holders on top of the staking rewards.
It also could have an impact on how teams design tokenomics. They could put x numbers of their treasury into the LST & use that for traditional buckets like community or even treasury general. This allows for market buying to get their token which is then distributed however they want while holding SOL in their treasury. From there the options are nearly limitless w how they use it. I think the potential of tokenSOL for teams could be extremely powerful. Whether it DCAs or not.
For the dcaSOL a setup fee could be charged where it is converted to CLOUD or you need to bond Cloud to create the dca.
Same for tokenSOL
I guess the question then is at what point would the attachment of CLOUD make it less adoptable on a broader scale.
I share same sentiment with Mike, and I think we can’t compare these 2 thing because they serve 2 different target market
dcaSOL → serve people who want to invest in certain coin, without being a community member. holder can swiftly change the DCA target in the UI if they think projects going downhill. Projects can’t give incentives easily
tokenSOL → Serve community member who wants to get more involved deeper in the projects, and projects can give more incentives with user who hold tokenSOL
If we have time and energy to develop both, I think it will be nice. but if no, I think stick to tokenSOL and improve their mechanic (auto DCA and airdrop etc) will be a better .
FP this is awesome. Funny enough I was discussing this DCA with Beng and I proposed the idea of be able to re-invest the APY back to DCA SOL (like re investing the dividends back to the stock). I am just surprised we had the same idea. Love this.
This is genius! In my opinion, way better than having a different LST for each coin, but in some cases both could exist, as the original project might want to offer additional things.
As for the lending problem, what if in the moment you swap for the LST, you could choose not only the token you want, but also input the wallet you want the funds delivered to? I think maybe this could solve the problem
Cheers!
Believe economics and opportunity should decide the dcaSOL vs tokenSOL debate.
most smaller projects could not get approval for their own tokenSOL. If this is the case but the foundation of users exists, then we can add them to a dcaSOL like INF index type. If the community is strong enough with some sort of voting, then they can start or even branch out into their own tokenSOL, kind of like an L1/L2 issue.
In my mind they would be 2 seperate entities, LSTs are we know them today (INF, jupSOL etc) are investments in their own right, dcaSOL would be a investment vehicle if that makes any sense
What if is was a hybrid token where any other token could be sent to it, and then removed via a user interface by the holder ? No idea if such a hybrid exists though
Hydration, a Polkadot parachain, is currently doing this with a product called Yield DCA which uses the Bitfrost DOT LST.
It’s super simple, can DCA into pretty much any token. Hydration have built an app chain so have complete control over the execution. I think the DCA part is the tricky one as even DCAs you set up on Jupiter yourself sometimes partially fail.
I’ve detailed more about it here Yield Utility Extension products - research group
If you combined traditional farm incentives with this idea instead of DCA (which involves a lot of small transactions, some of which may not go through) you could have the user come to collect rewards based on time staked in the module. It would remove the overhead of having to try and programmatically ensure transactions were going through (just like farm rewards do for LPs).
Possibly this would work best with the Creator coins as they are meant for (I’m assuming) less technical projects.