Security enhancements: Passkey limits, 2FA for large transactions, and recovery mechanisms

[Rapha-btc]

---

Title: Security enhancements: Passkey limits, 2FA for large transactions, and recovery mechanisms

Description:

Three security features to consider for CSW that would make it more robust for mainstream adoption:

1. Passkey transaction limits

Add a configurable limit on how much can be moved via passkey authentication in a single transaction or time period.

(define-data-var passkey-tx-limit uint u100000000) ;; e.g., 1 sBTC max per tx
(define-data-var passkey-daily-limit uint u500000000) ;; e.g., 5 sBTC per day
(define-map daily-passkey-spent principal { amount: uint, reset-height: uint })

Why: If a passkey is compromised (device stolen, phishing), the attacker can only drain up to the limit. Larger amounts require full admin auth.

2. Two-factor / time-lock for large transactions

Beyond a certain threshold, require either:

• Option A: Two signatures (e.g., passkey + hardware wallet, or two different passkeys)
• Option B: Time-lock mechanism with cooldown period

(define-data-var large-tx-threshold uint u1000000000) ;; e.g., 10 sBTC
(define-data-var cooldown-period uint u144) ;; ~24 hours in blocks
(define-map pending-large-tx

uint ;; tx-id

{

action: (buff 2048),

initiated-at: uint,

initiator: principal,

confirmations: (list 5 (buff 33)) ;; pubkeys that signed

}

)

Flow for large transactions:

1. User initiates large transfer → goes to pending
2. Wait cooldown period OR get second signature
3. After cooldown/confirmation, execute or cancel
4. Owner can cancel anytime during cooldown (in case of compromise)

Why: Defense in depth. Even if attacker has one key, they can't immediately drain large amounts. User has time to notice and cancel.

3. Recovery mechanism

What happens if user loses all passkeys / admin access?

Possible approaches:

A. Social recovery (Argent-style)

(define-map guardians principal bool) ;; trusted friends/family
(define-data-var recovery-threshold uint u3) ;; 3 of 5 guardians needed
(define-public (initiate-recovery (new-admin principal))

;; Requires guardian signature

;; Starts cooldown period

)
(define-public (confirm-recovery (new-admin principal))

;; After threshold guardians sign + cooldown passed

;; Transfer admin to new-admin

)

B. Time-locked recovery address

(define-data-var recovery-address (optional principal) none)
(define-data-var recovery-delay uint u4320) ;; ~30 days in blocks
(define-public (set-recovery-address (addr principal))

;; Only admin can set

)
(define-public (initiate-recovery)

;; Recovery address can initiate

;; Starts 30-day countdown

;; Current admin can cancel anytime

)

C. Dead man's switch

(define-data-var last-activity uint block-height)
(define-data-var inactivity-threshold uint u52560) ;; ~1 year
;; If no activity for 1 year, recovery address can claim

Why: Users WILL lose access. Without recovery, funds are lost forever. With recovery, there's a path back — but with enough safeguards that attackers can't abuse it.

---

Summary

Feature	Protects against	Tradeoff
Passkey limits	Device theft, phishing	Convenience for large txs
2FA / cooldown	Single point of compromise	Slower large transactions
Recovery	Lost keys	Potential social engineering vector

These features are standard in modern smart contract wallets (Argent, Safe, etc.) and would significantly improve CSW's security posture for holding meaningful amounts.

Happy to help spec out any of these in detail!

---

[friedger]

Thank you for the input.

The main challenge is to make the choices and create an opinionated product out of it. :-)