diff --git a/mobile-app/docs/Quests Functional Spec.md b/mobile-app/docs/Quests Functional Spec.md
new file mode 100644
index 00000000..660706f8
--- /dev/null
+++ b/mobile-app/docs/Quests Functional Spec.md	
@@ -0,0 +1,384 @@
+# Quests - Functional Specification
+
+This document defines **what** the Quests feature must do, not **how** to implement it. A designer can use this to create new UI/UX patterns while ensuring all functionality is preserved.
+
+---
+
+## Overview
+
+The Quests feature is a reward/gamification system that incentivizes user engagement through:
+- Participation in a reward program
+- Social account linking (X/Twitter, Ethereum)
+- Referral tracking
+- Social media engagement tasks ("raids")
+- Activity tracking (sends, reversals, mining)
+
+---
+
+## Core Concepts
+
+### Reward Program
+Users must explicitly opt-in to participate. Once opted in, they receive a queue position number that represents their place in the reward distribution.
+
+### Account Associations
+Users can link external accounts to their wallet for verification and reward eligibility:
+- **X (Twitter) Account** - Verified via posting requirement
+- **ETH Address** - For potential cross-chain rewards
+
+### Quests
+Time-limited or ongoing tasks that earn points/rewards:
+- **Referrals** - Invite others to join
+- **King of the Shill (Raids)** - Engage with specific social media content
+
+---
+
+## Functions
+
+### F1. Check Reward Program Status
+**Goal:** Determine if user has opted into the reward program
+
+**Inputs:** None (uses authenticated wallet)
+
+**Outputs:**
+- Boolean: is participant or not
+- If participant: queue position number
+
+**Used to:** Gate access to quests features; show opt-in flow for non-participants
+
+---
+
+### F2. Opt-In to Reward Program
+**Goal:** User joins the reward program
+
+**Inputs:**
+- Confirmation (user intent)
+
+**Outputs:**
+- Success/failure status
+- Queue position number (on success)
+
+**Constraints:**
+- One-time action (cannot opt out once in)
+- Requires wallet to be set up
+
+---
+
+### F3. View Queue Position (removed, not needed)
+**Goal:** User sees their position in the reward queue
+Note: Let's ditch this. Not needed.
+---
+
+### F4. View Account Associations Status
+**Goal:** User sees which external accounts are linked
+
+**Inputs:** None
+
+**Outputs:**
+- ETH Address: linked/not linked (+ address if linked)
+- X Account: linked/not linked (+ username if linked)
+
+**Navigation:** Should allow user to manage associations
+
+---
+
+### F5. Link ETH Address
+**Goal:** User associates an Ethereum address with their wallet
+
+**Inputs:**
+- ETH address (0x... format)
+
+**Outputs:**
+- Success/failure status
+- Error message if invalid or already used
+
+**Validation:**
+- Must be valid ETH address format
+
+---
+
+### F6. Update ETH Address
+**Goal:** User changes their linked ETH address
+
+**Inputs:**
+- New ETH address
+
+**Outputs:**
+- Success/failure status
+
+**Constraints:**
+- Replaces existing association
+
+---
+
+### F7. Remove ETH Address
+**Goal:** User unlinks their ETH address
+
+**Inputs:**
+- Confirmation
+
+**Outputs:**
+- Success/failure status
+
+---
+
+### F8. Link X Account
+**Goal:** User verifies ownership of an X (Twitter) account
+
+**Inputs:**
+- X handle/username
+- Verification post URL (proof of ownership)
+
+**Outputs:**
+- Success/failure status
+- Error message if verification fails
+
+**Verification Process:**
+Verification happens on the backend. UX can focus on just input. 
+1. User provides their X handle
+2. User must have @QuantusNetwork mentioned in their bio
+3. User must post a specific message from that account
+4. User provides URL to that post
+5. System verifies post exists and matches handle
+
+**Constraints:**
+- Post URL must match the provided handle
+- Post must contain required verification content
+
+---
+
+### F9. Remove X Account
+**Goal:** User unlinks their X account
+
+**Inputs:**
+- Confirmation
+
+**Outputs:**
+- Success/failure status
+
+---
+
+### F10. View Activity Stats
+**Goal:** User sees their engagement statistics
+
+**Inputs:** None
+
+**Outputs:**
+- Referral count (people who joined using their code)
+- Send count (transactions sent)
+- Reversal count (transactions reversed)
+- Mining count (blocks mined, if applicable)
+
+**Refresh:** Should support manual refresh
+
+---
+
+### F11. Get My Referral Code
+**Goal:** User retrieves their unique referral code
+
+**Inputs:** None
+
+**Outputs:**
+- Referral code (human-readable checkphrase format, e.g., "word word word word word")
+
+**Note:** Derived from wallet address, always the same for a given wallet
+
+---
+
+### F12. Share Referral
+**Goal:** User shares their referral link with others
+
+**Inputs:** None
+
+**Outputs:**
+- Pre-formatted share text including:
+  - Referral code
+  - Download link
+  - Promotional message
+- System share sheet triggered
+
+---
+
+### F13. Copy Referral Code
+**Goal:** User copies just the referral code
+
+**Inputs:** None
+
+**Outputs:**
+- Referral code copied to clipboard
+- Confirmation feedback
+
+---
+
+### F14. View Active Raids
+**Goal:** User sees available raid quests (King of the Shill)
+
+**Inputs:** None
+
+**Outputs:**
+- List state:
+  - Active raid available / not available - details are not shown, what to raid appears in the Telegram group
+  - There could be an explanation of this?
+  - No active raid: show "no active raid" message
+  - X not linked: prompt to link X account first
+
+**Constraints:**
+- Requires X account to be linked to participate
+
+---
+
+### F15. Submit Raid Entry
+**Goal:** User submits proof of raid participation
+
+**Inputs:**
+- Reply tweet URL (link to user's reply on raid target)
+
+**Outputs:**
+- Success/failure status
+- Updated submission list
+
+**Validation:**
+- Must be valid X status URL format
+- URL must be from user's linked X account
+
+---
+
+### F16. View My Raid Submissions
+**Goal:** User sees their submitted raid entries
+
+**Inputs:** None
+
+**Outputs:**
+- List of submissions showing:
+  - Tweet ID or link
+  - Submission status (if applicable)
+
+---
+
+### F17. Remove Raid Submission
+**Goal:** User removes a submitted raid entry
+
+**Inputs:**
+- Submission ID/tweet ID
+- Confirmation
+
+**Outputs:**
+- Success/failure status
+- Updated submission list
+
+---
+
+### F18. View Submitted Referral Code
+**Goal:** User sees if they used someone else's referral code
+
+**Inputs:** None
+
+**Outputs:**
+- Referral code used (if any)
+- "Not submitted" state if none
+
+**Note:** This is the code the user entered when they joined, not their own code
+
+---
+
+## User States
+
+The quests feature has several distinct user states that affect what is shown:
+
+### State 1: Not Opted In
+- Show opt-in promotional content (video/info)
+- Show "I'm In" / opt-in action
+- No access to quests functionality
+
+### State 2: Opted In, No Associations
+- Show queue position
+- Show association status (both unlinked)
+- Prompt to link accounts
+- Show quests list (some may be locked)
+
+### State 3: Opted In, Partial Associations
+- Show queue position
+- Show association status (partial)
+- Show quests list
+- Some quests may require specific associations
+
+### State 4: Opted In, Fully Associated
+- Show queue position
+- Show association status (all linked)
+- Full access to all quests
+
+---
+
+## Data Dependencies
+
+| Function | Requires |
+|----------|----------|
+| F2-F18 | Opted into reward program |
+| F8, F14-F17 | X account linked (for raids) |
+| F14-F17 | Active raid available (time-limited) |
+
+---
+
+## Error States
+
+Each function should handle:
+- Network errors (API unreachable)
+- Authentication errors (session expired)
+- Validation errors (invalid input)
+- Conflict errors (already exists, already submitted)
+
+---
+
+## Refresh Behavior
+
+- **Manual refresh:** Pull-to-refresh on main quests view
+- **Auto refresh:** On app resume from background
+- **After actions:** Refresh relevant data after submissions/updates
+
+---
+
+## External Links
+
+The feature should support opening external resources:
+- "Learn more" links to documentation pages
+- X app/website for posting and verification
+- Raid target tweets (for context)
+
+---
+
+## Summary of Functions
+
+| ID | Function | Category |
+|----|----------|----------|
+| F1 | Check Reward Program Status | Core |
+| F2 | Opt-In to Reward Program | Core |
+| F3 | View Queue Position | Display |
+| F4 | View Account Associations Status | Display |
+| F5 | Link ETH Address | Association |
+| F6 | Update ETH Address | Association |
+| F7 | Remove ETH Address | Association |
+| F8 | Link X Account | Association |
+| F9 | Remove X Account | Association |
+| F10 | View Activity Stats | Display |
+| F11 | Get My Referral Code | Referral |
+| F12 | Share Referral | Referral |
+| F13 | Copy Referral Code | Referral |
+| F14 | View Active Raids | Raids |
+| F15 | Submit Raid Entry | Raids |
+| F16 | View My Raid Submissions | Raids |
+| F17 | Remove Raid Submission | Raids |
+| F18 | View Submitted Referral Code | Referral |
+
+---
+
+## Design Considerations
+
+When redesigning the quests UI, consider:
+
+1. **Progressive disclosure** - Don't overwhelm new users; reveal complexity as they engage
+2. **Clear status indicators** - User should always know their current state
+3. **Actionable prompts** - Make it clear what steps to take next
+4. **Feedback loops** - Immediate feedback on actions (success/error)
+5. **Gamification elements** - Make progress feel rewarding
+6. **Mobile-first** - Most users will access via mobile app
+
+The current implementation spreads these functions across multiple screens. A redesign could consolidate or reorganize based on user journey analysis.
diff --git a/mobile-app/docs/User Flows Abstract.md b/mobile-app/docs/User Flows Abstract.md
new file mode 100644
index 00000000..4aa3feb9
--- /dev/null
+++ b/mobile-app/docs/User Flows Abstract.md	
@@ -0,0 +1,576 @@
+# Quantus Wallet - Functional Requirements (Abstract)
+
+This document defines **what** the wallet must do, not **how** to implement it. Each capability describes the user's goal, required inputs, and expected outputs. UI designers and developers can implement these capabilities using any screen flow or interaction pattern that best serves the user experience.
+
+Numbers correspond to the Implementation spec for cross-reference.
+
+---
+
+## 1. Create Wallet
+**Goal:** User establishes a new wallet from scratch
+
+**User Inputs:**
+- Account name (optional, can default)
+
+**Wallet Outputs:**
+- Generated 24-word recovery phrase
+- Derived account address
+- Human-readable checkphrase (address verification aid)
+
+**Constraints:**
+- Phrase stored securely on device
+
+---
+
+## 2. Import Wallet
+**Goal:** User restores access to existing wallet using recovery phrase
+
+**User Inputs:**
+- Recovery phrase (12 or 24 words)
+
+**Wallet Outputs:**
+- Derived account address(es)
+- Discovered on-chain accounts with balances
+
+**Constraints:**
+- Must validate phrase format before proceeding
+- Should discover all derived accounts with on-chain activity
+
+---
+
+## 3. Send (Immediate)
+**Goal:** User transfers funds to another address with immediate finality
+
+**User Inputs:**
+- Recipient address
+- Amount
+
+**Wallet Outputs:**
+- Chain Fee (shown before send, not adjustable)
+- Transaction submitted to chain
+- Transaction hash
+- Updated pending balance
+
+**Async Resolution:**
+- Transaction status: pending → confirmed/failed
+- Typical confirmation: 20 seconds to several minutes
+
+---
+
+## 4. Send (Reversible)
+**Goal:** User transfers funds with a cancellation window
+
+**User Inputs:**
+- Recipient address
+- Amount
+- Reversibility duration
+
+**Wallet Outputs:**
+- Chain Fee (shown before send, not adjustable)
+- Transaction submitted to chain
+- Transaction ID (for cancellation)
+- Scheduled execution time
+- Funds locked during reversibility window, deducted at send
+- Free balance is changed immediately, changed back if transfer is reversed
+
+**Async Resolution:**
+- Status: pending → scheduled → executed/cancelled/failed
+- Countdown timer until execution
+
+---
+
+## 5. Cancel Reversible Transfer
+**Goal:** User cancels an outgoing reversible transfer before execution
+
+**User Inputs:**
+- Transaction selection
+- Confirmation
+
+**Wallet Outputs:**
+- Cancellation submitted to chain
+- Funds returned to sender
+
+**Constraints:**
+- Only possible while countdown is active
+- An account can only cancel their own transfer, not another account's transfer
+- Cannot cancel after execution
+
+---
+
+## 6. Receive
+**Goal:** User shares their address to receive incoming funds
+
+**User Inputs:** None
+
+**Wallet Outputs:**
+- QR code of address
+- Copyable address
+- Copyable checkphrase
+- Shareable link/text
+
+---
+
+## 7. Enable High Security
+**Goal:** User activates theft deterrence on an account (permanent)
+
+**User Inputs:**
+- Guardian account address
+- Safeguard window duration (mandatory delay for all future sends)
+- Confirmation (acknowledging irreversibility)
+
+**Wallet Outputs:**
+- High security configuration submitted to chain
+- Account permanently marked as high-security
+
+**Constraints:**
+- Cannot be disabled once enabled
+- All future sends from this account must use the safeguard window
+- Requires sufficient balance for transaction fee
+
+---
+
+## 8. Intercept Transaction (Guardian)
+**Goal:** Guardian pulls funds from a pending transfer on an entrusted account
+
+**User Inputs:**
+- Transaction selection (select entrusted reversible transaction)
+- Confirmation
+
+**Wallet Outputs:**
+- Interception submitted to chain
+- Funds transferred to guardian account
+- Original transaction cancelled
+
+**Constraints:**
+- Only guardian account can intercept
+- Only during reversibility window
+
+---
+
+## 9. View Recovery Phrase
+**Goal:** User retrieves their recovery phrase for backup purposes
+
+**User Inputs:**
+- Wallet selection (if multiple wallets exist)
+
+**Wallet Outputs:**
+- Recovery phrase (12 or 24 words)
+
+**Constraints:**
+- Should require explicit user action to reveal (not shown by default)
+- Could require biometrics auth
+- Copy functionality required
+
+---
+
+## 10. Enable Device Authentication 
+**Goal:** User secures app access with biometrics/PIN
+
+**User Inputs:**
+- Enable toggle or could be always on (no user choice)
+- Biometric/PIN verification
+
+**Wallet Outputs:**
+- Authentication requirement saved locally
+
+**Constraints:**
+- Could be done in settings or else just at app start without option to not do it.
+
+---
+
+## 10a. Configure Authentication Timeout (optional)
+**Goal:** User sets how long before re-authentication is required
+
+**User Inputs:**
+- Timeout selection (immediate, 1min, 5min, 15min, 30min, 1hr)
+
+**Wallet Outputs:**
+- Timeout preference saved locally
+
+**Note:** Could also leave this out and just set to a reasonable default value.
+
+---
+
+## 10b. Disable Device Authentication (optional)
+**Goal:** User removes biometric/PIN requirement
+
+**User Inputs:**
+- Disable toggle
+- Current authentication verification
+
+**Wallet Outputs:**
+- Authentication requirement removed
+
+**Note:** This may not be offered - authentication could be mandatory.
+
+---
+
+## 11. Submit Referral Code
+**Goal:** New user links to a referrer for rewards
+
+**User Inputs:**
+- Referral code (5-word phrase or prefilled from deep link)
+
+**Wallet Outputs:**
+- Referral recorded on backend
+- Confirmation of submission
+
+---
+
+## 12. Opt-In to Reward Program
+**Goal:** User joins the rewards/quests program
+
+**User Inputs:**
+- Opt-in confirmation
+
+**Wallet Outputs:**
+- Participation status
+- Queue position number
+
+---
+
+## 13. Manage Accounts (overview)
+**Goal:** User manages their accounts and wallets
+
+This section covers multiple related capabilities for account/wallet management.
+
+---
+
+## 13a. Add Wallet
+**Goal:** User adds another wallet (when they already have one)
+
+**User Inputs:**
+- Choice: create new or import existing
+- If create: account name (optional)
+- If import: recovery phrase (12 or 24 words)
+
+**Wallet Outputs:**
+- New wallet added with its own mnemonic
+- First account derived from new wallet
+- Account address and checkphrase
+
+**Note:** This is different from flow #1 (Create Wallet) which is for first-time users. This flow is accessed from account management when user already has a wallet.
+
+---
+
+## 13b. Add Account
+**Goal:** User creates a new account derived from an existing wallet
+
+**User Inputs:**
+- Account name
+
+**Wallet Outputs:**
+- New account address (derived from wallet mnemonic using next index)
+- Human-readable checkphrase
+
+**Constraints:**
+- Account derived using standard derivation path
+- Requires existing wallet with stored mnemonic
+
+---
+
+## 13c. Switch Account
+**Goal:** User changes which account is currently active for transactions
+
+**User Inputs:**
+- Account selection
+
+**Wallet Outputs:**
+- Active account changed
+- UI reflects new account's balance/history
+
+---
+
+## 13d. Edit Account
+**Goal:** User modifies account metadata
+
+**User Inputs:**
+- New account name
+
+**Wallet Outputs:**
+- Updated account name stored locally
+
+---
+
+## 13e. View Account Details
+**Goal:** User sees full information about an account
+
+**User Inputs:**
+- Account selection
+
+**Wallet Outputs:**
+- Account name
+- Full address
+- Human-readable checkphrase
+- Current balance
+- Account type/tags (High Security, Guardian, Entrusted, Hardware)
+
+---
+
+## 14. Add Hardware Wallet
+**Goal:** User connects an external signing device (e.g., Keystone)
+
+**User Inputs:**
+- QR code scan from hardware device
+- Account name
+
+**Wallet Outputs:**
+- Hardware account address added
+- Account marked as hardware-signed
+
+**Constraints:**
+- Transactions require QR-based signing workflow
+- Private keys never touch the app
+
+---
+
+## 14a. Remove Hardware Account
+**Goal:** User disconnects a hardware wallet account
+
+**User Inputs:**
+- Confirmation
+
+**Wallet Outputs:**
+- Account removed from local storage
+
+---
+
+## 15. View Transaction History
+**Goal:** User sees their transaction history
+
+**User Inputs:**
+- Optional: account filter
+- Optional: transaction type filter
+
+**Wallet Outputs:**
+- List of transactions showing:
+  - Type (send/receive/reward)
+  - Amount
+  - Counterparty
+  - Status (pending/confirmed/failed/scheduled/executed/cancelled)
+  - Timestamp
+  - For reversible: remaining time
+
+**Async Updates:**
+- Background refresh (typically 60 seconds)
+- Aggressive refresh for pending/reversible items
+
+---
+
+## 16. View Transaction Details
+**Goal:** User sees complete information about a specific transaction
+
+**User Inputs:**
+- Transaction selection
+
+**Wallet Outputs:**
+- Full amount
+- Counterparty address and checkphrase
+- Transaction status
+- Transaction hash
+- Block explorer link
+- For reversible: countdown timer
+- For failed: error message
+
+---
+
+## 17. Retry Failed Transaction
+**Goal:** User resubmits a transaction that previously failed
+
+**User Inputs:**
+- Failed transaction selection
+
+**Wallet Outputs:**
+- New transaction submitted with same parameters
+- New transaction hash
+
+---
+
+## 18. Configure Notification Preferences
+**Goal:** User manages which notifications they receive.
+
+**User Inputs:**
+- Toggle for each notification type:
+  - Transaction failures
+  - Low balance alerts
+  - Reversible transaction reminders
+  - Incoming transactions
+
+**Wallet Outputs:**
+- Preferences saved locally
+
+---
+
+## 18a. View Notifications
+**Goal:** User sees their notification history
+
+**User Inputs:**
+- Optional: account filter
+
+**Wallet Outputs:**
+- List of notifications with:
+  - Type/severity
+  - Message
+  - Timestamp
+  - Related account
+- Ability to dismiss individual/all
+
+---
+
+## 19. Share/Invite Others
+**Goal:** User invites others to earn referral rewards
+
+**User Inputs:** None
+
+**Wallet Outputs:**
+- Shareable text with referral code/link
+- System share sheet
+
+---
+
+## 20. Reset Wallet
+**Goal:** User removes all wallet data from device
+
+**User Inputs:**
+- Explicit confirmation and warning
+- Possibly prompt to securely store the mnemonic
+
+**Wallet Outputs:**
+- All local data cleared
+- Return to initial/onboarding state
+
+**Constraints:**
+- Must warn user this is irreversible
+- Must require deliberate confirmation (prevent accidental reset)
+
+---
+
+## Additional Capabilities
+
+### View Reward Status
+**Goal:** User checks their reward program standing
+
+**User Inputs:** None
+
+**Wallet Outputs:**
+- Opt-in position
+- Associated accounts
+- Available quests
+- Quest completion status
+
+---
+
+### View High Security Configuration
+**Goal:** User views their high security settings
+
+**User Inputs:**
+- Account selection
+
+**Wallet Outputs:**
+- Guardian account address
+- Safeguard window duration
+- List of entrusted accounts (if guardian)
+
+---
+
+## System Capabilities (not direct user flows)
+
+### Fee Estimation (on any chain transaction)
+**Goal:** System calculates network fee before user confirms transaction
+
+**Inputs:**
+- Recipient address
+- Amount
+- Transfer type (immediate/reversible)
+- Reversibility duration (if applicable)
+
+**Outputs:**
+- Estimated fee amount
+- Current block height (for transaction validity)
+
+**Constraints:**
+- Must recalculate when inputs change
+- Fee may change between estimate and submission
+
+---
+
+### Address Validation
+**Goal:** Verify a recipient address is valid before sending
+
+**Inputs:**
+- Address string
+
+**Outputs:**
+- Valid/invalid status
+- Human-readable checkphrase (if valid)
+
+---
+
+### View Balance
+**Goal:** User sees their current funds
+
+**Inputs:**
+- Account selection
+
+**Outputs:**
+- Total balance
+- Available balance (accounting for pending outgoing)
+- Locked/reserved balance (if any)
+
+**Async Updates:**
+- Background polling
+- Immediate optimistic updates after transactions
+
+---
+
+## Common Async Patterns
+
+All chain transactions follow this lifecycle:
+
+1. **Submission:** Transaction sent to network
+2. **Pending:** Awaiting block inclusion (optimistic UI update)
+3. **In Block:** Included in block, awaiting finalization
+4. **Confirmed/Failed:** Final state reached
+
+**Timing:**
+- Block inclusion: typically 20 seconds to several minutes
+- Reversible execution: user-defined delay
+- Background sync: 60-second intervals
+- Active transaction tracking: 10-second intervals
+- Reversible execution detection: 5-second intervals near deadline
+
+**Optimistic Updates:**
+- Balance reduced immediately on send
+- Transaction appears in history immediately
+- Reverted on failure
+
+---
+
+## Data Persistence Summary
+
+| Data | Storage | Notes |
+|------|---------|-------|
+| Recovery phrase | Secure local storage | Encrypted |
+| Account metadata | Local storage | Names, derivation indices |
+| Authentication settings | Local storage | Biometric preferences |
+| Notification preferences | Local storage | |
+| Transaction history | Chain (via indexer) | Fetched on demand |
+| Pending transactions | Local + chain | Reconciled on sync |
+| High security config | Chain | Permanent once set |
+| Referral data | Backend | API-based |
+
+---
+
+## External Integrations
+
+| Integration | Purpose |
+|-------------|---------|
+| Blockchain RPC | Transaction submission, balance queries |
+| Subsquid/Indexer | Transaction history, account discovery |
+| Block Explorer | Transaction detail links |
+| Backend API | Referrals, rewards program |
+| Deep Links | Referral codes, address sharing |
+
+---
+
+This specification defines the functional requirements without prescribing UI patterns. Implementers should design flows that best serve their users while ensuring all inputs are collected and outputs are properly displayed.
diff --git a/mobile-app/docs/User Flows Implementation.md b/mobile-app/docs/User Flows Implementation.md
new file mode 100644
index 00000000..c832465f
--- /dev/null
+++ b/mobile-app/docs/User Flows Implementation.md	
@@ -0,0 +1,616 @@
+# Quantus Wallet User Flows
+
+## 1. Create New Wallet
+
+**Intention:** First-time user wants to create a new wallet and account
+
+**User Flow:**
+1. User opens app and lands on Welcome Screen
+2. User taps "Create New Wallet"
+3. System generates a 12-word mnemonic phrase
+4. User inputs account name (defaults to "Account 1")
+5. User sees checkphrase and account address displayed
+6. User can tap "Show Recovery Phrase" to view and optionally copy the mnemonic
+7. User taps "Create Wallet"
+8. System saves mnemonic to secure storage
+9. User is navigated to home screen with optional referral prompt
+
+**Data In:**
+- Account name (user input)
+
+**Data to Chain:**
+- None (local wallet creation only)
+
+**Data Out:**
+- Mnemonic phrase (generated, stored locally)
+- Account address (derived from mnemonic)
+- Human-readable checkphrase (derived from address)
+
+**Pending States:** None - this is a local operation
+
+---
+
+## 2. Import Wallet
+
+**Intention:** User wants to restore an existing wallet from recovery phrase
+
+**User Flow:**
+1. User taps "Import Wallet" from Welcome Screen
+2. User enters 12 or 24 word recovery phrase
+3. User taps "Import Wallet"
+4. System validates mnemonic format
+5. System discovers existing accounts on-chain (account discovery)
+6. System shows "Discovering existing accounts..." loading state
+7. User is navigated to home screen
+
+**Data In:**
+- Recovery phrase (12 or 24 words)
+
+**Data to Chain:**
+- None
+
+**Data Out:**
+- Account address(es) derived from phrase
+- Discovered accounts with balances (queried from chain)
+
+**Pending States:** Account discovery queries the chain but is not a transaction
+
+---
+
+## 3. Send (Immediate)
+
+**Intention:** User wants to send coins immediately without reversibility window
+
+**User Flow:**
+1. User taps Send from home screen
+2. User inputs destination address (via typing, paste, scan QR, or recent addresses)
+3. System validates address and displays human-readable checkphrase
+4. User inputs amount
+5. User can tap "Max" to auto-fill maximum sendable amount
+6. User selects "Now" in reversibility selector
+7. System fetches network fee estimate
+8. User taps send button
+9. Confirmation sheet appears showing: amount, recipient checkphrase, recipient address, network fee
+10. User taps "Confirm"
+11. Progress state shown with "TRANSACTION IN PROGRESS"
+12. Completion state shown with "SENDING" and done button
+13. User returns to home screen
+
+**Data In:**
+- Recipient address
+- Amount (BigInt)
+- Selected reversibility mode (none)
+
+**Data to Chain:**
+- Balances.transferKeepAlive extrinsic with:
+  - Recipient address
+  - Amount
+
+**Data Out:**
+- Transaction hash (extrinsic hash)
+- Estimated fee (pre-submission)
+
+**Pending States:**
+- Transaction appears in pending transactions list immediately after submission
+- Status: `created` → `inBlock` → `confirmed` (or `failed`)
+- Typically takes 20 seconds to a few minutes for block inclusion
+- Balance is optimistically reduced by amount + fee immediately
+- History polling service monitors for confirmation (10s intervals for inBlock tracking)
+
+---
+
+## 4. Send (Reversible)
+
+**Intention:** User wants to send coins with a reversibility window during which they can cancel
+
+**User Flow:**
+1. User taps Send from home screen
+2. User inputs destination address
+3. System validates address and displays human-readable checkphrase
+4. User inputs amount
+5. User selects reversible time duration (e.g., "10 min", can tap to edit)
+6. Time picker sheet allows: days (0-7), hours (0-23), minutes (0-59)
+7. System fetches network fee estimate for reversible transfer
+8. User taps send button
+9. Confirmation sheet shows: amount, recipient, network fee, "Reversible for: X hours, Y minutes"
+10. User taps "Confirm"
+11. Progress → Complete states
+12. Transaction appears in history with countdown timer
+
+**Data In:**
+- Recipient address
+- Amount
+- Reversibility duration (seconds)
+
+**Data to Chain:**
+- QpScheduler.scheduleReversibleTransfer extrinsic with:
+  - Recipient address
+  - Amount
+  - Delay (as timestamp offset)
+
+**Data Out:**
+- Transaction ID (for cancellation)
+- Extrinsic hash
+- Scheduled execution time
+
+**Pending States:**
+- Transaction appears immediately in pending state
+- After block inclusion: shows as "SCHEDULED" reversible transfer
+- Countdown timer displays remaining time until execution
+- Status flow: `created` → `inBlock` → `SCHEDULED` → `EXECUTED` (or `CANCELLED`)
+- Aggressive polling (5s) when timer approaches zero
+
+---
+
+## 5. Reverse/Cancel Transaction
+
+**Intention:** User wants to cancel a reversible transaction before it executes
+
+**User Flow:**
+1. User taps on a reversible transaction in history (with active countdown)
+2. Reversible Transaction Action Sheet appears showing:
+   - Remaining time countdown
+   - Recipient details
+   - Amount
+3. User taps "Reverse" button
+4. Confirmation prompt: "Are you sure you want to reverse this tx?"
+5. User taps "Reverse" again to confirm
+6. System submits cancellation
+7. UI updates to show "Transaction Reversed"
+
+**Data In:**
+- Transaction ID (hex encoded)
+
+**Data to Chain:**
+- QpScheduler.cancelReversibleTransfer extrinsic with:
+  - Transaction ID
+
+**Data Out:**
+- Updated transaction status (CANCELLED)
+
+**Pending States:**
+- Cancellation submission is immediate
+- UI optimistically updates status to CANCELLED
+- Background polling confirms final status
+- Funds return to sender's available balance
+
+---
+
+## 6. Receive
+
+**Intention:** User wants to share their address to receive coins
+
+**User Flow:**
+1. User taps Receive from home screen
+2. Receive sheet displays:
+   - QR code of account address
+   - Account name with gradient icon
+   - Human-readable checkphrase (copyable)
+   - Full address (copyable, chunked for readability)
+3. User can tap copy icons to copy address or checkphrase
+4. User can tap "Share Wallet" to open system share sheet
+5. Share includes: address, checkphrase, and deep link URL
+
+**Data In:** None
+
+**Data to Chain:** None
+
+**Data Out:**
+- Account address (displayed/shared)
+- Checkphrase (displayed/shared)
+- Share link: `{websiteBaseUrl}/account?id={accountId}`
+
+**Pending States:** None - display only
+
+---
+
+## 7. Enable High Security
+
+**Intention:** User wants to enable theft deterrence features on an account (irreversible)
+
+**User Flow:**
+1. User navigates to Account Settings → High Security
+2. High Security Get Started screen explains the feature
+3. System checks balance for fee requirement
+4. User taps "Start"
+5. **Step 1 - Guardian Account:** User inputs guardian address (paste/scan QR)
+6. System validates address and shows checkphrase
+7. User taps "Next"
+8. **Step 2 - Safeguard Window:** User selects delay time (days, hours, minutes)
+9. This sets the mandatory reversibility window for all future sends
+10. User taps "Next"
+11. **Step 3 - Summary:** Shows high security account, guardian account, safeguard window
+12. User taps "Next"
+13. **Confirmation sheet** with warning: "Once enabled, this cannot be undone"
+14. User taps "Confirm"
+15. Transaction submitted to chain
+16. Success sheet shown with "High Security Enabled"
+
+**Data In:**
+- Guardian account address
+- Safeguard window duration (seconds)
+
+**Data to Chain:**
+- HighSecurity.enableHighSecurity extrinsic with:
+  - Guardian address
+  - Safeguard window (as duration)
+
+**Data Out:**
+- High security configuration stored on-chain
+- Account now flagged as high-security
+
+**Pending States:**
+- Submission pending → confirmed
+- Once confirmed, all future sends from this account must use the safeguard window
+- Cannot be disabled after enablement
+
+---
+
+## 8. Intercept Transaction (Guardian)
+
+**Intention:** Guardian account holder wants to intercept a transaction from an entrusted account they guard
+
+**User Flow:**
+1. Guardian sees incoming reversible transfer in notifications/history from entrusted account
+2. Guardian taps on transaction
+3. Action sheet shows "Intercept Transaction" option
+4. Details shown: amount, original recipient
+5. Guardian taps "Intercept"
+6. Confirmation: "Are you sure you want to intercept this transaction and pull it to your account?"
+7. Guardian taps "Intercept" to confirm
+8. Transaction is cancelled and funds pulled to guardian account
+9. UI shows "Transaction Intercepted"
+
+**Data In:**
+- Transaction ID
+
+**Data to Chain:**
+- HighSecurity.interceptTransaction extrinsic with:
+  - Transaction ID
+
+**Data Out:**
+- Funds transferred to guardian account
+- Original transaction cancelled
+
+**Pending States:**
+- Submission pending → confirmed
+- Intercepted status shown on transaction
+
+---
+
+## 9. View Recovery Phrase
+
+**Intention:** User wants to view their wallet's recovery phrase for backup
+
+**User Flow:**
+1. User navigates to Settings → Show Recovery Phrase
+2. If multiple wallets exist, user selects which wallet
+3. Recovery phrase screen shows blurred/hidden grid
+4. User taps "Hold to Reveal"
+5. Mnemonic words displayed in numbered grid
+6. User can tap "Copy to Clipboard"
+7. User taps "Done" to close
+
+**Data In:** None (reads from secure storage)
+
+**Data to Chain:** None
+
+**Data Out:**
+- Recovery phrase displayed to user
+
+**Pending States:** None
+
+---
+
+## 10. Enable/Disable Biometric Authentication
+
+**Intention:** User wants to secure app access with device biometrics
+
+**User Flow:**
+1. User navigates to Settings → Authentication
+2. Toggle switch for "Authentication" shown
+3. User toggles ON
+4. System checks biometric availability
+5. System prompts for biometric authentication (Face ID/Touch ID/PIN)
+6. If successful, authentication is enabled
+7. User can configure timeout: Immediately, 1 min, 5 min, 15 min, 30 min, 1 hour
+8. App will require authentication after timeout period when returning
+
+**Data In:**
+- Enable/disable toggle
+- Timeout duration selection
+
+**Data to Chain:** None (local setting)
+
+**Data Out:**
+- Setting stored locally
+
+**Pending States:** None
+
+---
+
+## 11. Submit Referral Code
+
+**Intention:** New user wants to link their account to a referrer
+
+**User Flow:**
+1. Referral sheet appears after wallet creation (or via Settings → Referral)
+2. If deep-linked with referral code, shows prefilled code
+3. Otherwise, user manually enters 5-word referral code
+4. User taps "Submit"
+5. System sends referral to backend
+6. Success: sheet closes
+7. User and referrer receive reward program points
+
+**Data In:**
+- Referral code (5 words)
+
+**Data to Chain:** None (backend API call)
+
+**Data Out:**
+- Referral recorded on backend
+- Points credited
+
+**Pending States:** API submission only
+
+---
+
+## 12. Opt-In to Reward Program (Quests)
+
+**Intention:** User wants to participate in the reward program
+
+**User Flow:**
+1. User navigates to Quests tab
+2. If not opted in, promo video plays
+3. After final video, "I'm In" button appears
+4. User taps "I'm In"
+5. System calls opt-in API
+6. User is now a reward program participant
+7. Quests screen shows: opt-in position, associated accounts, quest list
+
+**Data In:** None
+
+**Data to Chain:** None (backend API)
+
+**Data Out:**
+- Opt-in position number
+- Participation status
+
+**Pending States:** API call only
+
+---
+
+## 13. Manage Accounts
+
+**Intention:** User wants to add, switch between, or edit accounts
+
+**User Flow:**
+1. User navigates to Settings → Manage Accounts
+2. List shows all accounts grouped by wallet
+3. Each account shows: name, checkphrase, address, balance, tags (High Security/Guardian/Entrusted)
+4. User taps account to make it active
+5. User taps settings icon to view account settings
+6. User can tap "Add Account" to create new derived account
+7. User can tap "..." menu to: Create new wallet, Import wallet, Add hardware wallet
+
+**Data In:**
+- Account selection
+- New account name
+
+**Data to Chain:**
+- None for switching/editing
+- Account derivation is local
+
+**Data Out:**
+- Active account changed
+- New accounts added to local storage
+
+**Pending States:** None for local operations
+
+---
+
+## 14. Add Hardware Wallet Account (Keystone)
+
+**Intention:** User wants to add a hardware wallet account
+
+**User Flow:**
+1. User taps "Add hardware wallet" from accounts screen
+2. QR scanner opens to scan Keystone export QR
+3. System parses account data from QR
+4. User names the account
+5. Account added to wallet
+6. For transactions: QR code displayed → Sign on device → Scan signature QR back
+
+**Data In:**
+- Keystone QR code data
+- Account name
+
+**Data to Chain:**
+- None for account addition
+- Transactions signed on device
+
+**Data Out:**
+- Account address from hardware
+- Signed transactions
+
+**Pending States:** Same as regular transactions after signature submission
+
+---
+
+## 15. View Transaction History
+
+**Intention:** User wants to see all past transactions
+
+**User Flow:**
+1. User taps History tab or scrolls down on home screen
+2. Combined list shows:
+   - Pending transactions (top, with status indicators)
+   - Reversible transfers (with countdown timers)
+   - Confirmed transactions (immediate and executed reversible)
+3. User can filter by account
+4. User can pull-to-refresh
+5. User taps transaction for details sheet
+
+**Data In:**
+- Account filter selection
+
+**Data to Chain:** None (GraphQL queries to subsquid)
+
+**Data Out:**
+- Paginated transaction list
+- Transaction details
+
+**Pending States:**
+- Background polling every 60 seconds
+- Real-time updates for pending/reversible transactions
+
+---
+
+## 16. View Transaction Details
+
+**Intention:** User wants to see full details of a transaction
+
+**User Flow:**
+1. User taps transaction in history
+2. Details sheet shows:
+   - Status icon (sent/received/failed/cancelled)
+   - Amount
+   - Counterparty checkphrase and address
+   - For reversible: remaining time countdown
+   - Copy address button
+   - View in Explorer link (opens browser)
+3. For failed transactions: Retry button available
+
+**Data In:**
+- Transaction data from list
+
+**Data to Chain:** None
+
+**Data Out:**
+- Formatted transaction details
+- Explorer URL: `{explorerEndpoint}/{type}/{hash}`
+
+**Pending States:** Timer updates for reversible transfers
+
+---
+
+## 17. Retry Failed Transaction
+
+**Intention:** User wants to retry a transaction that previously failed
+
+**User Flow:**
+1. User views failed transaction details
+2. User taps "Retry" button
+3. System resubmits same transaction (amount, recipient, reversibility)
+4. New pending transaction created
+5. Details sheet closes
+6. User monitors new transaction status
+
+**Data In:**
+- Original transaction data
+
+**Data to Chain:**
+- Same extrinsic as original (transfer or reversible transfer)
+
+**Data Out:**
+- New transaction hash
+- New pending transaction
+
+**Pending States:** Same as original send flow
+
+---
+
+## 18. Configure Notifications
+
+**Intention:** User wants to manage notification preferences
+
+**User Flow:**
+1. User navigates to Settings → Notifications
+2. User can enable/disable notification types
+3. Notifications include:
+   - Transaction failed alerts
+   - Low balance warnings
+   - Reversible transaction reminders
+   - Account added confirmations
+
+**Data In:**
+- Notification preference toggles
+
+**Data to Chain:** None
+
+**Data Out:**
+- Settings stored locally
+
+**Pending States:** None
+
+---
+
+## 19. Share/Invite Others
+
+**Intention:** User wants to invite others to use the app
+
+**User Flow:**
+1. User taps "Invite & Share" in Settings
+2. System generates share text with referral link
+3. System share sheet opens
+4. User can send via messaging apps, email, etc.
+
+**Data In:** None
+
+**Data to Chain:** None
+
+**Data Out:**
+- Share text with download link and referral info
+
+**Pending States:** None
+
+---
+
+## 20. Reset & Clear Data
+
+**Intention:** User wants to completely reset the app and remove all data
+
+**User Flow:**
+1. User taps "Reset & Clear Data" in Settings
+2. Confirmation sheet appears with warning
+3. User must confirm the action
+4. All local data cleared (wallets, accounts, settings)
+5. User returned to Welcome Screen
+
+**Data In:**
+- Confirmation
+
+**Data to Chain:** None
+
+**Data Out:**
+- All local data deleted
+
+**Pending States:** None
+
+---
+
+## Common Pending State Behavior
+
+All transaction submissions follow this pattern:
+
+1. **Optimistic Update:** UI immediately reflects the intended change (balance reduced, transaction in pending list)
+
+2. **Pending State:** Transaction shows status indicators:
+   - `created` - Just submitted
+   - `inBlock` - Included in a block, awaiting finalization
+
+3. **Polling:** 
+   - 10-second intervals for inBlock tracking
+   - 5-second aggressive polling for reversible execution detection
+   - 60-second background sync for general updates
+
+4. **Confirmation:** Transaction moves from pending to confirmed history
+
+5. **Failure Handling:** 
+   - Error message displayed
+   - Retry option available
+   - Balance reverted to pre-transaction state
+
+---
+
+This covers all the major user flows identified in your codebase. Each flow documents the complete user journey, data requirements, chain interactions, and how pending states are handled asynchronously.
\ No newline at end of file
diff --git a/mobile-app/pubspec.yaml b/mobile-app/pubspec.yaml
index 511d90f2..b9bb1923 100644
--- a/mobile-app/pubspec.yaml
+++ b/mobile-app/pubspec.yaml
@@ -38,7 +38,7 @@ dependencies:
 
   human_checksum:
     git:
-      url: https://github.com/Quantus-Network/human-checkphrase.git
+      url: https://github.com/Quantus-Network/qp-human-checkphrase.git
       ref: v1.1.0
       path: dart
   provider: ^6.1.5
diff --git a/quantus_sdk/pubspec.lock b/quantus_sdk/pubspec.lock
index 34253e89..334c9cbb 100644
--- a/quantus_sdk/pubspec.lock
+++ b/quantus_sdk/pubspec.lock
@@ -392,7 +392,7 @@ packages:
       path: dart
       ref: "v1.1.0"
       resolved-ref: "6eb6ffbddab6f7ebc00cd79a4c36b2da23bb8347"
-      url: "https://github.com/Quantus-Network/human-checkphrase.git"
+      url: "https://github.com/Quantus-Network/qp-human-checkphrase.git"
     source: git
     version: "0.1.0"
   integration_test:
diff --git a/quantus_sdk/pubspec.yaml b/quantus_sdk/pubspec.yaml
index dcb63250..abe709b5 100644
--- a/quantus_sdk/pubspec.yaml
+++ b/quantus_sdk/pubspec.yaml
@@ -41,7 +41,7 @@ dependencies:
   # Git dependencies (can't be managed by melos dependency_overrides)
   human_checksum:
     git:
-      url: https://github.com/Quantus-Network/human-checkphrase.git
+      url: https://github.com/Quantus-Network/qp-human-checkphrase.git
       ref: v1.1.0
       path: dart