Knowledge Expansion Protocol
The evidence-bound protocol beneath CyberAlchemy Exchange, expanding access to encrypted knowledge without erasing its origin.
Contents
Abstract
Digital knowledge can be copied without being surrendered. KEP models that fact as an expansion of an owner set: { A } becomes { A, B }. A remains associated with the artifact while B receives independently controlled access.
The knowledge stays encrypted off-chain. A’s browser encrypts it, B’s browser decrypts it, and Durable Storage retains only ciphertext and sealed recipient envelopes. Solana never encrypts or decrypts knowledge; it records identities, protocol membership, commitments, revisions, and replay protection.
Sharing is represented as a bounded, auditable expansion of access—not an exclusive transfer.
Who encrypts, what is stored, and what Solana proves
Cryptographic ability and protocol authorization are separate. The participants hold the secrets. The hosted service stores sealed material. Solana records which recipient and envelope commitment the protocol recognizes.
Cryptography and custody details
| Component | Can see | Performs | Never receives |
|---|---|---|---|
| A’s client | Plaintext, content key, B’s public key | Encrypts V and creates B’s envelope | B’s private key |
| Hosted storage | Ciphertext, sealed envelopes, public metadata | Persists and verifies sealed material | Plaintext, content key, private keys |
| Solana | Membership, commitments, revision, replay identity | Validates and records the public transition | Ciphertext, envelope bytes, content key, plaintext |
| B’s client | Ciphertext, B’s envelope, B’s private key | Opens the envelope and decrypts locally | A’s private material |
A random 32-byte content key encrypts the artifact. The same authenticated ciphertext is shared with every authorized recipient.
B’s X25519 public key seals the content key into recipient-specific bytes bound to the artifact, epoch, policy, key binding, and envelope revision.
HPKE Base mode does not authenticate A. A’s signing-key binding, wallet signature, propagation policy, and Solana program checks authorize the grant separately.
This is public-key encryption, not a traditional certificate-authority PKI. The protocol binds a stable Knowledge Identity to a versioned encryption public key. The envelope carries an encrypted content key—not a generic “decryption key.”
The problem
Files are easy to copy, but proving who authorized access, what exact version was shared, and whether the recipient can still recover it is much harder. Conventional transfer language also suggests that the originator gives something up.
Origin must persist. Adding B must not remove A.
Knowledge must stay private. Neither chain nor service should receive plaintext.
Access needs evidence. A prepared envelope is not releasable until its matching Solana commitment is finalized and reconciled.
Keys will fail. B needs a reissue path that does not create a second grant or alter the owner set.
Core model
- Knowledge Artifact Version
- The immutable content instance whose commitments are exchanged.
- Stable Knowledge Identity
- The protocol identity, distinct from wallet signing and encryption keys.
- Propagation Policy
- The immutable rules attached to one artifact version.
- Encryption Epoch
- The cryptographic generation of the encrypted artifact.
- Recipient Key Envelope
- HPKE-sealed bytes containing the content key for one recipient’s versioned X25519 public-key binding.
Type model
The hosted protocol is not one unstructured record. Its Rust model separates identity, immutable artifact content, prepared intent, recipient material, reissue, and the access projection returned after authorization.
Stable identity. One protocol identifier may survive wallet or encryption-key changes.
Immutable knowledge version. The ciphertext commitment, policy, and encryption epoch identify what was shared.
Revisioned access. Grants and reissues name the revision they expect, preventing stale intent from silently applying later.
Protocol logic
Each transition is deliberately narrow. A request first creates intent; only a matching finalized Solana observation may change the hosted access projection.
owners′ = owners
revision′ = revision
access(B) = falsePreparing a grant records exact intent, but creates no owner or retrieval effect.
finalized(tx) ∧ matches(tx, grant)
owners′ = owners ∪ { B }
revision′ = revision + 1Only the expected program, artifact, recipient, envelope commitment, and revision authorize release of B’s prepared material.
owners′ = owners
V′ = V · policy′ = policy · epoch′ = epoch
binding′[B] > binding[B]
envelope′[B] = replacement · revision′ = revision + 1Recovery replaces B’s active envelope while the artifact and ownership relation stay fixed.
Architecture
The browser owns plaintext, the content key, and private encryption keys. The hosted service verifies signed intent, stores ciphertext and sealed envelopes, and observes finality. Solana coordinates recognized protocol membership and commitment revisions but cannot decrypt. SQL-backed durable storage provides the portable record layer; independent backup, restore, and content-key recovery remain production obligations.
Protocol flow
- 01Establish identity
A and B bind independently controlled wallets to encryption public keys.
- 02Seal the artifact
A encrypts one exact artifact version in the browser and stores only sealed material.
- 03Prepare and submit
A prepares B’s envelope, submits the grant, then waits for finalized state.
- 04Release and decrypt
The service reconciles matching finalized state, releases only B’s envelope, and B decrypts locally with B’s private key.
- 05Reissue when recoverable
B may request a replacement envelope. An authorized fulfiller must recover the unchanged content key; artifact, policy, epoch, and members remain fixed.
- 06Inspect bounded evidence
The result proves only the exact state and byte relationships checked by this flow.
Your account, your originals.
The console uses wallet-signed requests and an encrypted account backup. Keep the recovery file privately: wallet access alone cannot restore your encryption keys.
Original files up to 10 MB stay encrypted. The first verified download acknowledgement starts a one-year expiry timer; each later acknowledged download resets it. Before the first, there is no deadline. Extraction remains planned provenance.
What the local tests establish
Recovery restored an identical original. Interrupted saves and download acknowledgements were retried; stale account saves were rejected. A later PostgreSQL repair rejects a second writer and fences writes after connection loss. Browser tests preceded that repair, so a combined run remains due.
Download acknowledgement is not proof of saving to disk. A recovery file is not a payload backup. Lost recovery secrets, independent backup deletion, real wallet compatibility, and live-chain testing remain open. A disconnected service can still return stale reads.
What supports the design?
Evidence for specific properties, each tied to its tested source snapshot.
Protocol modelLean theorem checked twiceHistorical model · no implementation refinement
The modeled grant preserves A, adds B, binds the envelope commitment, advances revision, consumes replay identity, and keeps consideration zero.
Scope: Historical formal-model receipt. No proof that Rust or Solana faithfully implements the model.
Inspect receipt
Receipt: LOCAL-LEAN-EVIDENCE
SHA-256: dd054c07a433ef8aa156b769ccbd7bbce205778db7ae1cb2620ca494a868f34f
Broader formal checks7 claims · 15 deterministic projectionsHistorical bounded models · no end-to-end proof
Recorded bounded checks across Lean, TLC, and Alloy cover encoding, storage gating, grant, activation, reissue, cost separation, and secret placement.
Scope: Historical EVF PASS_BOUNDED. Model assumptions and finite bounds apply; no end-to-end implementation refinement.
Inspect receipt
Receipt: LOCAL-EVF-FORMAL-RECEIPT-V2
SHA-256: 3c8553c4fe1694ca8e4021c2178e4628bfa0eeef3177b5ec0434c89e79933b38
Checkpoint recovery34 JavaScript tests passedLocal tests · no live-chain submission
Six added regressions exercise checkpoint failure and submission ambiguity. Known pre-submission failures can retry; restored uncertain submissions stay blocked.
Scope: September 6 local test run. No live-chain submission or arbitrary crash-recovery proof.
Inspect receipt
Receipt: LOCAL-SEP6-CHECKPOINT
SHA-256: e881a83ed844cefec73dc3d633de317ab8a04a97740d50c661a4ad16b3714499
Original-file recoveryIdentical original recoveredTest signer · before writer repair
An isolated browser restored identity and a 10,246-byte original with the same SHA-256 digest, and retried interrupted saves and download acknowledgements.
Scope: September 6 browser run before the writer repair. Test signer only; no wallet-extension or memory-zeroization proof.
Inspect receipt
Receipt: LOCAL-SEP6-BROWSER-RECOVERY
SHA-256: 558db330165db86d529446d8c5484dfc152b9f1b81c3a6352c701c7e835f4982
Lost responses and stale tabsRetry preserved revision · stale save rejectedOne process · no divergent-edit merge
After a committed response was dropped, retry used the same ciphertext and revision. A competing stale tab received HTTP 409; explicit discard and recovery succeeded.
Scope: One backend process, before the writer repair. Divergent-edit merging and backend crashes were not tested.
Inspect receipt
Receipt: LOCAL-SEP6-COMMIT-TABS
SHA-256: d2275ad2052c1cef2f0a893acb7b9bb62c865fda9a98789fa7b905e46fe3e635
Database writer exclusion9 Rust + 4 PostgreSQL tests passedParticipating writers · stale reads remain possible
The repair checks second-writer rejection, takeover after shutdown, and failure of stale writes after connection loss. A separate process test confirmed startup exclusion and takeover.
Scope: September 6 repair run. Participating upgraded writers only; disconnected reads can remain stale.
Inspect receipt
Receipt: LOCAL-SEP6-SINGLE-WRITER
SHA-256: c5fcaf03a99e5708570fd072535e5501a14955f2eda8d7469d3511a25526378a
Independent reviewCandidate 011 · bounded passHistorical candidate · ten medium residues
Review 009 recorded zero unresolved high or critical findings and ten carried medium residues for its exact frozen candidate.
Scope: Historical candidate review, not a review of the current hosted console or a production security clearance.
Inspect receipt
Receipt: LOCAL-EVF-INDEPENDENT-REVIEW-009
SHA-256: 9ad256e4b2803f1efccd122529dc7bf06b469bba7b86d355b0d33c5609ccb875
Still open
Still unproved: a combined browser journey after the writer repair, exact Rust-to-model refinement, real wallet compatibility, independent backup recovery, and production security. Hash matching establishes which receipt was inspected; it does not independently verify the receipt’s experiment.
What the evidence establishes.
Selected properties have evidence. Full-system correctness and production readiness remain unproved.
Remaining work and claim limits
This overview does not establish legal ownership, licensing rights, marketplace value, production security, Mainnet readiness, or publication approval. The current source is not one frozen product candidate, the hosted binding has drifted from accepted bytes, and historical residuality counts describe their original snapshots. The next construction step is a combined recovery run against one frozen product candidate. Production still requires security review, wallet compatibility testing, independent backup and content-key recovery, a separately authorized hosted two-party trial, operational infrastructure, and legal and user research.