Confidential · Architecture Documentation
Haven
This material is strictly confidential and intended only for authorised recipients. Enter your email address, the access password, and accept the terms below.

HAVEN — Confidential Architecture Documentation

Non-Disclosure & Confidentiality Terms

Effective upon access · April 2026

1. Acceptance
By checking this box and proceeding, you confirm that you have read, understood, and agree to be bound by these terms in full. These terms are legally binding.

2. Confidential Information
All information contained in or accessible through this presentation, including but not limited to financial data, product architecture, patent filings, technology descriptions, commercial strategies, partnership details, and valuation materials, constitutes confidential and proprietary information of Haven Holding Company LLC-FZ (“Haven”), incorporated in the Meydan Free Zone, Dubai, UAE.

3. Permitted Purpose
You may access this material solely for the purpose of evaluating a potential investment, acquisition, or commercial relationship with Haven. Any other use is strictly prohibited.

4. Non-Disclosure Obligations
You agree that you will not disclose, reproduce, distribute, summarise, copy, or communicate any part of this material to any third party without the prior written consent of Haven. This obligation applies to the existence of this presentation as well as its contents.

5. No Onward Transmission
You will not forward access credentials, share links, or otherwise enable any other person to access this material. Access is personal to you as the intended recipient.

6. Intellectual Property
Nothing in this material grants any licence, right, or interest in Haven’s intellectual property, including its provisional patent applications (USPTO App# 64/032,300 · 64/032,311 · 64/032,324), technology, brand, or trade secrets. All rights are reserved.

7. No Representation or Warranty
This material has been prepared in good faith but does not constitute a prospectus, offering document, or financial promotion. No representation or warranty, express or implied, is made as to the accuracy, completeness, or fairness of the information contained herein. Haven accepts no liability for any loss arising from reliance on this material.

8. Forward-Looking Statements
Certain statements in this presentation are forward-looking and reflect current expectations. Actual outcomes may differ materially. Nothing herein should be construed as a guarantee of future performance, revenue, or valuation.

9. No Offer
This material does not constitute an offer to sell, or a solicitation of an offer to buy, any securities, shares, or financial instruments. Any such offer, if made, will be made only pursuant to definitive documentation.

10. Return or Destruction
If you decide not to proceed with any relationship with Haven, or upon Haven’s written request, you agree to promptly destroy or return all copies of this material and any notes derived from it.

11. Survival
These obligations survive the termination of any discussions or relationship between you and Haven and remain in force indefinitely.

12. Governing Law
These terms are governed by the laws of the Dubai International Financial Centre (DIFC), UAE. Any disputes shall be subject to the exclusive jurisdiction of the DIFC Courts.

Haven Holding Company LLC-FZ · Meydan Free Zone · Dubai, UAE · mj@haven.app

Product Documentation  /  Haven Protocol Stack  ·  03 of 03

Social-Gated
Biometric Recovery

A Haven-proprietary recovery protocol that eliminates seed phrases entirely. Recovery is gated by a user-designated Security Circle whose members must approve the request while reviewing a live selfie. A second biometric layer then executes on the new device against an encrypted backup, defeating even a colluding guardian. No seed phrase. No custodian. No single point of attack.

Scope:  Guardian approval · Encrypted biometric delivery · On-device biometric match · Private key reconstructed
⚙
Patent Protection  ·  United States Patent & Trademark Office
USPTO Provisional Application  App# 64/032,324  ·  Filed April 7, 2026  ·  Priority date established  ·  Full non-provisional in progress
Two-Gate Separation Architecture
Recovery requires two independent principal gates to succeed. Gate 1 is social: a human guardian attests the owner's identity via live selfie. Gate 2 is biometric: the owner must match against an encrypted backup on the new device — a gate the guardian cannot pass on their behalf. Corruption of either gate alone is structurally insufficient to complete recovery.
●  Social Gate
●  Encrypted Delivery
●  Biometric Gate
●  Key Reconstruction
Standard step
Active / processing
Verified / authorised
Failed / blocked
Encrypted delivery
Recovery Flow  ·  Step by Step
📱
RECOVERY
INITIATED
Recovery Initiated username only — new device, no credentials required
The registered owner enters their username on a new device. No password, PIN, or seed phrase is requested at any point. The recovery session is opened and Haven signals the user's designated Security Circle guardians. Haven does not hold any key material or biometric data that could bypass this flow — the architecture structurally requires human guardians and the owner's own biometric to proceed.
Username Only — No PasswordNew DeviceNo Seed PhraseHaven Holds No Recovery Keys
📷
SELFIE
CAPTURED
Liveness Selfie Captured transmitted to Security Circle for human identity review
The recovering user is prompted to capture a live selfie on the new device. This image is transmitted to each guardian in their Security Circle alongside the recovery request notification. The selfie is not processed by automated facial recognition at this gate — it is presented to the human guardian for visual identity review. Haven does not store or retain this image beyond the active session.
Live Selfie — Liveness ConfirmedTransmitted to Guardian OnlyNo Automated FR at Gate 1Haven Does Not Retain Selfie
🔔
GUARDIAN
NOTIFIED
Security Circle Guardian Receives Push Notification live selfie + recovery request displayed
Each designated guardian receives a push notification displaying the live selfie and recovery request. The guardian's decision is binary: approve or deny. Guardians are instructed to approve only if they can visually confirm the person in the selfie is the registered owner they know. The guardian cannot see the encrypted biometric backup and cannot access the user's private key. Their function is identity attestation only — not key custody.
Guardian Decision RequiredGuardian Cannot Read BackupGuardian Cannot Access Private KeyIdentity Attestation Only
GATE 1
GUARDIAN
APPROVES?
Approved — Identity Confirmed
The guardian confirms the selfie matches the registered owner they know. The protocol proceeds to Layer 2: the encrypted biometric backup is released from the guardian's app sandbox to the recovering device. E2E encrypted — the guardian cannot read its contents.
→ ENCRYPTED BACKUP RELEASED
Denied — Identity Not Confirmed
The guardian does not recognise the face in the selfie or declines. The recovery session is immediately terminated. No backup is released. No key material is transmitted. The attack ends at the social gate.
→ RECOVERY TERMINATED
🔒
ENCRYPTED
BACKUP
Encrypted Biometric Backup Delivered guardian sandbox → recovering device — E2E encrypted throughout
On guardian approval, the encrypted biometric backup is released from the guardian's app sandbox and transmitted to the recovering device. The backup is end-to-end encrypted: the guardian cannot read it, and Haven does not hold a decryption key. The payload can only be decrypted by a successful biometric match on the recovering device. This is the architectural separation that defeats the colluding guardian attack: approval and decryption are two independent events controlled by different principals.
E2E EncryptedGuardian Cannot Read BackupHaven Holds No Decryption KeyDecryptable Only by Biometric Match on Device
Encrypted Biometric Backup — Payload Structure
Released from guardian sandbox on approval  ·  E2E encrypted in transit  ·  Decryptable only by biometric match on recovering device
The backup is a sealed payload: it holds the biometric reference template and the encrypted private key shard. Neither is accessible without a biometric match on the recovering device. A guardian who approves and retains the payload gains zero exploitable value from it.
Biometric Reference Template
Encrypted — match-only access
Private Key Shard (Web3Auth)
Encrypted — unlocked by match
Guardian Read Access
NULL — cannot decrypt
Haven Read Access
NULL — key not held
Decryption Trigger
Biometric match on device only
In-Flight Encryption
E2E — opaque in transit
The colluding guardian attack is defeated here: a guardian who approves a fraudulent recovery releases an encrypted payload that is useless without the registered owner's biometric on the recovering device.
👁
BIOMETRIC
SCAN
Layer 2 Biometric Scan on-device match against decrypted backup — TEE on new device
The recovering user performs a biometric scan on the new device. This scan is matched against the biometric reference template from the decrypted backup, entirely on-device within the TEE. No biometric data is transmitted at any point. If the person in possession of the device is not the registered owner, recovery is blocked unconditionally — regardless of what was approved at Gate 1. A compromised or coerced guardian cannot complete recovery for an attacker who fails this scan.
On-Device Match — TEEZero Biometric Data TransmittedColluding Guardian Defeated HereOutput: Binary Match Result Only
Colluding Guardian Attack Vector — Structurally Defeated:  If a guardian is compromised or coerced into approving a fraudulent recovery, they release an encrypted payload they cannot read. The attacker receives the backup but cannot decrypt the biometric template or private key shard without the registered owner's biometric on the new device. Corruption of Gate 1 and failure at Gate 2 are independent events — both must be satisfied simultaneously, which is only possible for the registered owner themselves.
GATE 2
BIOMETRIC
MATCH?
TRUE — Owner Confirmed
The biometric scan matches the reference template in the decrypted backup. The private key shard is released. Layer 3 key reconstruction via Web3Auth is authorised. Recovery proceeds to completion.
→ KEY RECONSTRUCTION AUTHORISED
FALSE — Mismatch Blocked
The scan fails. No key shard is released. Recovery is permanently blocked. The guardian approval at Gate 1 is rendered structurally irrelevant. No exception path exists.
→ RECOVERY BLOCKED — NO KEY RELEASED
🔐
KEY
RECONSTRUCT
Layer 3 Key Reconstruction Web3Auth recovery key → private key decrypted → TEE re-bound on new device
With the biometric match confirmed, the Web3Auth recovery key is issued and combined with the decrypted key shard. The full private key is reconstructed and immediately re-bound to the hardware TEE on the new device. The key is never exposed in plaintext. Once bound, the new device operates under the same owner-verification gate architecture as Protocol 01 — every subsequent action requires biometric confirmation from the registered owner.
Web3Auth Key ShardingPrivate Key Never ExposedTEE Re-Bound on New DeviceProtocol 01 Gate Architecture Immediately Active
⓫
WALLET
RECOVERED
Wallet Fully Recovered same owner · new device · no seed phrase · no custodian
The wallet is fully restored on the new device under the registered owner's biometric identity. All balances, history, and settings are intact. The owner-verification gate (Protocol 01) is immediately active — every subsequent action requires biometric confirmation. Recovery completes without the owner ever holding, writing down, or transmitting a seed phrase. Haven's role was notification routing only. No key material passed through Haven's infrastructure at any point.
Full Wallet Access RestoredNo Seed Phrase Required or UsedHaven Held No Key MaterialProtocol 01 Gate Active Immediately
✕
RECOVERY
TERMINATED
Recovery Terminated at Gate 1 guardian denied — no backup released, no key transmitted
The guardian did not confirm the identity of the person in the selfie. The recovery session is terminated immediately. No encrypted backup is released from the guardian sandbox. No key material is transmitted. A failed recovery attempt record is created. There is no escalation path, no support override, and no fallback.
No Backup ReleasedNo Key TransmittedNo Escalation PathFailed Attempt Record Created
🚫
RECOVERY
BLOCKED
Recovery Blocked at Gate 2 biometric mismatch — colluding guardian attack structurally defeated
The biometric scan does not match the reference template. No key shard is released. The backup remains encrypted. Recovery is permanently blocked. The guardian approval at Gate 1 is structurally irrelevant — a coerced or compromised guardian who approved a fraudulent request has provided an attacker with encrypted ciphertext they cannot decrypt. No exception path exists.
No Key Shard ReleasedBackup Remains EncryptedColluding Guardian Attack DefeatedFailed Attempt Record Created
Core Protocol Claim — What Haven Invented
"The patentable invention is the two-gate separation architecture. Gate 1 is social: a human guardian attests the owner's identity via live selfie review. Gate 2 is biometric: the owner must match against an encrypted backup on the new device — a gate the guardian cannot pass for them. Haven invented the architecture in which guardian approval releases a payload that is cryptographically useless without the owner's own biometric, transforming recovery from a single-point-of-failure custodial model into a multi-principal chain of custody where corruption of either gate alone is structurally insufficient."
Protocol Differentiation  ·  Haven vs Industry Standard Recovery
✕  Industry Standard
🔒Seed phrase — single point of failure, phishable, losable, transferable
🔒Custodian-held key — institution is a single attack target
🔒Social recovery: guardian approval alone = full wallet access
🔒No biometric gate on the recovery path itself
🔒Customer support override exists as a structural backdoor
🔒Guardian corruption = wallet compromised
✓  Haven Protocol 03
●No seed phrase — nothing to lose, steal, or phish
●No custodian — Haven holds no key material at any point
●Two independent gates — social approval alone is structurally insufficient
●Biometric gate on new device defeats colluding guardian unconditionally
●No support override, no exception path, no custodian bypass
●Guardian corruption yields encrypted ciphertext — zero exploitable value
Attack Surface Analysis  ·  How Each Vector Is Defeated
Attack Vector 01
Social Engineering the Guardian
Attacker impersonates the owner and attempts to persuade a guardian to approve. Liveness detection flags non-live capture. If the selfie reaches the guardian, visual mismatch triggers denial. Recovery terminated at Gate 1 with no material released.
DEFEATED AT GATE 1 — Liveness check + guardian visual review rejects impersonation
Attack Vector 02
Colluding or Coerced Guardian
A compromised guardian approves a fraudulent recovery. The attacker receives the encrypted backup payload. Without the registered owner's biometric on the new device, the backup cannot be decrypted. Gate 2 blocks recovery regardless of Gate 1 outcome.
DEFEATED AT GATE 2 — Biometric match required; no key shard released without it
Attack Vector 03
Backup Interception in Transit
Attacker intercepts the encrypted backup during transmission. The payload is E2E encrypted and Haven holds no decryption key. Without the registered owner's biometric, the payload is opaque ciphertext. Interception yields nothing actionable.
DEFEATED IN TRANSIT — E2E encryption; biometric match required for decryption
⚙ Patent Protection  ·  USPTO App# 64/032,324
Filed April 7, 2026  ·  Priority date established  ·  Two-gate social-biometric recovery architecture claimed
Haven Holding Company LLC-FZ  ·  Meydan Free Zone, Dubai, UAE
● Haven-Proprietary Protocol
No seed phrase  ·  No custodian  ·  Guardian approval insufficient alone
Social gate + biometric gate — two independent principals required