SSV graffiti support about ssv-spec HOT 7 CLOSED

@lior-blox are you supporting this in V3?

from ssv-spec.

@alonmuroch we want to allow the validator owner to decide on graffiti?
currently, it's out of the scope of v3, but we can consider to include it

from ssv-spec.

@lior-blox If not them then who?

from ssv-spec.

basically we need to decide from the following
a. Validator owner
b. Operator owner (through contract or Ssv node configured )
c. Default ssv

from ssv-spec.

I'd say option a.
We can simply have a "per account" graffiti not per validator.

from ssv-spec.

Beaconcha took off the graffiti value from most of their interface (you can only see it inside a block page) so the use around graffiti for the end user is almost gone.

Most of the graffiti today is bigger operations trying to push the brand forward or pass some info there (rocketpool and Lido use it for node versions and clients)

The use cases for graffiti are pretty thin(and dwindling) IMO and if it involves complex mechanisms it's not really worth any work on it.

I would say put in something default that pushes ssv forward and consider letting the account owner control it, but that would mean more complexity and a need for TXN to change it, making it costly for the owner.

In any case, the operator would never be relevant since ( is m guessing) the actual graffiti would be the leaders and then would not actually give any insight to the whole cluster

adding some examples of the leading types of graffiti

from ssv-spec.

@yoanatanblox @lior-blox @arielblox I'm closing this as we decided to put a default value and potentially let the operator override via a flag, either way no need to change spec

from ssv-spec.