All posts by Dexaran

Ethereum Commonwealth development update (11 Jan, 2018)

1. Callisto network project.


  • The main goal of Callisto network is to research and provide a reference implementation of an experimental protocol changes that aim to establish a smart-contract based on-chain governance system, completely financially transparent built-in development funding mechanism and balance the interest in the network between the miners and coin holders (ordinary network users).
  • It is possible to improve the scalability of both ETC and Callisto networks by using one as a sidechain.
  • Create a field for crosschain services improvements. It is also possible to establish a core of any crosschain service at the Callisto network and use Callisto smart-contracts state on ETC chain and visa versa which allows to facilitate the bandwidth of ETC chain. (Currently, DexNS, Address-To-Address message system, Token swap channels and ECNS are crosschain services that are deployed on ETC chain simultaneously)

Here you can track the progress:


Callisto is a separate blockchain that is based on Ethereum protocol with its own cryptocurrency (CLO). Callisto has a fixed cap monetary policy similar to ETC. Unlike ETH, ETC is posing itself as a value storage. It should be noted that the ETC does not have any incentives for coin holders. The whole emission is completely controlled by miners and their influence grows with the growth of the network. Callisto introduces a Cold staking protocol that rewards coin holders for being a network participants.

Cold staking is a smart-contract based process that allows CLO holders to earn interest in a total CLO emission when they hold CLO coins at their balances for long enough preiod of staking time (1 month by default).

Cold stakers are not required to run a node to participate in cold staking process. Cold stakers are not validating transactions and the whole system can remain fully POW which is important since ETC adheres to POW consensys. It is only necessary to call the “Staking contract” to become a cold staker.

Cold staking is a step towards the goal of turning the desired cryptocurrency into a value storage currency because this significantly increases a total demand to hold for stake holders. Further protocol improvements would be described at this open document. It may take years to propose any changes to ETC protocol and achieve a consensys on whether we need to implement it or not. As the result it was decided to launch a separate network to implement the protocol. If the reference implementation will succeed then we can implement the protocol changes on ETC as well.

Cold staking protocol could be an intermediate step of automated on-chain governance system implementation.

Callisto whitepaper will be released soon.

Callisto initial distribution

It was decided to distribute the initial stake of CLO between current ETC holders. We will make a snapshot of ETC blockchain at block 5500000 (approximately 5 March, 2018. This depends on ETC block time and ETC hashrate changes). Then we implement the initial balance of each ETC holder in the Callisto network genesis block, so each ETC owner will receive CLO coins automatically in a 1:1 ratio to the amount of ETC that he had at block 5500000.

2. Cold staking protocol.

Problem that is solved by this project:

  • There is no incentive for coin holders to continue to own coins which is important for “store of value” currencies.
  • Interest and influence in the network are not balanced. The balance is strongly biased towards the miners.
  • Lack of governance system. Cold staking protocol could serve as an intermediate step for governance system implementation.

Here you can track the progress:

Update summary:

Reference implementation of the cold staking protocol is developed and tested. The 1.0 version of the protocol has some issues that can hurt the network bandwidth in some circumstances. The 2.0 version of the protocol is intended to resolve bandwidth issues but it is still in development.

3. Callisto testnet.

Problem that is solved by this project:

  • Lack of a specialized testnet for Callisto and ETC chains. If Ethereum will introduce any breaking changes then there will be no viable testnet for ETC chain. Morden testnet is very old and require syncing and mining a test block to start testing contracts on it which is not suitable in most cases.

Here you can track the progress:

Update summary:

Callisto-TEST is ETC-compatible implementation of Callisto protocol that allows to run smart-contracts with the same version of EVM that ETC is currently relying on. Unfortunately, there is no blockchain explorers that support Callisto-TEST now. We are working on our own blockchain explorer that will support multiple networks but it is still in development.

Callisto-TEST is now supported at ClassicEtherWallet.This means that any developer can successfully deploy, run, test and debug contracts on Callisto-TEST network.

We have a manual faucet for Callisto at the moment. You should join the ETC discord and type your address at the special #callisto-faucet channel in tech topic. We will distribute test-CLO manually (analogue to how Ropsten testnet works).

Advantages of Callisto-TEST network:

  • Proof of Authority consensys. High DDOS resistance.
  • Zero install requirements to test your contracts at this testnet.
  • No need to sync your node to test contracts at this testnet.
  • Reduced block time for testing reasons which allows to execute contract calls and normal transactions faster.

4. DexNS revenue.

Here you can track the progress:

Update summary:

A final version of DexNS is launched. 56 names are currently registered at DexNS which brings 5,6 ETC to the revenue distribution address. The amount is too small to launch a distribution between DEX token holders now.

The amount of revenue that is generated by DexNS will be distributed between DEX token holders according to announcement#24: revenue distribution process of Ethereum Commonwealth as soon as the amount of revenue will be sufficient to cover gas fees for transfers to the smallest DEX holders.

5. Address to Address message system.

