Can we build liquid staking directly into the dapp staking portal?
(A mechanism that is supported and backed by ASTAR).
Staking via independent dapps can create multiple risks.
Would be good if it was built directly into the dapp staking.
Thoughts?
You raise a valid point regarding the risks of independent dApps, but it’s worth noting that there are already well-established and highly relevant independent liquid staking dApps within the Astar ecosystem, such as Algem and Neemo, which have shown significant traction and value.
Algem, for example, has been providing liquidity and staking solutions with impressive on-chain data. Similarly, Neemo has been providing nsASTR (a liquid staking token) for ASTR with dApp staking as its backend mechanism, ensuring both liquidity and long-term sustainability for stakers.
Both of these dApps contribute significantly to the Astar ecosystem and expanded to Soneium, and their performance shows that independent liquid staking mechanisms are viable and valuable.
In fact, the idea of implementing a native liquid staking solution was previously raised by Sota in this discussion, where the potential benefits and challenges were explored. It’s an interesting area for further consideration, but we should also acknowledge the success of current independent solutions that continue to operate securely and provide meaningful benefits to the ecosystem.
Wouldn’t it be ideal to incorporate a hybrid model where both native and independent liquid staking dApps coexist, providing users with more flexibility and ensuring robust security standards?
We need to consider that a native liquid staking solution could essentially cannibalize the existing liquid staking offerings, which are some of the few dApps that contribute to TVL, growth, and user retention within the ecosystem. By introducing a native solution, we might risk undermining the efforts of these independent projects that have already established themselves and are playing a crucial role in the ecosystem’s development.
Supporting and nurturing these independent dApps, rather than replacing them, could help maintain a diverse and competitive ecosystem while encouraging further innovation. It’s important to find a balance that allows for the growth of both native and independent liquid staking solutions, ensuring that the ecosystem remains vibrant and attractive to developers and users alike.
In this sense, I believe the technical efforts to maintain and manage a native liquid staking solution wouldn’t align with the Foundation’s roadmap, especially considering that the existing solutions are excellent and already integrated into Soneium’s DeFi ecosystem. These solutions have independent teams, focus on their own marketing, and rely on diversified revenue streams, which allow them to be aggressive in expanding towards the Superchain and even Ethereum in the future.
A native liquid staking solution, on the other hand, could end up being too passive and might not foster the same level of innovation and growth that the independent projects are driving. Supporting the existing solutions and allowing them to thrive could be a more effective approach in maintaining a competitive and dynamic ecosystem.
While I can understand all of the points you made here..
I’m trying to think what is best for ASTR token holders and other DAPP owners..
What is the point of having non-staking tokens now?
Complicated schedules. Worse user experience.
If we want to improve dapp staking.
Then why keep this part complicated?
I’m not saying that Neemo and Algem can’t keep doing their thing and continue to give users incentives and more products (And slick UIs 
).. Just do it in an easier way.
I don’t think that all dapps should be implementing their own liquid tokens because the infrastructure would get confusing.
Make ASTR Staking Easy Again!
Creating an LSD protocol as Astar with several LSD projects already launched and active on Astar respectively is almost a betrayal to them and to the holders of the LSTs issued there. This is because if there is a native LSD, many people are more likely to choose to go there.
Also, a critical point is that LST and dApp Staking do not mesh well. It could be complicated to resolve, mainly in terms of voting rights in governance and the handling of votes in dApps Staking.
In particular, users seeking LSTs need liquidity, but to address the above issues, tokens would need to be issued by Native rather than EVM. However, currently Astar Native does not have DEX, and while it is possible to use Hydration, etc., this would result in a more complex UX for the user and also create problems in securing liquidity.
Thus, due to the many problems, it is not realistic for Astar to create an LSD protocol natively.
I don’t see much sense in bringing a lIquid staking service directly to the Portal. In addition to the complexities already expressed by You425 , liquid tokens are primarily a feature of DeFi being a derivative of the token useful for reassuring the PoS network. Consequently, having it for users would be useful for speculation and it would make no difference to have it on an external dApp or on the native staking dApp. Algem and Neemo already have a very user-friendly and easy-to-use interface (Astar EVM) with all the extra rewards they offer and I believe there is no need to complicate things.
I don’t think it’s a betrayal because we’d be making a better product for astr holders and helping the LST platforms to not have to keep updating their products every time there is a Dapp staking update.
Neemo and Algem can still offer their services but instead focus on the tokens that they’re giving to stakers. (That will still be a very important product.) Instead of focusing on the staking product itself.
In terms of difficulty to implement. Algem have open-sourced their staking contracts now. So we can just work off of that.
We don’t really need a dex if we are just depositing ASTR.
Astar Network is a platform/infrastructure, not dApps. It is enough to release the UI needed for governance and dApp Staking, a feature of the chain.
It is up to other developers to release products, not the platform side.
Of course, it is not wrong for the platform side to release products, but it is not recommended except in special circumstances, as it seriously undermines the principle of competition.
Also, you misunderstand the difficulty of implementation; Algem is an EVM LSD protocol. As I commented last time, to be fully functional as a Native LSD, it must be implemented as a Native feature, not EVM. Therefore, the code would have to be implemented differently for the most part, although there would be some overlap.
If the LSD is to be created as an Astar Network, it must have full access to Native functionality, such as voting on dApp Staking and participation in governance. There is no LSD protocol that meets this requirement.
Then there is no point in issuing LSTs; they are there to release liquidity that would otherwise be locked up, and to allow for some kind of operation (trading or DeFi use).
To my knowledge; it is not technically possible to stake in an LSD and be able to vote etc. (Maybe possible if user completely surrenders their ASTR).
So my suggestion would be an improvement to dapp staking.. (Otherwise this will never improve because dapps will basically never be able to do it.)
Wouldn’t the current dapps that are operating with LSDs be happy to have improved services as well? More features, etc?
If we have a wrapped token on the astar native chain. Then we can create a market for it on arthswap or another dex. That would be outside of Astar Foundation though.
My suggestion is just the wrapping and unwrapping part.
LSDs will increase on-chain activity. Which is what we need.
It seems that we will probably never agree, as you and I have a fundamental difference of opinion.
I think what you are looking for is convenience of tokens and on-chain activity, then security/reliability with native LSD protocol. This could be accomplished by natively implementing the already existing LSD protocol. I don’t think this in itself is wrong.
However, I believe that if we are going to implement a native LSD protocol, we need to address governance and voting on dApp Staking. In other words, the system requirements definition is different: as Astar Network, we should not create a system that allows itself to discard its governance rights. Once the native LSD protocol is implemented, it is likely that many stakers will take advantage of it. And if we do not design for it, it is the same as discarding the right to vote in governance and dApp Staking. This would mean its collapse as a decentralized protocol.
I understand the sensitivity of the subject due to the already available solutions.
Yes convenience is part of what I’m looking for.
My problem is this:
As an ASTR holder. I would prefer to stake with Algem or Neemo to avoid worrying about scheduling private key interactions.
However, I don’t because I believe the Neemo contracts are only partially opensource and if I stake with Algem there could be an exploit and I don’t know who would be liable. Would Astar foundation step in and issue refunds for everyone?
Which leads me to wonder; if Astar Foundation becomes liable for these problems then why are we not implementing our own version. So that if there is an exploit then it can be properly mitigated.
For me it is better for:
ASTR Holders.
Dapps.
Astar Ecosystem.
Astar Foundation. (Minus the work 
)
I’m just struggling to see who it is negative for?
100% agree that governance and voting with a native LSD would have to be a priority if we do go down this route. Also things like delegating could be a discussion now that we have governance as well.
I think this is the solution we need to reinvigorate the ASTR perception, price and ecosystem.
The current dApp Staking v3 encourages stakers to take action on a regular basis to eliminate “Forget to Earn” as they did until v2. This helps to encourage communities to become “participants” in the Astar Network.
LSDs such as Algem and Neemo promote “Forget to Earn”. That is, projects that keep the holder a “user” rather than a “participant”. Of course, we are not criticizing these projects, but there is no rational reason to implement them natively, as they do not fit the vision we aim for as Astar Network.
Therefore, if users want the convenience of “Forget to Earn,” they should accept the corresponding risk and use a third-party product. There is no need for Astar Network to compensate for this risk.
Even if you natively support LSD and meet the requirements I mentioned, concerns also arise about the acquisition of voting capacity. You can still increase voting capacity by purchasing tokens, but the ASTRs used to vote are locked, so there is a disincentive to vote against the Astar Network. However, depending on the design of the LSD and the ballot, this could create a potentially fatal risk.
In any case, if we want to pass this proposal, we will need to re-propose it with a more detailed design.
I can understand the new mechanism that we’ve built. To try to encourage more participation.
The problem I see is:
You’re a large holder. You shouldn’t really be interacting with your private keys too much because every transaction is a risk.
It is not financially smart to hold ASTR and not earn through staking. Thus people have sold.
You’re a smaller scale holder. The reward is small but the effort is matched.
If you have $1000 or less. Earning an extra $100 a year to keep up to date with dapps and the ecosystem is hardly worth the inflation.
For me it’s way deeper than just forgetting to earn.
Yes, getting locked in for voting can still be a thing. Double wrapped tokens. Voting power being delegated to a dapp in return for incentives would also go against everything.
I thought I’d get some opinions here before jumping into a full scale design.
Would be good to hear from @sota and others as well. 
Pitcoin has said everything that can be said (LOL)
I almost agree with him.
In short;
Developing such a system in an ecosystem based on open source is an open intervention in the free market and I don’t think it will lead to a good result.
What would be the potentially bad result?