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

Haven Protocol Stack  /  02 of 03  ·  Haven-Proprietary — Independent of YEO

Dual-Authenticated
Settlement Record (DASR)

A novel protocol combining biometric liveness verification, mutual identity attestation, and cryptographically anchored settlement proof into a single privacy-preserving record. DASR produces verifiable evidence that both parties to any action were verified live humans at the precise moment of execution — not merely that credentials or keys were presented.

Haven-Proprietary.  Vendor-independent  ·  Mutual authentication  ·  24hr acceptance window  ·  Session lineage chain  ·  Three deployment tiers
Stack connection:  DASR is formed by combining two Execution Proof Packets — one from each party (SAO and RAO) — into a single composite settlement record. Protocol 01 proves a single party executed. Protocol 02 proves both parties executed.
⚙
Patent Protection  ·  United States Patent & Trademark Office
USPTO Provisional Application  App# 64/032,311  ·  Filed April 7, 2026  ·  Priority date established  ·  Non-sequential signing also claimed as variant  ·  Full non-provisional in progress
Tier 1 — Authentication
SAO Only
Single-party verified action. No chain anchor. Scenario: compliance officer authorising a large exchange withdrawal — biometric proof that an identity-verified human approved it, not just a device.
Tier 2 — Verified Transaction
SAO + RAO
Bilateral mutual authentication. Optional chain anchor. Scenario: two solicitors executing a property sale contract — both parties verified live at the moment of execution. No "I didn't sign that" dispute possible.
Tier 3 — Insured
SAO + RAO + Anchor
Mandatory on-chain anchor. Scenario: crypto hedge fund sending $2M USDC to an OTC desk — both parties verified, anchor immutable. This satisfies a key underwriting requirement for digital asset insurance models — cryptographic proof of mutual human authorisation at execution.
Sender / SAO
Receiver / RAO
DASR composite / settlement
Verified / complete
Failed / blocked / void
Path A — Haven native
Path B — web session (T1/T2 only)
DASR Protocol Flow  ·  Three Phases  ·  Two Parties
Phase 1  —  Sender Initiation
⚡
ACTION
TRIGGERED
Action Triggered initiating party raises DASR request
An action requiring DASR authorisation is initiated — a payment, contract execution, high-value transfer, or authenticated access event. The Haven interface presents the action details and identity exchange configuration. The sender selects exchange mode: hash-proof only, one-time photo exchange, or retained exchange. The action is queued. Nothing executes yet.
Sender InitiatesExchange Mode SelectedAction Queued
👁
SENDER
LIVENESS
Sender Liveness Verification server-seeded randomised challenge
The sender completes a server-seeded randomised liveness challenge. The Haven server generates a cryptographic random seed and derives the challenge sequence — look left, look right, blink, tilt, return to centre. The sequence is unknown to the device. Motion vectors captured on-device are validated against the session seed. A replay, photo, or deepfake attack cannot satisfy an unknown sequence order. On pass, the SAO is created and held in escrow.
Server-Seeded ChallengeReplay / Deepfake DefeatedSAO Created on Pass
Sender Authentication Object (SAO)  —  Held in Escrow
Biometric Hash
SHA-256 face geometry
Liveness Proof
Session seed ref + motion vectors
Haven Attestation
JWT — signed by Haven
Timestamp
ISO 8601 UTC
Action Reference
Bound to this action only
Session Token
One-time — expires on void
SAO is cryptographically bound to this specific action. It cannot be reused for any other action or session. Only derived authentication signals and attestations are used — no raw biometric data. Held in escrow until RAO received or 24hr window expires.
📤
DASR
DISPATCHED
DASR Session Opened — Receiver Dispatched simultaneous with SAO escrow
The moment the SAO is created and escrowed, the DASR session is opened and the receiver is simultaneously notified. The 24-hour acceptance window begins. The receiver is contacted via push notification (Path A — Haven app user) or a one-time deeplink via email or SMS (Path B — non-Haven user). The dispatch timestamp is logged. The session is now live for both parties independently.
SAO EscrowedReceiver Notified Simultaneously24hr Window OpensSession Token Live
Phase 2  —  Receiver Authentication  (parallel, independent of sender)
⇄
PARALLEL
AUTH
Sender  —  SAO in Escrow
SAO is held in escrow state. The sender’s authentication is complete. The sender waits for the receiver to respond independently within the 24-hour window. The escrowed SAO cannot be reused for any other action during this period.
Awaiting Receiver RAO
Receiver  —  Two Paths
Path A (Haven user): Receives push notification. Opens Haven or Haven Authenticator. Completes native liveness sequence. Full hardware-backed RAO created.

