Chapter V: Smart Contracts & Frontend/Design

This beautiful imagery was created by our fellow Leservian: arbitruss

Dear Leservians, in this chapter we delve into the smart contract architecture and frontend/design aspects pertaining to Leserve. We believe that shedding light into these aspects is of vital importance, as it enables the community to look into the backbone of our protocol. Sharing this information enables us to bring in transparency, clarity and rationale behind many of the decisions that we have taken.

Leserve is underpinned by a strong conviction and belief in the Terra blockchain and its constituent ecosystem. We believe that positioning and immersing the protocol in the world of Terra is one of the key distinguishing factors and added values of Leserve. The Terra chain is in many ways uniquely distinct and thus building a robust protocol in many ways requires us to opt-in for chain-specific approaches and solutions. This chapter sheds light upon those distinct features.

Smart contract architecture

The smart contract architecture is one of the key elements which differentiates Leserve from any other Olympus-related protocol. Most Olympus-inspired protocols are operating on EVM (Ethereum Virtual Machine) compatible blockchains and thus leverage the exact same code as Olympus. However, the Terra blockchain is not EVM compatible and thus requires a completely different approach and solution, as the code cannot be simply replicated and used in the context of Terra.

Terra is powered by CosmWasm and Rust which employ considerably different infrastructure and logic to Solidity and EVM-powered solutions. Therefore, every line of Olympus’s code has to be completely reenvisioned and rewritten in the context of CosmWasm and Rust. Rather than seeing the complete logical and structural rehaul as a downside and disadvantage, we took this as an opportunity to improve upon Olympus’s current technological design and architecture. As a result, Leserve is being created and developed as a fully native reserve currency specifically designed and catered to the Terra blockchain.

Core contracts

The Leserve contract ecosystem is represented and embodied by its core contracts. These hold the funds and mint our base LSRV token. The core contracts are also responsible for the computation of the correct Risk Free Value for each asset.

LSRV Token

LSRV Token is a standard CW20 token. Only the treasury contract possesses the right and ability to mint the token. This effectively ensures that every LSRV token is accounted for and backed by at least 1 UST.

Treasury

The Treasury contract is at the heart of Leserve. Its main purpose is to safely store funds and mint LSRV against it. The treasury itself is technically unaware of the remainder of the Leserve system. This structure and approach ensure that Leserve’s use cases can be expanded in a modular way without changing or altering the Treasury code.

The Leserve treasury supports the following use cases:

• Storage of three asset classes:
• Reserve stables such as UST
• LP tokens
• Investment / Volatile assets such as Luna
• Depositing funds with or without LSRV minting
• Withdrawing funds and incurring debt
• Providing funds to other parts of the system such as staking and yield generating strategies

Value calculator

Value calculator is a contract responsible for computing Risk Free Value and UST valuation of the assets that the protocol encounters and interacts with. It employs different price source methods for each asset class:

• Stables are assumed to have a value of 1 UST.
• LP token price is computed from liquidity pool data on the chain.
• Luna price is taken from the price oracle provided by the Terra blockchain.
• Any other asset price will be sourced from ChainLink oracles that are being launched on Terra network.

When computing a RFV (risk-free value), each asset can have a risk ratio set. This number is in the range of 0 to 1. 0 represents assets with no risk at all, while 1 represents extremely volatile assets that cannot be used for LSRV backing.

The final RFV of an asset is equal to:

RFV = Asset Price * (1-riskRatio)

Using risk ratio to value assets is one of Leserve’s core innovations to the DAO playbook. It allows us to utilise and leverage volatile assets more effectively while enabling Luna or Ethereum to directly back LSRV tokens.

Bonding contracts

Bonding contracts provide and facilitate bonding services to the entire Leserve ecosystem. The design of Leserve’s bond contracts is constructed in a manner that ensures the contracts can be reused by third parties. Hence, launching a bond-as-a-service offering for the Terra ecosystem should be an easy task for Leserve.

Yet another compelling innovation brought to the table by Leserve is that the protocol only contains one Bond contract (which is deployed multiple times). All the differences between bonds of different asset classes are abstracted away in the Value Calculator contract. This solution therefore greatly reduces the protocol’s complexity and redundancy.

Moreover, Leserve bonds allow multiple bond maturity lengths. The longer an individual bonds maturity length, the greater the incentive. This ensures that Leserve’s greatest believers are effectively recognized and appropriately rewarded.

