Why There Is No Light Client Yet: Nobody Could Write One From Outside, Because the Node Does Not Publish What One Consumes

The concession first

There is no light client. A search for one across the protocol, the packages and the published SDKs returns nothing at all, and this page is not going to describe a plan as though it were a component.

What a light client actually is

A full node downloads everything and checks everything. A light client downloads headers and checks proofs, so a phone or a browser can decide for itself whether something is true rather than believing whoever answered.

It needs three things, and it is worth naming them precisely, because the reason there is no light client here is which of the three are missing.

one: that a block was really agreed by the network two: that a transaction is really in that block three: that a piece of state is really under that block's state root

Number two works today, and we ran it rather than asserting it

A block publishes an ordered list of its transaction hashes and a digest over them.

We recomputed the digest from the list and it matched exactly. Block 83,721 carries one transaction; hashing that transaction's hash with the same function the protocol names reproduces the header's value character for character, computed in a clean directory with a published library rather than with our own code.

So a reader can already verify that a block's transaction list is the list its header commits to. That loop closes, with no account and no trust in us, and it is the one thing on this read surface that does.

And that field is a digest, not a tree

The value is a hash over every transaction hash joined together. There are no sibling paths in it.

So you cannot prove that one transaction is in a block without fetching every hash in that block. A tree lets you prove membership with a handful of hashes. A joined digest makes you download the lot.

Today that costs nothing, because blocks here carry zero or one transaction. It is a shape that does not become a light client later, and the word "root" invites the assumption that it already is one.

Number one is impossible from outside

Inside the node, agreement is a real object. It names the block it certifies, its round, an aggregated signature, and a bitmap of exactly which committee members signed.

None of it is published. The block a reader receives is an explicit list of ten fields, and that object is not among them.

So no outsider can check that a block was agreed rather than merely served. Five earlier pages in this estate have stopped at the same wall, and this is the page where the consequence gets a name.

And even if it were, there would be nothing to check it against

The validator listing returns an address, a stake figure, an unbonding figure, a reputation figure and a flag.

It returns no keys. The node's own validator type carries both a signing key and an aggregation key. Neither reaches the wire.

A signature you cannot check against a key is not evidence, so publishing the certificate alone would not be enough. Both halves are missing, and a reader deserves to know it is two things rather than one.

Number three is missing too, and we said so on a different page

There is no endpoint that returns a proof against a state root, which is why a resolution answer cannot be checked either.

So of the three inputs a light client consumes, one is available, one is unpublished, and one has no endpoint.

Which reframes the whole question

"We have not written a light client" makes it sound like a client is the missing work.

It is not. The read surface is. Nobody outside this team could write one today, and neither could this team without publishing the certificate, the keys and a proof endpoint first.

That is a more useful answer than a roadmap line, and it is checkable in three calls.

And it is worth less here than the word suggests

A light client is a tool for trusting fewer people.

On this network there is nobody else to trust. Four machines produce every block and one team operates all of them, so a verified signature would tell you that the operator agreed with itself.

The value arrives with an independent operator, not before. Building the client first would produce a component that proves something nobody currently doubts.

What you can check yourself

solidus_getBlock at a height with a transaction, then hash the listed transaction hashes joined together and compare with transactions_root

Then look for a certificate or a public key in either response, and notice there is none.