Introduction
With the kind of crypto bear market we saw recently, it has become ever more important that the most famous blockchains (BTC/ETH/NEO) start getting real-world adoption. Without adoption, the whole crypto industry will slowly lose relevance. This is what Vitalik Buterin (founder of ETH) has to say:
So, projects which try to improve real world usage of blockchains should be given more importance. One such project on the NEO blockchain is Master Contract Token (MCT).
MCT explained
As the website states, MCT token is a utility token for the NEO Smart economy.
Most utility tokens on the NEO blockchain are built for a specific dApp. However, MCT wants to be a utility token used for multiple dApps, similar to NEO/GAS. Thats why they call themselves a utility token for the NEO Smart economy, as they are not tied to any dApp.
But, how do they plan to do this? Basically, the team behind MCT has the hypothesis that dApp development on NEO can be increased by removing certain noteworthy obstacles developers might face presently. These obstacles do not exist on the Ethereum blockchain, and solving them will get more developers to consider developing on NEO vs. Ethereum. If MCT succeeds in its mission, NEO will become a formidable competitor to Ethereum, and many developers will use MCT as their utility token. With more developers flocking to NEO, the probability of projects helping real-world adoption increases. NEO Global Capital (NGC) believes in the aim too, so they invested in MCT recently.
NEO Global Capital invests in MCT
Issues for developers with NEO
Let’s look at the existing obstacles with NEO for developers and how MCT solves them.
- High costs to deploy smart-contracts
The following shows the 3 ways NEO smart contracts are deployed:
- No storage — 90 GAS
- Basic storage — 490 GAS
- Full storage — 990 GAS
Generally, a smart-contract for a dApp requires some form of storage. It could be a record of what was sent to the contract or any other kind of key-value pairs. So, Basic storage contract deployments are common. But, the cost of deployment at 490 GAS is on the higher side. So, small-time dApp developers might have to shift to Ethereum to lower their costs.
However, with MCT, the cost for Basic storage can be lowered to just 90 GAS by staking 10,000 MCT. This lowers the cost considerably and has a tremendous boost to the budget of a dApp developer. In the long run, the ecosystem gains by keeping those developers on NEO.
With MCT, the cost of deploying smart-contracts on NEO decreases considerably which leads to more developers on NEO. A win-win for MCT and NEO.
2. NEP-5 token limitations
The NEO smart economy has a major limitation that on receiving system assets (NEO, GAS) or other NEP-5 tokens, the receiving smart-contract is not triggered. In other words, there is no event for the contract to act on. Also, the smart contract cannot independently spend the tokens without coordination with off-chain code or wallet. This is ok if you want to raise funds for an ICO, however when you start developing specific use cases for the dApp, it leads to unnecessary complexity and points of failure.
This is what Joe Stewart (known as @hal0x2328 on Discord, or “Hal”), the lead developer of MCT has to say about this:
“Receiving assets or other tokens doesn’t trigger the receiving smart contract at all, you have to construct an InvocationTransaction to invoke an operation in the contract. That’s fine if you want to build a dApp with it’s own specialised wallet or add it to existing wallets if it’s a universal type of operation (like mintTokens was added to Neon) but it is still extra code to be written.
But what if you want another smart contract from another owner to invoke your contract’s function? They would have to go through your dApp’s off-chain code unnecessarily or implement the same code in theirs.
With MCT, contract 1 just transfers some MCT to contract 2 and adds whatever parameters on the end of the transfer call. Done, in a single transaction, and contract 2 can reject the transfer if some conditions aren’t met. Right now, with the existing method dApps are using, that mintTokens call could fail or return false, but the assets would still be transferred. Now the off-chain part of your dApp has to be written to handle refunds for failed invocations. MCT eliminates that headache. Sending assets/tokens by a smart contract is also a chore. For assets, that’s a new UTXO transaction that has to be created. Smart contracts can’t perform that function, so off-chain code has to “withdraw” the funds from the contract in a crafted transaction to send the funds elsewhere. But what triggers that off-chain code? What if the listener that triggers it goes down for these transfers or refunds?
Does the dApp have redundancy to prevent missed transactions, but also to prevent double-spends? It takes time and effort to build a reliable solution. For tokens, it’s not quite as hard but your dApp has to construct the transaction in a way that will allow the smart contract to authorize itself as the owner of the tokens being transferred. Just calling transfer() in the NEP-5 contract won’t cut it (except with MCT), it still needs a custom wallet/dApp to create this transaction and invoke your contract with it.”
As you can understand, this inherent limitation of NEO constrained its use-cases. However, with MCT, developers of dApps can use it as a universal form of payment instead of each dApp having yet-another-token you have to go buy on an exchange. This is huge!
Having understood what obstacles MCT solves for NEO, lets see what new opportunities open up.
Use-cases:
Payments
Having looked at the limitations MCT solves, it seems to be a great idea for developers to use it in their smart contracts on NEO. However, not all projects would need MCT. I think dApps which have the need to pay or be paid, especially both, for e.g. lottery, dice and casino style dApps, games (both paid in and paid out) need MCT the most, as opposed to an ICO crowd-sale (paid in only, and wallets are already integrated with mintTokens). Generally, dApps that receive funds aren’t as bothered as dApps that need to send funds.
So, dApps which only need tokens to raise funds won’t need MCT much. However MCT will become a multi-dApp utility token for all games, lottery dApps etc. — i.e. projects that need to pay and get paid.
Games
NEO is promoting the usage of the ecosystem to develop games because of the addictiveness games create. http://neo.game/works-en.html. NEO recently had an AMA on August 2nd, 2018 where Da Hongfei, the founder of NEO stressed on that point.
Da Hongfei’s response on an AMA question
In such a scenario, I feel MCT might act as a brilliant utility token for these games. Users won’t have to go to various exchanges to pick up different tokens for various games; its convenient.
This naturally opens up a question — in the present market scenario every project wants to have their own token. How does a project decide to choose between their own token vs. using MCT?
Hal gave some intersting insights on this:
It’s really a question of why they need a token — if it’s for large-scale fundraising, then they might choose to use their own token. But not all dApps need millions of dollars for development, so in those cases there’s really no functional reason to use their own token and every reason to use MCT instead.
1. It’s already available so no need to write any NEP-5 contract code
2. It’s already on listed on exchanges so new users can obtain it easily
3. It’s in a lot of users’ hands already due to the 98% airdrop
4. It’s convenient for users who already use MCT with another dApp
The Team
Let’s look at the team behind the project. MCT has been developed by Splyse, the team behind the highly awaited Cryptokitties-like game on the NEO blockchain called HashPuppies. Do you remember Cryptokitties had broken the Ethereum blockchain with its high number of transactions! It is expected HashPuppies might do the same to NEO. However, it is still a couple of months away from getting live.
The team had previously won the inaugural City of Zion dApp competition by developing NEO Smart IoT and came 3rd in the NEO/Microsoft dApp competition by developing the Non-Fungible token (NFT) smart contract template. So, we can say the team has strong credentials. Also, development of MCT has already been completed and the token is live for usage. Awesome, right?
Since, I got really interested in the project. I had further discussions with Hal which are provided verbatim below. Its a gem of a project, and will start gaining traction as one reads about it more!
Further discussions
- Q: It seems NEO 3.0 will solve the specific issues MCT plans to solve, in that case isn’t MCT redundant?
Hal: Interestingly no.
1. Backwards compatibility:
The NEO team prefers if developers can make changes to the NEO blockchain using contracts rather than making changes to the core code. It makes it easier for backwards compatibility. For e.g. NEP 7 solves some of the changes MCT brings. However, it will be an extremely tedious task to roll it out as it impacts all past transactions as well as future ones. One mistake, and you can invalidate previous ICO token sales if every interaction of every previously deployed contract is not considered.
2. NEO 3.0 might solve all changes MCT brings. However, it is around 1–2 years down the line.
3. MCT solves the required NEO issues NOW, not a year down. It is extremely important to note that. So, there will be many developers who use MCT as a utility token now. Eventually, when NEO 3.0 is released, MCT will be valuable due to these network effects. It will be a multi-dApp utility token among the various single dApp utility tokens.
Q: If MCT is so beneficial for the NEO ecosystem, what stops someone from forking it and creating their own version of MCT, then repeating the same process of airdrop etc.? Doesn’t this undermine MCT’s future potential?
This was one of the questions someone asked in MCT’s Discord channel. MCT’s lead developer Hal had a convincing answer, which makes MCT more valuable in my eyes.
Hal: They’d have to solve all the problems that we solved to get to this point — right now there aren’t that many developers who have deep of knowledge of the Neo VM to understand how to write this contract securely. The contract is not open source so they’d have to reverse-engineer the whole thing. And they’d have to be willing to front 990 GAS to deploy their clone token and hope they didn’t just throw away $26,000 if they made a mistake in the code trying to replicate it.
Conclusion
So, thats all about MCT! Splyse, the team behind MCT, seems to have picked up an extremely important problem statement and have delivered a working product. It can effectively replace GAS in various transactions. Now, the success can only be gauged by how effectively the developer community picks up using the token. I wish the team all the best.
Hope you enjoyed the article! Can think of someone right now who should read this? The ‘Share’ button is all yours.
About the Author
Ankit is the co-founder of a crypto investment fund — Bitazu Capital (www.bitazu.com). Let’s be friends on Twitter.
Disclaimer
The views presented in this article are my own. This article is for information purposes only. It is not intended to be an investment advice.