Substratum’s SUB Token Swap & Smart Contract Update

Substratum’s smart contract for its SUB ERC-20 token has recently been the subject of widespread criticism due to its built-in mint token function. The minting function, which can be found in the second version of Substratum’s whitepaper states that, “should the market ever reach 90% saturation, the network will create 10% additional tokens and separate them into an account that is only used to fuel the network. These will not hit the exchanges and will only be available for transactions within the network.”

SUB Smart Contract V1

Here is the mint token function from SUB’s original smart contract.

Line 136:

function mintToken(address target, uint256 mintedAmount) onlyOwner {
balanceOf[target] += mintedAmount;
totalSupply += mintedAmount;
Transfer(0, this, mintedAmount);
Transfer(this, target, mintedAmount);
}

In response to a June 2018 statement put out by Binance, Substratum CEO Justin Tabb announced that the mint token function would be removed in an upcoming smart contract update. Tabb’s statement reads as follows.

In our original Whitepaper we specified that if liquidity in the network reached too low we would be able to Mint 10% new supply for our token using the method mintToken() within the Smart Contract. This method can ONLY be called by the originator wallet and has NEVER been called. Throughout product development we have decided that we will not need this function and have been meaning to remove it for a while to provide our users with a greater sense of security that their token will always maintain its value by never becoming diluted.

In the accompanying YouTube video, Tabb references the mint token function and states the following.

Our original idea was that if we got to a point where liquidity was low in the network where there was less than 10% liquidity that’s in the sense that everybody would be HODLing and not releasing their tokens. If we ever got to this point, we wanted to make sure we had a way to basically add tokens so that the network could continued to run. However, we’ve just come to realize that we don’t need this, right? So we’ve got plenty of liquidity and there’s no reason to have this function. So basically, we’ll be removing this function, and the reason for that is we want to make sure that people know that their tokens will never be diluted, and as a result of that will never depreciate, and so by removing this function, it ensures the max supply of Substratum is ever 592,000,000, of which 120,000,000 tokens have already been burned, so basically 472,000,000 tokens, and that’s all that ever can be as soon as we remove this function. So that will be done next week.

A few thoughts in response to this original statement.

What does “less than 10% liquidity” even mean?
Where is SUB’s plentiful liquidity? In June 2018, SUB’s 24h volume dropped from $5 million to $1 million. Today, SUB’s 24h volume is less than $125,000 with 18 BTC of buy-side demand on the SUB/BTC pair.
SUB has depreciated to sub-ICO prices since Tabb’s statement.
Nonsense aside, I’m glad Substratum decided to remove the mint token function and appease the community. Or did they?

Fast forward to November 18, which is not “next week,” Tabb stated the following in an update video posted on YouTube.

Now as we’ve moved forward with SubstratumNode towards our monetization, what we need to do with monetization, we wanted to carefully look at the smart contract, and not just make any reaction-based decisions. A while ago, a few months ago, we informed you that we’re going to remove the mint token function capability even though it’s written about in our original whitepaper with a specific case for it, we’ve decided to move forward without needing that mint token function. Number one, we will of course be removing the mint token function from the smart contract. The contract is being rewritten from the ground up so we can utilize the opportunity to remove things like the buy and sell function within it, so that we can also take those 120,000,000 tokens that have been burned that we do not have access to, but some people think that we do. Along the way, those 120,000,000 tokens when we perform this migration will be disintegrated.

After a half year delay, Tabb finally made an update video announcing that the token swap and smart contract migration would start on December 17, 2018. In this video, he once again assured viewers that Substratum has “removed the mint token function even though it was specified in [thei]r whitepaper.”

Great news.

SUB Smart Contract V2

After taking a look at SUB’s new smart contract, here are a few thoughts in response to Tabb’s previous statements.

A burn() Function

Substratum has implemented a proper burn function, so they will no longer have to resort to creating a new ETH wallet on camera to ~~move~~ burn tokens.

Line 363:

/**
* @dev Internal function that burns an amount of the token of a given
* account, deducting from the sender's allowance for said account. Uses the
* internal burn function.
* @param account The account whose tokens will be burnt.
* @param value The amount that will be burnt.
*/
function _burnFrom(address account, uint256 value) internal {
require(value <= _allowed[account][msg.sender]);

// Should https://github.com/OpenZeppelin/zeppelin-solidity/issues/707 be accepted,
// this function needs to emit an event with the updated approval.
_allowed[account][msg.sender] = _allowed[account][msg.sender].sub(
value);
_burn(account, value);
}
}
/**
 * @title Burnable Token
 * @dev Token that can be irreversibly burned (destroyed).
 */
contract ERC20Burnable is ERC20 {

  /**
   * @dev Burns a specific amount of tokens.
   * @param value The amount of token to be burned.
   */
  function burn(uint256 value) public {
    _burn(msg.sender, value);
  }

  /**
   * @dev Burns a specific amount of tokens from the target address and decrements allowance
   * @param from address The address which you want to send tokens from
   * @param value uint256 The amount of token to be burned
   */
  function burnFrom(address from, uint256 value) public {
    _burnFrom(from, value);
  }
}

contract Substratum is ERC20Burnable, Ownable {
  string public constant name = "Substratum";
  string public constant symbol = "SUB";
  uint8 public constant decimals = 18;

An Updated Initial Supply

As promised in Justin’s previous videos, the initial supply of SUB has been fixed at 472,000,000 tokens (592,000,000 — 120,000,000) to account for the burned SUB that wasn’t actually burned. This was a great move by Substratum.

Line 410:

// 472 million tokens * decimal places (10^18)
  uint256 public constant INITIAL_SUPPLY = 472000000000000000000000000;

  constructor() public {
    ERC20._mint(msg.sender, INITIAL_SUPPLY);
  }

A Mint() Function

It turns out Substratum’s updated smart contract does, in fact, contain a mint() function. However, this mint() function is only used to create the initial supply and doesn’t appear to be nefarious. Regardless, it would be wise for Substratum to make this clear because the new contract’s mint() function looks similar to the previous contract’s mintToken() function, which was indeed nefarious in nature.

Line 334:

/**
* @dev Internal function that mints an amount of the token and assigns it to
* an account. This encapsulates the modification of balances such that the
* proper events are emitted.
* @param account The account that will receive the created tokens.
* @param value The amount that will be created.
*/
function _mint(address account, uint256 value) internal {
require(account != 0);
_totalSupply = _totalSupply.add(value);
_balances[account] = _balances[account].add(value);
emit Transfer(address(0), account, value);
}

Conclusion

Even though Substratum’s token swap and smart contract update is six months late, it’s nice to see the team finally act on promises. In my opinion, this is the first instance of Justin Tabb handling PR professionally. At the moment, Substratum is in the process of freezing SUB tokens under the current smart before migrating to the new one. If all goes smoothly, the highly controversial mintToken() function will be a thing of the past very shortly.

BrianLi.com