The Sovryn core team has been diligently working on enhancing the technical aspects of smart contracts. This effort involves addressing what is commonly referred to as “technical debt”, a process we are actively rectifying. Moving swiftly often means leaving certain elements behind, and now is the time for us to address these aspects.
Our focus has been on optimizing and enhancing various elements. Some of these enhancements will be pivotal for Sovryn Layer, while others aim to reduce gas consumption for Sovryn users, prevent breaches of the block gas limit, enhance codebase clarity, bolster robustness for further development and integrations, and fortify security measures.
On December 18th, we will introduce first two technical SIPs:
SIP-0072 will upgrade MYNT (DLLR aggregator) codebase, eliminating all legacy bridge-related code to enhance security and code clarity.
SIP-0073 will replace an AMM interface contract within the Sovryn core protocol, addressing ambiguities. This contract serves as a foundational element for every module, as trading or borrowing cannot occur without utilizing AMM for swaps and exchange rate queries. This SIP will upgrade all Sovryn protocol module contracts.
With great power comes great responsibility.
This is the responsibility we shoulder, and we kindly ask you to prepare for voting on Monday, December 18th, 2023.
Understanding the benefits of technical upgrades, even if they don’t directly impact users, is crucial for Sovryn owners. It’s about ensuring the platform’s continued growth and efficiency.
SIP-0073’s refactoring of the Sovryn Protocol Interface with the Automated Market Maker (AMM) might not immediately alter users’ day-to-day interactions. However, its significance lies in its impact on the platform’s future development and external integrations.
We faced an issue in the past where a particular improvement led to confusion due to a contract functioning in two ways: independently, with its own storage duplicating protocol’s storage snapshotted at the time of creation, and as a library over the protocol’s storage. This confusion exemplifies how “technical debt” accrues, a cost we’re now addressing—a byproduct of rapid development that necessitates tradeoffs.
Imagine developers working on integrating new functionalities or expanding Sovryn’s protocol. Prior to SIP-0073, the SwapsImplSovrynSwap contract’s dual functionality created complexities, posing challenges in understanding and causing inconsistencies in integration, both internally and externally.
Post-refactoring, the introduction of SwapsImplSovrynSwapModule and segregated AMM integration functions streamlines development. This clarity helps developers integrate new features seamlessly, saving time, reducing ambiguity, and laying a solid foundation for a more robust ecosystem.
No longer will developers need to spend time figuring it out, mitigating the risk of misuse or inadvertently introducing inconsistencies.
Though the direct impact on user-facing features might not be evident, SIP-0073’s improved clarity and structure significantly bolster the platform’s readiness for future developments and external integrations.
It’s important to note that we have to encapsulate this change in a separate SIP due to technical limitation - a maximum of 10 executable actions per SIP.