Knowledge Expansion Protocol
The evidence-bound protocol beneath CyberAlchemy Exchange, expanding access to encrypted knowledge without erasing its origin.
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. Public state carries identities, policy and epoch commitments, owner membership, envelope commitments, revisions, and replay protection—not plaintext or content keys.
Sharing is represented as a bounded, auditable expansion of access—not an exclusive transfer.
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 active until matching Solana state is finalized.
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
- The recipient-specific wrapping of the unchanged content key.
Architecture
The browser owns plaintext, the content key, and the private encryption key. The hosted service verifies signed intent, stores ciphertext and envelopes, and observes finality. Solana coordinates the public owner set and commitment revisions. SQL-backed durable storage provides the portable record layer; independent backup and restore 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.
- 04Activate access
The service reconciles matching public state before B’s envelope becomes active.
- 05Reissue when needed
B may request a replacement envelope; artifact, policy, epoch, and owners remain unchanged.
- 06Inspect bounded evidence
The result proves only the exact state and byte relationships checked by this flow.
A working research candidate, not a production claim.
This interface does not establish legal ownership, licensing rights, marketplace value, production security, Mainnet readiness, or publication approval. Production still requires security review, wallet compatibility testing, physically independent backup and restore, hosted two-party trials, operational infrastructure, and legal and user research.