Mercury in 2018

Mercury Protocol

Published in

mercuryprotocol

7 min readJan 11, 2018

Dev Highlights from the Break

QA testing and final changes for the “status” field from Byzantium fork
Upgraded to Web3J 3.0
Implemented parameter encoding/decoding and signature decryption to verify the transaction signer’s Ethereum address in order to securely execute transactions on behalf of users on the blockchain

As we move into a new year, we took a step back to assess the state and direction of the Mercury Protocol. With a complex, multi-faceted project such as Mercury, we’ve accomplished some tasks faster than expected and encountered complications with others. As a result we’ve made some updates to our roadmap (seen below), and wanted to share the exciting amount of progress we achieved over the holiday season.

Roadmap 2018

Our roadmap for 2018 can be found here, and will be updated quarterly as we continually reassess our progress.

We are currently in phase 1, and will be providing more detailed insight into our technical solutions, product design, and business motivations as they are finalized. Please note that the timeline indicators are merely estimates, and actual completion of line items may be faster or slower depending on how quickly we can expand our team with high quality personnel.

We’re Hiring!

A key element to any project’s success is a quality team, and we’re looking to expand our Mercury family to get more brains solving complex problems, increasing project throughput, and sharing different points of view. We’re currently seeking:

We’ll be looking to fill even more positions in the coming months, so keep an eye out here for an up to date list of openings. If you don’t see your ideal job title listed but still think you have a skill set to offer the Mercury project, send us an email at info@mercuryprotocol.com.

Reputation Score

We’ve begun research and development on a Mercury reputation score, and will be sharing a post devoted to detailing it in coming weeks. At a high level, the score will be composed of two main types of metrics:

1. User Activity

User activity score will be determined by objective metrics such as account age, total number of tokens earned through incentivized action rewards, and a ratio of tokens earned to tokens spent on premium features.

These metrics will provide a measure of how active a user is on the Mercury network, how long they have been active, and how likely a user is to spend or hoard token rewards. This aspect of the score is designed to be more business facing, as these metrics are useful in calculating the value of a user to the network in terms of token flow generated. If users are more likely to perform incentivized actions and spend those tokens on premium features, they are more desirable to the app development team building out the platform and tokenized services.

2. Activity Quality

Activity Quality is a subjective measure of the caliber of a user’s participation within various application communities. It will be measured through various quantitative metrics of quality such as five star ratings, upvotes and downvotes, shares and likes, followers, etc.

Given the subjective nature of the Activity Quality score, great care will be taken to weight positive and negative feedback appropriately to prevent gaming the system. For example, five hundred down votes from the same trolling account should have proportionately less impact than ten likes from ten different non-trolling users. Machine learning solutions will be developed to protect against bots, trolls, and fake accounts.

While the reputation score metrics will be gathered from all Mercury network activity, use of User Activity, Activity Quality, and Aggregate Reputation Score will be left entirely to an app development team’s discretion. They may use one, all, or none of these scores within their respective ecosystems, but the goal is to make consistent, useful metrics available to everyone.

Partnerships and Integrations

If we are to succeed in making Mercury the de facto network for social media and communications, we must acquire massive user adoption. From a business perspective, the more integrating apps and partnerships we make, the faster the user network grows as each individual partner grows their app user base. To that end, we have already engaged a dozen or so teams in discussing the integration of Mercury on a product level.

However, as evidenced by Dust currently on Rinkeby testnet, there are several outstanding issues that need to be solved before Mercury is ready for production grade use (detailed below). Once Dust is on Mainnet and we can demonstrate the safety and scalability of our solutions for tokenized features, we will shift our partnership discussions from product level to technical implementation and help other teams build the protocol into their apps. As mentioned previously, once we and our partners are both ready to announce in unison, we will announce integrations.

If you’re curious about how Mercury can benefit your app, send us an email at integrations@mercuryprotocol.com.

Getting Dust on the Mainnet

Before we can move Dust onto the Ethereum Mainnet, there are several issues to be resolved:

1. Paying user Ethereum gas fees in ERC20 tokens (QA testing)

Compared to social media, crypto is still a small niche community. While it’s hard to tell for sure, estimates put the global number of Bitcoin owners somewhere in the tens of millions, compared to Facebook’s more than 2 billion monthly active users. As we learned with Dust, complexity is a major barrier to entry for the average person with any new product. To acquire and retain users for the GMT fueled Mercury network, the token system has to be understandable to the average person.

Currently, apps pay Ethereum transaction costs in ETH. Rather than introduce users to a second type of crypto used only when they want to spend GMT, we built a solution to let users pay their gas fees in GMT. This way, Mercury network users only have to worry about the amount of GMT they hold instead of both GMT and ETH. This solution is a major breakthrough that we’re very excited about and will be sharing more details in a technical post in coming weeks.

2. Reduce gas fees to scalable numbers for micro-transactions (research & development)

In addition to paying gas fees in GMT, it is critical to build a solution for reducing gas fees to an acceptable level for micro-transactions. Spending 5 GMT becomes significantly less useful if it costs 45 GMT to pay for the transaction.

Our team is currently experimenting with several possible solutions and we will share an update once we have one finalized.

3. Move Dust to Mainnet (in queue)

Once the above two issues are resolved and pass quality assurance testing, we will begin final preparations for moving Dust to the Mainnet. This will include logistical preparations such as ensuring users who created Mercury GMT wallets on Rinkeby receive wallet creation rewards on Mainnet, as well as traditional pre-release checklists such as user testing, security audits, stress testing, etc. Once we feel confident everything is ready, Dust will move to Mainnet and GMT will start flowing.

Unfortunately, as of now the GMT rewards given on the testnet will not transfer as credit once switched to the mainnet. The amount of GMT in rewards or needed for premium service may change but the functionality will be the same.

The Mercury Protocol GitHub Repository

As you may have noticed, there is a distinct lack of commits in the Mercury Protocol GitHub project repository. This is not because we have not been developing the protocol, but because the issues we’ve been focusing on require real-world data on elements like transaction frequency, gas fees, etc. that can only be gained by implementing them into Dust first. Once we have working solutions to issues like the ones mentioned above in “Getting Dust to Mainnet”, we will abstract them out of Dust, make them platform agnostic, and push them to the Mercury Protocol GitHub for peer review.

Broadcast

At the end of last year, we decided to take a more aggressive approach with our plans to integrate Mercury into Broadcast. Instead of simply adding GMT based features on top of an existing centralized application, we wanted to make Mercury a core part of the app. In addition to GMT premium features, the redesigned version of Broadcast will store user profiles and posts on blockchain as a production grade proof of concept for blockchain based content. We are aware of network congestion and are making it a point to develop a scalable solution that doesn’t present a risk of throttling the Ethereum network.

We currently have a working POC for blockchain stored profiles, which can be imported into any Mercury integrated app to make user onboarding even easier by recycling common data points such as username, bio, website, etc. Blockchain based posts are currently in research and development. As Broadcast v1 nears, we will share more details about the Mercury integration, standard and premium feature sets, screenshots, and more.

TL;DR:

We made incredible progress last year, and are even more excited to push blockchain technology to its limits as we build Social Networking 2.0 with the Mercury Protocol.

Connect

Slack
Telegram
Twitter
Reddit
Facebook
LinkedIn
GitHub

Learn more about the Mercury Protocol
Read the Mercury Protocol whitepaper
Follow +mercuryprotocol on Dust