Last week Merriam-Webster announced that they were adding embiggen to the dictionary. Today we’re announcing Embiggen (MBGN) - an ERC20 token that grows in your wallet.

MBGN has a 10% annual inflation rate, compounded hourly. But unlike fiat currency, where new currency is issued to the banks, or traditional cryptocurrencies, where new currency is issued to miners, new MBGN is issued directly to wallets holding MBGN.

Another way to think about this is that the MBGN token pays interest. If your wallet holds 1 MBGN right now, in one hour you will receive an additional 0.000011415525114155 MBGN. An hour after that you’ll receive 0.000011415655428368 MBGN (slightly higher thanks to compounding interest). Over the course of a year you would earn a total of 0.105182903374472518 MBGN even if there are no further MBGN transactions from your account.


Many cryptocurrencies and tokens have some mechanic to increase the supply of the currency. For coins like Bitcoin and Ether, increases in supply are sent to miners who do the proof-of-work calculations. Some ERC20 tokens allow their creator to mint new tokens. Other ERC20 tokens provide users a way to create tokens by collateralizing other assets.

Embiggen offers a way to introduce new currency by providing it to all MBGN holders at once, proportionally to the amount of MBGN they hold. It can be thought of kind of like a stock split; the total supply of the token is increased, but each individual’s share of the pie stays the same through the increase.

Other Uses

MBGN is mainly a proof-of-concept for the idea of “embiggening” tokens. The same basic concept could be paid by other tokens that want to pay interest to their users. Interest doesn’t necessarily have to be paid in the same percentage every hour. Interest could be paid on an exponential or logarithmic schedule, or even triggered when certain events occur without having to touch every user’s balance.

Enshrinkening Tokens

A related idea, which may actually have more practical implications, is the opposite of embiggening tokens. Just as we created a token contract where users’ balances increase over time, we could also create a token contract where users’ balances slowly decay over time. This could be used if you were creating a token redeemable for a real world good and you wanted to encourage people to redeem their tokens sooner rather than later.

Another idea could be to keep the total supply of a token fixed and treat their decaying balances like a tax, reallocating those tokens for some other purpose. This might be used to reward accounts who facilitate some kind of service, while charging all token holders across the board.

One challenge with Enshrinkening tokens that is less pronounced with Embiggening tokens is trading them on decentralized platforms. On 0x if you offered your entire balance of an enshrinkening token in a trade order, as soon as the first decay event happened your balance would be insufficient to complete the trade, and the relayer would delist your order (or they should, assuming their balance monitoring system accounts for decaying tokens).

It’s even worse on trading platforms such as EtherDelta that use deposit contracts. With a deposit contract, you send the contract your tokens and it credits your account with the deposited tokens. After you trade these tokens with someone, they try to withdraw the tokens only to find that the deposit contract no longer holds all the tokens they thought they just bought. Embiggening tokens also have problems with deposit contracts, in that interest accrued while stored in the deposit contract probably can’t ever be withdrawn, but that’s less problematic than the deposit contract running out of a token while still having deposits on the books.


Obviously nobody is sending new MBGN tokens to every address once an hour. In fact, interest will accrue every hour even if the Embiggen contract doesn’t get a single transaction for days.

Most ERC20 Contracts store user balances in a simple mapping:

mapping(address => uint256) balances;

The Embiggen contract defines a struct for user balances, tracking both the balance and timestamp of the last change in the user’s balance:

struct UserBalance {
  uint latestBalance;
  uint lastCalculated;

The contract then has a mapping to UserBalance objects:

mapping(address => UserBalance) balances;

The getBalance() method then uses the latestBalance and lastCalculated timestamp to calculate interest earned since the UserBalance object was stored to determine the current balance.

When you send or receive MBGN tokens it calculates the current balance of the sender and receiver, increases or decreases those balances based on the amount sent or received, and creates a UserBalance object with the calculated balance and the current timestamp.

Interest Calculation

Doing interest calculations as part of balance checks means that it costs more to call getBalance() for MBGN than it does for conventional ERC20 tokens. The interest calculation fuction looks like this:

function getInterest(uint value, uint lastCalculated) public view returns (uint) {
  if(value == 0) {
    return 0;
  uint exp = (block.timestamp - lastCalculated) / 3600;
  uint x = 1000000000000000000;
  uint base = 1000000000000000000 + hourRate;
  while(exp != 0) {
    if(exp & 1 != 0){
      x = (x * base) / 1000000000000000000;
    exp = exp / 2;
    base = (base * base) / 1000000000000000000;
  return value.mul(x - 1000000000000000000) / 1000000000000000000;

If this looks a bit convoluted, that’s for two reasons:

All told, the gas consumption for balance calculation isn’t too bad. One target we considered is how long it takes for the balanceOf calculation to reach 5,000 gas. 5,000 gas is the price of storing a value in a contract, and to protect against re-entrancy some contracts that interact with unknown ERC20 tokens (such as the 0x Exchange Contract) only give 4,999 gas to balanceOf calls (since, in theory, ERC20 contracts should never store data on a call to balanceOf unless they’re doing something fishy). Embiggen’s interest calculator stays under 4,999 gas to calculate up to 179 days worth of interest. If your account hasn’t sent or received MBGN in over 179 days and you’re interacting with a contract that limits gas in this way, you might start to run into problems.

How Do I Get Some?

The Embiggen Token is mostly a proof-of-concept. The tokens aren’t backed by any kind of collateral, or even empty promises that they’ll someday be useful for something (maybe we’ll do something fun for MBGN holders in the future, but as it stands what you see is what you get). It also hasn’t been through anything resembling a rigorous security audit. That said, if you want some MBGN to start embigenning in your wallet, you’ve got some options.

Initially we’re offering them to addresses seen using OpenRelay. Starting immediately, if you post an order to OpenRelay or fill an order you find on OpenRelay, we’ll send some MBGN tokens to your address (if you post an order, we’ll send you some MBGN even if your order never gets filled). We’ll send out tokens in batches, so it may be a day or two after your trade that your MBGN arrives in your account. Since OpenRelay supports trading on both Mainnet and Ropsten, we’ll send you MBGN on Mainnet even if you’re just trading on Ropsten (using the same address across networks).

In a slightly longer time frame, we’re going to try distributing MBGN through a new sort of airdrop. The plan is to create one 0x order for every single Ethereum account holding ETH and load them all into OpenRelay. Users will be able to search OpenRelay for orders addressed to them, and redeem them through a simple user interface. This will entail loading around 30 million orders into OpenRelay, which will be the biggest stress test of our system to date. A big part of the reason we’re doing it is to flush out problems in OpenRelay, and not knowing how many problems we’ll run into it’s hard to put a timeline around the airdrop, but we’ll keep you posted.


We’ve launched our Embiggen Airdrop. You can claim yours today at