How the cryptographicboundary works.
GuardKin’s differentiator from other estate-technology platforms is structural, not feature-based. This page explains the structure in technical depth without jargon.
The metadata / content boundary
Every vault item — a bank account, an insurance policy, an estate document, a personal wish — has two cryptographic parts:
- Metadata record — encrypted with a metadata key. Contains the planning-scope information the advisor needs to advise: account type, institution, approximate balance range, document staleness, beneficiary status. The metadata key is provisioned to the advisor role at relationship creation, under explicit client consent. Rotated and revoked at unlink.
- Content record — encrypted with a content key. Contains the specifics: account numbers, exact balances, document text, personal letters, credentials, beneficiary names, medical directive contents. The content key is held only on the client’s device. GuardKin servers have never seen it. Advisors have never seen it. GuardKin employees have never seen it. It is not recoverable from anywhere except the client’s own credentials.
The boundary is enforced at the data-model level — not at the access-control policy level. A bug in the advisor dashboard cannot expose content because the server literally does not have the key material to provide it. An advisor’s attempt to query content directly fails at the cryptographic layer, not at the API authorization layer.
Live cryptography
Encrypt something. Watch it happen.
No animation, no fake data path — the libsodium WASM implementation runs locally and produces real ciphertext as you type.
Walkthrough
The cryptography in six steps.
The diagram on the left morphs as you read. Deep links: each step is an addressable anchor.
Step 1 — The metadata / content boundary
Two cryptographic halves of every vault item.
Every vault item — a bank account, an estate document, a personal letter — has two parts the server stores and the cryptography keeps separate. A metadata half that the advisor can decrypt under client consent. A content half that only the client’s device can.
The diagram on the left is the canonical picture: two ciphertext blobs, one boundary, two keys distributed to two parties. This page walks through how those keys come to exist.
Step 2 — Two-Secret Key Derivation
Three inputs become the Master Key.
The client’s Master Key is derived from three inputs combined under Argon2id (memory-hard, GPU-hostile):
- Master Password — chosen by the user. Never stored, never transmitted.
- Secret Key — 128 bits of randomness generated on-device at registration. Saved by the user (password manager + printed recovery kit).
- Server Salt — 128 bits generated by GuardKin at registration. Sent to the client at login.
A breach of any single component is insufficient. Offline attack requires simultaneous possession of memorized password, device-stored secret, and server storage.
Step 3 — Advisor consent boundary
The Metadata Root Key wraps to the advisor.
From the Master Key the client derives the Metadata Root Key. When the client links to a wealth manager, the device wraps that key to the advisor’s public key under explicit consent and uploads the wrapped copy to the server.
The advisor now has a key that decrypts metadata. They do NOT have a key that decrypts content; they never will. When the client unlinks, the wrapped copy is deleted, the metadata is re-encrypted under a new key, and the advisor is mathematically excluded from any future read.
Step 4 — Trigger events
When something must happen, it happens on a clock.
Settlement, unlinking, executor designation, and recovery initiation are all time-sequenced operations. The system records each one to an append-only audit chain with a deterministic ordering — so an after-the-fact reconstruction can verify what happened, in what order, with what consent.
The timeline on the left shows the canonical sequence of events that the platform guarantees: who initiated, when, with what consent token. None of it is alterable after the fact, including by GuardKin.
Step 5 — Audit chain
Every consequential action chains to the previous.
Trigger events, key rotations, advisor provisioning, and recovery initiations are written to a hash-chained audit log. Each entry incorporates the hash of the previous entry, so any tampering anywhere in the chain invalidates everything after it.
The chain is observable to the client. A future open-sourced verifier will let any third party (including a litigation-time examiner) confirm the chain’s integrity end-to-end.
Step 6 — Shamir recovery
When the client is gone, the shares come together.
The client’s Master Key can optionally be split into Shamir shares — typically 5-of-8 or 3-of-5 — distributed to designated recovery contacts (executor, attorney, adult children, family-office principal). Any qualifying threshold can reconstruct the key after a verified trigger event.
The shares carry no useful information individually. The threshold is set by the client. GuardKin never holds a share. Recovery contacts can reconstruct only after a triggering event has been recorded to the audit chain.
Unlinking is architectural enforcement
When a client chooses to unlink from their wealth manager, three things happen atomically:
- The advisor-client relationship row is marked unlinked, the advisor’s wrapped copy of the metadata key is deleted from the database.
- The client’s device generates a new Metadata Root Key, re-encrypts every metadata record under the new key, and uploads the new ciphertexts.
- The client is presented with three continuation options — convert to monthly direct subscription, pay the lifetime fee, or use a 90-day grace period with full data export — and chooses one.
From the moment the client confirms the unlink in their own UI, the advisor cannot decrypt any metadata for that client — including any data the advisor’s client cached locally. The keys to interpret the new ciphertext were never given out. No firm contract, configuration, or administrative action can prevent or delay this. The right to unlink is structural.
What the advisor sees, what the advisor does not see
Visible (planning-scope metadata)
- Account existence, type, institution, approximate balance range
- Insurance policy existence, type, carrier, approximate coverage, beneficiary status (present / absent / outdated), last verified date
- Estate document existence, type, last-updated date, jurisdiction, currency flags
- Asset existence, type, approximate value range, jurisdiction
- Contact existence and role (e.g., “primary executor: designated”)
- Activity patterns: vault completeness score, last-activity date
Never visible (content)
- Credentials, passwords, recovery phrases
- Specific account numbers
- Exact balances
- Document contents (will text, trust provisions, healthcare directive specifics)
- Specific beneficiary names or percentages
- Letters, video messages, personal wishes
- Funeral or memorial preferences
- Any item the client has marked as private from the advisor
Same item · two viewers
The boundary, in motion.
Below: one encrypted vault item, viewed from each side of the cryptographic boundary. The advisor pane has the metadata key but no content key — the toggle proves it.
Tamper-evident log
You can verify the audit chain yourself.
Every privileged action is signed with an Ed25519 keypair and hash-chained. The button below runs the same verifyChain function the production audit pipeline runs.
External cryptographic review
Before public launch, GuardKin’s cryptographic protocol will be reviewed by an external firm with deep cryptographic-protocol-review experience (Trail of Bits, Cure53, or NCC Group). Findings will be published in our transparency reports along with remediation status.
Within two years of public launch, GuardKin’s client code is committed to be open-sourced so independent parties can verify what the client application does with sensitive content.