EOSCommunity.org Forums

The 3 aspects of the Greymass Roadmap

Greymass since its creation in 2018 has always had an underlying goal for the project we have chosen take on: to help connect the average user to the blockchain and applications using it.

To do this we set out to work on general technologies that are critical to the end user experience regardless of which application they’re using or which EOSIO-based blockchain it uses. This involved a multi year deep dive into these 3 topics:

  1. How a user can securely perform actions using the blockchain.
  2. How applications can request specific actions of their users.
  3. How users and applications can access the blockchain.

If you were to look back at all of our efforts since the genesis of the first EOSIO blockchain, each would fit into one of the above.

Up until this point, I don’t think we have ever explicitly stated these goals (except maybe in interviews or various chats). So in an effort to really drive home what Greymass is about, what we’re doing, and how we’re still striving to achieve these goals, we will now be maintaining 3 individual roadmaps and how we’re working ultimately towards adoption.

Greymass - Roadmaps

The 3 topics and our roadmaps are as follows…

1. How a user can securely perform actions using the blockchain.

It all started with a product that users can use. Originally called eos-voter, and launched at the time the EOS mainnet launched, this effort has now evolved into Anchor Wallet for Desktop and Mobile.

The living roadmap for Anchor exists here:

2. How applications can request specific actions of their users.

Then came a protocol and tooling allowing wallets and applications to talk to one another. A protocol that was flexible enough for any device the user might own, and any technique the developer may use to build their applications with.

Two protocols emerged, the ESR (EOSIO Signing Request) as an open standard and the Anchor Link protocol to further enhance the user experience.

The living roadmap for this tool chain exists here:

3. How users and applications can access the blockchain.

Finally comes the platform that allows the users and applications both equal access to read and write data to the blokchain. We have invested effort into many aspects of this suite of tools, touching on resource management (Fuel), history (Light History + Custom History Solution), and many other smaller initiatives.

The living roadmap for both our open source API initiatives and our public API hosting exists here:

Continuing beyond 2020

Greymass plans to continue focusing on these 3 areas of EOSIO for the foreseeable future. With as much progress as we’ve made so far, there is still an incredibly long way to go before we feel the complete EOSIO experience is ready for mainstream adoption. Things like key management, account creation, and network resources all still need to be presented to users in a more simple way.

Our team will continue to provide visibility into these efforts through these new roadmaps, blog posts, and other social channels for those who are interested in keeping up on our progress.


Hi Aaron,

Great work on Anchor Wallet and excited to see where it’s going.

Probably an idea that wouldn’t work on practice, but what do you think about including a default safe/basic mode for Anchor wallet, specifically designed to protect new users to the space, or those who want to remove accidentally signing high-risk transactions in daily use. For instance, removing the ability to sign Active/Owner key changes, and perhaps whitelisting genuine sites/smart contracts for reputable exchanges and blacklisting others. Experienced users could toggle the switch to al”Advanced” and sign whatever they like, but with warnings on high-risk actions.

Perhaps these features have been implemented already in ways I am not aware of, but just some thoughts.

1 Like

Thanks! We’re excited with where it’s heading too.

We do actually have this baked into our signing requests right now, at least on desktop. If you attempt to perform an updateauth or linkauth transaction, it’s going to popup and tell you it’s a dangerous transaction and that you’ll have to go into the settings to enable/allow actions like this.

This is something we’ve talked about for a while now, but just haven’t had the capacity to deal with. Having some sort of smart contract registry where information about contracts can be well defined and vouched for would make being able to trust requests all that much easier. Hopefully in the future we’ll find the time to work on those ideas, but would welcome anyone else to tackle the problem in the mean time.

1 Like