Proof · v0.2.2 · Apache-2.0

@flashyos/bolt

One secret, split across an estate, checked in the finder’s own browser

bolt/1 — one secret, split across an estate. A hunt verified by commitment, in the finder's own browser.

npm install @flashyos/boltnpm ↗source ↗

Why it exists

An easter egg is usually a gag with a server behind it: you find the thing, you submit it, and a database somewhere decides whether you won. That is the one shape an estate like this cannot use — every other claim its properties make is checkable by the reader without asking anybody, so an egg that phoned home would be the only thing on the estate you had to take on faith. `bolt/1` splits one secret across every live property, publishes a commitment over the ordered set, and lets a finder prove they hold it offline.

What it refuses to do

No server, no submission endpoint, no leaderboard. It also refuses to tell a finder which shard was wrong: a check that narrows the answer can be brute-forced one field at a time, and the whole set cannot. The page that verifies never holds a shard — it publishes the digest, which is the point of a commitment.

How it works

Each live property serves one word, revealed by typing `flashy`. `gord.holdings/hunt/` takes a collected set and checks `sha256` of the ordered words against a digest published before anybody started looking — in the finder’s own browser, with `crypto.subtle`. The page holds the digest and not one shard, sends nothing anywhere, and keeps no record that anybody visited ten domains.

A miss never says which shard was wrong. A check that narrowed the answer would be brute-forceable one field at a time, and the whole set is not.

Growth adds a tier rather than revoking one: each tier contains every property of the one before, so a new property makes the hunt strictly harder while an early finder’s proof stays good forever.

Related concepts

IntentMesh agentic autonomous organization machine-readable organizational trust AI agent trust register

Use it

Commit to a set, then check one without revealing it

import { commit, verify } from '@flashyos/bolt';

const commitment = commit(['ALPHA', 'BRAVO', 'CHARLIE']);
verify(entered, commitment); // true or false, and never which part failed

Questions

Why is there no server?

Every other claim on this estate is checkable without asking us — settlements, charters, tree heads. An egg with a backend would be the only thing you had to take on faith, which is a strange exception for the property whose entire pitch is that you do not have to trust it.

What does a proof actually prove?

That the finder holds every shard, because the digest of what they entered equals the digest published in advance. It does not prove who they are, when they found it, or that they visited anything — there is no record of the hunt, by design, and a finder can produce the proof offline and hand it to anybody.

The licence

Apache-2.0, read from the package’s own manifest. Embed it in anything, including closed software — that is what makes a spec adoptable and a verifier worth running. FlashyOS’s server side is AGPL-3.0-only instead, and a test in the monorepo asserts the direction between them: AGPL code may consume this, this may never consume AGPL code.

Keep reading

The estate graph

Also in proof

@flashyos/artifact @flashyos/verify @flashyos/countersign