Meet The Narwhal
Introducing The Indexed Uni/Sushi Swap Router
It’s always nice to have the luxury of choice. That holds especially true when it comes to DeFi: assets are often available on multiple DEX platforms, but the differences in liquidity between them often has you hopping back and forth to find the one with minimal slippage.
The Context
At Indexed Finance, we launched with quite strong ties to Uniswap: when minting new index tokens (such as DEFI5) through our UI, you have the option of utilizing our Uniswap minter to create new tokens using ETH directly rather than one of the underlying tokens:
The way that this works is that your ETH — or DAI, or USDT, etc. — is swapped for the asset within the index (e.g. MKR, UNI, CRV) with the best price on Uniswap, and that asset is then deposited into the underlying pool of funds in exchange for your index token.
More precisely, the minter:
- Checks the amount of each underlying token needed to mint the desired amount of the index token,
- Uses the Uniswap SDK to get the best swap route for those amounts, and
- Returns the best combination of Uniswap route and pool token.
Similarly, when destroying tokens, you have the option of utilizing our Uniswap burner to one-shot your index tokens back into e.g. ETH. This is useful if liquidity for an underlying index disappears: you can still ‘trade’ back out by making an intermediate stop through one of the constituent assets — the minting process above, but in reverse.
The Problem
The ‘issue’ here is that we are currently pigeonholed into using Uniswap. We cannot — at present — include tokens in our core indices (DEFI5, CC10, ORCL5) if they aren’t present on Uniswap, since we use a Uniswap V2 oracle to calculate TWAPs for determining weights and setting balance thresholds.
Moreover, if the liquidity for a token migrates heavily away from Uniswap, it may well be the case that that token is no longer viable as a minter/burner candidate relative to others within an index, since the Uniswap SDK would always find better routes with less slippage using different tokens. This is unlikely to happen for the largest assets such as MKR, but for smaller tokens such as those in the DEGEN index, it’s a possibility that we cannot discount.
The Solution
The two largest exchanges on Ethereum at the time of writing are Uniswap and Sushiswap. They both have deep liquidity for a vast majority of the assets which we include in our index products, and if an asset that’s worth including in an index isn’t present on one, it’s a near guarantee that it’s on the other.
So, given the choice between the unicorn and the fish when it comes to selecting swap routes between assets… why not both?
Meet the Narwhal: the unicorn of the sea.
Narwhal is a fork of the Uniswap peripheral contract suite that supports both Uniswap and Sushiswap. It supports all of the typical Uniswap functions such as swapETHForExactTokens but allows the caller to specify which swaps in a trade path should use Sushiswap and which should use Uniswap. One significant feature is that Narwhal doesn’t care whether or not an asset is only listed on one of the two exchanges: if you provide a pair and it turns out that it’s only available on Sushiswap, no problem!
There’s one major change under the hood (horn?): Narwhal uses bytes32[] for the path parameter instead of address[], with each token address encoded alongside a boolean indicating whether the swap to the next token in the path should use Sushiswap or Uniswap. This only adds a small amount of gas to each transaction despite doubling the accessible liquidity.
On top of the Uniswap router functionality, we’ve also merged the features from our old mint and burn routers for Indexed into the Narwhal router so that users only have to approve a single contract to use all of these features.
The smart contracts for the Narwhal router are in this repository, and it’s been deployed to mainnet at 0x429302C74a0350410fC8B43E4839D459dEC4D050. We also made a fork of the Uniswap SDK to route orders using Uniswap and Sushiswap pairs, which is available here.
There are no additional fees imposed when using Narwhal, and it is available under an MIT license.
The Benefit
Narwhal can theoretically be used as a separate tool in and of itself, entirely separately to our work here at Indexed Finance. However, at this stage, we will not be introducing a ‘Swap’ tab to our UI: people have their DEX of choice, and tend to only move around when needed.
It’s a different story when you’re DEX-agnostic, as you are when minting and burning our index tokens. What we have done to start with is integrated Narwhal into our router, opening up a wider range of swap route options, leading to — on average — more efficient minting and burning of index tokens.
Narwhal is our first step towards closer integration with Sushiswap, and while it may be hard for you — as the reader — to get excited about “cheaper routing”, it’s a nontrivial step towards increasing the efficiency of Indexed Finance as a platform.
Also: don’t try putting actual narwhal in sushi. It’s disgusting. We tried.
