Skip to content

Implement First Deposit Warning Modal and BTC Address TRM Screening #829

@evandrosaturnino

Description

@evandrosaturnino

Problem Statement

Currently, the tBTC minting flow lacks a specific warning for users making their first deposit regarding the required minimum amount (0.01 BTC). Additionally, TRM wallet screening is only performed for connected Ethereum addresses, not for Bitcoin addresses provided during the minting process. Finally, fetching bridge (deposit and redemption) activity can be slow, impacting user experience.

Proposed Solution

This issue tracks the implementation of three key enhancements:

1. First Deposit Warning Modal:

  • Objective: Warn users about the 0.01 BTC exact amount requirement for their first deposit to a new EVM address.
  • Implementation Details:
    • A new modal (FirstDepositWarningModal) will be displayed in the ProvideData step of the minting flow if the system detects it's the user's first deposit (no prior "MINTED" bridge activity).
    • The modal will contain a checkbox requiring the user to acknowledge the 0.01 BTC first deposit rule.
    • The deposit generation process will only proceed after the user confirms this acknowledgment.
    • Modal interaction is managed via Redux state (firstDepositWarningConfirmed in tbtcSlice) to ensure serializable state and avoid passing functions as modal props.

2. TRM Screening for Bitcoin Addresses:

  • Objective: Extend TRM wallet screening to Bitcoin addresses entered by the user.
  • Implementation Details:
    • When a user enters a BTC address in the "BTC Return Address" field (btcRecoveryAddress) in the ProvideData component, a TRM check will be triggered.
    • A new Redux action (bitcoinAddressSubmitted) and an associated effect (getBtcAddressTrmInfo) in the account store will handle this.
    • The fetchWalletScreening API will be called with networkName: "bitcoin" and the provided BTC address.
    • If the BTC address is flagged by TRM, the existing global isBlocked state in accountSlice will be set to true, effectively blocking the user.

3. Performance Optimization for Bridge Activity Fetching:

  • Objective: Improve the loading speed of bridge (deposit and redemption) activity history.
  • Implementation Details:
    • Refactor getBridgeActivity, _findL1DepositActivities, and _findL2DepositActivities methods in threshold-ts/tbtc/index.ts.
    • Utilize Promise.all to parallelize independent asynchronous data-fetching operations (primarily fetching different sets of contract events) within these functions.

Acceptance Criteria

  • A modal appears for first-time depositors in ProvideData.tsx warning about the 0.01 BTC limit.
  • The user must check an "agree" box in the modal to proceed with deposit address generation.
  • If the modal is closed without agreement, the flow does not proceed.
  • TRM screening is triggered when a BTC address is entered in the btcRecoveryAddress field.
  • If the BTC address is blocked by TRM, the user's isBlocked state is set to true.
  • Bridge activity loading time is observably reduced, especially for accounts with history.
  • The Redux store remains serializable (no functions stored in modal props).

Metadata

Metadata

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions