Anyblock Analytics and Blockdaemon Merger: short term and long-term actions

Node Operators
1

As some of you may be aware, Anyblock Analytics and Blockdaemon, both of whom are Lido Node Operators, recently announced that Anyblock Analytics has been acquired by Blockdaemon. First of all, we would like to congratulate both Anyblock Analytics and Blockdaemon on this partnership and new venture!

Secondly, from a Node Operator management perspective, this creates certain complications, especially since due to the freshness of the developments the roadmap for the merger and its effects on the operations of the two Operators are to be determined. To that end, today I suggested that an in-progress omnibus vote (vote #101), which included a key limit increase for Anlyblock Analytics, intentionally not pass so that we could separate this non-standard event from the other omnibus items and discuss and vote on the key limit increase separately. This suggestion was posted to the Lido discord and relevant Lido telegram channels. As of 30 minutes ago, Vote #101 lapsed without passing, and we will be proceeding with a new omnibus vote sans the limit increase for Anyblock Analytics.

The purpose of this topic is to discuss two things:

  1. Anyblock Analytics has recently submitted new keys and is requesting approval for a limit to increase their key limit from 1800 to 2300
  2. How Lido should deal with cases where multiple Node Operators within the Lido set merge, and more generally formalize expectations & requirements around operator participation and operations within the Lido Node Operator set, as other events that raise similar questions and challenges are likely to come up in the future

For Issue #1:
Contextual information:
Blockdaemon currently has a key limit of 2050
Anyblock Analytics currently has a key limit of 1800 (desired key limit of 2300)
In the event that Anyblock Analytic’s request to raise their limit to 2300 were approved, together with Blockdaemon they would have a combined key limit of 4,350, which would place them 9th in the list of operators by key limit (descending).

Additionally, I have asked that representatives from Anyblock Analytics provide additional info.

For issue #2:
Specifically regarding the merger, from a longer-term view, I think the possible outcomes of any such merger/acquisition are the following (please feel free to propose any additional scenarios). On the more general topic, I would like to leave this for a more open discussion.
a) Treat operators as separate operational entities (but we would need quite strong assurances here re: legal and operational independence). This is quite difficult to do given the decentralized nature of Lido (mostly the verification of these assurances).
b) Treat operators as one entity where basically total keys are shared, and key limit management will need to be a little higher touch as we make sure that in aggregate everything is OK. I think this is a practical solution for the medium term until withdrawals are possible, or a more robust solution like (c) is technically doable.
c) Sunset one operator and “merge” keys with the other (we would need to check what exactly the technical/operational mechanism for doing this would be).

5 Likes
2

NB: option b) means that combined Anyblocks and Blockdaemon’s keys will be filled up before a single operator of 2x keys capacity bc key filling algorithm considers them independent and favors operators with lower amount of deposited validators.

I think that first we need to get some clarity on the post-acquisition strategy of Anyblocks and Blockdaemon. E.g., on the surface, it makes a lot of sense business-wise to move all node operation to BD and focus Anyblocks team on analytics - if that’s the direction they’re going, they should be treated as a single operator.

4 Likes
3

I absolutely agree with @vsh here. I think we should first get some clarity on the post-acquisition strategy and get some input from them on what they would see as a good solution. Also a good point about b) that this would give them an advantage over other operators since the algorithm tries to distribute keys evenly.

I guess we should also consider that the total keys of BD and AA are still pretty low compared to other operators. For the future we should maybe also consider what happens if two larger Lido Operators would merge and considerably larger than all other individual operators.

3 Likes
4

I’m trying to think about the implications of mergers to Lido itself:

  1. Diversification and security of users’ assets
  2. Implications on systematic risks in case of slash on large operators (referring to Offline & Slashing Risks: Are Self-Cover Options Enough?)
  3. Legal and operational implications
  4. Fairness to other operators

In my opinion the merged parties shall be treated as one since they will be legally and operationally related. And this is also more fair to all other operators, especially considering more operators will be onboarded and mergers may happen more often in the future.

2 Likes
5

Hey all!

On the Anyblock side things are still in flux while we’re joining forces with the BlockDaemon team. Currently it takes more time to communicate with our new colleagues, so it might take a couple more days for us to have a common message to the Lido community.

But we’re generally agree with Izzy’s post and would probably go for a key merge approach if technically possible.

Until we have clarity on these things we would like to still to get our key cap raised to 2300 keys to make use of the keys already committed to the registry. This is a 500 key increase from our current cap and would bring Anyblock/Blockdeamon combined to 4350.
That cap raise would be the last one until we have sorted out the merger discussion with the Lido community.

Markus

6 Likes
6

Are there any objections to the 500 key limit increase for Anyblock and then halting raises until we have further clarity on the merger discussion?

EDIT:
We could do this in a manner to ensure that we don’t provide Anyblock+BD with an unfair benefit, e.g. raise limits a bit more slowly (like 100 at a time, until we reach the 500 keys that were submitted) to ensure that the other participants in the cohort are at the same key totals as Anyblock+BD.

1 Like