1. CEX 1 detects fraudulent transactions - hack that speedily turns into outflow of funds to the unknown wallet.
2. СЕХ_1 reports the event into HAPI Protocol that writes into the HAPI SC WalletID_1 to which the funds have been transferred.
3. HAPI Protocol analyses (based on the given metrics) a transaction and categorizes it in: Approved address WalletID_1 on the HAPI SC; Rejected inquiry of WalletID_1 on the HAPI SC
4. If the address is on the HAPI SC - HAPI Protocol sends WalletID_1 to DATAprovider in order to track and trace the upcoming transactional dealings from the same wallet.
5. DATAprovider via Oracles relays to the HAPI Protocol all of the nascent wallets on which the transactions are being transferred from the source wallet WalletID_1 6. HAPI Protocol analyses (based on metrics) wallet addresses Approved address WalletID_1 on the HAPI SC; Rejected inquiry of WalletID_1 on the HAPI SC
7. HAPI Protocol sends CEX_2 and DEX identificators of wallets from HAPI SC
An unlawful actor makes an attempt to send fraudulent funds on CEX 2. CEX 2 knowing the threat from the aforementioned wallet can expose it to the potential risk - blocks the transfer. Unlawful actor makes an attempt to connect the address to DEX, DEX declines this attempt and/or completely blocks the wallet from making a transaction within DEX.
HAPI allows for CEX to promptly notify its users about fraudulence taking place via Write Public Interface. CEX receives data about fraudulent activity described above, with this data available CEX may not only deftly freeze the siphon of funds but also reactively respond and announce to the users to abstain from using the CEX functionality for the time being. In this quite simple yet convenient fashion, CEX garners not only additional “points” for trustworthiness but also safeguards its users against the potentially exacerbating exploit.