Problem that is solved by this project:

  • This contract solves the problem of impossibility to contact the address owner without knowing anything other than his address.
  • Ethereum lacks a central messaging system that will allow to contact an address owner directly. As the result there is no viable way to deliver a message to address owner without knowing his real identity.

Here you can track the progress:

Update summary:

A2A Message smart-contract is successfully deployed. The next step is UI implementation and integration with ClassicEtherWallet.

For more information read this:

6. ClassicEtherWallet maintenance.


  • Maintain and improve the efficiency of the main web-wallet of Ethereum CLassic.

Here you can track the progress:

Update summary:

  • Callisto-TEST network integration.
  • Specialized GAS options for Callisto-TEST network.
  • Minor UI fixes and upgrades.
  • UBQ RPC endpoint fix.

Ethereum Commonwealth

Ethereum Commonwealth is a completely financially transparent development team that aims to solve a number of Ethereum Classic infrastructure problems and improve the whole Ethereum Classic ecosystem.

You can find a complete Ethereum Commonwealth roadmap here.

Ethereum Commonwealth official address: 0x52823e725a34d42e14a1b66fb67299c30c4d8edf

If you have something to say, feel free to reply to this post or contact via e-mail:

Response to Vitaliks’ speech about ERC 23

You can watch original Blockchain Developers Meetup here:

Vitaliks’ original speech about ERC23 in Russian:

Я сейчас на самом деле ещё не посмотрел. Я могу сейчас очень быстро посмотреть.

Вот он ERC23. Давай-ка посмотрим. Конечно больше сложности. Это то что `transferToContract` и `transferToAddress`. А понятно, то есть это внутренняя функция. Вот это я думаю не очень умная мысль, потому что наш долгосрочный план через EIP86 мы хотим что бы каждый аккаунт стал контрактом, то есть мы хотим, чтобы концепция неконтрактового аккаунта не существовала и мы любим такую идеологию Эфириума: если есть чистая общая система, то лучше если все описано через код, то лучше пусть всё и будет описано через код. [Я понимаю это так: “Если есть вещи, работа которых одинакова с идеологической точки зрения, то и коды, описывающие их работу, должны иметь одинаковую логику.”] Это конечно не очень будет хорошо работать в долгосрочной перспективе, но сейчас может иметь преимущество.

Какие у них тут, посмотрим, аргументы. `transferToAddress`, но ещё есть `data` field, а понятно, то есть они хотят чтобы можно было передать токены контракту и одновременно передать какие-то данные, потом контракт, который работает с токенами… Сделать так что бы транзакции токенами работали так же как и транзакции эфира. Я понимаю, что они пробуют делать. Я думаю, проблема такая: если сейчас в иных случаях нужно сделать функцию, которая принимает эфир, то есть ты, например, хочешь купить какие-то токены, REP к примеру, децентрализованная биржа в общем, в ней есть функция, в которую нужно как часть функции подать эфир. Сейчас если подать эфир, то можно вызвать функцию одним call’ом, но если ты хочешь платить за что-либо через ERC20 токен, то нужно сначала сделать одну функцию с `approve`, потом ещё одну функцию `transferFrom`, которая возьмёт токен, а потом уже внутри контракта будет ещё третий вызов функции. То есть проблема такого механизма в том, что он тратит много газа, он не совсем удобный.

Они хотят сделать это аналогично с эфиром — транзакция токена передаёт данные, которыми закодирован вызов контракта, как `data` транзакции эфира.
Потом он пробует вызвать `tokenFallback`. Проблема такого подхода в том что он не очень хорошо подходит с существующим ABI.
Получается они пробуют сделать свой ABI, в котором есть функция `tokenFallback`, один из аргументов `tokenFallback` будет msg.sender, и получается что чтобы найти кто sender нужно не использовать опкод `sender`, а взять этот вот кусок памяти. Внутри `tokenFallback` будет ещё `data` и это будет ещё одна внутренняя функция.
Я понимаю как они хотят понизить сложность, но я боюсь что такой подход наоборот ещё больше увеличит сложность.
Инстинктивно мне пока всё равно ERC20 больше нравится, но я понимаю почему людям ERC23 тоже нравится.

Преимущество в том что если есть один токен ERC20, есть ещё один токен ERC23, который можно обменивать через контракт в токен ERC20, получается такой ERC23 токен, подкреплённый токеном ERC20, то люди могут использовать оба стандарта параллельно, кому нравится — те пользуются ERC20, кому ERC23 — те пользуются ERC23 и в любой момент эти токены можно перевести из одного стандарта в другой.
Не важно какой формат человек выберет — всегда будет выбор стандартов. То есть это хорошо.

Это всё что я пока хочу сказать об этом.

English variant:

I have not yet watched. I can watch now.

It’s more complicated that there are `transferToContract` and `transferToAddress`. It’s internal functions. This is not a very clever idea, i think because of we are planning to make each account a contract (in EIP86). We don’t want no-contract account conception to exist. We like the following ideology in Ethereum: “If there is a total system, then let it be written in the code”. [I think it means: “If there are ideologically similar things then their code should have similar logic of work.”]
This [ERC23] will not work very well in long term but now it can have advantages.

