The Sovryn front end: Robustness of

In assessing the long term viability and robustness of a decentralized ecosystem it’s critical to evaluate not only the protocol level but also the on and off ramps of the system.

The vast majority of Sovryn users will not have the technical ability or know-how to interact directly with the protocol in absence of a front end and will therefore be dependent on the front end for access to the protocol. As such, the front end is a critical point of potential failure for the user both from an uptime perspective as well as from a trust perspective i.e. is the front end honestly interacting with the protocol?

The above two factors leave users vulnerable to the uptime and vulnerabilities of and are critical to the entire user base whether we think through it from the perspective of a small business owner taking out a loan in El Salvador or an investor who is assessing whether to stake significant capital to earn yield or help grow the platform. The uptime question also impacts the community in terms of token price as the front end is a primary source of liquidity into and out of the system. is the primary and leading front end around which the value of the protocol and the broader ecosystem is built. While it is positive that other front ends may be built in the future I have the following questions for the community:

1. How robust is the uptime to attack from malicious or state actors and how do we improve on any vulnerabilities so that the front end can’t be taken down?

2. What assurances are in place that the front end will continue to interact with the protocol in an honest way?

  • Example: How does a user know the front end is pointing to a loan contract with the terms displayed and not to a fraudulent other contract with a higher borrow APY?

Looking forward to the community’s thoughts given how dependent the ecosystem is on the robustness of


It would be a significant disservice to current and future users if these questions are left unaddressed so bumping the post for additional engagement and awareness.


For point 1, a good start could be to also host the frontend on IPFS. For point 2, I think an improvement to RSK explorer is needed. If users would be able to ‘read’ the contract like on etherscan, they could verify the displayed terms.

1 Like

Sia also announced this recently in terms of decentralizing the frontend:


I was wondering about the fragility and centralization of the web front end of Sovryn earlier this week, I found this thread as a result. I have been digging through the documentation to see if there are any references to the current state for hosting. I have not found anything. I am very curious to learn where things are at currently and would like to discuss how things might be improved.


The proof of concept of the sovryn front end running on a decentralised cloud (akash),

accesible over TOR (with VANITY onion addresses),
including .ens resolution
(ie, a COMPLETE decentralised solution of the FE)

has been shown to Sovryn Core team months ago, done by a previous sovryn contributor,

no additional support or interest from sovryn core followed,

even though this won hackathon prizes from both Sovryn and Akash during the Sovrython Hackathon.


The Liquity protocol ( on which Zero is based doesn’t host any front-end itself. They only provide a front-end dev kit and incentivize 3rd parties to host versions of this standard front-end. In this way, “the protocol” can hardly be forced to KYC their customers – there simply is no single point of entry other than the smart contract itself, which is deployed and immutable. And anyone can spin up their own front-end if they wish.


Thank you for sharing, I figured there was quite a bit of interest on this topic historically. I have some digging in to do on Akash, as this is the first I have heardo this decentralized hosting platform.

This is news to me, I didn’t know that Zero was based on Liquity, I’m late to the party and playing catchup :slight_smile: That’s a interesting approach they have taken for their front end. Am I correct in the assumption that Zero will be implemented so that it shares this same feature of having no single point of entry?

Zero will initially be hosted on the domain but the fee-sharing mechanism will still be in the code so other frontend operators could monetize their operations if they want to.

Have we tried to reach out to the Liquity front-end providers to see if they have interest in integrating Zero rather than us trying to get our own? Seems logical and would make sense since they’re already so familiar with the product on ETH’s side Liquity | Frontends List - Use Liquity

I’m not aware of any efforts to reach out to them yet. The Zero SIP specified a merkle-drop for LQTY holders, so when that is implemented and announced that might be the best time to start engaging the Liquity community, including about hosting alternate deployments of the frontend.