Anchor Transactions: The Word Names Three Different Operations, and Only One of Them Puts Anything Readable On This Chain

Three things are called anchoring

They are not variants of one operation. They differ in what is stored, on which chain, and in what anybody can later check.

one: an identity operation, which writes the record itself into this chain's state two: a compute anchor, which writes a hash and a count and nothing else three: a write on another chain, which does not touch this one at all

One: the identity operations put the content on the chain

Creating an identifier, updating it, recovering it, issuing a credential and revoking one are transaction types with their own handlers, and what they store is the document or the record, not a digest of it.

That is why you can resolve an identifier and get a whole document back, rather than a hash you would then have to match against something you were separately given.

Two: the compute anchor stores a commitment

A compute anchor carries two values: a thirty-two-byte root, and a count of how many receipts it covers.

The checks it makes are real and worth naming exactly. The sender must be authorised by governance. The count must not be zero. And the root must never have been anchored before, which is enforced against a second index keyed by the root itself, so a repeat submission cannot overwrite an earlier record.

Storage is append-only under a monotonic sequence number, with the counter bumped in the same step, so records accumulate rather than replace each other.

And what it does not do is the part that matters

The chain never sees the receipts. It sees the root.

The count is the sender's word. It is checked against zero and against nothing else. There is no way for the chain to know whether a root summarises four receipts or four hundred, because it has none of them.

So the honest description of what an anchor proves is narrow and precise: this value was submitted by an authorised sender at this time, and had never been submitted before. It proves nothing about what the value summarises.

A commitment is not a proof of the thing committed to. It becomes one only when whoever holds the underlying data publishes it, and nothing here obliges them to.

And none of it is readable from outside

The served interface declares twenty methods and not one of them concerns anchors.

CONTROL: that list is the interface itself rather than a guess at a name, so this is an absence in the contract rather than a failed lookup.

So an anchor is a record you cannot fetch, which puts it alongside the certificate and the state proof.

Three: the third one is on a different chain

A separate surface of ours writes its records to a public Ethereum test network, which is identified by its own chain number and is not this chain.

Calling both operations "anchoring" is the single most confusing thing in our own vocabulary, because a reader who comes to this explorer looking for one of those records will not find it, and the reason is that it was never here.

CORRECTION, 2026-08-02: we counted the wrong thing, and the real number is four times larger

This section originally reported sixty-five consecutive heights, forty-three of them not resolving, and five transactions. That measurement iterated the wrong index.

Block height on this chain is not one-per-block. Three chained blocks share a single height value, verified by their distinct hashes forming a parent chain, so the height numbers that "did not resolve" were never blocks at all: they are values the chain does not assign.

There is a contiguous index and the interface documents it. Fetching the same window by canonical sequence instead returns sixty-six blocks, with no gaps at all, and twenty-three of them carry a transaction.

So the original five were real and correctly read, and they were one in three of a set we could not see. The conclusion this page drew from them is withdrawn: five receipts selected by an artefact of the index cannot support a statement about what succeeds on this chain, and the remaining eighteen have not been classified here.

What survives is the mechanism, not the tally. And the lesson is on the page rather than in a private note: iterating an index is not iterating the thing the index names, which is the same mistake as reading a counter and calling it a rate.

What those five failures said, precisely, with the caveat above

Three of the failed transfers came from accounts at their first transaction with a zero balance, which could not cover the fee, so they were rejected without paying anything.

The fourth came from an established account far along in its transaction history. It paid the fee and failed anyway, because it could cover the fee and not the amount.

So a failed transaction is free only when you could not have paid in the first place. Once you can, failure costs the same as success, and that distinction is invisible until you read a receipt.

And the one that worked was free

The credential issuance paid a fee of zero and emitted one event.

That is the fee exemption working exactly as the code describes it: identity operations are exempt because an anchor of this kind is value-free by construction.

Read the window plainly: in this sample, the only thing that succeeded on this chain was an identity write, and it was the only thing that cost nothing.

What you can check yourself

solidus_canonHead, then solidus_getBlockBySeq down from that sequence, then solidus_getTransaction and solidus_getReceipt for each hash

Use the sequence, not the height. The interface's own documentation says to prefer it when you need to iterate every block, and this page had to be corrected for not doing so.

Read the receipts, not the block. A block tells you a transaction was included. Only the receipt tells you whether it did anything.