Bonds pay out staked LSRV. As a result of this, discounts can be low and it is easy for the end-user to compute the extent to which the bonding is profitable and how much they will get at the maturity date. We plan to provide a calculator within the GUI (graphical user interface) to enhance and simplify the user experience in this regard.

Moreover, we are also aware of the recent Olympus bond misconfiguration that cost the OHM treasury over $1.45M. We are finding ways to further strengthen the protocol and are implementing relevant solutions to address similar problems and exploits.

Leserve’s contract does not reset the minimum bond price when the bond price gets above it. This acts as a safety measure for this kind of exploit.

Staking contracts

Staking is the main mechanism for rewarding and incentivising LSRV holders. The four contracts responsible for staking closely follow the architecture of Olympus. The staking contract is where LSRV holders can stake their tokens in exchange for sLSRV, which is a customized CW20 token contract. sLSRV continuously rebases to keep its supply equal to that of LSRV.

We are considering using the sLSRV token just as an internal mechanism and not exposing it to the end-user. Instead, when staking, users would directly obtain gLSRV tokens, which represent Leserve’s wrapped, staked LSRV token that can be also utilised for governance-related aspects of the protocol (we have called this wsLSRV in the past).

We believe that this would yield additional simplicity and clarity, as users would not have to extensively wrap and unwrap their tokens, spend time understanding the relationships between various tokens and would encourage direct user participation in all aspects of the protocol from the outset and their very first interaction. Providing gLSRV tokens directly would also potentially encourage holders to partake in the governance of the DAO and ensure it is overall more approachable and inclusive for newcomers to crypto space.

Governance contracts

Governance contracts implement LeserveDAO’s on-chain governance model including its Councils and General Assembly. As of writing, this contract is mainly in the conceptual phase. Our first priority and focus are on the contracts required for launch. However, Leserve’s gLSRV tokens will be available right from launch.

Soon after, we will launch a Reputation contract that will allow Leserve DAO to keep track of reputation on-chain. The CW20 contract will be built to ensure reputation is non-transferable. The reputation will be bound to the address that acquired it. Tracking of the three reputation types (Leservanomics, Tech, Community) will be done by deploying the contract multiple times.

The LSRV Governance contract set will be the last to launch. This contract will hold and contain the hash of the constitution and will implement the mechanisms of councils, general assembly, proposals, judiciary and vetoing.

All of the Leserve DAO contracts are owned by CW1 Ownership Proxies. This allows handing over the smart contracts to the DAO governance easily and gradually when the right time comes.

Revenue generating contracts

Leserve DAO should generate revenue for its gLSRV holders and the contracts in this group make that happen.

Fund Allocator contract governs the distribution of funds between various strategies. Funds are allocated according to a risk/reward matrix. The risk/reward matrix is the main risk management tool for the Leservanomics council.

Treasury funds get allocated to the various protocol strategies. Any tokens earned by the strategy are deposited back into the treasury. There is a nice interplay with Value Calculator. Take AnchorStrategy for example. By depositing UST into Anchor, Leserve obtains aTerra tokens back. These can not be considered and treated as safe of an asset as UST due to the associated smart contract and liquidity risks. Therefore, its risk ratio is set higher than 0, for example to 0.2. (The risk ratio will be set by the Leservanomics council). The same amount of LSRV tokens cannot be backed as with the plain UST, but Leserve can still back 80% as much. That means that we can back LSRV tokens with it while it generates revenue at the same time!

Launch contracts

We are writing a set of Launch contracts that facilitate the following:

• Initial whitelisted sale of aLSRV tokens to create initial treasury supply and provide liquidity for the next launch step
• Vote facilitation for the aLSRV holders whether to deploy or not.
• Re-claiming aLSRV/UST based on the launch vote result.

Diagram showcasing the smart contract architecture

Design language

A set of brand and marketing guidelines have been established, to ensure that the Leserve brand is accurately and consistently represented. The design language has been developed to accurately reflect the values, mission and vision of Leserve, while ensuring it maintains the latest UI/UX standards.

https://drive.google.com/file/d/1TOBC-4f3PA27aBH1-ZXwTCerPiTcM9_I/view?usp=sharing

Frontend technology and hosted on IPFS

From the very inception of Leserve, the team has been aware that the design and technical complexities of decentralized applications (dApps) have been ever-increasing to higher standards, especially in the world of DeFi. Hence, we wanted to provide a unique experience on the Leserve dApp, while also maintaining a number of important aspects of dApp engineering and software lifecycle:

1. Zero downtime

2. Robust technologies

3. Agile styled iterative improvements

