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


Council: Bocheng, Elation Studios, Gelaxy, M&N, Strawberry Council, Sash, H&4, PG Bao, Rebecca, Song Sjun, Sai, Tyrolee

Secretariat: Cassie, Greg




  1. Elabox project update (Fakhul) 
  2. BPoS change to switch votes from inactive to active( MButcho, Gelaxy) 
  3. Status update for the LLC Proposal (Fakhul)
  4. General update on current active proposals (Cassie)


1) Elabox project update (Fakhul)

  • Delivery date still unknown
  • 80 Elaboxes are all they can do right now.
    • 150 boards can be handled with support from Elavation (stock remains an issue)
    • Most distributors are still out of stock
  • Further discussions are needed with the Elabox team before Elavation cn commit to anything concrete with them.


Nenchy – the comms have been awful.

Fakhul – We have already advised them about the comms status. An accurate delivery date is still not possible. And two years is too long!

We should be able to make a decision from an Elavation perspective about whether we can help Elabox out if we can get the right assurances from John.

2) BPoS change to switch votes from inactive to active (MButcho, Gelaxy)

    • Inactive nodes are not punished
    • Voters cannot switch nodes when they are inactive
    • Options
      • Un-stake
      • Change the vote
    • Preferential is to change the vote
  • 7 day inactive has been suggested by Bocheng – then voting rights can be moved to other nodes – this should be sufficient.
    • Un-staking changing the lock period doesn’t change
    • Rewards shouldn’t be lost by voters.
  • Atom – switching is permitted from inactive to active nodes
    • Even active to active is allowed, without un-staking.


Fakhul – Users should be able to re-delegate votes to any active nodes from any nodes. Minimum of 21 days perhaps (like Atom). It feels like an oversight that they can’t move.

When does slashing occur? It’s not enabled. What’s the mechanism behind this process?

Cassie – No penalties implemented. If your node tries to act nefariously there is a 200 ELA penalty. Blocked rewards are in place, not slashing.

MButcho – Should slashing be enabled? It also affects the voters.

Start with voting re-delegation. Then penalties can be added after that.

  • 3 days inactive then voters can move to another node.
  • Re-delegation for active to active can also be 3 days 

Bocheng – Users can only change votes if they are stuck in inactive validators. If the system allows switching votes then the opportunity for evil and instability is much higher.

The responsibility for voting lies wholly with the voter. 7 days might be okay for inactive nodes to swap from inactive to active.

Sai – Should we just allow the user to change their votes against any node that is currently not picked for the 36 blocks? If inactive, then obviously that node is not picked and they can change it for the next 36 blocks. For changing against an active node, we could do with the 3 day logic

MButcho – I am also thinking changing voting Active to Active on these 2 conditions:

  1. You changing from node that after you move your vote will not drop below 80k voting rights
  2. You will only be able to change to an active node with less than 80k voting rights

this feature will be to stabilize consensus basically so mostly benefits consensus

Kahuna – I personally don’t think nodes should lose any votes unless it is inactive for too long. I don’t think node owners should be punished for no reason. 

Although I do agree with #2.

MButcho – Inactive to active re-delegation will mostly benefit voters

Both 2 above are Active to Active.

Sai – On point 1, what if one of the nodes is playing bad. now this will allow them to continue right as voters won’t be able to vote them below 80k??

Nenchy – I think we should keep it as simple as possible.

Any voter should be able to change votes for any reason with a 3 day “cool down” period -.for another node…regardless if <80k or >80k accumulated votes.

MButcho – Correct, but it should not be on voters to decide if the node is playing “bad”. Consensus should manage it itself.

Fox – I would argue it should be a free market for the voter – they should be able to choose which node to vote on.

MButcho – they have a free market when they first vote.

Kahuna – It’s true and they have the choice before locking.

Fox – I understand the rationale from mbutcho as its important to have active nodes. It’s the way you perceive the locking aspect. 

My perception is I am locking my ELA into the network as a whole (not necessarily a specific validator), the lock period is purely to benefit my ELA reward amount.

Kahuna – This is why it is important to do some research on node owners before locking your ELA on that node. If your unsure voters can choose less days to lock.

Agreed, point 4 on the dev portal articulates this nicely: https://elastos.dev/learn/mainchain/bpos/#tips-for-selecting-validators

Nenchy – We need to make it as welcoming and simple as possible…lets not overdo it.

Fox – Equally though, a lot of this is true for a mature ecosystem and not necessarily the best approach when trying to bootstrap where some centralized elements may be needed for an initial period.

MButcho – I think we all agree that moving from inactive to active is a must. Let’s make it 3 days and see how consensus goes. Then we don’t have consensus active to active at all, so it needs more discussion.

Nenchy – Agree, but I think we all agree, this feature lets voters decide how to (re)distribute and it shows Elastos becoming mature without jeopardizing security and stability.

MButcho – also, users can vote for 10 days. If they could freely switch, we should not have 10 – 1k days curve.

Nenchy – Exactly. So to encourage locking ELA for more than 10 days, we should also provide “freedom” to redistribute votes…at free will of staker.

Kahuna – I would personally prefer the 7 days period over 3 days.

Nenchy – I vote for 3 days for all occasions…for node inactivity or just if a voter wants to re-delegate. For 3 days voters come in cool-down mode and start collecting voting rewards after re-delegation.

MButcho – I will then draft a suggestion following a breakout discussion in a dedicated asynchronous chat group.

3) Status update for the LLC Proposal (Fakhul) 

  • 50k was requested at the start of the year
  • 6206ELA to be returned to the CR 
  • 3589USD in the bank account
    • Preference is that this is kept for three things:
      • Tax filing 2023
      • Closing down costs
      • Any fees between now and closing
    • However, this might not be enough USD to pay further costs


Tyro – agreed.

Nenchy – agree. Keep USD in the bank and return ELA. As we go, we see if and how much is missing for finally closing down LLC.

4) General update on current active proposals (Cassie)

  • Redacted


Fakhul – Should all proposals be tracked, regardless of ELA requirements? When proposals are sponsored by the EF, they are passing governance of the running of the proposal to the CR. They are not just financially sponsoring teams to act autonomously – the CR still has the responsibility to oversee all proposals passed by the CR regardless of the funding source.



  • Further to the above, who is the Digerati team answerable to? Who tracks and monitors their performance?


Cassie – Anyone can apply to run the social channels and website.

Fakhul – Did the EF not fund Digerati for the CR to manage them, hence the proposal?

Nenchy – Regarding performance data – Are there any metrics tracked? Is there any accountability for the team’s performance? 

Cassie – Digerati is a collaborative team looking to provide all the most up to date information being available to all visitors and participants of the Elastos ecosystem.

The Digerati team, part of the Secretariat Team, is accountable to the Council and the community, including the EF who funds them. If the Digerati team fails or the Council finds a better choice, we welcome a new team to take over the Info site.

When the former Info Team left, the Secretariat Team stepped up to manage the social media channels and Info website. They had no funding or resources at that time. The current funding for Digerati comes from their own efforts. If a new team wants to take over, they need to settle their own funding. 

Regarding metrics, we see new followers every week, but Twitter followers fluctuate due to possible bot-related issues. We upgraded hosting due to increased traffic, thanks to Elavation and Digerati. More detailed data will be provided forthwith.


  1. Make a group to discuss voting redelegation rules for BPoS – MButcho
  2. Return LLC ELA to CR – Fakhul