top of page



This document is a whitepaper representing current and future developments of MCC platform and our ecosystem. This whitepaper is for information purpose only and should not be considered as an exact guiding document depicting all future intent of MCC platform, unless specified explicitly.

The subject, matter and products enclosed in this whitepaper are currently under development and are not yet deployed. MCC makes no representations or warranties for successful implementation or development of such technologies, innovation and platform or achievement of any other implementation or activities illustrated in the paper.

It further disclaims all the warranties implied by any law or legal authorities to the extent permitted by law. No person or company is entitled to rely on the content and promises illustrated in this paper or any other inferences drawn from it, which includes relation to any interactions with MCC or the technologies elaborated in this whitepaper. The information present in this publication is derived from data obtained through the sources which are believed by MCC to be reliable and is presented in good faith and forecasted as MCC strongly believes in it, but with no warranties or guarantees. Contents of this paper regarding accuracy, completeness or suitability of the information specified, are as per the sources available at the time of its drafting and should be not relied on and shall not confer remedies or rights upon, by holders of security, creditors or other equity holders or any other person.

MCC disclaims all the liability for any damage or loss of capital, interest, or property of any kind.

(whether foreseeable or not) which may arise from any company or person acting on any information and opinions relating to MCC, the MCC platform, or our ecosystem contained in this paper or any other information presented regarding any further inquiries. Some images used in this document may be subjected to copyright but are pursuant to the fair use regulation. Any opinion or illustration expressed in this paper reflects the current judgment of the author of this white-paper publication and may not exactly represent the opinion of MCC. The information reflected herein may change without any prior notice. MCC does not have any constraint to update, modify or ameliorate any projection, forecast, opinion, or estimate set forth, or subsequent changes which makes the data inaccurate.

MCC, its directors, contractors, employees, or representatives do not have any liability or responsibility to any recipient or person (whether by the negligence of misstatement or by reason).

Neither MCC nor its advisors independently take any guarantee of the information including projection, prospects, and forecasts presented in this whitepaper. Each recipient or person is to rely solely on its own investigation, knowledge, assessment, and judgment of the matter which is subject of this publication and any other information which is made available via further inquiries or to satisfy the accuracy of projections.

While MCC has made every effort to ensure the authenticity of the facts and forecasts made in this whitepaper. Any forecast, projections or plans mentioned in this whitepaper publication may not be achieved due to several risk factors like market volatility, legal or regulatory exposure, corporate actions, defects in technology development, unavailability of information and all other risks. MCC may provide website’s hyperlinks of entities present in this whitepaper, though the inclusion of any link does not imply that MCC recommends, endorses, or approves any material on the linked website.

Such linked websites should be solely accessed by your own risk and MCC does not accept any responsibility for any such material or consequences of it. This whitepaper is only available on and may not be reproduced, redistributed, or passed on to any other entity. The distribution of this whitepaper may be restricted by regulations or law in certain countries. By accessing this white-paper publication, the recipient agrees to be bound with foregoing limitations.


  1. Summary

  2. Introduction

  3. Structure

  4. Privat Distribution of Tax1

  5. Exchanging Value thru Crypto

  6. Revolutionizing Education

  7. External Exchange

  8. Economics

  9. Allies


The housing market of the world has been completed much the same way for hundreds if not thousands of years. Recently home ownership has become out of reach for many homeowners. MCC is dedicated to investing in technologies that will increase the efficiency of building homes so that they become more affordable to the average consumer. The plan is to purchase and perfect 3D concreate printers and implement them in the construction of homes. The construction of homes with this technology will start in opportunity zones to provide jobs and homes. Any excess funds will be used to promote local businesses.

As the digital finance world is poised towards the evolving emergence of cryptocurrencies, the entire ecosystem is seeing a soar in usability as well as easier accessibility of capital for businesses being unlocked. In these shifting paradigms, the rise of transactional utilities through tokens have become one of the most talked-about phenomena of the cryptographic realm. These technological & financial advances have not only simplified the process of dealing with investors but also have secured the fundamentals of investing for an individual by enabling asset driven investments that can be liquidated at later stages, the utility or security tokens.

 MCC token is digital reward token. Once homes are constructed in the opportunity zones those that have possession of sufficient reward tokens can use them in exchange for housing and other products produced by the business helped by the MCC thanks token.

