HIPS Merchant Protocol (HMP), the Hips Merchant Protocol Gateway (HMP- gateway) and
the governing Merchant Token (MTO) together, is a solution that aims to introduce consumer protection concepts from the traditional card payment industry onto any blockchain that has support for smart contracts like Ethereum, Cardano (ADA) or Solana.
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.
These are a set of rules that determine how different components interact in a system.
A node that converts information or data from one protocol to another.
A blockchain protocol or network that is not yet operating at full capacity. It is used by developers to test and troubleshoot its features before it can be deployed.
A blockchain protocol that is fully developed and deployed.
The point where people can interact with a computer system or an application. It consists of a series of visual elements contained in a system that enables a person to interact with it.
The Merchant Token ecosystem
The entire range of Merchant token products currently being developed.
The first phase of software testing. This is a pre-released version that goes through a dedicated testing process, with the overall aim of developing efficient, accurate and bug-free software.
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
made. This is where the project is modelled and turned into a product. The end product of this stage is called the Minimum Viable Product(MVP). This was concluded and the MVP was
HEIMDALL STAGE - LIVE NOW
The (MPGW) MVP Release with minimum functionality for both product purchases from a
merchant and consumer protection. Also has support for both Automatic Dispute Management (ADM) and Community Dispute Management (CDM).
At this stage, the functionalities and backend 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 has been completed). This stage will involve the creation of the dispute Managements system which will consist of the Automatic dispute Management (ADM) and Community Dispute Management (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 each case to resolve that particular dispute.
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 allow for the use of personal wallets when paying for goods and services. When someone clicks on buy, a pop-up from the personal wallet will appear to confirm the authorization and payment for the product or service.
The MTO native wallet will be created and tested in this stage, and will be designed to work with the MTO system. The alpha version of this wallet will be released during this stage.
Early Alpha with extended functionality in Merchant Protocol, Gateway and Merchant Wallet. Functionality to auto-swap MTO for consumer protection as well as disputes built-in to the Merchant Wallet.
This stage is similar to stage 3, but with extended functionalities (improvements) to the
merchant protocol, gateway and 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. A pop-up will ask the question “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 to. The
purchasing of a token from another token is what is called auto-swap, and will use latest up-to-date prices of tokens or coins. The auto-swap functionality simplifies the process and transaction time, as the other alternative would be having the customer to have to login to another exchange, purchase MTO, then pay withdrawal fees to transfer it to their wallet.
FRIGG STAGE (Beta net)
A temporary test network (MEO) which will support an intense period of public testing ahead
of the launch of the first version of the Merchant main-net. This stage will allow for community participation in the testing of wallets and nodes under real-world conditions.
A temporary test network with MEO as a native coin will be initiated. The network will be rigorously tested during an intense period of public testing ahead of the launch of the first version of the Merchant main-net.
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.
The 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 any MTO’s 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 when a customer wants to buy something.
Release candidate of the Main-net (MEO) and Merchant Ecosystem. This will involve a sneak preview of the finished main-net, which be available for everyone to test out and use.
The release candidate of the Merchant Token main-net will be at the verge of completion by this point. While the version will be functional, it will not be quite ready to be run by the public as it will still need to undergo further tests.
A release candidate (RC) is a term that refers to a developed software that has only a very few identified glitches or bugs that need to 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 will attract the interest of
consumers and hopefully have a massive uptake.
Release of the main-net (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 main-net (MEO) and Merchant Ecosystem. At this point, these complex final products 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 continue to give feedback for better improvements.
Updated 4 months ago