Developer Series: Designing Next-gen Yieldly Products With TEAL 5 Upgrades

In the latest edition of Yieldly’s Developer Series, we give you a deep dive on our TEAL 5 staking smart contracts. In particular, we explain:

• Upcoming Yieldly pool types
• TEAL 5 technical undertaking (including why we ‘skipped’ TEAL 4)
• How we leverage some of TEAL 5’s new features
• Why our V3 smart contracts herald a new (and improved) age of staking on Algorand
• What we are up to next

Upgrading to faster, more secure TEAL 5

With the community’s support and a lifetime of just 6 months, our TEAL 3 smart contracts facilitated some pretty amazing things including ~3M+ transactions and $145M+ TVL — but as stated in our roadmap, its time for an upgrade. There’s only a few more days until Yieldly’s multi-audited TEAL 5 contracts go live with the exciting launch of our first Liquidity Provider (LP) pools.

A few things to note about Yieldly’s new family of contract offerings:

• They make multi-token, liquidity token and auto-compounding staking possible.
• Leading blockchain cybersecurity auditing firms, Halborn and Runtime Verification, have audited the code base and given their green ticks of approval.
• They boast top-notch security, extreme precision, and combine the comfortable user experience of EVM-based staking projects with Algorand’s incredibly low transaction fees and lightning-fast validation times.

Next-gen Yieldly products

Yieldly’s next generation contracts deliver far more variety and choice for our community. Taking inspiration from existing staking providers like Pancakeswap, we intend to deliver the following pool models:

1. Liquidity mining + Yieldly staking pools:

A dual pool system. Users provide partner LP tokens and are rewarded in Yieldly ($YLDY) for helping secure liquidity. $YLDY can then be staked in a separate pool that yields the partners token. These complementary pools will always be released concurrently for the same duration (either 30 or 60 days).

2. Community staking pools:

Similar to the described product above, but with the added bonus that it’s up to the community. Our governance program empowers users to elect which ASA projects they would like to see in the Yieldly ecosystem. Community pools will be clearly identified on Yieldly’s Dapp, so users can distinguish between pool types and stake at their discretion.

3. Fair distribution pools:

As part of Yieldly’s role as ecosystem incubator, these pools provide fair ways for other ASA projects to distribute their tokens over time.

4. Auto-compounding pools:

Allows same-token staking pool users to set and forget. A user’s stake automatically compounds from rewarded tokens over time without the need for claiming and restaking.

Background on development

Development on Yieldly’s new TEAL contracts commenced a few months ago when Algorand released AVM 1.0 and TEAL 4 betanet. Our team immediately took action to implement these significant updates. After much planning and whiteboarding sessions, we were able to integrate many of the groundbreaking new features described later in the “Technical Breakdown” section.

After a period of intense development, we finally finished the first implementation of TEAL 4 staking contracts. However, TEAL 4’s reign in the Algorand ecosystem was short-lived. Namely because just after we finished TEAL 4 development, Algorand dropped a new beast — TEAL 5.

TEAL 5 introduced the game-changing feature of inner-transactions. Upon seeing the safety improvements that came with TEAL 5, our team decided to hold off on releasing TEAL 4 contracts in order to upgrade to the superior 5th iteration of the language. Key areas of the contract which required extensive security checks were no longer required due to the ability to construct the transactions from within the smart contracts logic. This heavily optimised our contracts’ security.

Technical breakdown

How does TEAL 5 improve the existing systems on Yieldly? To answer, here’s a breakdown of some of the key feature additions of our TEAL 5 contract implementation.

Precision: 512 bit numbers

TEAL 3 limitation:

One of the biggest hurdles with TEAL 3 was the ability to work around large numbers causing overflows in the program. TEAL 3 had a limit of a maximum of 64-bit numbers at any given moment. When you are dealing with numbers with an already large number of decimal places, any mathematical operation which includes multipliers has the capacity to invoke overflow errors.

Nevertheless, Yieldly cleverly worked around these TEAL 3 limitations by introducing arbitrary time limits. By unlocking rewards every 30 minutes and only updating user and global staking shares every 24 hours, we were able to eliminate the possibility of large number overflows.

TEAL 5 improvement:

