Jim McDonald

We have lots of endpoints that aren't required for validating, they sit in the "validator required" group. But we don't define their path based on that criterion. I'm pretty sure...

So for validator state we can define as follows: | Value | State | | ----- | ----- | | 0x00 | Unknown | | 0x01 | Pending initialized |...

Yes, I did consider this and it does have some advantages but I ended up discarding it. One possibility: | Bit | Meaning | | ----- | ----- | |...

> Ok fair, and we don't want gaps for unthought of statuses? I think we can just add to the list if required, they aren't in strict timeline order anyway...

Well the JSON is not a spec object, but still a well-defined output (as are various other entities within the API). I don't think that we're doing anything structurally different...

Yeah it's the additional items on top (index/balance/state) that make it a custom object. This was somewhat contentious at the time, as it was the only output in the first...

> avoiding JSON:isms that are hard to represent in SSZ. We already have one of those here, in the form of the validator status. It isn't hard to represent _per...

Are there any objections to me creating a PR based on the information in this issue?

The original beacon API was designed to provide an interface to the data structures in the spec, along with some minor additions where they were required to avoid a lot...

Vouch uses a submitter strategy to know where to send data. If this is configured by the user to send to all nodes (the `multinode` strategy) then all beacon nodes...