SushiSwap Explained!

Looking at the implementation details of SushiSwap

You've probably heard of SushiSwap by now. The Uniswap fork brought new features like staking and governance to the exchange. But how exactly are the contracts behind it working?

It's actually not too difficult. Knowing how this works in detail will be a great way to learn about Solidity and Defi.

The contracts in detail

We will now dive into the implementation details of SushiSwap. Some of the code was modified to be easier to understand. You can always check the full code inside Github.

1. Uniswap v2

At its core SushiSwap is just a Uniswap v2 fork. The contract code was copied 1:1 except for a few small differences. If you are curious about how Uniswap v2 works, check out my previous post here. And also keep an eye out for a deep dive into Uniswap v3 in the near future.

In particular SushiSwap is making use of liquidity pool tokens (LP tokens). Check out under 'Pool tokens' for all details. Essentially LPs are for receiving pro-rata fees accrued in the pool. So you provide liquidity in a pool and get LP tokens minted in return. When the pool is now collecting fees over time, they are evenly distributed to all LP holders at the time of the trade. When you burn your LP tokens, you will receive your share of the pool + the collected fees.

Two changes to the Uniswap code where made by SushiSwap:

  1. The function setFeeTo was called in the deployment and the fee recipient was set to the SushiMaker contract (see below). Once the fee recipient is set, 1/6th of the LP supply growth due to the current trade are minted as protocol fee in the form of pool tokens. Since the trade fee on Uniswap is 0.3%, this will result in a 0.05% fee of every trade going towards the SushiMaker.
  2. A migrator functionality was added (see SushiRoll below).

You can see the full diff between Uniswap's core contracts and how SushiSwap changed them here.

2. SushiMaker

Sushi Maker

The SushiMaker will receive LP tokens from people trading on SushiSwap. It mostly consists of a convert function which does the following:

  1. Burn the LP tokens for the provided token pair. The result will be receiving proportional amounts of both token0 and token1.
  2. Inside convertStep trade both received tokens into SUSHI. This may require additional steps if there's no direct pool to trade into SUSHI.

The swap itself is performed on the SushiSwap pools itself. Let's see how this is done by examining the _swap function.

