Sommelier This Week - April 8th 2021: What Uniswap v3 Means For Sommelier Architecture and Validators

It’s been a really exciting week for Sommelier’s cofounders. As they prepare for the release of Uniswap v3, the team plans to make good use of the $1 million grant it has received from the Graph (GRT) Protocol for index performance upgrades. Sommelier’s product VP, Jack Zampolin walks us through important changes the engineers have been working on this week, what prospective changes validators can expect, and how they can prepare for testing.

NOTE: Sommelier Uniswap LP Impermanent Loss management application is live at https://app.sommelier.finance. Make LP positions and receive rewards from our pool partners announced each week!

Jack explains this past week’s progress: “We got a great download from some folks at the Uniswap team to help us get started on Uniswap v3. Our team has been working through the code, a Sommelier system redesign, and some initial notes on that soon to be released to our validators. The main work this week has been in spec'ing out the new protocol on the chain side and working to talk through the functionality that we want to have around the launch of Uniswap v3. The third piece that we’re working on is data. The Uniswap v3 subgraph is a huge piece that we’re going to be working on and contributing upstream.”

Maintaining a Strong Foundation

As part of the redesign to Sommelier Cosmos SDK blockchain protocol, a key change has been to replace the Oracle Model, where validators submit data to be cleaned, aggregated, and then brought into consensus so that Sommelier can trigger impermanent loss alerts. Instead, there will be a Decision Module.

Jack explains:

“Because of the large amount of data, and also because we are connecting around Uniswap v3, we decided to make a change where instead of having an Oracle that’s just pulling in the data, the validators will pull the data in themselves and then they will use the new Decision Module to say where the liquidity within a given pool should be deployed. Now, you can’t just provide liquidity across the entire curve, you’re specifying pieces of the curve where you’re providing liquidity. This is actually going to be a huge benefit. It’s going to make the chain much more performant and it’s going to allow us to scale to service the large number of pairs that Uniswap supports.”

Right now Uniswap v2 supports something in the range of more than 34,000 pairs. A main goal of this re-architecture is to be able to support all of the pairs on a large exchange like Uniswap. “We’ll be releasing some work on that Decision Module along with the data formats that the validators are going to need to submit,” says Jack, adding: “Frederico is beginning work on that piece of it.”

What Validators Can Expect When Handling Data

For most Cosmos SDK-based chains now all you really need to do is run the core node itself and that takes care of most things. “Because we have these external systems, both Ethereum and Uniswap, that we’re integrating with we need to find a way to bring that data into the Cosmos SDK chain in a way that allows us to make intelligent decisions on that at a protocol level,” says Jack.

There are a couple of processes that validators are going to need to run and some data feeds that validators are going to need.

Jack explains:

“One of those processes is going to be some sort of Ethereum light client so that validators can get timely delivery of Ethereum events and relay them over the Gravity bridge. And that’s one piece of it. Justin, who we did a great profile on this week, is the lead engineer on that Gravity bridge and that orchestrator is the piece that validators will be running.”

Decisions, Decisions

For the Decision Module, validators will essentially need to query Uniswap state data.

“The way that we’re going to be serving them likely will be through The Graph,” Jack says. “A huge announcement from us this week is that we’ve received a $1million grant for The Graph to increase indexing performance. So, validators will need to pull some data from The Graph, perform some computations on it, and then submit decisions.”

Sommelier will have an economical version of a program that does that but the protocol doesn’t really care. “You can go in and modify that however you want to make the decision that your validator is going to vote on,” Jack says.

Each chain is slightly different. If you want to have a more aggressive liquidity strategy and you think the chain should be doing that, validators should be voting for that more aggressive liquidity strategy.

“The way we’re architecting that particular piece is going to make it easier to plug in different strategies within there,” says Jack. “We’ll offer initial implementations for a more aggressive strategy, a more conservative strategy, and then probably a middle one.”

Those two additional pieces are going to need to be run by validators.

“I think it’s actually a little less onerous than what we were envisioning for Uniswap v2, which would have required a full Graph node,” says Jack. “In this way, you can pull data from any number of sources and put your unique spin on it as a validator. The sum of all of those decisions determines where the liquidity that is in the individual pools on Sommelier is going to be deployed.”

A Simplified Cellar Module

In Uniswap v2 when users provide liquidity, they do it across the entire range of prices for the assets in the pool. This is a nice user experience that people have gotten used to. Uniswap v3 is a substantially different system with a lot more knobs, sliders, and buttons to press when you’re putting in liquidity.

“That’s a lot of complexity,” observes Jack, “The experience that we’re looking to offer at Sommelier is more of a passive experience that allows liquidity providers to put in liquidity in any amount, have that pooled together, and then be used intelligently within the pool. That essentially makes the liquidity within Uniswap v3 refungible.”

Currently the liquidity in Uniswap v3 is represented by non-fungible assets. Sommelier is going to take a group of those non-fungible assets and manage them intelligently with the Sommelier blockchain. Then, all of the liquidity that goes in that is going to go into a pool, and that’s going to become its own token.

“And,” Jack notes, “because we’re Sommelier, a fancy internet winery, these will be Cellars to disambiguate them from a Uniswap pool.”

