Security & trust
Our security model has one guiding rule: wherever possible, every claim should be verifiable at the source, by anyone, at any time. Here is how the platform is actually built.
Product batches are anchored as Merkle roots on Base L2 (a public Ethereum layer-2). The proof endpoint below is public and unauthenticated: anyone can fetch a product's Merkle proof, recompute the hashes and compare the root against the on-chain transaction on basescan.org. No account, no permission, no SealTrust involvement.
GET https://api.sealtrust.io/verify/merkle/{identifier}
Brand dashboard
Every NFC verification streams in live, and a replayed URL is refused on the spot. The anomaly analysis is read from the dashboard, built for hundreds of thousands of products.
At scale, your team never sees the raw stream: aggregated dashboards and triaged alerts, on anomalies only.
Illustrative values
Each protected item carries an NXP NTAG 424 DNA chip. It leaves the factory with a public default key; we write keys derived from a master key protected by a managed cloud KMS at encoding time, and once written they are never exposed and cannot be read back off the tag. On every tap the chip generates a fresh, single-use code (SDM) that our API decrypts and validates server-side. A captured code cannot be replayed, and without the keys an attacker cannot produce a valid one. Authentication is cryptographic, not declarative.
On-chain transactions signed with the platform key are signed inside a managed cloud KMS, which holds that private key and never releases it. The master keys that protect NFC chip secrets are stored encrypted under a KMS-managed key and are only ever decrypted in memory. Brand and end-user wallet keys are stored encrypted at rest, and no key material is committed to a repository.
Product units are grouped into batches whose Merkle root is anchored on Base L2 (chain id 8453); a unit's leaf commits its token id, the fingerprint of its chip UID and the fingerprint of its metadata URI, and nothing else. Published passport versions are anchored by a separate, periodic sweep that groups every version not yet anchored into one tree and commits its root the same way. Because the anchor is public, integrity is verifiable by any third party (a customer, an auditor, a marketplace) without asking us and without trusting our database.
Changing the owner of a product is a sensitive operation, so it requires explicit confirmation with a one-time code (OTP or authenticator TOTP). A stolen password or hijacked session is not enough to move a product, and every transfer is recorded in the item's verifiable history.
A replayed URL is refused inline, on the scan itself: the server rejects a counter it has already seen, and rebuilds the floor from durable history rather than letting one through when the cache has lost it. Every NFC scan then feeds a rule-based trust engine, whose per-product score brands monitor from their dashboard. On top of that, an anomaly analysis over a brand's scan history surfaces geo-impossibility (the same identity in two distant places at once), counters rolling backwards, replayed codes and multi-wallet patterns; it is run from the security page of the dashboard, not on a schedule.
A brand can place its most critical on-chain operations behind a Gnosis Safe multi-signature wallet. Brands that set a threshold of two signers or more apply an M-of-N policy: a quorum of authorised signers has to approve before anything executes, and every approval is recorded on-chain, so no lone key can then mint or burn on its own. By default, minting and burning execute directly, without a Safe quorum, and burning additionally requires a fresh one-time code (TOTP or backup code) from the operator.
Data-subject rights are working software, not a policy paragraph: data export (Article 15) and erasure (Article 17) are implemented as dedicated API routes. IP addresses in scan logs are anonymised after 30 days, and retention is bounded per data category.
Production runs on European infrastructure: the application, the database and media storage are hosted in the EU, and cryptographic keys sit in a managed KMS in an EU region. A limited number of sub-processors located outside the EU are listed in our privacy policy and covered by the European Commission's standard contractual clauses.
Security questions specific to your deployment? Talk directly to the team that built this.
Contact us