When a brand asks us why we anchor product records to a public blockchain, the question is fair. The naive picture — one transaction per product, each one paid for separately — is genuinely impractical at scale. For a small batch of high-value items it might add up. For a production run of ten thousand wallets or scarves, it would be absurd. So when we say that the same ten thousand products can be anchored to Ethereum's Layer 2 in a single transaction, brands tend to assume there is a catch. There is not. The trick is a forty-year-old idea from cryptography called a Merkle tree, and it has become one of the most useful tools we have for binding off-chain data to an immutable public ledger.
What a Merkle tree actually is
A Merkle tree is a way of producing a single short fingerprint that represents a set of items. You start by hashing each item — the product identifier, its associated metadata, the brand that produced it. That gives you a list of leaves. You pair the leaves and hash each pair to produce a smaller list. You repeat until only one hash remains. That last hash is the root. Change any item in the set, anywhere, and the root changes. Add an item, remove one, alter a single byte: the root tells you something has shifted.
What makes this useful is the second half of the trick. Suppose you only want to prove that one particular product is in the tree. You do not need to send the entire tree. You only need the chain of sibling hashes from your leaf up to the root. For a tree containing a million items, the proof is about twenty hashes. For ten thousand, it is roughly fourteen. This is the property cryptographers call logarithmic verification: the size of the evidence does not grow with the size of the set.
One transaction, regardless of batch size
This changes how anchoring works in practice. Instead of writing each product to the chain, we compute the root locally for the whole batch and write only that to Base — Ethereum's official Layer 2, secured by Ethereum mainnet itself. The smart contract stores the root for a given batch identifier. Anyone who later wants to prove that a specific product belonged to that batch presents their Merkle proof, and the contract recomputes the path and confirms it matches the stored root. The contract does not need to know what is in the batch. It only needs the root, and a verifier needs only the proof.
Because the on-chain transaction is constant in size — a small data write and an event — it costs roughly the same whether the batch represents ten items or a hundred thousand. The on-chain footprint is the root, and the root is thirty-two bytes.
What anchoring proves, and what it does not
It is worth being precise about what an anchored record demonstrates. An anchor proves that a particular set of identifiers existed at a particular moment in time, committed by a known signer to a public blockchain. The record cannot be backdated. It cannot be quietly altered. It cannot be deleted by a single party deciding to take it down. That is a useful guarantee in cases where authenticity must be verifiable years or decades from now, by someone who has no relationship with the original issuer.
What anchoring does not do is prove that the physical object in front of a consumer is the one corresponding to a particular digital identifier. That binding is the job of the cryptographic tag attached to the product itself. The two work together: the tag links physical to digital, and the anchor links digital to a public, durable record. Neither replaces the other.
Why Base, and what about Layer 1
We anchor on Base — an Ethereum Layer 2 built and maintained by Coinbase, secured by Ethereum mainnet through optimistic rollup proofs. Transactions on Base settle in seconds rather than minutes and cost a few cents instead of several dollars. For the overwhelming majority of authentication use cases, this is the right trade-off: a permanent, publicly verifiable record on a chain that inherits its security from Ethereum, at a cost that scales with usage instead of penalising it.
Ethereum Layer 1 itself remains the most decentralised and most economically secured public ledger in existence. For products whose verification record needs to survive without dependency on any particular sequencer or rollup operator — investment-grade watches, generational pieces, items likely to enter regulated secondary markets a generation from now — direct L1 anchoring is on our roadmap as an option for the Maison tier. Until then, every anchored batch lands on Base, where the proof is just as durable for any practical purpose and the economics let us anchor liberally rather than selectively.
Verification, scanning, and the offline question
Anchoring should never get in the way of a scan. When a consumer scans a tagged product, the immediate result they see — authentic or not, current ownership, history — comes from a local cryptographic verification of the tag itself. That verification works whether or not the device is online, and it works in milliseconds.
If the batch happens to be anchored on chain, a second piece of information becomes available: a verifiable link to a public ledger entry confirming when the product was registered. This badge loads asynchronously, after the primary result is already on the screen. It typically resolves within a few hundred milliseconds when the device has a connection. If the device is offline, the badge simply does not appear, and the primary verification is unaffected.
In short: on-chain anchoring is additive. It strengthens the public audit trail without slowing the consumer experience or breaking offline operation.
When it is worth doing
Anchoring is not the right answer for every product. For commodity items where end consumers are unlikely ever to invoke independent verification, the additional record adds complexity without delivering meaningful value. For high-value items, regulated categories, or anything entering secondary markets where future buyers will want to verify provenance themselves, the case becomes much stronger. We discuss with each brand which of their lines genuinely benefit from it and which do not. There is no obligation for a brand to anchor everything: anchoring is per-batch and can be enabled selectively.
For brands operating under the EU Digital Product Passport regulation, anchoring also matters for a different reason. The regulation does not yet mandate blockchain anchoring, but it does require verifiable, durable product records. Anchored records meet that bar by construction. Where compliance and trust intersect — and increasingly they do — anchoring becomes a forward-compatible choice.
Where it sits in the SealTrust platform
Inside the admin dashboard, anchoring is a single action on a production batch. The system computes the Merkle root locally, displays the root and the number of leaves, and submits the transaction when the operator confirms. The transaction hash is then recorded back against the batch and surfaced on every product page derived from that batch.
For consumers, the experience adds one element to the verification screen: a small badge linking to the on-chain record. Those who do not care simply see a stronger trust signal. Those who do can take the Merkle proof, verify it independently against the public contract, and convince themselves that nothing was fabricated. That independence is the point. The trust is not in our company. It is in the mathematics and the public chain.
Wondering whether anchoring makes sense for your brand? We can talk it through in a short call and look at your specific product mix. Get in touch.
