Sommelier This Week - April 22nd 2021: An Inside Look at Progress on Coordinating Sommelier Components That Contribute to the Chain

If you’ve been following these posts, or watching Sommelier This Week, you will be tracking the interesting process of an app being built from the perspective of someone leading the project. It's worth a look at the video just to see how enthusiastic Sommelier's VP project Jack Zampolin gets about all this stuff.

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

He says:

“For the next few weeks, we’re going to talk about all of the different threads that must come together and you can see how those individual things evolve, how these threads run into roadblocks, end up combining with each other, and then end up coming together into a coherent product. I really enjoy telling this story iteratively.”

Last week, Jack talked quite a bit about the architecture that Sommelier is shooting for and our updates from here on out are going to be primarily progress on those various pieces. Great progress has been made, particularly on the protocol side, as well gravity refactoring, cellar module upgrades, the feeder, the data layer, and on the front end.

The Decision module

The Decision module, which is a part of the Oracle module that Jack has been talking about is being worked on by one of Sommelier’s core developers, Mantis, right now.

Jack reports: “He’s got some PRs up on the Sommelier repo with that, so the Decision module is coming along nicely. We have started implementation there.”

The Cellar module

The Cellar module, named to invoke the Sommelier brand, has also made excellent progress.

“I started working on spec with that with some of the team from Tharsis, which passed a huge governance proposal to the Cosmos Hub to get some funding for their team.” says Jack. “I’m working with the Tharsis team to finalize spec on that.”

So, the protocol piece is coming along nicely. Jack says: “A lot of my work over the last couple of weeks has been building out some data indexing capability on Ethereum main net, particularly on Uniswap market data to help support the v3 launch.”

Supporting the Uniswap v3 launch

Providing users with good recommendations on where to deploy their liquidity on Uniswap v3 requires some data, or some understanding of the markets. Jack explains how the team is addressing this:

“Unlike on Uniswap v2, on Uniswap v3 you need to say: ‘I’m going to provide liquidity between these specific price ranges, and that requires some data, or some understanding of the markets. To help inform users as to what’s a good place to do that we need some data so we’re working with a graph on indexing performance. We’re still not 100% there on that work so we do need some data to support this on launch, and that’s what I’ve been working on.”

Because the team needs data to feed these decisions, it’s running into the limitations of Ethereum in terms of bulk data export capability. Jack explains:

“The same way the app team has been struggling with that, we on the protocol team are dealing with those issues. On the protocol side, the way that we deal with that is to step back and from a long-term perspective determine how we will resource and build the necessary pieces to get us where we need to go in a month or two.” He observes: “The work that we’re doing with the graph to help improve indexing performance there is part of that. As well, we are also building up capability to do these large HTL jobs and build some tools that do that.”

That’s what Jack is working on now.

The Gravity refactor

The team has made some good progress in the past couple of weeks on the Gravity refactor.

“There has been a lot of documentation that’s been written, which is huge!” says Jack. “We’ve also gotten unblocked on the Rust transactions, so that’s coming along. Once we have that refactor done then I’ll be able to give you a solid timeline for test nets.”

“Zooming out a little, in terms of resources on our side, we have only so many backend engineers to go around. A lot of those folks are working on the Gravity refactor right now and there’s a ton of time and energy dumped into that. We’re trying to spec out and work on skeletons for the Decision module and the Cellar module and those skeletons should be ready right around the time the Gravity refactor is done. Once that piece is ready we can finalize the other pieces and I can give you a solid timeline on test nets.”

Looking ahead to Decision and Cellar progress

Over the next week, we’re going to see the Decision model get into a place where the on-chain pieces of it are finalized.

First, Jack explains a bit about the Decision module: “What the Decision module does is each validator runs a little program that is querying a number of different data sources and saying this is where we need to deploy liquidity. So, we’ve got some on-chain work that needs to be done. I’d imagine that work is substantially done by early next week and we’ll be moving on to that feeder process that’s querying data from a number of different spots.”

This is just about performing the straight-ahead work needed to program and connect these various systems, so it comes along at a certain rate and is just going to continue.

“On the Cellar module, I have another call later this week to do a bit more work on spec, and then also early next week to do a bit more work on spec. So, next week I plan to have a hopefully relatively complete State Machine specification for the Celler module that will allow us to begin implementation.”

Steady, parallel progress and a finalized user interface vision