The MCC token can be stored in an Ethereum wallet until enough are collected to trade for housing products produced by any proceeds from the tokens or training, consultations, or compatible ERC20 Compliant tokens.


The MCC Whitepaper contains brief details, landscapes, technical specifications, and business models to help identify the project and explain our platform to the reader and stakeholder.

The platform provides multiple features to embed MCC in day-to-day life.

Exchange: The MCC token is designed to only be used as a reward token on the MCC websites and approved affiliates to access certain video classes, consultations and other activities that may be available on the https// website. However, the MCC token will have other ERC20 Ethereum tokens.

DeFi: Though MCC is not intended to be used on a decentralized finance platform exchanging the tokens may allow investors to participate in tokenization of assets ranging from real estate to business equipment.



MCC is laid on the Ethereum network and is an ERC20 token. The structure of the Ethereum blockchain is like bitcoin’s, in that it is a shared record of the entire transaction history. Every node on the network stores a copy of this history. The big difference with Ethereum is that its nodes store the most recent state of each smart contract, in addition to all the ether transactions. For each Ethereum application, the network needs to keep track of the ‘state’, or the current information of all these applications, including each user’s balance, all the smart contract code and where it is all stored. Bitcoin uses unspent transaction outputs to track who has how much bitcoin. While it sounds more complex, the idea is simple. Every time a bitcoin transaction is made, the network ‘breaks’ the total amount as if it were paper money, issuing back bitcoins in a way that makes the data behave similarly to physical coins or change. To make future transactions, the bitcoin network must add up all your pieces of change, which are classed as either ‘spent’ or ‘unspent’. Ethereum, on the other hand, uses accounts. Like bank account funds, ether tokens appear in a wallet, and can be ported (so to speak) to another account. Funds are always somewhere, yet do not have what you might call a continued relationship.

With Ethereum, every time a program is used, a network of thousands of computers processes it. Contracts written in a smart contract-specific programming language are compiled into ‘byte-code’, which a feature called the ‘Ethereum virtual machine.’

(EVM) can read and execute. All the nodes execute this contract using their EVMs. Remember that every node in the network holds a copy of the transaction and smart contract history of the network, in addition to keeping track of the current ‘state’. Every time a user performs some action, all the nodes on the network need to come to agreement that this change took place. The goal here is for the network of miners and nodes to take responsibility for transferring the shift from state to state, rather than some authority such as PayPal or a bank. Bitcoin miners validate the shift of ownership of bitcoins from one person to another. The EVM executes a contract with whatever rules the developer initially programmed. Actual computation on the EVM is achieved through a stack-based byte-code language (the ones and zeroes that a machine can read), but developers can write smart contracts in high-level languages such as Solidity and Serpent that are easier for humans to read and write.

Sharding Enhancements

Currently, every single node running the Ethereum network must process every single transaction that goes through the network. This gives the blockchain a high amount of security because of how much validation goes into each block, but at the same time, it means that an entire blockchain is only as fast as its individual nodes and not the sum of their parts. Currently, transactions on the EVM are not parallelizable, and every transaction is executed in sequence globally. The scalability problem then

• Decentralization • Scalability • Security

If we have scalability and security, it will mean that our blockchain is centralized and that would allow it to have a faster throughput. Right not, Ethereum is decentralized and secure.

How can we break this trilemma to include scalability in the current model? Well cannot we just increase the block size, or in Ethereum’s case, the GAS_LIMIT, to increase throughput? While in theory this can be a right approach, the more we keep increasing it, the more mining will be centralized around nodes running on supercomputers that would bring a higher barrier to entry into the system. A smarter approach is the idea of blockchain sharding, where we split the entire state of the network into a bunch of partitions called shards that contain their own independent piece of state and transaction history. In this system, certain nodes would process transactions only for certain shards, allowing the throughput of transactions processed in total across all shards to be much higher than having a single shard do all the work as the main chain does now.

