Two chip-release manifests carry the same product number. Both look authentic. One was approved before manufacturing. The other appeared later. Which one should a buyer trust?
Contracts, certificates, portal records and PDFs can describe what a manufacturer approved, tested and delivered. But those records usually remain inside systems the manufacturer controls. If two copies differ during an audit or dispute, the buyer lacks a neutral reference for the version that existed at the relevant time.
In one sentence
ProofStamp creates a public, time-bound commitment to the hash of selected evidence, while the evidence itself stays private.
Private file. Public proof.
At an authorized checkpoint, the manufacturer hashes a release manifest, test summary or other selected evidence locally. It signs the hash and timestamps the small proof record on a public blockchain. Schematics, source code, test data and customer information remain in existing systems.
The owner keeps the original beside a portable sidecar such as chip-release-v7.zip.proofstamp. Later, a buyer, auditor or arbitrator can hash a disclosed file and compare it with the signed public record. The manufacturer does not need to reveal the file until disclosure is appropriate, and the verifier does not need to rely on the manufacturer’s database.
Try to break the proof
The sample below represents a lot-acceptance security test record for one silicon revision. It identifies the production lot, exact test-suite version, sample count and two security checks. The detailed private results are represented by their own hash. Verify the record, change one test result and verify it again.
The checks are deliberately concrete: an invalid boot image must be rejected, and production debug access must remain blocked after lifecycle locking. The names and values are illustrative. A pilot would use the manufacturer’s existing tests and terminology.
Sample chip security test record
Lot L2408 · Silicon B1 · Security test suite SEC-FT-7.4.2
b46b7d04a4bb91b6985d1d6870e2d482a7ca67b4ee45ae3d2a3ec7423b305914Select “Verify test record”Private by design: the sample is processed on this page and is not uploaded. The results_bundle_sha256 field can bind a larger private test-results package without publishing it.
A hash match is not yet a timestamp
The local check above answers one question: do these bytes match the reference hash? To establish time independently, the manufacturer must anchor that hash, or a Merkle root containing it, in a confirmed public blockchain transaction.
Complete the public timestamp
- Hash locally. Calculate SHA-256 without uploading the private file.
- Anchor the hash. Submit only the hash, or a batch root, to a public blockchain.
- Wait for confirmation. The confirmed block supplies an independently checkable block height and time.
- Save the receipt. Store the network, transaction hash, block reference, timestamp and explorer link in the
.proofstampsidecar.
Only then can a verifier establish that the matching bytes were committed no later than the confirmed block time.
A complete production verification therefore checks three things: the recalculated file hash matches the sidecar, the manufacturer’s digital signature is valid, and the same signed hash or batch root appears in the referenced blockchain transaction. The block record supplies the public timestamp. The sidecar makes it portable.
What the timestamp proves, and what it does not
| It can establish | It cannot establish |
|---|---|
| Exact file bytes existed no later than a public block time | The design is correct or secure |
| A disclosed file matches the timestamped version | The chip contains no hidden feature or backdoor |
| The manufacturer signed a particular claim | The physical chip matches the records without existing traceability controls |
| The committed record was not silently replaced later | Every relevant record was disclosed |
The value is narrow but useful. An arbitrator can ask: does the file presented today match the version signed and timestamped before manufacture, testing or delivery? A public record lets the buyer answer that question without accepting a screenshot or depending on one vendor portal.
Where proof fits in the chip lifecycle
Normal semiconductor processes already produce design approvals, RTL or netlist releases, IP inventories, tape-out packages, lot references, firmware builds, test-program versions and shipment records. ProofStamp does not replace authorization, change control, test governance, lot traceability, key protection or evidence retention. It adds a vendor-independent timestamp to selected outputs from those controls.
The manufacturer still needs a reliable link between records and physical lots or devices through existing serial identities, provisioning or other traceability controls. Repeated checkpoints can then build a verifiable operating history across releases, suppliers and buyers.
For implementers: what belongs in a .proofstamp file?
Keep the exact original beside a readable JSON sidecar:
chip-release-v7.zip
chip-release-v7.zip.proofstamp- Format version, original filename and file size
- SHA-256 hash and relevant product, revision, lot or claim identifiers
- Manufacturer identity credential, public key and digital signature
- Blockchain network, transaction and block references, timestamp and explorer link
- Merkle inclusion proof when several file hashes share one transaction
The verifier hashes the original, compares the result with the sidecar, checks the signature, then confirms the public record. The sidecar is a portable receipt, not the authority. An altered sidecar fails against the signature or public record. The format can also map to architectures such as IETF SCITT.
Pilot it with one release, one lot and one buyer
A useful pilot does not need production machinery changes or confidential files on-chain. Connect three events already present in the release process:
Release
Approved design revision, firmware references, security review and named approvers.
Test
Lot reference, authorized deviations, test-program version and signed result summary.
Delivery
Delivered lot or serial range, expected configuration and verification instructions.
The pilot succeeds if:
- A buyer verifies a disclosed file without manufacturer assistance
- A substituted file produces an immediate no-match result
- An independent reviewer resolves a simulated file dispute
- No confidential design data leaves existing systems
- The added checkpoint effort and cost are measured
Selected sources
- NIST IR 8532: Enhancing Security of Devices and Components Across the Supply Chain
- NIST Semiconductor Traceability and Provenance Workshop
- Intel Tiber Transparent Supply Chain product brief
- DHS: Blockchain-Based Traceability for Semiconductor Assurance
- IETF RFC 9943: An Architecture for Trustworthy and Transparent Digital Supply Chains