Let’s look through their arguments. `transferToAddress` and `data` field means they want to attach data to token transactions. Let token transactions work similar to Ether transactions. I understand what they are trying to do.
I think the problem is you can execute payable function and send Ether with a single call. But if you want to pay something with ERC20 token you should call `approve` first, then call a function that will call a third function `transferFrom` to take your tokens. Problems of this mechanism [ERC20 `approve`+ `transferFrom`] are it’s spending a lot of gas and it’s not convenient.

They want it to be the same to Ether transactions. Token transaction will contain `data` field. `data` is encoded call of contract like `data` in Ether transactions.
Then it’s trying to call `tokenFallback`. The problem of this method is that this is not matching current ABI.
They are trying to make their own ABI with `tokenFallback` function. One of `tokenFallback` args will be `msg.sender` so we cant use `sender` opcode to get sender. We need to access this variable in memory [`_from` arg of `tokenFallback` function]. There will be `data` inside `tokenFallback` and it will be the next function call.

I understand how they try to reduce complexity, but I’m afraid that this will increase complexity on the contrary.
I still like ERC20 more but I understand why people do like ERC23.

There is an advantage that people can use both standards. For example it is possible to create ERC23 token backed by ERC20 token and it will be possible to exchange each token to another. There will be a choice of standard you would like. It’s good.

That’s all I want to say now.

I want to provide my response to this overview.

I designed ERC23 to solve a number of problems I found important.
This problems are:

  1. Users can lose their tokens in contracts and it often happens.
  2. There is no way to handle incoming token transactions.
  3. I like Ethereums’ ideology “similar things should have similar logic of code” but ERC20 transactions are not similar to Ether transactions.
  4. approve function is potentially vulnerable in current implementation. Read more here.

Let me explain each point more detailed. I have already wrote an article about ERC20 tokens that are already lost and will never be accessible.

I think user don’t need to know about token contract inner logic to use tokens. But the existing method of depositing ERC20 tokens to contracts or transferring ERC20 tokens is too confusing for regular users.

Fallback function execution is a standard method of handling events in programming. It can be confusing for developers that there is no way to handle incoming transactions of ERC20 tokens.

Ether transactions and token transactions are similar things. They are “transactions”.

Ether transaction:

  1. Transfers value.
  2. Could be handled.
  3. Can execute functions in contract.
  4. Could be rejected if something goes wrong or executed function is not accepting payments.
  5. Can contain hex messages.
  6. There is no difference between “send transaction intor contract” and “send transaction intor wallet address” from users point of view.

I’m trying to create a token that will behave in similar way.

Let me comment some moments.

It’s more complicated

I don’t found it more complicated. But even if you found my proposal more complicated for contract developers, then I found this increase in complexity a reasonable price, which should be paid for preventing accidental loss of tokens in the entire future and making token usage less complicated for regular users.

We like the following ideology in Ethereum: “If there is a total system, then let it be written in the code”.

Exactly. It was one of my goals of developing ERC23 too. It is third point in list of problems I marked above.

This [ERC23] will not work very well in long term but now it can have advantages.

I like the idea of wallet-contracts. But even if it will be wallet-contracts will handle incoming Ether transactions. I think incoming token transactions could be handled in similar way.

From technical point of view transferToAddress can become rudimentary. transferToContract will be executed every time someone will try to send transaction to a wallet-contract that contains code. So wallets-contracts should implement ReceiverInterface to receive tokens. It may be a good idea to implement it by default like empty fallback function() payable { } that will allow to receive Ether.

At the other hand its a problem only when tokens are accidentally thrown into contract because contract can’t perform transactions if have no functions for it. Wallet-contract can still access every token inside it. Even if they were sent accidentally.

But if wallet-contract should handle incoming tokens and do something it means tokenFallback still should be executed even inside wallet-contract.

The problem of this method is that this is not matching current ABI.
They are trying to make their own ABI with `tokenFallback` function. One of `tokenFallback` args will be `msg.sender` so we cant use `sender` opcode to get sender. We need to access this variable in memory.

Yes. First of all receiver should implement ReceiverInterface to receive tokens.
While handling incoming tokens on tokenFallback(_from, _amount, _data) function we can access sender of tokens by _from variable. msg.sender will be token contract address so handler will know what tokens are sent.

If someone can find this inconvenient this extension can be implemented:

struct tkn {

address sender;

uint value;

bytes data;


function tokenFallback(_from,_amount,_data)


tkn.sender=_from; tkn.value=_amount;;


so sender of transaction will be accessible as msg.sender and variables of token transaction (token sender, tokens amount sent and data of token transaction) will be accessible as tkn.sender / tkn.value / .

I understand how they try to reduce complexity, but I’m afraid that this will increase complexity

I understand it but if we can decrease complexity of using tokens for regular users and make transactions unificated for Ether and tokens that will decrease complexity of working with tokens for third party UI developers for example, its a reasonable price that should be paid. Even if it will increase complexity of contracts a bit.