Before we dive into how a sharded blockchain works, let’s go over some important vocabulary: • State: the entire set of information that describes a system at any point in time. In Ethereum, this is the current account set containing current balances, smart contract code, and nonces at a given moment. Each transaction alters this state into an entirely new state. •Transaction: an operation issued by a user that changes the state of a system •Merkle Tree: a data structure that can store a large amount of data via cryptographic hashes. Merkle trees make it easy to check whether a piece of data is part of the structure in a short amount of time and computational effort. •Receipt: a side-effect of a transaction that is not stored in the state of the system but is kept in a Merkle tree so that its existence can be easily verified to a node. Smart contracts log in Ethereum are kept as receipts in Merkle Trees, for example.

Let us look at how Ethereum 2.0 would work. We will create a sidechain known as a random beacon chain that stores hashes to main chain blocks in its own blocks. This sidechain will be a full Proof of Stake system implementing Casper FFG and will provide a source of distributed randomness that will allow us to build a sharding system on top of it.

The problems with sharded blockchains become more apparent once we consider that possible attacks on the network. A major problem is the idea of a Single-Shard Takeover Attack, where an attacker takes over most collators in a single shard to create a malicious shard that can submit invalid collations. How do we solve this problem?

The Ethereum Wiki’s Sharding FAQ suggests random sampling of validators on each shard. The goal is so these validators will not know which shard they will get in advance. Every shard will get assigned a bunch of validators and the ones that will be validating will be randomly sampled from that set.

To begin, we will deploy a contract on the main chain called the Validator Registration Contract, where people will burn 32ETH in exchange for becoming a validator in this sidechain. The beacon chain will periodically check for registered validators and consequently queue up those that have burned ETH into the contract. This beacon chain will serve as a coordination device for a sharding system, as it will allow for distributed pseudo-randomness that will be critical for selecting committees of validators on shards. The source of randomness needs to be common to ensure that this sampling is entirely compulsory and cannot be gamed by the validators in question.

On each shard, we would have nodes called proposers that would be tasked with creating a cross-link on the beacon chain, which is a specific structure that encompasses important information about the shard in question. These cross-links are like mini descriptions of the state and the transactions on a certain shard.

A typical cross-link would tell us the following information:

• Information about what shard the collation corresponds to (let us say shard 10).

• Information about the current state of the shard before all transactions are applied. • Information about what the state of the shard will be after all transactions are applied.

•Signatures from at least 2/3 of all collators on the shard affirming shard blocks were legitimate.

What about if a transaction happens across shards? For example, what if I send money from an address that is in shard 1 to an address in shard 10? One of the most important parts of this system is the ability to communicate across shards, otherwise we have accomplished nothing new.

An initial idea is using the concept of receipts for this system to work. Raul (Address on Shard 1) Wants to Send 100 ETH to Jim (Address on Shard 10)

• A transaction is sent to Shard 1 that reduces Raul’s balance by 100 ETH and the system waits for the transaction to finalize.

• A receipt is then created for the transaction that is not stored in the state but in a Merkle root that can be easily verified.

• A transaction is sent to Shard 10 including the Merkle receipt as data. Shard 10 checks if this receipt has not been spent yet.

•Shard 10 processes the transaction and increases the balance of Jim by 100 ETH. It then also saves the fact that the receipt from Shard 1 has been spent.

•Shard 10 creates a new receipt that can then be used in subsequent transactions.

This Sounds So Complex for Solidity Devs and Ethereum Users to Understand! How Will We Educate Them on Sharding?

They do not need to. Sharding will exist exclusively at the protocol layer and will not be exposed to developers. The Ethereum state system will continue to look as it currently does, but the protocol will have a built-in system that creates shards, balances state across shards, gets rid of shards that are too small, and more. This will all be done behind the scenes, allowing devs to continue their current workflow on Ethereum.

Beyond Scaling: Super-Quadratic Sharding and Incredible Speed Gains