More Active Liquidity Management

Going forward, the Sommelier protocol is going to actively manage the liquidity within the pool for all of the users that are a part of the Cellar over on Sommelier.

Jack explains why:

“In order to get the most returns out of a Uniswap v3 position, you need to actively manage that position. If the market moves away from where you’re providing liquidity your position becomes inactive, you’re not making any money and you’re actually opening yourself up to a lot of potential risk. If the market moves back into the range that you’re trading in it has the potential to create some losses.”

Cellars will have different properties, aggressive or conservative, and each Uniswap pair will have its own cellar. Jack shares a practical perspective on how this might work in a market.

“Right now on Uniswap each pair is sort of a unique trading pool, but in v3 each pair also has fee levels below it. But, if you listen to the public statements from the Uniswap team, and observe practically in a market, the way this is likely to work out is all trading within a given payer is going to congregate within a specific fee level and potentially move between them. Cellars abstract over the fee level and prevent users from having to think too much about that and allow them to say this is a pair I would like to provide liquidity to and here’s my liquidity, without having to decide on a fee level or where within the curve to position.”

Concentrating on Contracts

Sommelier’s Gravity contracts over on Ethereum are not going to change. The team’s work on Gravity enables this use case by default. There are cross-chain contract calls already in the system. However, the contracts on the Ethereum side called from the SDK state machine are going to change a little bit.

Jack explains:

“The first contract we call is a batch contract. Essentially, it takes a group of different function calls on Ethereum, batches them together, and then executes them serially. So, the batch contract will likely stay roughly the same, but the individual contracts that manage liquidity across Uniswap v3 are going to have to change. Previously we had contracts that were managing contracts on Uniswap v2 and now we have to re-architect those contracts for v3. I think we’re going to use Viper primarily as the way to do that as we’ve seen a lot of success with our users having very low gas transactions on Uniswap v2 due to optimizations in the Viper contracts.”

Refining the Sommelier App Experience

When Uniswap v3 launches, we’re planning to launch a Sommelier app experience that allows users to add liquidity in a way that’s very similar to the way that they added it in V2, so the work should go quickly.

“We’re trying to abstract away a lot of the complexity that Uniswap v3 brings and offer a simple, profitable user experience for folks using those contracts for the first time,” says Jack.

Masterful Tinkering and Testing

A huge piece of work that’s happening before testing begins is an ongoing Gravity refactor in response to some issues that were raised during an audit with informal systems in addition to some other usability fixes.

Jack explains why it’s critical to get this piece right. “It is the bedrock support of the rest of this protocol because if we don’t have a strong, resilient and reliable smart contract calling system on the Cosmos SDK side, all of the stuff that we want to build on top of it is not going to happen.

The team has made some significant progress over the last week.

“We have refactored the tests to make them a lot more extensible,” says Jack. “that PR just landed today. And, the client side, i.e., the interface to Gravity, is currently undergoing acceptance testing. It should be merged early next week.”

Frederico is working on the Decision Module, which is very, very similar to the Oracle module in a lot of ways so that development should go relatively quickly.

Jack elaborates further:

“At that point we will be able to start digging into the Seller Module where users will submit liquidity from Ethereum, ETH, or USDC and potentially a couple of other stable coin-supported assets and that liquidity will then be a fungible token that they will receive that’s a full share. So very similar to v2. That module does have a lot of complexity in it, particularly around back-off and retry for failed Ethereum transactions. But we do have a good idea of what that looks like and we’re working on architecture right now. We should be releasing some architecture diagrams next week and begin coding that soon."

Getting Gravity Right

Of all the pieces, Gravity requires and is getting the most engineering effort. After all, it’s going in the Hub as well.

“We’re working really hard to get the Gravity piece right,” says Jack. “We’re working on this with Injective Protocol, the Althea team, a couple of folks from the Tendermint team, the entire Sommelier team, and a few other parties. Because that piece is the most important it is likely to take the longest to complete. We’ll be able to finish the other pieces that rely on Gravity more quickly.”

The goal: Sometime around the May 5th date of Uniswap v3 launch, the team should be at a place where they are able to at least be able to stand up an internal test net and begin inviting validators that week or the next week. “That’s the goal in my mind and that’s what we’re charging towards,” says Jack.

Stepping Up Our Validator Relationships

It’s important for validators to understand that this is going to be a heavier lift from a DevOps perspective than some other protocols they’ve run.

“If you’d like to talk to the team, I think we’re going to start doing some calls with validators to discuss the architecture, discuss the different pieces, explain the protocol, and begin working on developing that initial validator set sometime in the next two weeks.”

That’s one piece Jack’s looking forward to. He recalls: “Zaki and I developed the validator community on the Cosmos Hub and we’ve had incredible responses from those validators who are very interested. The time to start stepping up the cadence on those relationships is close.”

If you’re a validator that’s interested in validating on top of Sommelier make sure to join our Discord: https://discord.gg/bjbhpdBsxH

NOTE: Sommelier Uniswap LP Impermanent Loss management application is live at https://app.sommelier.finance. Make LP positions and receive rewards from our pool partners announced each week!