Date & Time

13 September 2023 / 09:00-11:00AM (UTC-5)


  1. ELK Proposal review – Elk team 
  2. DID chain with APoW consensus – Sash
  3. Allocate some CR assets for BPoS staking in case of not enough BPoS nodes – Hwedini


1) ELK Proposal review – Elk team


None = keep ELK proposal running, next audit in March of 2023. 

2) DID chain with APoW consensus – Sash

  • Why did we close this?
  • Should we reopen this for the security benefits from PoW through the mainchain?
  • Elastos sponsoring the Bitcoin Layer 2 conference at Token 2049
    • BTC is waking up to the opportunities for Layer 2 and DeFi
  • Can we hear the Council’s thoughts on re-activating a situation where we can use the strengths of Elastos (merge-mined with Bitcoin) to push the narrative of security for our offering of DIDs?


Greg – The decision to stop the previous DID chain was for cost reasons. Coupled with the EID being faster it was decided that running both was an unnecessary expense and complication.

Zehua – The old DID with PoW consensus has already been closed. The data has been moved to the new chain. Old data still exists on the old chain.

If we restart the old chain then the user would have to choose which chain to use for their DID. The sidechains can’t communicate with each other.

If we want to design something to pursue the BTC L2 narrative it might be better to create a new chain rather than restart the old one.

Sash – The parallel complexities do make this tricky.

Question for Gelaxy – What were the problems that made this decision take place?

If the council were to choose which DID they’d prefer, which would it be?

  1. PoW/Mainchain-secured or
  2. Sidechain-secured?

Gelaxy – Bad UX using the PoW chain because the block times are so much longer. 2 – 10 mins for creating an identifier on the PoW DID chain is much slower than the EID chain now.

MButcho – There can be three layers perhaps? One for holding and one for editing data. All underneath the Mainchain.

Sash – As a log-in for dApps it would be a powerful narrative for our DIDs. We do have a credible architecture but this can evolve over time. Perhaps it’s best to leave it as it is for now.

3) Allocate some CR assets for BPoS staking in case of not enough BPoS nodes – Hwedini

  • Perhaps we need a back-up system for when BPoS doesn’t have enough nodes online?
  • How much ELA would be needed?
  • Is there enough CRC-available ELA to do this?


Fakhul – Maybe the Council wallet can be used to step in and help in emergencies?

MButcho – Can the minimum 80k voting rights be adjusted in such times? Why is it so high anyway?

Gelaxy – The 80k voting rights threshold was designed by Su Yipeng and based on statistics from the voting system. And also to encourage more ELA staking for ELA. Originally it was actually 160k for voting rights.

We can look at how this threshold is handled. In the same way as we are moving to use CR proposals that can change ESC gas fees by voting automatically, the BPoS voting rights can go through a separate category for such things.

Hwedini – Can we also have a category for fast track proposals in emergencies? Under 7 days for example.

MButcho – This was proposed before. But the risk is that it can become too complicated. But we can’t run the risk of chains stopping. A dynamic vote threshold might be worth exploring – increasing voting rights when over X nodes exists, and decreasing when under Y exist.

Greg – If there aren’t enough BPoS nodes then we revert to PoW, yes? At that point does everything still work, but on PoW mining? 

MButcho – If under 24 nodes are running then the mainchain will keep working on PoW. If the mainchain reverts to PoW then no, the sidechains shut down. Full BPoS is needed for sidechains. You can only send and receive ELA when on PoW.

Gelaxy – Yes, that’s right – BPoS is needed for the whole system to work, including sidechains.

MButcho – The flexible/dynamic solution for nodes’ voting rights requirements might be the best solution. Halve the voting rights daily until it’s back online. This means little budget would be needed. We can’t risk the chain shutting down and relying on community voting in times like we’re discussing. It should be self-correcting and automatically managed.

Hwedini – The adjustment being automatic is a good idea.

MButcho – We can find a range, maybe from 10k. There is the voting rights curve in place already, so we will have to find an algorithm to suit this purpose. And it can work both ways – the voting rights could also be increased on an average voting rights basis. Maybe not as high as 160k, but more than 80k.

Tyro – Concerned that with the ELA price being so low it would make it easier for Elastos to be attacked if the node requirements are reduced.

MButcho – It doesn’t have to go so low. Previously there was no fear of this. It was just 5000 for the node and votes for each node could be just 1 ELA for them to be part of the validator set. It’s a bigger problem if the chain shuts down. Having to rely on community voting for resolution isn’t sensible and it should be automated.

We don’t have to solve this now, but should consider it internally.

Gelaxy – We will consult with Su Yipeng and provide an update at the next Council meeting.




  • Gelaxy – Explore further the feasibility of reinstating the APoW-DID Chain and having it running side by side with EID, and revert to the Council in the next meeting
  • Gelaxy – Ask Su Ypieng to revisit the node activation voting rights requirements and confer with the Council next time about topic “3” discussed today.