Path B (non-Haven user): Receives one-time deeplink. Opens Haven-hosted web session on mobile browser. Completes liveness via device camera API. Guest RAO created. Limited to Tier 1 & Tier 2 only.
Path A or Path B
Receiver Authentication Object (RAO)  —  Created Independently
Biometric Hash
SHA-256 face geometry
Liveness Proof
Session seed ref + motion vectors
Haven Attestation
JWT — signed by Haven
Timestamp
ISO 8601 UTC
Path Type
A (native) or B (web)
Action Reference
Bound to same action as SAO
RAO is created independently of the SAO. Both AOs reference the same action. Neither party’s biometric data is transmitted to the other party at any point. Path B is limited to Tier 1 and Tier 2.
BOTH AOs
RECEIVED
WITHIN 24HR?
Yes — Both Verified
Both SAO and RAO received and validated within the 24-hour window. Settlement Module activates — composite DASR hash created from cryptographic combination of both Authentication Objects.
→ SETTLEMENT MODULE ACTIVATES
No — Window Expired
24-hour window closes without RAO received. SAO is automatically voided. Session token invalidated. Deeplinks and push notifications expire server-side. A signed void record is created and linked to any successor session.
→ SAO VOIDED — SESSION TERMINATED
🚫
SESSION
VOID
SAO Voided — Session Lineage Record Created expiry path
The SAO is cryptographically voided and cannot be reused. A signed void record is created by Haven at the moment of expiry — immutable, timestamped, and linked to the successor session if the action is retried. This creates a Session Lineage Chain: each new attempt carries a predecessor session reference, a lineage depth count, and all prior failed or expired attempt records. The receiving party of any completed DASR can see how many prior attempts preceded it.
SAO Cryptographically VoidedCannot Be ReusedSigned Void Record CreatedSession Lineage Chain Established
Session Lineage Chain — Patent Claim:  Each new DASR session created after an expiry or block carries a predecessor_session_id, a lineage_depth integer, and a signed record of all prior void events. Failed liveness attempts within a session are logged with rejection reason codes (LIVENESS_FAIL, IDENTITY_MISMATCH, SESSION_EXPIRED, COUNTERPARTY_DECLINED, TIMEOUT). These records are cryptographically signed by Haven at creation — not editable log files. They form a forensic trail of non-authorised or failed attempts that can serve as evidence of unauthorised signature attempts. Haven may publish aggregate blocked-attempt counts as a verified security metric.
Phase 3  —  Settlement, Delivery & Deployment
⚖
SETTLEMENT
MODULE
Settlement Module SAO + RAO combined into DASR composite hash
Haven’s Settlement Module receives both Authentication Objects and combines them into a single DASR composite hash. This hash cryptographically links both authentication events — proving that two specific, identity-verified humans independently authorised the same action. The hash is derived from both AOs plus the action reference. No biometric data enters this computation — only the authentication confirmation signals and attestations.
DASR Composite Hash CreatedBoth AOs Cryptographically LinkedNo Biometric Data in HashHaven-Proprietary
DASR Composite Record  —  Settlement Output
DASR Composite Hash
SHA-256(SAO + RAO + action_ref)
SAO Reference
Sender AO hash + attestation
RAO Reference
Receiver AO hash + attestation
Lineage Depth
0 (first attempt) or N
Failed Attempt Log
Signed records if applicable
Identity Images
NULL unless both consented
DASR composite hash proves mutual human authorisation. Neither party’s raw biometric data is included. Only derived authentication signals, attestations, and action bindings enter this computation. Identity images only present if both parties independently consented.
🔓
IDENTITY
EXCHANGE
Identity Exchange Gate mutual consent required — both parties or neither
Identity is not revealed by default. It is only revealed through mutual, simultaneous consent. If both parties independently consented during their authentication events, their identity images are bundled into the delivery package. If either party declined, no identity is transmitted to either party. There is no asymmetric exchange — both share, or neither shares. Haven prepares simultaneous delivery.
Both Consent or NeitherNo Asymmetric ExchangeSimultaneous Delivery Prepared
📨
PACKAGE
DELIVERED
DASR Package Delivered — Haven Deletes both parties simultaneously, Haven data role ends
The complete DASR package is delivered to both parties simultaneously. Delivery confirmation is logged with timestamp. Following confirmed delivery, Haven deletes all identity images from its systems. Haven retains only the DASR composite hash, attestation references, and the delivery audit log. Haven’s data processing role terminates at delivery. Any party electing to retain the package accepts data controller responsibility for the personal data it contains.
Delivered to Both Parties SimultaneouslyHaven Deletes Photo Data on DeliveryHaven Retains: Hash + Delivery Log OnlyData Controller Handoff at Delivery
TIER
DEPLOYMENT?
Tier 3 — Mandatory On-Chain Anchor
For insured and regulated transactions, the DASR composite hash is anchored on-chain — an immutable, timestamped, publicly verifiable record. Failed attempt records also anchored. Satisfies insurance underwriting requirement. Cannot be altered or deleted by any party.
→ ON-CHAIN ANCHOR — DASR COMPLETE
Tier 1 / Tier 2 — No Anchor Required
Tier 2 may optionally anchor. Tier 1 (SAO only) requires no anchor. DASR package held by the parties. Same proof integrity, no public chain dependency.
→ DASR COMPLETE — PARTIES HOLD RECORD
●
DASR
COMPLETE
DASR Complete mutual human authorisation proven — action executes
The DASR record is complete and the action executes. Both parties now hold a cryptographic proof that two specific, identity-verified, biometrically-confirmed humans independently authorised this specific action at precise timestamps. For Tier 3, this proof is also immutably on-chain. No existing payment, settlement, or contract execution rail provides this record. This is the first time mutual human authorisation has been cryptographically provable at the point of execution.
Action ExecutesMutual Human Authorisation ProvenBoth Parties Hold ProofTier 3: On-Chain Immutable AnchorSatisfies Insurance Underwriting Requirement
✕
ACTION
BLOCKED
Action Blocked liveness fail, identity mismatch, or counterparty declined
The DASR fails to complete. Either the sender’s liveness challenge failed, the receiver’s liveness challenge failed, or one party actively declined the action. The SAO is voided. No DASR composite hash is created. A signed failed attempt record is created with the rejection reason code. This record is included in any successor session lineage chain and may serve as evidence of a non-authorised signature attempt.
No DASR Record CreatedSAO VoidedSigned Failed Attempt Record CreatedLineage Chain Updated
Core Protocol Claim  —  What Haven Invented
"No existing payment, settlement, or contract rail produces cryptographic proof that both parties were verified live humans at the moment of execution. DASR is a novel protocol combining biometric liveness verification, mutual identity attestation, and optional blockchain anchoring into a single privacy-preserving record — without storing any biometric data, without revealing identity unless both parties consent, and without depending on any third-party vendor for its core operation."
Protocol Differentiation  ·  DASR vs Industry
✕  Traditional Payment
Email / password proves device access only
No counterparty verification at execution
No proof sender was live human
No immutable record of mutual intent
Uninsurable — no verified human proof
—  DocuSign / eSign
Email click proves inbox access only
Identity via email — not biometric
No liveness check at signing moment
Record held on DocuSign servers
Suitable for documents, not transfers
—  FIDO2 / Passkeys
Proves device possession — not human identity
Single party only — no mutual proof
No liveness verification layer
No settlement record produced
No chain anchor or insurance path
●  Haven DASR
Biometric liveness proves human presence
Both parties independently verified
Mutual consent-gated identity exchange
Composite hash — self-contained proof
Tier 3: on-chain anchor, satisfies digital asset insurance underwriting requirement
⚙ Patent Protection  ·  USPTO App# 64/032,311
Filed April 7, 2026  ·  Priority date established  ·  Non-sequential signing claimed as variant
Haven Holding Company LLC-FZ  ·  Meydan Free Zone, Dubai, UAE
● Haven-Proprietary Protocol
Vendor-independent  ·  Engine-agnostic  ·  Privacy-preserving by architecture
No biometric data stored  ·  No identity without mutual consent