Happy New Year! Here’s to one of the most tumultuous years in crypto so far 🍻. Centralized services crashed and burned spectacularly, leading to a re-birth in decentralization and on-chain services -- maybe 4th time’s the charm 🤞.

Every previous bear market had a major protocol launched, and 2023 won’t be any different given the amazing teams working on new DeFi primitives, scaling, and ZK privacy.

Increasing On-Chain Capital

Unlike the previous downturns where capital and activity evaporated, things are trending up and to the right. The centralized blowups have simply accelerated the move from off-chain to on-chain.

More teams are leveraging Safe wallets to conduct their business on-chain instead of relying on untrustworthy centralized counterparties. As we build better financial infrastructure on-chain, in the future every block will have a Safe transaction.

DEX Outcompete CEX

It’s good to get perspective on how far DEXs have come in just 4 years! TWAMMs are the next evolution of DEXs that enable efficient on-chain trading for whales & protocols. Institutions won’t use DEXs is the next domino to fall in the argument against DEXs.

With the development of advanced on-chain algorithms, institutions will trade on-chain rather than off-chain where the risks are far higher. Additionally, our implementation of TWAMMs solves the MEV issues of on-chain services. Large trades affected by slippage/sandwiching are executed over multiple blocks, and loss-vs-rebalancing of LP rewards are addressed by re-directing MEV from miners to LPs.

Interesting Usecases

In the past updates, we’ve spoken at length about different obvious use cases for TWAMMs like treasury diversification, peg maintenance, and whale liquiditations. However, the beauty of open & permissionless protocols is it gives developers new tools that can easily be composed with other DeFi legos to create new innovations.

Case and point, the new liquidity tool developed by DefiLlama helps risk teams understand a token’s on-chain liquidity and what volumes could cause the price to drop 10-20%. Now, what if we can help them also take counter-measures? That’s exactly what TWAMMs help teams accomplish, Olympus being the first customer to leverage this feature. Interestingly, this tool also shows traders the exact point at which TWAMMs need to be used instead of atomic DEXs.

Product Updates

During the past month, numerical analysis and system review, have consumed much of our technical efforts. As a part of that process, we've made numerous small changes to the product.

To improve the UX for virtual order users, we store their order ids in a map to their address, simplifying the process of monitoring their active orders. For scalability, we added pagination to the order id getter and limited the maximum results returned. A nod to FRAX as part of this interface was inspired by their TWAMM product.

As the pool factory's development became closer to production, we needed to aggressively reduce contract size further. Currently, the main contract is 19.191kB, and combined with the factory, they are 24.101kB. That figure was achieved using, but not limited to, the following methods:

• Modifying visibility of state variables.

• Refactoring any common snippets into functions.

• Creative reuse of bit-packing operations intended for multiple words with a single word (and deletion of single-word methods).

• Reducing convenience in the API for some methods to operate at a lower- level of abstraction.

Beyond updating our integration with Rook/KeeperDAO to accommodate changes in their arbitrageur list contracts resulting from their recent audit, we also introduced a generic and extensible system for adding arbitrage partners. This system will benefit the protocol by ensuring arbitrage of pools where some partners may not have an interest in arbitraging the underlying tokens.

Part of the review involved revisiting the roles and permissions model of the
protocol, where a number of changes were made. The following diagram shows
access to the pool's API by the public, the factory owner, pool administrators,
Rook, and other arbitrage partners.

To facilitate Maximally Extracted Value (MEV) rewards to Liquidity Providers (LPs) the pool features a holding period that dissuades attacks by parties with privileged information about forthcoming MEV rewards. This system previously relied upon an unbound array to store the time and amount of a pool join (mint) for LPs. Experiments in gas usage showed that the worst-case use was when two LPs both had a significant number of join events--resulting in two lengthy array manipulations. Based on that data and other experiments, join events were limited to 50 per address, alleviating that possible gas pitfall.

Part of the systematic review has been making conventions throughout the code consistent and well-documented as well as explaining optimizations that might not appear intuitive initially. For instance, an obvious optimization is to store the pool's accounting of Orders, Proceeds, BalancerFees & CronFees for both Token 0 and Token 1 in a single slot each. However, since these values are 112-bit, totaling 224-bit when sharing a slot, another state has been combined into the slots. If for instance Cron-Fi fee collection is not enabled, the Cron Fees should be zero, and reading that slot would be a waste, so additional state variables have been merged in to facilitate the elimination of unnecessary slot reads. (Note that simply checking if the Cron-Fi fee collection is enabled is inadequate because these counters could hold non-zero values after disabling fee collection).

Finally, we're continuing numerical analysis to confirm our scaling factor the choice is appropriate and if and where possible, making use of more gas-efficient unchecked arithmetic where analysis indicates overflow and underflow is an impossibility. We also continue to add to our testing and coverage throughout this process.