Anchor Transaction

Origin: composes: a general integrity-proof pattern used across timestamping systems and DID methods, not a Solidus original. Solidus status: shipped, live for credential issuance; live in code but thinly used for compute-job batches.

An anchor transaction commits a short cryptographic hash of some larger piece of off-chain data onto a blockchain, without putting the data itself on-chain. The data, a document, a batch of records, a credential, lives wherever it actually needs to live; only its fingerprint goes into the transaction. This buys two things cheaply: proof that the data existed, unmodified, at or before the moment the transaction was finalized (because the hash could only have been computed from that exact data), and a way to later verify a copy of the data hasn't been tampered with, by simply re-hashing it and checking the result matches what's on-chain. It's a much lighter-weight alternative to putting entire documents or datasets on a blockchain directly, which is usually neither necessary nor affordable.

Where it comes from

The general pattern predates and extends well beyond blockchains, OpenTimestamps and Certificate Transparency logs both anchor hashes for integrity and timestamping purposes without needing the underlying data to be public or on-chain at all. Within decentralized identity specifically, DIF's Sidetree protocol, already covered elsewhere in this Lexicon, is built entirely around this idea: it batches many DID operations into a file and anchors just that file's hash with one small transaction on an underlying chain like Bitcoin. Solidus took a different path for its own DID method (did:solidus writes every operation directly as its own transaction, without Sidetree-style batching, see that entry for the full contrast), but composes the same general anchoring pattern for the two use cases described below.

Where Solidus actually uses it

Two real transaction types anchor hashes in Solidus's shipped code. The more established one is CredentialIssue (and its BBS+ selective-disclosure variant, CredentialIssueBbs): when an issuer issues a verifiable credential, the full credential payload stays off-chain with the holder, and only a BLAKE3 hash of that payload is anchored on-chain, at issuance. A verifier can later confirm a presented credential matches what the issuer actually issued by re-hashing it and comparing against the anchored value, without the credential's contents ever having touched the chain itself.

The second is ComputeAnchor, part of Solidus's GPU compute-network governance: an admitted operator's batch of off-chain job receipts gets anchored by Merkle root, so the batch's contents can later be checked for integrity without every individual receipt living on-chain. This one is real code, but thin in practice: the compute network it belongs to runs on a small, founder-approved allow-list, one admitted operator today, not an open network, so "anchored" currently means one Solidus-run node's own batches, not data from independent third parties.

Check it yourself

solidus_getTransaction and solidus_getReceipt are live, public JSON-RPC methods on rpc.solidus.network. Pull a recent block with solidus_getLatestBlock, find a CredentialIssue transaction's hash, and query it directly to see the anchored hash field yourself, no account or trust in Solidus's word required. Both transaction types are visible in source in the public solidusnetwork/protocol repository's solidus-txns crate.

Related terms: Sidetree · Verifiable Credential · BBS+ Signature · Credential Portability · State Root · did:solidus