#Custom Accounts issues for wallets

5 messages · Page 1 of 1 (latest)

wind falcon
#

At Beans, we are considering transitioning from Stellar Classic Accounts to Custom Accounts, but we are encountering a few obstacles.

One major issue is that users cannot deposit their assets from crypto exchanges because these exchanges do not yet support C... addresses. Is Stellar actively reaching out to crypto exchanges about this? It might be helpful to show them Tyler's SuperPeach demo, which has generated a lot of excitement among everyone I've spoken to.

Another challenge is our heavy reliance on the Stellar Classic DEX. We need to use path payments to facilitate cross-border transactions, as we currently do. While we considered leveraging Soroswap for this, Soroswap mentioned they are facing liquidity problems with larger amounts. This is a significant barrier for an app like ours. Therefore, it would be beneficial to find a way to support path payments on Soroban using the Stellar Classic DEX.

Additionally, it would be valuable to hear from other wallets about the challenges they face in making this transition. For us, we believe this is the future, provided these issues can be resolved.

quick barn
night ridge
#

@wind falcon thanks for sharing this feedback. We are actively discussing how to address better classic/soroban account interop as well as accelerate anchor and exchange support. A couple of questions for you:

  1. Any sense of what the liquidity delta is and pairs you need to enable this?
  2. If there was sufficient sustained liquidity would Soroswaps 30BP spread work for your users given they are swapping stables?
    3)What is the ideal solution from your perspective on the anchor/exchange side, is it everyone adds support for C address support along side existing G and M address support or is it something else?

Just to share some of my thinking on this from an ecosystem strategy perspective, we are all excited about what Tyler has been demonstrating with his passkey work and as he mentioned stay tuned, we are going to have some cool stuff coming to promote further experimentation and adoption here. With that said, I think its critical we are intentional about our approach here, because we need to balance where we allow friction and where we make efforts to make things seamless in-order to enable growth and evolution of the ecosystem.

Friction opens space for people to innovate, and in the case of network liquidity we have opened up space inside soroban for teams like Soroswap, Phoenix and Estrella to build liquidity venues. If we bridge in dex liquidity immediately, it will close much of that space before they even have a chance to build momentum. It will draw a lot of usage and demand back to the classic dex, limiting the demand for swaps and availability of LP capital to support it. If instead we focus on improving those things, giving the teams time to iterate on their designs and protocols we may end up with something much better. For example I would love to see someone build an aggregator ala 1inch that provides a path payment like API for Soroban.

night ridge
#

I also think its worth noting that there is a possibility that someone could reimplement a CLOB like the dex on the Soroban side, given the work thats been done already on managing state growth, as well as the work that will be done on expanding capacity in Soroban through footprints and parallel execution, I think the scalability roadmap on the Soroban side has a lot of headroom for capacity increase. If we contrast that with the DEX on classic, where we don't have these things it might be a short term win but a long term mistake to connect the classic dex directly into Soroban because it would close the market opportunity for someone to build a native one in Soroban.

On the anchor/exchange interop I think this one seams a lot clearer from my perspective, no one is served by the friction or fragmentation of the on/off ramp network. Anchors and exchanges want more volume, applications and dapps want easy low friction access to the on/off ramps for their users. The only question from my perspective is whether we try and address this by proposing a protocol change or if we tackle it through ecosystem adoption efforts and tooling.

wind falcon
#

I wanted to let you know that I'm currently a bit occupied and need some more time to get back to you. I'm aiming to have an answer for you by next week. Unfortunately, I've fallen behind with work due to the Consensus project. Thank you for your understanding!