Patents Wiki
Back to briefings
PaperBlockchain

The Mint Contract That Tried to Make Game Items Real Money

If you bought a flaming sword in your favorite MMO a few years back, you owned a row in somebody else's database. The publisher could change the drop rates, nerf the sword into uselessness, or shut the servers down tomorrow and your "asset" would vanish with the company. In September 2017, a small Singapore team published a 34-page whitepaper that tried to do something new with that database row: turn it into a token on Ethereum, with a real, on-chain, redeemable value floor. The idea is called Enjin Coin. Two years on, the team has shipped an Ethereum Improvement Proposal that became an official token standard, and the Mint/Melt mechanism that anchors the whitepaper is now the design pattern that an entire corner of the gaming crypto industry uses.

This briefing walks through the whitepaper from first principles. We will start with the economic problem the protocol is trying to solve, then unpack the Mint/Melt contract pair, look at how a virtual item actually gets a token price, and end with the open risks and what to watch in the next six months. No prior blockchain background is required.

The paper at a glance

  • Title: Enjin Coin — Smart Cryptocurrency for Gaming (Whitepaper v1.10)
  • Authors: Enjin PTE LTD, co-founders Maxim Blagov (CEO) and Witek Radomski (CTO)
  • Published: 26 September 2017 (the version on enjincoin.io)
  • Length: 34 pages
  • Where to read: https://enjincoin.io/enjincoin_whitepaper.pdf
  • Companion spec of interest: ERC-1155, authored by the same Witek Radomski and adopted as an Ethereum standard on 17 June 2019

Why a game item is, technically, just a lie

The whitepaper opens with a striking number: for every legitimate virtual item that successfully changes hands, approximately 7.5 items are lost to fraud. The team cites a study from eMarketer to back the figure. They use it to argue that the existing virtual-goods market is structurally broken in four ways.

First, an item you buy in a game is not really yours. It is a record in a centralized database that the operator can modify, freeze, or delete at will. You do not have a property right; you have a license that the operator can revoke.

Second, items do not move. A sword in World of Warcraft cannot travel to Final Fantasy XIV, and a skin in Counter-Strike cannot be used in Fortnite. Every publisher runs a closed garden, so the network effect of game items is fragmented across thousands of walled databases.

Third, the value is opaque. There is no public ledger showing how many of a given item exist, what they were originally sold for, or what their secondary-market price is. Buyers cannot tell a scarce item from a massively-printed one, and sellers cannot prove provenance.

Fourth, the redemption path is missing. If you stop playing a game, your inventory goes nowhere. There is no way to convert the time and money you put into a virtual sword into any other kind of asset: not cash, not cryptocurrency, not even a different game's item.

These four problems share a common root: there is no neutral, shared infrastructure for game items. Each game rolls its own. Enjin's bet is that Ethereum can be that infrastructure, as long as the protocol solves a specific problem first: how do you make a token that is honestly worth a known amount of money?

One coin, three layers, and the reserve trick

The whitepaper's answer is to build a three-layer value hierarchy on top of Ethereum, with a single reserve asset at the bottom that gives every layer a known, redeemable price.

The bottom layer is the Enjin Coin (ENJ), an ordinary ERC-20 token with a fixed supply of one billion units. ENJ is the universal reserve currency across the entire Enjin ecosystem. When an item is priced in ENJ, the price is in something real, because ENJ itself is tradable on any Ethereum exchange for ETH and, through ETH, for fiat.

The middle layer is the Custom Coin. A game developer, community operator, or content creator can issue a project-specific ERC-20 token (say, "ForestShards" for a particular game). Every unit of a Custom Coin is backed 1-for-1 by ENJ held in reserve. The Custom Coin is a denomination of ENJ, packaged with metadata that says "this fraction belongs to Project X."

The top layer is the Virtual Item. A sword, a skin, a plot of land, even a custom in-game currency that is too small to be worth its own Custom Coin. All of these are issued as their own ERC-20 tokens, each backed by some quantity of Custom Coin, and therefore ultimately by some quantity of ENJ.

This three-layer cake is not new. Stablecoins have used the same trick for years: a token that is redeemable for a reserve asset has, by construction, a known price floor. The move in Enjin's whitepaper is to extend the same idea up the stack from a single coin to an entire hierarchy of game items, and to bake the redemption into the smart contract logic at every level.

The Mint and Melt pair, explained with concrete numbers

