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: for a batch minted on the contract we use today, that hash covers the token identifier, the hash of the unit identifier and the hash of the address of the metadata. The brand name is not part of it, so renaming a brand never invalidates a proof. 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, up to ten thousand items
This changes how anchoring works in practice. Each product is minted individually on the contract, with its own token identifier and its own mint transaction, and anchoring is a separate step layered on top. Rather than one anchoring transaction per product, we compute the root locally for the whole batch and write that single root to Base, an Ethereum 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 ten thousand, the largest batch we anchor in a single transaction. 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 Layer 1 anchoring is a design we have costed but not deployed: there is no Ethereum mainnet contract today, and 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 scan reaches our verification service, which checks the chip's cryptographic seal and returns the verdict along with the current owner and the product history. The iOS app additionally carries a local cryptographic fallback: with no connection, it confirms on the device that the chip is genuine and shows the brand, the identifier and the mint date, without owner or history, and queues the scan for a server check as soon as the device reconnects.
If the batch happens to be anchored on chain, that fact does not ride along with the scan verdict: it comes back on the separate product lookup, which carries the batch's Merkle root, this unit's leaf and the sibling hashes that lead from it to the root, and the Base transaction that wrote that root. The product page turns them into a badge linking to the transaction on a public block explorer, next to a public endpoint that serves the same proof to anyone who would rather recompute it themselves. On the offline fallback path the badge simply does not appear, because there is no connection to fetch it, and the local verdict stands on its own.
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. For brands operating under the EU Digital Product Passport regulation, anchoring also matters for a different reason. The regulation does not mandate blockchain anchoring. Nor does it, at the time of writing, say what a passport must contain: the ESPR sends that to a delegated act per product group and none has been published, the battery regulation being the exception, since it carries its own content list and its own date. Anchoring is therefore not a compliance measure and we do not present it as one. It is a choice about evidence: a record committed to a public chain on a given day can be dated and checked by a third party years later, against the public contract rather than against our word. 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.
