[Active] AE maintenance Q2-2022

Application Status

Status: Approved on the 12.04.2022, submitted on the 01.04.2022
Last updated: Submitted on the 01.04.2022
Submited by: Fabian Krol
Team: Michal Bargowski, Craig Everett, Sean Hinde, Dimitar Ivanov, Fabian Krol, Chandru Mullaparthi, Hans Svensson, Dincho Todorov,Ulf Wiger
Approved Budget (in h): -
Used Budget (in h): -
Planned Delivery: -

Specify the funding category

Open Source Development

Application Title

Core team application April-June 2022


Aeternity core developers team.

Value Application

We are developing new features, improving the current state of the node and fixing bugs.

During the second quarter, our main task will be to continue HyperChains implementation. However, We do not expect to finish it in the scope of this application.

We will also be working on various ongoing tasks:

  • GUI launcher improvements
  • RocksDB refactoring
  • aeCanary improvements and refactoring
  • Rosetta API
  • Plugins
  • MultiSig improvements
  • Beam sync
  • Advanced State Channels
  • Garbage collection

Definition of Terms

Here is a more detailed description of the mentioned features:

  • HyperChains - a HyperChains Alpha testnet is now up and running. We have made significant progress with the support for contract-based consensus, but much work still remains. Development will progress in phases and tested heavily both in private and public testnets. It will require updating some of the tools in the ecosystem.
  • GUI launcher - a native application that compiles and runs the node. New developer features will be added depending on Craig’s availability.
  • RocksDB refactoring - we are using a RocksDB plugin but so far we’ve been limited only to using a small subset of its API. There is a huge effort from our side - we had to refactor significant portions of our code. We also fixed some C++ bugs in the plugin itself. Remaining work is mainly about refactoring the core code to take full advantage of the new possibilities. Stay tuned.
  • aeCanary - our monitoring tool needs refactoring. We’re planning to release the tainted account feature.
  • Rosetta API - ongoing work on the implementation. Delivery will depend on Chandru’s availability.
  • Plugins - as we now have support for proper plugins, a number of ideas have come up for example indexing- and utility plugins. Documentation and carefully crafted APIs are needed.
  • MultiSig - Implement and test MuSig2 for ed25519; this will produce transaction signatures indistinguishable from “normal” signatures. To test and showcase this we also need rudimentary wallet/key support which means AEX-3, AEX-10 and a couple of more things. Most of ther work is done but it needs a bit more polish and documentation.
  • Beam sync - we have started initial work on a sync option that aims to deliver a secure working new node within a few hours rather than days by first syncing keyblocks then fetching state on the fly.
  • Advanced State Channels - Develop the concept of State Channel markets and perhaps other advanced State Channels use cases. This may involve improving the client-side experience.
  • Garbage collection - Once the RocksDb refactoring is merged, chain garbage-collection can be redesigned and extended, in order to significantly reduce the on-disk footprint of garbage-collected nodes.

Status Quo

None of this is present.

Required Work

Once we have enough features implemented, we will make official releases.


We would be working full time on this, although some of the team (Hans, Dincho and Chandru, Michal, Craig) already have other commitments and would help us depending on their availability.

Known Limitations

We do not expect finishing the HyperChains.
Chandru’s availability: the Rosetta API might also not be fully implemented.
Craig’s availability: the scope of GUI launcher improvements will depend on availabilty


HyperChains have been a long-standing goal, but there is still a lot of work left.

Beam sync will significantly improve the user’s experience by delivering a secure working node within a few hours rather than days.


We publish our work in the official AE repositories.

I am not that deep into that. but I have a general question here that @hanssv.chain can probably answer. is it possible to prove to the public that the account requires a specific set of signers? I am thinking of usecases where I want to be able to show that a certain account is actually a multisig account

Yes and no. Just looking at an account A and a transaction T signed by A you can not tell that it is a multi-sig account. But - you can show that if you combine accounts X, Y and Z (in the right way according to MuSig2) you do get account A! Does that answer your question?

1 Like

yeah that’s what I mean. would be cool to have some tool to prove that to the public without revealing the private keys of course.

Haha, yes preferrably without revealing the private keys :joy:

1 Like

You’re saying that I might not develop Rosetta, right? How difficult is a technique that takes a long time or gives up?

Does the abandonment of Rosetta’s development mean giving up listing on Coinbase?

@forjuwon, we’re not abandoning Rosetta by any means.
We’re planning to deliver in Q2, but depending on Chandru’s availability(he’s not working full time for the core team), it might bleed into Q3.

The main complication with Rosetta is that it was not designed with Bitcoin-NG in mind.

But as already stated, we’re not dropping it.