There are various justifications and reasonings behind each of the decisions and choices that were made.

Zero downtime

IPFS was deemed as a suitable service provider over battle-tested providers such as AWS, Azure or GCP for a number of reasons. One of the main concerns has always been the possibility of downtime. Any centralised system is prone to downtime and to those who have been following software engineering related news, this case has been very apparent with AWS in the past week. The case study of AWS has confirmed a number of theories suggesting that even a ‘too big to fall’ behemoth can have considerable outages. This could present severe implications in the context of Leserve and thus we do not feel it is a risk worth taking. Furthermore, there are always risks of centralised cloud providers potentially interfering with our protocol and hence opting for their offerings could potentially be in misalignment with what Leserve stands for.

That is why we believe that IPFS is an ideal solution and service provider for the mission and vision of Leserve. The InterPlanetary File System is powered by its peer-to-peer network to store and share data. It is essentially a distributed file system, which will help Leserve make each of its components even more decentralized. Better uptimes can be expected with IPFS, while also staying true to the philosophic nature of decentralization and transparency of Leserve.

Robust technologies

To deliver bug-free features that live up to the expectations of the state of the art applications, ReactJS and TypeScript appeared to be the most suitable options. We are sure that web developers reading this article will understand such an approach and the choice, however, we wish to cater to all leservians. Hence, if you know what is coming up, feel free to move on to the next section.

ReactJS is a framework that allows one to develop web applications with the best practices and engineering conventions in mind. React’s philosophy is primarily built upon being component-based. What does this mean? If used correctly, developers can leverage React to build the fastest and most secure web applications while also leaving the code fairly easy to read and comprehend. Using React can drastically increase development speed while also providing a high level of maintenance. This is very important for Leserve, as its codebase will be open source. Hence, allowing others to easily read and comprehend its code will encourage other developers to contribute and maintain Leserve to its highest standards. Having a codebase of this level also enables the maintainers to easily spot mistakes & amend them.

Furthermore, TypeScript is a superset of JavaScript which provides the so-called “typings” to Leserve’s codebase. It is there to act as an anchor for web developers to make fewer mistakes. However, TypeScript codebases are much longer and can take up more time to write. Nevertheless, we have decided to go with TypeScript from the get-go, as many dApps (Olympus included), which have started with JavaScript, have eventually decided to turn their entire codebase from JavaScript to TypeScript.

Agile styled iterative improvements

We strongly believe in iterative improvements and the Agile Manifesto. Hence, the choice of the technology stack should reflect this approach. Each of the chosen technologies has been around for a while and has very good community support and documentation. Leveraging such technologies will enable Leserve to incrementally yet very quickly develop new robust features while tying everything together.

That is why we have chosen Tailwindcss for styling, ReactJS for building our dApp, and NextJS for server-side rendering. Firstly, we have the domain expertise in these technologies, and we have the experience to show for it. Secondly, the chosen tools also provide very high levels of developer experience, and we can maximize our productivity with them.

Security

The security of the protocol is taken very seriously and remains to be one of our core priorities and focus areas. That is why the following measures have been put in place right from the inception of Leserve:

• The team is using a multisig wallet based on CW3/CW4 smart contracts. The Apollo DAO Safe implementation that has been kindly offered to us will be utilised.
• Each core team member is using a hardware wallet for managing the multisig.
• Code-reviews are performed on every part of the code
• Each team member compares the expected code hashes of what should be deployed before approving the deployment/upgrade transaction
• Code will be audited by an external company:
  Before launch
  Before major upgrades to the protocol
  At least once a year
• Leserve Contracts implement a special “freezable” trait, that allows the protocol to be frozen, should there be any considerable security threat appearing.
• All of our dependencies are either pre-audited smart contract code from CW-plus library or rust libraries, that are community audited via cargo-crev
• All on-chain code and the GUIs will be open-sourced. The community can verify that what is deployed on the chain corresponds with what is on Github
• We have a suite of unit tests and integration tests that test all contract sets, including edge cases such as integer overflows and rounding errors.

It is of utmost importance to ensure that the security is not compromised. However, at some point, the dilemma becomes “good security” vs “excellent security”. Given the time-sensitivity and increasing pressure on our launch, we are leaning towards having a product launched within a reasonable time with “good security” and after it grows and proves viable, upgrade to “excellent security”:

Introducing a two-phase upgrade at a certain point is being considered. This would allow instant freezing of the bonding/staking functionality of the contracts to prevent potential abuse and to protect the funds. The upgrade would contain a time-lock of 1–3 days where the first the hash of the code has to be published and then publishing the code itself in its entirety after 1–3 days in a commit-reveal kind of a schema. This would ensure and give time to people to potentially withdraw their funds, should they assume that the upgrade is deployed for the purposes of a security patch / innocent functionality.

Audit

We realize the importance of auditing our code by a third party and believe it is an essential component of launching a successful, safe and strong protocol in the world of DeFi. We also recognize the importance of choosing the right partner for such matters. That is why we want to ensure the chosen auditor is trustworthy, reputable, established and aligned with the vision, values and community of Leserve.

Leserve aims to choose a partner which understands the importance of proficiently evaluating our code and solution while enabling us to operate and proceed at the pace that we have established. We are currently undergoing a thorough evaluation process and determining the suitability and alignment with different auditors.

Furthermore, we are considering enabling the community to indicate its stance and preference in regard to choosing an auditor, as we want to ensure there is alignment and mutual recognition in this formative and trust-related decision. On the other hand, we are evaluating the extent to which such indication is feasible and how to execute it in a manner that does not compromise or delay the auditing process.

Tooling

Given the novelty of the Terra chain, there is currently a lack of tooling in the Terra/Cosmos ecosystem compared to the established EVM-compatible chains.

We feel welcomed and empowered by the Terra community and realize that products such as Ethers.js truly transformed the productivity of engineers in the Ethereum ecosystem. That is why we want to give back in a manner that hopefully encourages and promotes further development and growth of the Terra chain. We will be open-sourcing our TypeScript tooling that we have developed internally for smart contract development in the Terra/CosmWasm ecosystem after the launch of Leserve.

Our tooling provides the following features:

• Useful abstractions for contract deployment, instantiation, upgrade and execution
• A transparent way on how to call contracts via proxy or submit TX via multisig wallet
• Integration with HW wallet
• Allows grouping contracts into contract sets, deploying them in the correct order, setting up dependencies and querying them to perform consistency checks
• Deploy to multiple environments including testnet, mainnet and local terra
• Generate contract typings from rust Msg schemas

—

Thank you for your time and for keeping up with what Leserve is up to. We are excited to reveal the upcoming Chapters and slowly initiate the transition into the new era of Leserve.

In the next Chapters we will look into:

VI. Community & Growth

• Marketing strategy
• Leserve’s social identity & overarching philosophy

X. Launch strategy

• Whitelisting, tiers, launch sequence
• How we plan to fight for the community and tackle frontrunners and bots

To stay updated, make sure you are following our Discord and Twitter.,

Until then,
(🌖,🌖)

Disclaimers

The above content is published solely for informational purposes. It should not be construed as an investment thesis or be deemed to constitute a prospectus of any sort or a solicitation for investment or investment advice. The information provided in this Medium Post pertaining to the LeserveDAO is for general informational purposes only and is not a formal offer to sell or a solicitation of an offer to buy any investments, securities, options, futures, or other derivatives related to securities in any jurisdiction and its content is not prescribed by securities laws.

The information provided in this Medium Post pertaining to LeserveDAO, its business assets, crypto-assets operations, and strategy, is for general informational purposes only and is not a formal offer to sell or a solicitation of an offer to buy any securities, futures, options, or other derivatives related to securities in any jurisdiction and its content is not prescribed by securities laws. Information contained in this Medium Post should not be relied upon as advice to buy or sell or hold such securities or as an offer to sell such securities. This Medium Post does not take into account nor does it provide any tax, legal or investment advice or opinion regarding the specific investment objectives or financial situation of any person. LeserveDAO and its agents, directors, advisors, employees, officers and shareholders make no representation or warranties, expressed or implied, as to the accuracy of such information and LeserveDAO expressly disclaims any and all liability that may be based on such information or errors or omissions thereof. LeserveDAO reserves the right to amend or replace the information contained herein, in part or entirely, at any time, and undertakes no obligation to provide the recipient with access to the amended information or to notify the recipient thereof. The information contained in this Medium Post supersedes any prior Medium Post or conversation concerning the same, similar or related information. Any information, representations or statements not contained herein shall not be relied upon for any purpose. Neither LeserveDAO nor any of its representatives shall have any liability whatsoever, under contract, tort, trust or otherwise, to you or any person resulting from the use of the information in this Medium Post by you or any of your representatives or for omissions from the information in this Medium Post. Additionally, LeserveDAO undertakes no obligation to comment on the expectations of, or statements made by, third parties in respect of the matters discussed in this Medium Post.