To go above and beyond, it is possible that Ethereum will adopt a super-quadratic sharding scheme (which in simple English means a system built from shards of shards). Such complexity is hard to imagine at this point but the potential for scalability would be massive. Additionally, a super-quadratically-sharded blockchain will offer tremendous benefits to users, decreasing transaction fees to negligible quantities and serving as a more general-purpose infrastructure for a variety of new applications.

The ultimate ideology of educating MCC’s stakeholders and readers is to make them understand the level of architecture and our technical strength in terms of the blockchain that we currently have within our system. Ethereum to Ethereum 2.0 will only enhance the blockchain and make it a robust and fast processing blockchain in the universe.

ERC Elements

In 2015, Ethereum issued technical specifications for tokens on the Ethereum blockchain. Tokens that conform to these specifications are known as ERC20 tokens. (ERC stands for Ethereum Request for Comments.) In essence, ERC20 tokens are smart contracts that run on the Ethereum blockchain. While ERC20 tokens function within the framework set by the Ethereum team, the framework is broad enough to simultaneously allow developers considerable flexibility in the design and function of the tokens. Most tokens created through ICOs on Ethereum are ERC20 compliant.

The ERC20 standard has 6 functions and 2 events. The standard was created to enable interoperability across applications, exchanges, and interfaces. The functions describe how tokens can be transferred and how token-related data can be accessed. The events lay out formatting guidelines for transfers and approvals. Smart contracts on Ethereum, including all ERC20 contracts, are written in Solidity.

Contract ERC20{

pragma solidity ^0.6.0;

interface IERC20 {

    function totalSupply() external view returns (uint256);

    function balanceOf(address account) external view returns (uint256);

    function allowance(address owner, address spender) external view returns (uint256);

    function transfer(address recipient, uint256 amount) external returns (bool);

    function approve(address spender, uint256 amount) external returns (bool);

    function transferFrom(address sender, address recipient, uint256 amount) external returns (bool);

    event Transfer(address indexed from, address indexed to, uint256 value);

    event Approval(address indexed owner, address indexed spender, uint256 value);



ERC20 tokens can be customized to enable to following features:

1.Automatic buying and selling: you can peg the token’s value to that of another token or currency by creating a fund that automatically buys or sells tokens to maintain the balance.

2. Auto refill: transactions on the Ethereum blockchain require payments to miners in ‘gas’. You can program your token to auto-refill gas for future transactions once if it falls below a certain level.

3. Adding a central mint that can change the number of tokens in circulation: this could be useful if your token mirrors or simulates government currencies.

4. Freezing tokens: if instructed to do so by a regulatory body, you can freeze the tokens owned by that user and unfreeze them when required.

5. Proof of work: you can tie your token supply to the supply of Ether by programming a contract to run “merged mining” with Ethereum. A miner who finds a block in Ethereum then also gets a predetermined number of your tokens as a Block Reward.



The distribution of MCC will be done on the https// website as a reward token and through various crowdfunding events.

Shaping the tax consulting and entrepreneur industry

The use of reward tokens to encourage the public to learn more about how taxes affect their business and how they live their lives will significantly change how the public sees the income tax and how they need to order their businesses and lives to accommodate their tax planning.

The use of a crypto token makes it easier to track their earned rewards and keep them from expiring before they can accumulate enough to exchange the rewards for services or training.



MCC is designed to help in building products and platforms that transform your crypto assets into a digital token, MCC. We call it “crypto-assets” because major use of virtual currencies today is not mainstreamed to a global extent and therefore is often traded on exchanges to earn ROI. Transforming it into a cryptocurrency is basically when we make your virtual currencies usable and spendable across the world so that it has increased utilities and you not only keep it as an asset but as a mode of payment in daily use. We are penetrating the entire merchant market by targeting acceptance of MCC at high transactional volume segments such as retail, automobile, and real-estate to start off with.

The MCC token supply is fixed at 10,000,000. These tokens will be used to purchase services on the website and eventually become available on the decentralized exchanges at market value. Proceeds from the website and sale of these tokens will be invested in growing business in Opportunity zones to help them expand by purchasing real estate and equipment in the intent to create jobs and opportunities to encourage new businesses to locate and expand in these important areas of the country.

bottom of page