Tinyman AMM V2.0 Protocol
Yesterday we announced a new version of the Tinyman AMM protocol coming in January 2023. In this blog post, we’d like to give an overview of the new protocol and explain the next steps. We are providing these details early before the launch to give ample time for users and the ecosystem projects to familiarize themselves with the new protocol and prepare for the migration.
Since the launch of the Tinyman AMM in October 2021 there have been many improvements to the Algorand protocol that allow applications to do more complex and interesting things while also improving safety and removing some of the friction points. For the past 6 months, we have been working on designing, building, and testing a new implementation of the Tinyman AMM that takes advantage of these improvements.
Some highlights of this new protocol include:
- Dynamic calculation of outputs to remove the need for redeems
- Flexible liquidity addition and removal
- Flash loans & flash swaps
- Dynamic fee settings
- Full composability and interoperability
- Additional safety checks
- Improved readability of contract
While this is a complete reimplementation of the AMM with new features some things remain the same:
Tinyman AMM V2 is permissionless
Tinyman AMM V2 is immutable (not upgradable)
Tinyman AMM V2 has no admin keys to pause activity or drain pools
Tinyman AMM V2 is transparent and open source
Tinyman AMM V2 is audited
Tinyman AMM V2 is still ridiculously fast and cheap to use
No More Redeems
One of the most important improvements to the Algorand protocol over the past year has been the introduction of Inner Transactions. These allow contracts to programmatically create transactions. This enables Tinyman to dynamically calculate swap outputs and issue a transaction for the full output amount. The contracts still safely ensure that the minimum expected amount is received.
This removes a major source of friction and confusion and will immediately result in a better user experience.
No More App Opt-ins
Now that we don’t need to support redeems any longer we also don’t need to store per user state on-chain. This allows us to remove the requirement to Opt-in to the Tinyman contract app. This will free up some minimum balance requirements of Tinyman users and remove another source of friction.
Asset Opt-ins are still required but we are now able to group them with swaps and other operations so users will not have to separately sign for them. This will speed up the process and reduce the steps involved for swaps.
More Flexible Liquidity Management
We noticed that a very common pattern among users wishing to become poolers was to swap some asset to another and then deposit an equal amount of both in the pool. We have added a feature that automates this step at the protocol level so a user can add liquidity to a pool with only one of the pool assets in a single operation. It’s also flexible so the user can add whatever they have available of each asset and the pool will balance things out and issue the correct amount of pool tokens for the combined value.
It’s critical to understand that the user still has exposure to both assets when using this technique. The implicit internal swap is just a user convenience feature. It is also important to understand that this feature is most suitable for small poolers. There still needs to be some poolers with significant liquidity in both assets to create a balanced pool in the first place.
This feature also ensures that all of the user’s liquidity in LP token is correctly accounted for, even if they supply liquidity at an incorrect ratio. This improves safety for new poolers during periods of high volatility.
The protocol now also supports removing liquidity in just one asset. This is the inverse of the above case, where an implicit internal swap happens before returning the funds to the user as the selected asset.
These two features allow us to improve the user experience by simplifying common flows. They also, however, lay the foundation for much more complex contract-to-contract interactions.
Composability and Interoperability
Again we have taken advantage of the latest Algorand protocol improvements to design the V2 protocol to be fully composable and interoperable. This means that Tinyman V2 transactions can be placed inside the same atomic groups as other transactions and that Tinyman V2 can be called from other contracts.
This allows us and others to build features on top of the protocol for atomic multihop swaps, limit orders, metapools, and lots more. These features will help improve the user experience for swappers while also driving more volume towards Tinyman pools and generating more fees for poolers.
Flash Loans & Swaps
One feature that takes advantage of this composability is Flash Loans. We now have support for this built into the protocol so users can take a zero collateral loan from a pool as long as they repay it within the same transaction group. This may seem like a useless feature but thanks to the interoperable nature of the protocol and the developing Algorand DeFi space there will be plenty of opportunities for profits to be made within a single block. This is a complex feature and only intended for use by people with detailed knowledge of DeFi protocols and strategies and as such won’t be included in the web UI. The inclusion of this feature is driven by our core philosophy of providing financial tools to everyone, regardless of their wealth. It removes the need for large amounts of capital traditionally required to take advantage of certain opportunities.
Flash swaps and loans are risk-free for the protocol (in a financial sense) and provide an additional revenue source for poolers.
Adjustable Fees
Tinyman AMM V1 has a fixed swap fee of 30 basis points which is split 5:1 between poolers and the protocol. This has served the users well until now but there are cases where other fee options would be more suitable. For pegged/stable assets a lower fee that causes less price impact would benefit swappers. The increased volume due to lower fees should also benefit poolers. Rather than fragmenting liquidity across multiple pools for different fee tiers of the same asset pairs the V2 protocol allows for the fees of a pool to be adjusted over time. All pools will start with the defaults (same as V1) but the fee rate can be changed by the Fee Setter account within the allowed bounds.
The intention here is that the Fee Setter will initially be an account controlled by the Tinyman core team and the fees will only be adjusted for stable/pegged pairs. Later we intend to introduce a feature to enable poolers to collectively decide on fees for their pool. Ultimately we intend for all fees to be controllable by the Tinyman DAO when it exists. The protocol is designed to be flexible in this regard so that responsibility for fee setting & collection can be delegated to smart contracts or external accounts and revocable if necessary. This allows for the rules and mechanisms regarding fees to change over time without affecting any other aspects of the protocol. Further details will be provided before the launch on the policies surrounding fee changes.
A Safer, Transparent Protocol
With any protocol, there are design assumptions and inherent technical limitations. We have previously documented these for V1 and put safeguards in the UI to keep users from using the protocol in unexpected ways. With Tinyman V2 we have been able to go a step further and enforce some of these at the protocol level.
There are a number of mathematical/logical invariants that should hold in the protocol. In Tinyman V2 these are explicitly checked after every operation to ensure that even with very unexpected behavior the pools cannot lose value.
The protocol can only be safe if it can be easily read, understood, and reviewed by multiple independent people. To help in that regard we have put work into a number of areas:
- Readable contract source code — We have developed a new language for Algorand, Tealish, that allows us to express our logic and intentions clearly at a high level while compiling to readable low-level Teal. Fergal Walsh (Tinyman CTO) will be speaking about Tealish and how it was used for V2 at Decipher 2022.
- Auditable audits — The protocol specifications and contracts have been analyzed and audited at multiple levels to attempt to identify many different kinds of issues. This includes analysis and modelling of the specifications, the Tealish source code and the generated Teal code that ultimately executes on the AVM. We have worked with the auditors to make the audit process more transparent than usual. We will publish another blog post about this in the coming weeks with references to the reports and all the supporting material.
- Bug Bounty — We have worked with the Algorand Foundation and Immunefi to create a bug bounty program with rewards of up to 250,000 USD for critical issues. This program is live immediately and will remain active after the Mainnet launch.
- Open source public contracts and specifications — We have published the source contracts, generated Teal, and the final bytecode together with the protocol’s design document and specification. This allows anyone to review the protocol details to ensure its implementation matches their expectations.
No Big Red Button
We are regularly asked why there is no Big Red Button for Tinyman to pause the contracts if something goes wrong. This question was raised more following the unfortunate incident in January. While designing V2 we gave a lot of thought to this question. Can we implement a pause functionality? How would it work? Who can control it? Who is responsible for calling it? What happens after the pause? We will go into further details on this in a future post on security issues but we ultimately came to the same conclusion that we had when designing V1; there is no safe and useful pause mechanism that would not compromise the core values of Tinyman and DeFi in general. A pause mechanism without upgradable contracts is not very useful and upgradeable contracts are the other side of a line we are not willing to cross. Upgradable contracts would enable the Tinyman team (or an attacker) to change the rules of the protocol and potentially take custody of the liquidity. The main purpose of DeFi is to avoid such possibilities.
Your Funds, Your Decision
We as a team are excited about the new protocol and have been busy building a new and improved UI around it. We believe users will have a much better experience overall on the new protocol but ultimately it is your decision as a user of the protocol. When you placed your funds in V1 you agreed that they would be bound by the rules and logic of the V1 contracts. By design, we cannot change those rules to port your liquidity to V2. It must be your decision. We encourage all poolers on V1 to read the details of the protocol and the independent audit report and decide for themselves if they wish to migrate their liquidity to V2. The V1 protocol will continue to live on Algorand Mainnet for eternity and we will continue to support existing pools in the web UI for the foreseeable future.
Next Steps
We hope you are as excited as we are about V2. This is just the beginning however! We also have many UI improvements to be launched with the V2 protocol. We will go over these in further blog posts over the coming weeks. Post-launch, there will be additional improvements and features built upon the foundation that the V2 protocol provides.
We will also have additional posts on the migration plan before the launch.
In the meantime, we suggest you familiarize yourself with the details of the protocol and ask questions in our community spaces.
References
V2 Protocol Documentation & Specification
Immunefi Bug Bounty Program (Link to be added)
