Learn
VerifierExample CV
Storage & limitsFor everyone4 min read

Where your signed data lives

Short answer: almost none of it is on our servers. Here's the long answer — and the exact limits.

Most "trust" products work by being the place everything lives — your posts, your endorsements, your audit log, all behind their login. The whole point of a cryptographic signature is that you don't need that. So we don't do it.

What lives where

  • Signed blocks (the text + signature you generate): nowhere on our servers. The instant you click Generate signed block, the output is yours to copy. Paste it under a LinkedIn post, into a PDF CV, into an email — wherever the audience already is. We don't keep a copy.
  • The public key: published at https://born.engineer/.well-known/did.json as a W3C DID document. That single file is the only thing a verifier ever needs to fetch.
  • The private key: held server-side as an environment secret (DID_SIGNING_KEY). It never reaches the browser, never goes into a database, never appears in a log line.
  • Recommendations on the example CV: stored as plain text in source code and re-signed on every page render. There is no recommendations database to leak or lose.
What this means in practice
If born.engineer disappeared tomorrow, every signed block you've ever issued would still verify — as long as someone, somewhere has a snapshot of the public key at /.well-known/did.json. That's the whole design.

Storage limits

Because nothing is stored per user, the only limits are on the size of a single signing or verification request:

  • Payload per signed block: up to 8,000 characters. For reference, a LinkedIn post maxes out at 3,000, so this comfortably covers posts, recommendations, press statements, and short articles.
  • Verifier input: up to 20,000 characters. This is the payload limit plus headroom for the pretty-printed envelope (headers, hash, base64 signature).
  • Number of blocks you can sign: unlimited. There is no quota, no per-user counter, no monthly cap. Each signature adds about 100 bytes of overhead on top of your payload.
  • Number of verifications: also unlimited. Anyone can verify, anonymously, without an account. The verifier is stateless — each request just fetches the public key and re-checks the math.
  • DID document: a few hundred bytes, cached at the edge for 5 minutes.

What we never store

  • No copies of the posts or claims you sign.
  • No list of who you've sent signed blocks to.
  • No analytics on who verified what, or when.
  • No account, no profile, no password — the verifier has no login.
The trade-off
Because we don't keep a copy, we can't recover one for you. If you lose the signed block, just re-sign the original text — you'll get an equivalent block with a fresh timestamp. The signature on the old block remains valid for anyone who still has it.

Compared to a typical SaaS "trust" product

A typical product stores every endorsement, every verification event, and every reader's IP in its own database — and the trust signal only works while you're paying for the seat. A signed block is the inverse: the trust signal is the artifact itself, it travels with the content, and it keeps working long after any vendor relationship ends.

The best place to store proof of who said what is inside the thing they said.
Try it now
Try the verifier yourself

Keep reading