Product Documentation  /  Live App Architecture

Haven App
User Authorisation Flow

The end-to-end authorisation process inside the Haven Wallet as it operates today. From session start to action execution — every step, every decision gate, every outcome.

Scope:  Live app behaviour only  ·  YEO CFR SDK = biometric engine component  ·  Authorisation decision stays on-device  ·  No credential transmitted
Standard step
Active / processing
Verified / permitted
Failed / blocked
YEO CFR SDK component
Authorisation Flow  ·  Step by Step
📱
SESSION
START
App Launch User opens Haven Wallet
The user opens the Haven Wallet on their device. The app loads the secure session environment. No network call is made at this point — the authorisation process is entirely local from start to finish.
Local OnlyNo Server ContactNo Credential Required
👁
BIOMETRIC
ENGINE
Biometric Engine Activates YEO CFR SDK initialises
The YEO Continuous Facial Recognition SDK activates and accesses the device camera. It loads the user’s enrolled facial hash from the device’s hardware-secure storage (Secure Enclave on iOS / TrustZone on Android). The original enrolment image was discarded at setup — only the encrypted hash was retained.
YEO CFR SDKHardware-Secure HashNo Raw Biometric Stored
YEO CFR SDK component:  Patented Continuous Facial Recognition engine licensed exclusively to Haven for the crypto wallet and blockchain sector. Performs liveness detection, deepfake resistance, anti-spoof analysis. Outputs a single binary signal — TRUE or FALSE.
🔄
CONTINUOUS
CHECK
Continuous Verification Runs throughout the session
The CFR engine checks multiple times per second. Each check compares the live camera feed to the enrolled hash using liveness detection. Verification is not a one-time login check — it runs continuously for the entire session. The moment presence cannot be confirmed, the session status changes immediately.
YEO CFR SDKMultiple checks/secondDeepfake ResistantReplay Attack ResistantContinuous — Not One-Time
OWNER
VERIFIED?
Yes — Owner Confirmed
The CFR engine confirms the registered owner is present. The device issues a local authorisation signal. The wallet session remains active. No data leaves the device at any point.
→ SESSION ACTIVE
No — Verification Fails
Wrong face, spoof attempt, device moved, or owner absent. Session is terminated instantly. All pending actions are cancelled.
→ SESSION TERMINATED
ACTION
INITIATED
User Initiates Action Transfer, swap, or sensitive operation
Within the active verified session, the user initiates an action — a crypto transfer, fiat transfer, or wallet configuration change. The action is queued but not executed. A second authorisation check is triggered at the point of action to confirm the owner is still present at the moment of execution.
Action Queued — Not ExecutedSecond Verification TriggeredContinuous Auth Still Running
🛡
ACTION
GATE
Live Action Verification Biometric confirmation at the moment of execution
At the exact moment the user confirms the action, the CFR engine performs a synchronous verification check. This ensures the registered owner is present at execution — not just at session start. A stolen device with an open session cannot execute actions if the owner is no longer in front of the camera.
YEO CFR SDKSynchronous Check at ExecutionOwner Must be Present NowOpen Session Provides No Bypass
ACTION
PERMIT?
Permitted — Owner at Execution
Point-of-action verification passes. The owner is confirmed present at the moment of signing. The app proceeds to execute the action using the device’s hardware-secured key.
→ PROCEED TO EXECUTION
Blocked — Owner Not Confirmed
Verification fails at execution moment. Action is cancelled before signing. No transaction is submitted. Wallet state is unchanged.
→ ACTION CANCELLED
EXECUTE
Action Executed Hardware-key signing — verified path only
With both the session verification and point-of-action verification passed, the app executes the action. The transaction is signed using the private key held in the device’s hardware-secure storage (TEE). The key is inaccessible to the OS, other apps, and Haven. The signed transaction is broadcast to the network. The session continues — continuous verification keeps running.
Action ExecutedHardware TEE Key SigningTransaction BroadcastContinuous Auth ContinuesKey Never Exposed
BLOCKED
Action Blocked No credential fallback — no override
The action is cancelled immediately. No transaction is signed. No wallet state changes. There is no PIN entry option, no password fallback, no seed phrase recovery path, no override mechanism. The only way to proceed is for the registered owner to be present and verified by the CFR engine.
No Transaction SignedNo PIN FallbackNo Password OverrideNo Seed Phrase BypassReturns to Wallet Home
Architecture Principle — Live App
“The authorisation decision never leaves the device. There is no server that grants or denies access. The registered owner’s presence — verified continuously by the biometric engine — is the only mechanism that permits action.”