Share on Twitter
Share on Facebook
Share on Reddit
Share via Email
Share on LinkedIn
Share via RSS
Share on Google+

On May 8th, 2018, development group Splyse began airdropping its new Master Contract Token (MCT) to NEO addresses that had received a transfer of any existing NEP-5 token on the NEO MainNet before May 8, 2018 00:00 UTC (ending with MainNet block 2,240,482).

1,000 MCT tokens are being distributed for each NEP-5 token held for any length of time, regardless of the amount. For example, if a NEO address held only RPX, RHT and ONT (in any quantity) at any point before May 8, 2018, they will receive an airdrop of 3,000 MCT.

A total of 567,442,000 tokens will be airdropped to 404,453 NEO addresses, and the airdrop is expected to be completed by May 10, 12:00 UTC. 580,000,000 tokens is the maximum supply of MCT with the remaining ~2% allocated to Splyse for development costs and ongoing support.

Splyse is the development team behind the upcoming HashPuppies game. Previous achievements include winning first place in the inaugural City of Zion dApp competition with NEO Smart IoT, and winning third place in the NEO / Microsoft dApp competition with their Non-Fungible Token (NFT) Smart Contract Template.

What is Master Contract Token?

The MCT token has been in development since March 2018, and was created to solve a limitation in the smart contract functionality of NEO. Whilst NEO smart contracts can receive funds, it has not yet been possible to programatically trigger a send action on-chain. Send transactions require triggering by an external piece of code that exists off-chain, such as a wallet.

This is often a stumbling block for smart contract developers who may migrate from Ethereum.

MCT solves this issue by first modifying the existing NEP-5 “transfer” implementation, adding the “GetContract(scripthash)” NEO API call. Upon transferring MCT tokens to a smart contract, the MCT smart contract will check the receiving scripthash against all the deployed smart contracts on the network. If a match is found, it will then invoke the “OnTokenTransfer” operation in the receiving contract.

The “OnTokenTransfer” operation can be written to perform any function, including the automatic execution of a send transaction.

If either a matching scripthash is not found, or the receiving smart contract does not support “OnTokenTransfer”, the transfer will fail. This protects users from sending tokens to a smart contract that doesn’t exist, or does not support the receiving of tokens.

A recent example of this issue was when users tried to send NEO to the Ontology smart contract through the Neon Wallet, thinking they could purchase ONT tokens. Unfortunately, Ontology was unable to refund the tokens sent to their contract as they left out the code that would normally allow the contract owner to spend assets sent to it (since they weren’t doing a crowdsale). The NEO sent to that contract are essentially burned, now stuck in the ONT contract address. Under the MCT format, the transfer would have been rejected and the tokens would not have left the sender’s wallet.

MCT Use Cases

Splyse has provided various examples of MCT implementations on their GitHub. One example is an atomic swap contract that exchanges one MCT for another MCT-compatible token in a single transaction, at an exchange rate determined by the contract owner.

Another example provided by Splyse is a king-of-the-hill contract. In it, they demonstrate receiving tokens from one user (the prospective new king of the hill) and sending tokens to another user (the old king) in the same transaction.

Both of these examples work simply by sending MCT to an address – there’s no middleware and no front-end code required for them to function as intended. Tokens go in, and based on a decision by the contract, tokens go out, all in the same transaction.

Other possibilities include lottery, dice and casino style contracts, as payouts can be distributed seamlessly and through a self-contained, single auditable contract.

Contract Storage

As an additional value add on for both the MCT token and the NEO ecosystem, MCT tokens can be staked to use the MCT smart contract as a storage proxy.

Smart contract deployment on the NEO MainNet costs 90 GAS for a simple smart contract, 490 GAS for a smart contract that uses persistent storage, and 990 GAS for a contract with storage and dynamic invocation capability.

Use of the MCT smart contract storage requires a stake of 10,000 MCT. This will allow developers who only require basic storage to deploy a smart contract for 90 GAS instead of 490 GAS – a savings of approximately USD$30,000 based on the exchange rate at the time of this writing.

Splyse hopes that this will give individuals and small development teams more incentive to build applications on NEO instead of Ethereum or looking at one of the other emerging smart-contract platforms.

Moving forward

Speaking to NEO News today, Splyse co-founder Joe Stewart, gave some early indications of future plans for MCT.

“There’s a good chance it may be used in other Splyse projects but we haven’t made the decision yet. HashPuppies is the big project to roll out in the next few months, and we have to decide how we are going to do puppy auctions – MCT could potentially make that process easier.

Since newcomers might then need to get their hands on some MCT, we would like to see exchanges list it and credit their users with any airdropped tokens that hit the user’s deposit address.”

Joe also pointed out that for 90 GAS (plus 10,000 MCT staked), anyone could set up their own “MCT exchange” and set their own exchange rate to trade MCT for NEO or GAS. However, those contracts would still be subject to the limitations of system assets, which would be unable to refuse transfers once the MCT supply in the contract ran out – which is the reason MCT needed to be created in the first place.

For more information on Master Contract Token, you can visit the GitHub or join the MCT Discord.