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.