These bigger protocol pieces are a bit like icebergs, they move slowly but consistently and the teams are just pushing forward on those axes where they can.

“One of the nice things about the way that we’ve set it up, and what the Cosmos SDK gives us natively, is this modularity, which means that these pieces are separate from each other and we can work on them in parallel. So, the number of parallel threads that we have on the backend will increase as we get more engineering and hiring is another focus for me over the last couple of weeks as well.”

The protocol piece will not be ready for Uniswap v3 but Sommelier will be offering people on the app side a preview of what the experience is going to be like on the protocol side.

Jack says: “One of the great things that happened on the app over the last week is that we finalized what we want as a user interface, and that’s a huge thing. If we think about Sommelier as a protocol that is curating different forms of liquidity and offering them nicely to end users, that’s saying that we want a curated experience where the users don't have to make too many decisions. Essentially, they say, ‘I want that bottle of wine over there.’ And that’s what we want to end up offering to users. We don’t want the users to have to say ‘I want that bottle of wine in this decanter and in that particular class for these reasons.’ We just want people to say “that, give it to me.”

This is why Sommelier needs a user interface that conveys those choices and also minimizes risk as much as possible. Jack explains: We’ve worked on a very Uniswap v2 style of adding liquidity to these Uniswap v3 pools that hides a lot of the complexity of Uniswap v3 while still giving the user an acceptable risk profile. And we’re driving those decisions primarily through historical market data that allow us to say “Hey here’s where we think you should place your liquidity.”

Sommelier is very opinionated in that way, and the core protocol will help with that as well. Jack says: “Even further, the experience that we’re offering with the core protocol where you just kind of throw liquidity at it and it takes care of the rest for you, that’s what we’re going to be offering at launch on the app, too.”

When the Sommelier front end for Uniswap v3 launches folks will still be able to use it even though the protocol is not yet ready.

Jack says: “This is actually one of the pieces of Sommelier that I’m most excited about. Over the last few years in Cosmos we have been building only protocol and that’s really hard. It iterates slowly, it’s slower to upgrade, and there are these big glacial pieces that are drifting slowly and hard to change course. Front ends are very different from that. It’s build one, iterate quickly, get users. And one of the very hard things about the protocol design that we’ve been doing is that user feedback cycle is much slower. Working with Kevin and the rest of the app team, the user feedback cycle is much faster.”

Plus, a lot of the on-chain smart contract stuff on Ethereum that is used to support the app side will also support the protocol side. So, in addition to having a much faster user feedback cycle, Jack notes “we’re also building code that the protocol will be using and understanding a lot more about our users. So, from a strategic and company perspective it’s hugely advantageous and it’s going to allow us to move much faster and allow us to ship much more polished products when the protocol comes alive.”

We’re hiring Go, Rust, JavaScript engineers

The talent hunt is on to help Jack and his teams continue progress on the multiple threads that must be pulled together.

Jack says: “On the back end, I’m really looking for some folks to help me build out the Cosmos SDK pieces of this and support some of the upstream Cosmos SDK work that we need to do because the Cosmos SDK is an evolving and continuing open source project and there are issues with it that we need to fix in order to ship the things that we need. So there’s upstream and downstream work there. We’re going to be hiring a number of Go engineers so if you are a Go engineer please reach out we’d love to chat and learn how we can work together at Sommelier.”

Given the data-intense nature of some of these pieces, especially the decisions on the chain and the front end on the app side, there’s a lot of infrastructure that needs to get built that supports that.

“We talked about the grant from the Graph,” says Jack. “We need Rust engineers to help service that grant, so if you write Rust we have a great team that writes a lot of Rust. There’s Rust in the orchestrator that is the Gravity bridge piece. Tony Arcieri who builds our infrastructure is a major core contributor to most of the Rust cryptography libraries, so if you’re interested in Rust in cryptography we have some folks from that community who are very active in that here to learn from. And, obviously on that graph side with that indexer there’s going to be quite a lot of work there. So if you write Javascript, Go, or Rust and you’re interested in some of the problems that we’re working on here at Sommelier, I would really encourage you to drop me or Taariq or the company a line and we’d love to chat.”

He adds: “Right now, I don’t know if we’re hiring any additional front end engineers, but if you are a talented front end engineer who is looking to build data-intensive applications that could help users make smart financial decisions on the front end, please hit us up we’d love to chat.”

Interested? Have a look at our Jobs page or just reach out to us over Discord or Telegram!