i Scope of the open repository

What we open-sourced, and what we didn't.

We open-sourced the part that has to be trusted — the cryptography. We did not open-source the part that has to be a business — everything around it. Here is the line we drew, and why.

In the public repository
The cryptographic engine
  • The split function — turns a secret into N shards
  • The reconstruct function — turns M shards back into the secret
  • SLIP-39 conformance — interoperable with any compatible tool
  • Complete test suite — 214 official vectors plus our own
  • A minimal standalone HTML — split and recover, fully offline
  • Build instructions — reproducible, hash-verified
This is the part you must be able to audit. The math, the implementation, the test results — all readable line by line.
Kept private
Everything around it
  • The Shards website you are reading right now
  • The kit design, layout, and printing specifications
  • The order flow, payments, fulfillment, and shipping
  • Marketing copy, brand assets, and the Shards wordmark
  • Internal documentation and operations
  • Customer data — which we do not collect anyway
Open-sourcing the business would help future competitors, not future customers. So we didn't.
Why this split is honest, not stingy

The reason to open-source cryptography is so users can trust it without trusting the company. The reason not to open-source the whole business is that the business is not the source of trust — the math is. Every meaningful security guarantee we make is testable in the public repository.

You do not need our marketing pages to recover your shards. You need the code, the test vectors, and the build instructions. All three are public.

ii Conformance testing

Tested against every published vector.

A test vector is a known input paired with a known output. Cryptographic libraries use them to prove that any implementation behaves identically — ours, yours, or one written 20 years from now.

Official vectors
214 / 214
SLIP-39 reference suite
Custom vectors
+ 36
Edge cases & round-trips
CI passing
100%
Every commit, every branch
Runtime
< 30s
On standard hardware

The 214 official vectors come from Trezor's published SLIP-39 reference suite — the canonical test set for Shamir-based seed sharing. If a library passes them, its output is interoperable with every other compliant library. If it fails any of them, it has subtly diverged from the standard.

Our 36 custom vectors cover edge cases: minimum thresholds (1-of-1, 2-of-2), maximum thresholds (16-of-16), round-trip correctness under unusual parameters, and known-malicious inputs (corrupted shares, truncated mnemonics, wordlist substitutions).

Once the public repository launches, the test results are visible in the CI badge on GitHub, and the test suite itself is runnable in under thirty seconds with npm test.

iii Reproducible builds

Verify the build yourself.

A reproducible build means that anyone, starting from the same source code, produces a byte-identical output. If our published artifact matches what you build from source, you know it hasn't been tampered with between the repository and your browser.

# Step 1 · Clone the repository $ git clone https://github.com/mindcraft-inc/shards-core $ cd shards-core # Step 2 · Install dependencies (Node.js LTS required) $ npm install # Step 3 · Run the test suite — 214 + 36 vectors, ~30 seconds $ npm test ✓ 250 / 250 vectors passing # Step 4 · Build the production artifact $ npm run build → dist/shards-core.min.js (24.6 KB) # Step 5 · Verify the hash matches our published release $ shasum -a 256 dist/shards-core.min.js <published on first release> dist/shards-core.min.js
Single dependency tree. Audited regularly, kept minimal.
Deterministic builds. Same input, same output, every time.
SHA-256 published with every release on GitHub.
CI runs the same steps on every commit, publicly viewable.
If the hashes don't match — stop

If you build from source and the resulting SHA-256 does not match the hash published on the release page, do not use that artifact. Open an issue on GitHub. Either the published version has been tampered with, or there is a build environment issue worth investigating. A reproducible build is the simplest verification you can run, and it should always succeed.

iv Air-gapped operation

Run it without the internet.

For high-value secrets, running the split and reconstruction on a machine that has never touched the internet is the strongest practical protection. Two methods, depending on how paranoid you need to be.

Method A · Load the page once, then disconnect. Visit thresholdvault.com/split, wait for it to fully load, then disconnect your device from the network. Perform the split or reconstruction. The page does not make additional network calls during operation — verifiable in your browser's developer tools, Network tab.

# Verify no network traffic during sensitive operations 1. Open browser DevTools (F12 or Cmd+Option+I) 2. Switch to the Network tab 3. Load https://thresholdvault.com/split 4. Disconnect from WiFi or unplug ethernet 5. Perform the split — watch the Network tab → Expected: zero new requests after disconnect

Method B · Build from source on an air-gapped machine. Clone the repository on a connected machine, transfer it to an air-gapped device via USB, then build and run the standalone HTML. This eliminates the dependency on our domain entirely.

# On a connected machine: $ git clone https://github.com/mindcraft-inc/shards-core $ cd shards-core && npm install && npm run build # Transfer the entire directory to USB # Move USB to air-gapped device # On the air-gapped machine: $ open standalone/standalone.html → Split or recover, with no network of any kind.
What air-gapped operation cannot protect against

Running offline eliminates network-based risks. It does not eliminate physical risks (a compromised device, malware loaded before air-gapping, key-logging firmware, printers with retained memory). For the highest-value secrets, the cryptographic operation is just one link in a longer chain — see our threat model for the full picture.