Hosted compiler October updates

Last Friday the v4.0.0 final of the Sophia compiler was released by @hanssv.chain , and since today both the cli and the http interfaces for the compiler are available to use.

As it was mentioned in previous post this release is an important milestone in the development of the aeternity blockchain since it introduces the support for the new VM, codename FATE (for more details about fate refer to the specifications here and the talk from @Happi here)

And it is now the time to announce what is the plan regarding the hosted compilers as it was done in July.

Currently the default hosted compiler ( is the v3.2.0 that it is the latest one compatible with pre-Lima protocol, while the v4.0.0 is available at the

The above setup is going to change on the Mainnet HF day (30/10) where the default compiler will be set to version v4.0.0.

Starting from the 16/10, when the Lima HF is schedule for Testnet, you will have to switch to the latest compiler (see above) for your contracts deploys and calls to work.

On the same date all the rcX versions will be removed from the hosted compiler.

In terms of the SDKs, they do already support the new compiler version:

  • Js v5.x
  • Py v5.x
  • Go v6.x

but they use by default the FATE backend, that means that any new contract that you will deploy after the HF will be using FATE (it’s a good thing!).

What does it means practically?

Scenario A

You have a contract deployed before Lima HF

Option 1 (best)
Rebuild and re-deploy the contract using FATE, it is going to be also cheaper on the long run.

Option 2
When updating to the Lima-capable SDKs, add the backend="aevm" to the compiler client (TODO: details soon)

Scenario B

After Lima HF you want to deploy a contract X that depends on contract Y that is either pre-Lima (default AEVM) or compiled using the AEVM backend.

Since cross-vm type calls (FATE to AEVM and vice versa, they need to have the same ABI) are not possible you have to make sure to keep using the same VM type (same ABI) used by contract Y, that is AEVM in this case: again in this case you will have to make sure to provide the option backend="aevm" to the compiler.


brief update, all the rcX compilers have unpublished from the hosted compiler

For the Scenario A. What will happen to already existing data if we rebuild our contract using FATE? Will we need perform any additional procedures in order to have everything stay as is? Also what your plans about the support of AEVM backend? Will it be deprecated someday?

These are very important questions. For the first part, if you deploy a new contract with FATE you will be having a new contract instance, with a new address and a new state, afaik there is no way to “upgrade” an existing contract maintaining the state.

As far as the AEVM support in the future, there are no official plans that I know of regarding deprecation or how such deprecation could look like; I believe that it will be always possible to call contracts running on the AEVM, but it is just my speculation.

1 Like

Currently I 100% agree to that answer. There is no particular reason why the AEVM should be shut off. Still it’s recommended to go with FATE as this will be constantly maintained and upgraded in the future.