function convert(address token0, address token1) external {
  UniV2Pair pair = UniV2Pair(factory.getPair(token0, token1));
  require(address(pair) != address(0), "Invalid pair");


  (uint256 amount0, uint256 amount1) = pair.burn(address(this));

  if (token0 != pair.token0()) {
      (amount0, amount1) = (amount1, amount0);

  _convertStep(token0, token1, amount0, amount1)
function _swap(
    address fromToken,
    address toToken,
    uint256 amountIn,
    address to
) internal returns (uint256 amountOut) {
    UniV2Pair pair =
        UniV2Pair(factory.getPair(fromToken, toToken));
    require(address(pair) != address(0), "Cannot convert");

    (uint256 reserve0, uint256 reserve1, ) = pair.getReserves();
    uint256 amountInWithFee = amountIn.mul(997);

    if (fromToken == pair.token0()) {
        amountOut =
            amountInWithFee.mul(reserve1) /
        IERC20(fromToken).safeTransfer(address(pair), amountIn);
        pair.swap(0, amountOut, to, new bytes(0));
    } else {
        amountOut =
            amountInWithFee.mul(reserve0) /
        IERC20(fromToken).safeTransfer(address(pair), amountIn);
        pair.swap(amountOut, 0, to, new bytes(0));

The swap itself is performed on the SushiSwap pools itself. For the trade we are using the low-level Uniswap swap function.

  1. Get the current reserves of both tokens in the pool.
  2. Compute the receiving amount from the reserves and token amount being swapped minus the fees. Calculation is based on the x * y = k curve.

Once the amount out is computed, we can perform the swap. The last step to convert into SUSHI will always call the _swap function by passing the SUSHI token address and sending it to the bar:

_swap(token, sushi, amountIn, bar)

That's it, now we converted all LP tokens into SUSHI. All converted SUSHI are sent to the SushiBar, see next contract.

3. SushiBar

Sushi Bar

Inside the SushiBar people can enter with SUSHI, receive xSUSHI and later leave with even more SUSHI. Remember that all SUSHI from the SushiMaker are sent here. So over time the bar will accumulate more and more SUSHI.

Who will receive this SUSHI?

Anyone who entered the bar. For entering a user receives xSUSHI which are kind of like the LP tokens for Uniswap. They represent ownership of the SUSHI token in the bar.

The amount of xSUSHI you receive is your transferred SUSHI * total xSUSHI supply / current balance of SUSHI. So if you send 10 SUSHI to the bar which already has 100 SUSHI in it and 200 xSUSHI total supply, you will receive 10 * 200 / 100 = 20 xSUSHI.

function enter(uint256 _amount) external {
  uint256 totalSushi = sushi.balanceOf(address(this));
  uint256 totalShares = totalSupply();

  uint256 mintAmount =
      totalShares == 0 || totalSushi == 0
      ? _amount
      : _amount.mul(totalShares).div(totalSushi);
  _mint(msg.sender, mintAmount);
function leave(uint256 _share) external {
    uint256 totalShares = totalSupply();
    uint256 transferAmount = _share

    _burn(msg.sender, _share);
    sushi.transfer(msg.sender, transferAmount);

Now when you leave again, you get your equal share of SUSHI back. This will be at the minimum what you paid in, but considering the bar will accumulate SUSHI over time, it should be more than what you put originally in.

The amount of SUSHI you receive is your transferred xSUSHI * current balance of SUSHI / total xSUSHI supply. So if you send 20 xSUSHI to the bar which has 100 SUSHI in it and 200 xSUSHI total supply, you will receive 20 * 100 / 200 = 10 SUSHI.

3. SushiToken

Of course you have the SUSHI token contract itself. There's nothing special to it other than being a regular ERC-20 with delegation functionality identical to the COMP token. We've previously discussed COMP governance here. The mentioned Timelock contract is also included in SushiSwap.

The token allows delegating your voting power to some other trusted address. This address can then vote with increased power. Any time you may choose to re-delegate somewhere else.

4. SushiRoll (Migrator)

Sushi Roll

In the SushiRoll contract a migrator is provided, so people can easily move liquidity from Uniswap to SushiSwap.

With the migrate function, you essentially

  1. Remove liquidity from Uniswap.
  2. Add liquidity in SushiSwap.

Any potential leftover tokens from the token pair will be returned to the user.

function migrate(
    address tokenA,
    address tokenB,
    uint256 liquidity,
    uint256 amountAMin,
    uint256 amountBMin,
    uint256 deadline
) external {
    require(deadline >= block.timestamp, 'SushiSwap: EXPIRED');

    // Remove liquidity from the old router with permit
    (uint256 amountA, uint256 amountB) = removeLiquidity(

    (uint256 pooledAmountA, uint256 pooledAmountB)
        = addLiquidity(tokenA, tokenB, amountA, amountB);

    if (amountA > pooledAmountA) {
        IERC20(tokenA).safeTransfer(msg.sender, amountA - pooledAmountA);
    if (amountB > pooledAmountB) {
        IERC20(tokenB).safeTransfer(msg.sender, amountB - pooledAmountB);

5. MasterChef

Sushi Chef

The MasterChef enables the minting of new SUSHI token. It's the only way that SUSHI tokens are created. This is possible by staking LP tokens inside the MasterChef. The MasterChef is controlled by the owner which originally used to be Chef Nomi, but is since controlled by a 9 person multi-sig belonging to:

Eventually the plan is to move control of the MasterChef to governance. The owner has the power to control the allocations points from pools. What this means is the higher the allocation points of a liquidity pool, the more SUSHI one receives for staking its LP tokens. In the future this might create powerful control to create incentives for participating in special liquidity pools.

The owner can control pool allocations via the add function:

function add(uint256 _allocPoint, IERC20 _lpToken, bool _withUpdate) public onlyOwner;


Ongoing pools can be updated and then mint SUSHI to the people staking the LP tokens using updatePool.

The newly minted SUSHI amount per pool depends on the passed blocks since the last update and the set allocation points for the pool. (plus some extra multiplier left out for simplicity in the example on the right)

The calculated sushiReward is then distributed in 10% towards the dev address and the other 90% towards the pool LP stakers.

function updatePool(uint256 _pid) public {
    PoolInfo storage pool = poolInfo[_pid];
    if (block.number <= pool.lastRewardBlock) {
    uint256 lpSupply = pool.lpToken.balanceOf(address(this));
    if (lpSupply == 0) {
        pool.lastRewardBlock = block.number;

    uint256 sushiReward = sushiPerBlock
        .div(totalAllocPoint);, sushiReward.div(10));, sushiReward);

    pool.accSushiPerShare = pool.accSushiPerShare.add(
    pool.lastRewardBlock = block.number;
function deposit(uint256 _pid, uint256 _amount) public {
    PoolInfo storage pool = poolInfo[_pid];
    UserInfo storage user = userInfo[_pid][msg.sender];
    if (user.amount > 0) {
        uint256 pending = user.amount
        safeSushiTransfer(msg.sender, pending);


    user.amount = user.amount.add(_amount);
    user.rewardDebt = user.amount


Using the deposit function users can stake their LP tokens for the provided pool. This will put the user's LP token into the MasterChef contract.


Using the withdraw function users can unstake their LP tokens for the provided pool. In return they will

  1. receive their original LP tokens
  2. get their share of newly minted SUSHI tokens

The amount of minted SUSHI depends on the accSushiPerShare computed previously (see updatePool).

function withdraw(uint256 _pid, uint256 _amount) public {
    PoolInfo storage pool = poolInfo[_pid];
    UserInfo storage user = userInfo[_pid][msg.sender];
    require(user.amount >= _amount, "withdraw: not good");
    uint256 pending =
    safeSushiTransfer(msg.sender, pending);
    user.amount = user.amount.sub(_amount);
    user.rewardDebt = user.amount
    pool.lpToken.safeTransfer(address(msg.sender), _amount);

The Sushi Future

Since the SushiSwap creator has since left the field, its future remains uncertain. The token itself maintained a very high market cap and future developments towards decentralized governance may drive SushiSwap further. On the other hand Uniswap v3 is on the horizon and that's certainly not the only competition for SushiSwap.

Markus Waas

Solidity Developer

More great blog posts from Markus Waas

  • London

    What's coming in the London Hardfork?

    Looking at all the details of the upcoming fork

    The Berlin Hardfork only just went live on April 14th after block 12,224,00. Next up will be the London Hardfork in July which will include EIP-1559 and is scheduled for July 14th (no exact block decided yet). So let's take a look at the new changes and what you need to know as a developer....

  • Computer Deployment Terminal

    The Ultimate Ethereum Mainnet Deployment Guide

    All you need to know to deploy to the Ethereum mainnet

    We all love Ethereum, so you've built some great smart contracts. They are tested intensely with unit-tests and on testnets. Now it's finally time to go to mainnet. But this is a tricky business... 1. What exactly is a deployment transaction? First let's quickly discuss what a contract deployment...

  • Solidity Overview

    Solidity Fast Track 2: Continue Learning Solidity Fast

    Continuing to learn Solidity fast with the advanced basics

    Previously we learned all of the basics in 20 minutes . If you are a complete beginner, start there and then come back here. Now we'll explore some more advanced concepts, but again as fast as possible. 1. Saving money with events We all know gas prices are out of control right now, so it's more...