The mechanism that ties the three layers together is a pair of contract operations. Let us walk through a concrete example, since the abstract description is harder to follow than the actual numbers.

Imagine a game developer named Alice who wants to issue a "Legendary Sword" item. She starts by going to the Mint Contract, a smart contract whose only job is to hold ENJ deposits and issue Custom Coins against them. She calls the mint function with two arguments: the address of the Custom Coin contract she wants issued, and the quantity of ENJ she is putting up. Suppose she sends 10 ENJ.

The Mint Contract does two things atomically: it transfers 10 ENJ from Alice into a custodial balance inside the Mint Contract (the contract now holds her ENJ), and it calls the Custom Coin's issue function, which mints 10 units of the project-specific token and sends them to Alice. The Custom Coin's total supply is now 10, and the Mint Contract's ENJ balance is also 10. The 1:1 ratio is enforced by code, not by a promise.

Now Alice mints the sword. She uses the ENJ-backed Custom Coin to back the sword token, again through a mint operation at a known ratio. Suppose each sword is backed by 0.1 Custom Coin. She calls the appropriate function, the Custom Coin gets locked in the Mint Contract, and 100 sword tokens appear in her wallet.

Now a gamer named Bob buys one of Alice's swords. He pays Alice 0.1 ENJ (or some agreed amount in any token; the backing stays 0.1 Custom Coin per sword, which is 0.1 ENJ per sword). Bob now holds a sword token, and that token's on-chain provenance traces back to 0.1 ENJ held in the Mint Contract.

Here is the redemption part. Bob later decides he is done with the game. He calls the Melt operation on the sword. This is the inverse of mint. The contract destroys Bob's sword token, destroys the corresponding 0.1 Custom Coin, and returns 0.1 ENJ to Bob's wallet, less any fees. The whitepaper says the holder "can convert custom virtual goods directly back to Enjin Coins and retain value." The protocol enforces this at the contract level: the melt value is locked in at mint time, not at melt time, so Bob's redemption is independent of any later ENJ price volatility against the sword. He gets back the ENJ that was originally committed, not whatever ENJ is worth today.

Every in-game item has a known, on-chain, auditable ENJ value floor. That is the whole protocol.

Core Architecture/Flow

What the whitepaper actually claims

Reading carefully, the v1.10 paper makes a small set of specific, falsifiable claims rather than vague promises.

First, a quantified framing of the existing market's problem. The team cites the 7.5-items-lost-to-fraud-per-legitimate-purchase figure and the general fragmentation of game economies as the motivation. This is the only number in the paper that is an empirical claim, and it functions more as a rhetorical anchor than as a benchmark. The actual savings depend on what fraction of a given game's transactions were fraudulent before the protocol, which the paper does not measure.

Second, a fixed-cap token. The ENJ supply is one billion units, with a defined crowdsale schedule running from a pre-ICO bonus tier to a main ICO window that opened on 3 October 2017. The whitepaper specifies that unsold tokens would be retained by the company and locked for six months, with a stated minimum sale price floor.

Third, a Mint/Melt rate guarantee. The whitepaper commits that the Mint and Melt operations use the same exchange rate, locked in at mint time. If the rate could move, the floor would be soft, and a Custom Coin or item could be redeemed for less ENJ than was put in.

Fourth, an explicit integration with the Enjin content management system. The paper states that ENJ will be fully integrated into Enjin's existing CMS, which hosted 250,000 gaming communities and 18.7 million registered gamers as of late 2017, within six months of the launch. The point is distribution: the team was not just shipping a smart contract, they were shipping a smart contract with a built-in user base of gamers.

