Rewrite audit-ready briefing: software is not a certificate.
Some checks are pending
ci / markdown (push) Waiting to run

Open with an executive summary that HIPAA, SOC 2, and ISO 27001
are organizational programs. Verae DataCubes supply store,
communicate, timestamp, verify, and audit tools for the technical
portion only. Chapters cover transit (HPKE, visible routing), rest
(IPFS/Peergos hash-verified restore), receipts, EU Peergos
evaluations (Cure53 2019, ROS 2024), cross-blockchain timestamping,
and write-once Iceberg archive. PDF is branded with the Verae logo
top-left and Verae Inc contact in the footer; last chapters are
sourced bios for Garfinkel (FINRA CRD 5052743), Haber, and Lambert.
This commit is contained in:
George Lambert 2026-09-16 00:55:21 -04:00
parent da60402e88
commit 4fcbb9ac95
53 changed files with 6323 additions and 814 deletions

View file

@ -0,0 +1,138 @@
Verae global timestamping --- a cross-blockchain receipt
========================================================
Lineage
-------
The scientific problem Verae is productizing is not new. In
1991, Stuart Haber and W. Scott Stornetta published "How to
Time-Stamp a Digital Document" in the *Journal of
Cryptology*. They asked how to certify when a digital
document was created or last changed **without trusting the
medium** and **without giving the timestamping service the
document**. In 1993, with Dave Bayer, they showed how Merkle
trees make that efficient. In 1997 they published "Secure
names for bit-strings." Satoshi Nakamoto's 2008 Bitcoin
white paper cites those three papers as references [3], [4],
and [5] --- three of the eight citations in that document.
Haber co-founded **Surety** in 1994, widely described as the
first commercial blockchain: a hash-linked chain of document
certificates, with a weekly summary published in the Sunday
*New York Times* so that the day's commitments sat in a
public, widely archived analog record.
Haber is a **co-founder of Verae**. Verae's public site
states the aim directly: make that proof simple enough for a
compliance team and precise enough for an SEC exam, without
forcing the enterprise to operate a public blockchain. The
quote on verae.com is: "I co-founded Verae to make
blockchain accessible to enterprises without having to deal
with the complexity of blockchain."
What "cross-blockchain" means here
----------------------------------
A single private log, held only by the vendor, is a vendor
assurance letter with extra steps. A single public chain may
be operationally and commercially the wrong place to put an
enterprise's registration traffic. Verae's design is
**cross-blockchain** in the following sense:
* an **organizational chain** runs at the customer, inside
or beside the DataCube, recording hashes, metadata, and
sequence;
* a **central Verae chain** records fingerprints and issues
receipts;
* the two are **cross-verified**, so that neither side can
rewrite history without the other side's record disagreeing;
* when policy calls for it, commitments can be **anchored
further** --- additional public or consortium chains --- so
that proof of existence does not collapse if one operator
disappears.
The customer does not have to become a blockchain operator
to use this. That is the product claim. The examiner does
not have to trust a single vendor's database to verify a
receipt. That is the scientific claim, inherited from
Haber--Stornetta.
Two deployment patterns
-----------------------
**Linked organizational server.** The organization runs a
timestamping node next to its DataCube server. That node is
linked to the central Verae timestamping server. Local
registrations are committed locally (low latency, private
metadata stays home) and cross-verified centrally (receipt
the rest of the world can check).
**Direct sync.** An organization that does not want to run
the organizational node can sync registrations directly with
Verae's central timestamping server. Proof of existence at a
specific date and time still issues. Private metadata and
attached files, if any, remain the organization's problem to
store --- typically in the encrypted Peergos DataCube.
Both patterns produce the same external artifact: a receipt
bound to a hash, a time, and a sequence. They differ in
where the organizational metadata lives and in how much
infrastructure the customer operates.
The digital bundle
------------------
The unit of production is a **digital bundle**:
* the **receipt** (hash, time, sequence, verification path);
* **private metadata** (classification, matter, hold,
internal identifiers) that need not be on a public chain;
* **attached files** that should be produced together;
* a pointer or capability to the object in the encrypted
DataCube, when the organization chose to store the object
and not only its fingerprint.
An examiner can be given the bundle, or a redacted bundle,
without being given a login to the production console and
without Verae ever having seen the object bytes.
Proof of existence versus proof of custody
------------------------------------------
Timestamping answers: **did these bits exist by this time?**
The DataCube answers: **does the organization still have
them, encrypted, hash-checkable?**
The Iceberg write-once tier answers: **can anyone quietly
delete them anyway?**
A complete production to a regulator often needs all three.
Timestamping alone is not an archive. An archive without a
receipt is a pile of files with a clock on the filesystem
that the administrator can set.
What this does, and does not, satisfy
-------------------------------------
For SEC Rule 17a-4, FINRA books-and-records, and similar
regimes that demand records in a non-rewriteable,
non-erasable form **with the ability to produce the
original**, timestamped receipts plus write-once archive are
the **technical portion** of the answer: you can show when
the record was sealed, that the bits match, and that the
archive copy is not under ordinary delete.
They do not satisfy:
* the requirement to **capture the channel in the first
place** (if the team used an unsealed tool, there is
nothing to timestamp);
* the requirement to have **written procedures** for
production, legal hold, and supervision;
* the requirement that a **named principal** own the
recordkeeping obligation.
Software seals what it is shown. The organization must still
show it the right things, on time, under a policy someone
will sign.