The team at Polymath, along with Fabian Vogelsteller have recently published ERC 1400, a standard for security tokens. We’re excited at the prospect of helping to build standards that achieve a broad consensus across all stakeholders in the security token ecosystem.

Created by Jackie Niam — Freepik.com

An important component of ERC 1400 is the concept of a Partially Fungible Token which is described in ERC 1410. This token concept is used by the Security Token Standard, but also has many applications outside of securities, some of which I’ll sketch out below.

A partially fungible token allows the token contract to partition a token holder’s balances into tranches, within which tokens are fungible, and outside of which they may not be. This provides additional granularity into a token holders balance. Each tranche can be associated with whatever metadata the implementation or use-case requires and drive on-chain logic around token usage and transferability. The standard provides an interface to operate on tokens at the tranche level as well as a non-tranche level (backwards compatible with ERC20 / ERC777).

In-Game Credits

Created by Starline — Freepik.com

Suppose you join a blockchain poker dApp — the game offers a 5 DAI in-game credit the first time you deposit 10 DAI, as an incentive to sign up. The in-game credit can be used on the platform, but not withdrawn (unlike the deposit which can be withdrawn).

Once Alice deposits 10 DAI, she would have a balance of 15 GDAI (Game DAI) for the purposes of game play, but a balance of 10 GDAI for the purpose of withdrawals. The smart contract needs to track both balances — the 10 GDAI in her default tranche which can be withdrawn (turned back into DAI) and the 15 GDAI she can play with (including the 5 GDAI in her game_credit tranche).

Alice can play using her total balance (15 GDAI), but only withdraw from her default tranche (10 GDAI)

As a partially fungible token this would be represented by the player having a single balance of 15 GDAI which is partitioned into two tranches, a game_credit tranche of 5 GDAI and a default tranche of 10 GDAI.

The contract would only allow withdrawals and transfers from the default tranche, but allow game play from both tranches.

Plasma Cash

Photo by Josh Riemer on Unsplash

Due to the vagaries of plasma cash implementations, life is easier if you can establish provenance for your tokens. Usually this is implemented by using ERC721 non-fungible tokens.

It’s fairly easy to use partially fungible tokens to flexibly track the provenance of tokens as they are transferred between users. The sendByTranche function sets the receiver’s tranche to be a keccak256 hash of the sender’s tranche, and the sender’s address. This is possible because a partially fungible token determines the destination tranche, rather than this being an input into the sendByTranche function.

Let’s look at an example:

Alice starts with 10 tokens, Bob starts with 5 tokens:

Alice transfers 5 tokens to Bob:

Bob then transfers 3 tokens to Charles from his default tranche, and 2 tokens to Charles from the balance received from Alice:

This means that if Alice now sends another 5 tokens to Charles, via Bob, these additional 5 tokens would drop into the same tranche on Charles’ balance (as they’d have the same provenance which generates the tranche key).

If you want the full history on-chain, the token contract can associate this list of addresses as metadata with each tranche key as it transfers balances into it.

mapping (bytes32 => address[]) trancheHistory;

trancheHistory[default] == [];

trancheHistory[hash(Alice, default)] == [Alice];

trancheHistory[hash(hash(Alice, default), Bob)] == [Alice, Bob];

Security Tokens

Partially fungible tokens form the basis for ERC 1400 which describes a proposed standard for security tokens.

There are lots of ways you may need to partition the balance of a holder of securities — one of the most common use-cases would be to use it to implement a lock-up period during which the securities can’t be transferred.

For example, suppose a security has a 12 month lock-up period that starts from when an investor receives their securities. Suppose Dave, an investor in the STO (Securities Token Offering), purchased 100 securities on 1st Jan 2018, and 50 securities on the 1st Feb 2018.

As a partially fungible token, this would represent the investor’s balance of 150 as being split into two tranches . A 1-Jan-2019 tranche with a balance of 100 and a 1-Feb-2019 tranche with a balance of 50. The sendByTranche function would only allow transfers from a tranche after the date is past the tranche key. The destination tranche of any successful transfer would be the unrestricted tranche, and unrestricted tranche balances can always be transferred.

So, if Dave were to transfer 50 securities to Edward on the 2nd Jan 2018, Edwards’ balance would show 50 in the unrestricted tranche.

Wrap Up

The security token standard ERC and the underlying partially fungible token standard ERC are intended to drive forward the conversation on standards for securities on Ethereum. Our aim is to build a broad consensus across all organisations involved in this exciting area to increase adoption, accessibility and interoperability.

Please get involved in the conversation at:

ERC 1400: Security Token Standard

ERC 1410: Partially Fungible Token Standard

Joining Polymath

Do you want to join the security token revolution? We are growing rapidly and always looking for high quality talent. Check out our careers page at https://polymath.bamboohr.com/jobs/ to apply!

About Polymath

Polymath Network (Polymath) is a decentralized platform that makes it easy to create security tokens. The platform simplifies the complex technical challenges of creating a security token and aims to bring the multi-trillion dollar financial securities market to the blockchain.