Fifth, an open-source software development kit and a set of supporting contracts, including Token, Mint, Registry, TopList, and Crowdsale, that the team promised to publish. The Enjin Coin contracts repository on GitHub (https://github.com/enjin/contracts) is the canonical code for these.

Sixth, a stated melt cap. Companion materials describe the melt redemption as returning "up to 50%" of the original ENJ backing. The exact percentage is governed by the contract parameters and is not a fixed protocol constant. The whitepaper describes the mechanism, not a specific number.

Seventh, a positioning claim. The paper explicitly deploys ENJ and the virtual assets as ERC-20 tokens on the Ethereum mainnet, in 2017, before multi-token standards existed. The architecture is intentionally simple: each layer is a separate ERC-20 contract, and the value hierarchy is enforced by the Mint/Melt contract calls, not by a new token standard.

That last point matters for protocol designers. The whitepaper shipped in September 2017, before the ERC-1155 standard was even proposed. The CTO Witek Radomski later authored ERC-1155, which generalized the design into a single contract that could mint both fungible and non-fungible tokens, and that standard was officially adopted on 17 June 2019. The v1.10 whitepaper reads as a pre-standard statement of intent; the formal multi-token specification is the later work.

Why this matters beyond gaming

The Mint/Melt pattern applies to more than game items. Any community that wants to issue a token honestly backed by something, whether points, credits, gift cards, or loyalty miles, can use the same three-layer cake and the same Mint/Melt pair. The contract pair is generic: deposit a reserve asset, get a wrapped token; burn the wrapped token, get the reserve asset back.

The on-chain redemption floor is the part that changes the game. Most "asset-backed token" proposals pre-2017 had no on-chain enforcement of the redemption; the issuer could go bankrupt, the custodian could abscond, the bank could freeze the account. The Enjin paper's bet is that putting the reserve in a public smart contract, and exposing both mint and melt as public functions at a fixed rate, removes the issuer as a trusted party. The token is what it is because the contract says so, not because a company says so.

For game publishers, the practical effect is that a publisher who mints items on Enjin cannot quietly print more swords, because every mint increases the Custom Coin supply, which is auditable on Ethereum. A publisher who shuts down a game can be ignored by the items, which will continue to exist on-chain and can be melted back to ENJ at the original rate. Whether or not the publisher cooperates, the items have a real value floor.

For Ethereum itself, the Enjin architecture is one of the early serious uses of smart contracts as a backing-reserve layer, alongside the Dai stablecoin design. The two approaches are similar in spirit and differ mostly in domain: Dai backs a stablecoin with crypto-collateral, Enjin backs game items with ENJ-collateral.

What is unresolved

A short list of what the whitepaper itself flags, plus what an attentive reader should worry about.

Ethereum throughput. In 2017, Ethereum could comfortably handle tens of transactions per second; in 2019, with network usage at its highest level, gas costs made small in-game trades expensive. The v1.10 architecture assumes every mint, melt, and transfer happens on the main chain. There is no L2, no sidechain, no batching. The team has indicated that follow-on work will address scaling, but the v1.10 design does not.

Custody and user experience. The trust-minimization story depends on the gamer holding their own private key. In 2017, mainstream gamers were not familiar with seed phrases or gas fees. The whitepaper relies on the Enjin Wallet to abstract this, but every abstraction is a potential custody reintroduction.

The 50% melt cap. The "up to 50%" redemption is a contract parameter, not a protocol constant. A future version of the Mint contract could lower the cap, freeze melts, or add new fees. The current code is open-source and auditable, but the parameters are upgradeable.

Security of the supporting contracts. The Token, Mint, Registry, and TopList contracts are deployed and used in production. The whitepaper does not include a formal security audit; readers who want to assess risk should look at the Enjin contracts repository directly and at any subsequent audit reports.

Regulatory treatment. ENJ was sold in an ICO in late 2017, and the regulatory status of gaming tokens, especially in the US, was unsettled in 2017-2019. The whitepaper does not commit to a specific legal wrapper for the token, and the team has had to navigate ongoing enforcement actions against other ICO issuers in this period.

Standardization lag. The v1.10 paper specifies a stack of separate ERC-20 contracts. The later ERC-1155 work by the same CTO collapses several of these into a single contract and adds native non-fungible support. New projects building on Enjin today are more likely to use ERC-1155-based infrastructure than the original 2017 design.

What to watch next

For readers who care about this protocol specifically, the next six months are about deployment rather than design. The Mint/Melt design is settled; what is open is how much of the gaming world adopts it. Concrete signals to watch: the share of ENJ actually locked in Mint contracts, the number of distinct Custom Coin contracts in active use, and any audits of the deployed contracts. The first two are observable on-chain; the third is more a function of how much institutional money is willing to bet on Enjin-built games.

For readers who care about the broader pattern, the Enjin whitepaper is one of the cleaner production examples of the reserve-backed token idea. Watch how the multi-layer ERC-20 stack with explicit mint/melt compares to ERC-1155's single-contract approach, and how both compare to the L2-native and sidechain approaches being explored for 2020. The design space is wide open, and Enjin's v1.10 is a useful reference point.

Sources