MTO Development Stages

Heimdall Is Here

HIPS Merchant Protocol (HMP), the Hips Merchant Protocol Gateway (HMP- gateway) and
the governing Merchant Token (MTO) is a solution that aims to introduce consumer
protection concepts from the traditional card payment industry to any blockchain with
support for smart contracts like Ethereum, Cardano (ADA) or Solana.

DEVELOPMENT PROCESS

Software products move through a multi-step process before being released to the public.
Below are the stages that the Merchant Ecosystem will move through.

KEYWORDS

Protocol

These are a set of rules or instructionsthat determine how different components
interact in a system.

Gateway

A node that converts information, data orany other communication from one
protocol to another.

A testnet

Is a blockchain protocol or network thatis not yet operating at full capacity. It is
used by developers to test and troubleshoot its aspects and features before it can be
deployed.

Mainnet

Is a blockchain protocol that is fully developedand deployed.

User interface(UI)

Is a point where humans can interactwith a computer system or an
application. It’s a series of visual elements contained in a system that enables a person to
interact with it.

The Merchant Token ecosystem

Is the entire range ofthe Merchant token products that are being developed and this includes; the Merchant Token Wallet, the Merchant Token
protection protocol, the MEO and MTO mainnet.

Alpha

Thealphaversion of a software product is the firstphase of software testing. This is a
pre-released version that goes through a dedicated testing process. The aim is to develop an
efficient, accurate and bug-free software.

DEVELOPMENT STAGES

TYR STAGE - Successfully Completed.
This is the Merchant Protocol and Gateway (MPGW) Pre-MVP stage. Overall technical design
of the MPGW and the technical design of the UI for the dispute management platform.

The first stage is like creating the foundation or skeleton code upon which improvements are
done. This is where a concept gets to be turned into a product. The end product of this stage
is called the Minimum Viable Product(MVP) This was concluded and the MVP was
launched.

HEIMDALL STAGE - LIVE NOW
The (MPGW) MVP Release with minimum functionality for purchase of a product with
merchant and consumer protection and with support for both Automatic Dispute
Management (ADM) and Community Dispute Management (CDM).

At this stage, the functionalities and thebackend requirements that facilitate the
integration of the marketplace for products will be created.
The merchant dashboard and the consumer protection functions will also be built.
It will include the escrow (a way by which funds paid to purchase a product or service are
locked until a transaction is completed). This stage will involve the creation of the dispute
Managements system consisting of the Automatic dispute Management (ADM) and (CDM)
For the ADM, the dispute resolution process will be handled automatically by the software,
while for the CDM, it will involve an agent (person) taking the case and resolving the dispute.

VALE STAGE
Early Alpha version of the MPGW "Heimdall" with basic support for purchases from external
wallets. This release will include an Alpha version of the Merchant Wallet (MW).

This stage will have plugins and functionalities that will enable purchases and connectivity
to an external wallet (Metamask or any other crypto wallet)
This will enable the use of personal wallets when paying for goods and services. Just click
on buy and a pop-up from the personal wallet will appear to authorize and pay for the good
or service.

MTO native wallet will be created and tested in this stage. It will be designed to work with the
MTO system. The alpha version of this wallet will be released at this stage.

BALDUR STAGE
Early Alpha with extended functionality in Merchant Protocol, Gateway and Merchant Wallet.
Functionality to auto-swap MTO for consumer protection and also built-in dispute in the
Merchant Wallet.

This stage similar to stage 3, but with extended functionalities (improvements) in the
merchant protocol, gateway, and the Merchant wallet.

The auto-swap MTO attribute will be added. This is for use when a consumer is making a
purchase but has no MTO and they will be prompted with a pop-up note asking, “Do you
want consumer protection for x amount of money?” If they choose yes, and they don't have
MTOs, they will be asked to choose how they want to pay and as long as they have other
tokens/coins in the wallet, they will be able to buy MTO automatically if they choose. The
buying of a token with another is what is called autoswap and will be calculated using the
most up-to-date prices of the tokens or coins. The autoswap functionality simplifies the
process and transaction time as the other alternative would be a customer has to login to
another exchange, purchase MTO, then pay withdrawal fees to transfer to their wallet.

FRIGG STAGE (Beta net)
A temporary test network (MEO) which will support an intense period of public testing ahead
of launch of the first version of the Merchant mainnet; and will enable community
participation in testing of wallets and nodes under real-world conditions.

A temporary test network with MEO as a native coin will be operationalized. This network will
be rigorously tested during an intense period of public testing ahead of the launch of the first
version of the Merchant mainnet.

MEO being the native coin on this blockchain means it will be used for transactions on it.
This is very different from MTO which is an ERC20 token that relies on the Ethereum
blockchain and ETH for transactions. So, when the Merchant blockchain is active, MEO will
be used instead of MTO.

Swapping of MTO’s to MEO will be tested at this point. It’s important to note that users will
be able to keep MTO’s on the ETH network until they choose to swap to MEO’s. There will be
no loss of tokens if they choose to leave MTO on the ETH network for some time.
At this stage, community participation in testing the wallet and nodes (connection points)
under real world scenario will be initiated. This means that merchants (sellers) and
customers (buyers) will start using the system as long as the person Is willing to purchase
something.

THOR STAGE
Release candidate of the Mainnet (MEO) and Merchant Ecosystem. Sneak preview of the
finished mainnet, which everybody will be able to test out and use.

The release candidate of the Merchant Token mainnet will be at the verge of completion at
this point. While the version is functional, it will not be quite ready to be run by the public and
will undergo further tests.

A release candidate(RC), is a term that refers to developed software that has fewer identified
glitches or bugs that must be addressed before the program can be tested by a small
number of consumers.

The goal of the release candidate is to produce a final product that attracts the interest of
consumers and hopefully be used massively.

ODIN STAGE
Release of the mainnet (MEO) and Merchant Ecosystem.

The 7th stage is the final stage of the Merchant token development process.

It will end up with the release of the mainnet (MEO) and Merchant Ecosystem. These
complex final products at this point will have been rigorously tested and able to function
flawlessly. It’s also important to know that the product will continue to be updated as users
give feedback for better improvements.