TEAL 4 (and by extension 5) introduced the ability to perform arithmetic using byte values as well as uint values. Byte arithmetic allows for up to 512-bit operations, doubling EVM’s/Solidities 256-bit maximum number. This allows for a high degree of accuracy in mathematical calculations with the ability to introduce higher levels of precision for multiplication and division operations.

Yieldly has integrated the ability to use such operations into all our latest staking contracts. This removes the need for all workarounds required in earlier contracts! It also allows us to work with more complex mathematical operations to improve the accuracy of calculations and utilise stronger reward distribution schemes.

Security: recursion + script jumping

TEAL 3 limitation:

Due to TEAL 3’s lack of recursion and inability to move back up the contracts program, it became necessary to repeat security logic in multiple areas of the contract. This reduced the amount of available space for more complex logic as security took up significant portions of the contract. This made it difficult for developers to expand contract logic without running the risk of breaking existing security implementations, as well as auditors who needed to statically analyse any potential vulnerabilities in the contracts.

TEAL 5 improvement:

The addition of recursion and the ability to move freely around the smart contracts has significantly reduced the amount of redundant security checks required in the program’s logic. This effectively relegated some of the most important and frequent security checks to a single function — called in the majority of application calls. Doing so increased our smart contracts’ capacity for significantly more complex logic than previously available.

Our contracts are now more accessible to developers and auditors. TEAL 5 makes it easier to implement and test new security features, should more boutique checks be required for different functions. Plus, our developers can focus more time on the business logic and create more fluid user experiences.

Reliability: inner transactions (TEAL 5)

TEAL 3 limitation:

Prior to inner transactions, contract developers building applications that included the storage and distribution of ASA/ALGO tokens would usually require the combined use of smart contracts and smart signatures (previously known as stateful smart contracts and stateless smart contracts respectively as they were known in TEAL 3 days). The reason for this was smart contracts previously did not have a public address and thus were unable to hold Algos or ASA tokens, which is where the smart signature came in. For more info on smart signatures, read here…

But the tl;dr is essentially this: TEAL 3 required smart signatures to hold the tokens, with logic inside where you would protect the account from malicious attacks, usually by making the contract reference an existing smart contract which will have a more detailed security implementation and only allow tokens to enter and exit the smart signature based off the success of the smart contracts logic.

TEAL 5 improvement:

With TEAL 5’s addition of inner transactions as well as smart contracts having a public address that can opt-in + send/receive tokens, all the aforementioned limitations are eliminated. Contracts now have the ability to construct and execute their own ASA asset or Algo transactions from within the contract itself. This allows us to secure withdrawal transactions much more easily than previous implementations, which would have required significantly more security checks in each transaction. It essentially becomes impossible to inject malicious behaviour in the transaction unless the contract allows you to.

Complexity: larger smart contracts

TEAL 3 limitation:

Previously smart contracts were limited to 1000 bytes in size. For any developer who has built with previous TEAL iterations, you know that this is not a lot, especially when you consider the above limitations reducing the already limited space.

TEAL 5 improvement:

With the increased contract size limit, supplemented by the above improvements of the TEAL programming language, TEAL 5 has allowed us to have a stronger focus on the business logic and user experience rather than worrying about space. With all optimisations considered, our TEAL 5 smart contracts are actually SMALLER in size compared to previous iterations, despite having more complex logic and improved user flow.

What happens next?

Yieldly is working closely with new and existing partners to introduce them to the power of our deep liquidity incentives. Keep an eye on our socials to stay updated: Twitter, Telegram Group, Announcements, and Discord.

If you are a potential partner and wish to see your project on Yieldly, please reach out to hello@yieldly.finance.

Disclaimer

Whilst we strongly support the open-source movement and making software free, we also believe that Yieldly should be the first to build an ecosystem around the bespoke products we put to market. We believe that our experience and maturity in DeFi as an organisation will enable us create a safe and prosperous environment for users and projects entering the space.

Accordingly, Yieldly’s code is protected by copyright, trademarks, service marks, patents, design registrations, and/or other proprietary rights. Yieldly’s code cannot be, inter alia, copied, adapted or commercialised without Yieldly’s express prior written permission. For more information on this, please read Yieldly’s terms of use.