Skip to content

Instantly share code, notes, and snippets.

@aaroncox
Created March 13, 2020 07:19
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save aaroncox/f694a270f4b94fd6b3fa43e4e4ba0f30 to your computer and use it in GitHub Desktop.
Save aaroncox/f694a270f4b94fd6b3fa43e4e4ba0f30 to your computer and use it in GitHub Desktop.

Since this is a new section, this part of the report is going to be longer than usual. If this ends up being unreadable in the form viewer, I've also created a gist with this information which can be found here:

https://gist.github.com/aaroncox/f694a270f4b94fd6b3fa43e4e4ba0f30

Below are the 3 more major projects we're actively working on in the last 2 months since we reported:


  1. EOSIO Signing Requests

We believe this is one of the most important projects we're currently working on. No signing protocol within the EOSIO ecosystem up until this point has been able to service all device and dapp configurations, with mobile development being especially tricky. The ESR protocol sets out to creates a flexible method of relaying signature requests between applications and wallets. The specification itself is completely open source and can be implemented by any EOSIO wallet provider. The protocol currently allows communication between:

  • Desktop App/Browser -> Desktop Wallet
  • Desktop App/Browser -> Mobile Wallet
  • Mobile App/Browser -> Mobile Wallet
  • NFC/QR Code -> Mobile Wallet

Additionally, the protocol can be used to serve as a login method for a variety of frontend and backend services by proving ownership of an account through signature creation. Built-in sessions within these channels can persist these logins and be used in subsequent signing requests to prompt the user through background processes.

Currently our roadmap is:

Aaron, Johan, and Daniel from our team are all involved in the development of this project.


  1. Anchor

Anchor is the rebranded and reimagined version of the eos-voter wallet we launched during the genesis of the EOS blockchain for desktop and is now coming to mobile.

We are currently shifting towards the authenticator model, where the primary purpose of the wallet itself is simply to sign transactions with whatever device you'd like. This route is very similar to the EOSIO Authenticator that Block.one released a tech demo for, but instead we utilize the ESR protocol for the communication layer.

Our goal is to create a standard experience around EOSIO blockchains with a familiar and trustworthy brand.

Currently our roadmap is:

  • Spring

    • A complete rebrand of Anchor before a final 1.0.0 release.
    • Release of Anchor Desktop 1.0.0 (RC6 available now, RC7 release soon - greymass/anchor#802)
    • Version 1 release of Anchor Mobile for iOS (currently in the hands of beta testers via TestFlight, invitations available upon request)
    • New website related to Anchor with guides/tutorials to help users understand the wallet software they are using.
  • Summer

    • Start moving most of our in-app interfaces out to web-based applications.
    • Integrate ESR session and session management interfaces into the desktop build.
    • Start work on the prototype of Anchor Mobile for Android to match the iOS experience.
    • Building of an kotlin/java library that matches out swift-eosio implementation.

Current Aaron and Daniel are building Anchor desktop, with Johan leading the iOS initiative. Daniel will begin prototyping out the Android application in the near future. Our designers Nick and Max are busy working on the rebranding effort.


  1. Custom v1 History Implementation

Since our January update we have continued to add additional components to our custom history solution. We set our sights on matching the v1 specification while focusing in on performance, scalability, and stability - all on reasonably priced servers. This new platform is built in golang and uses custom indexers to build data sets external to nodeos using BadgerDB.

Our roadmap with this history solution is:

  • Spring

    • (Complete) Move account history, key associations, and controlled account indices external to nodeos.
    • (Complete) Move trace data out of shared memory and into an external data set.
    • (Complete) Build associated API calls to access this external data.
    • (Complete) Develop an event system to deal with forking logic.
    • (In Progress) Move trace retrieval process and compilation out of nodeos.
    • (In Progress) Move all microservices into a containerized deployment and open up for testing
  • Summer

    • Release a version 1 implementation that others are able to run.
    • Start drafting a new API specification to improve on call structures, while maintaining v1 reverse compatibility.
    • Deploy the custom history solution to WAX and other EOSIO chains

Currently Scott is leading development on this new software, with Aaron helping in a minor capacity.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment