The proposal is to add a new category to the HAPI Protocol - “Hacker”. Hacking is one of the common ways a malicious actor gets unauthororized access to a user assets as such adding this as a separate category to the protocol might increase the specificity of the categorization and enable both users and businesses to be more selective when adjusting thresholds/categories for their specific purpose. Adding new categories to the HAPI Protocol makes it possible to provide more coverage across criminal domains.
What Defines Hacker Category
Unauthorized access to sensitive user or business data: in the cryptocurrency realm this refers to an access to a private key of the wallet which renders the wallets itself compromised. Usually caused by negligence.
Malware or virus infections: Hackers may use various methods to distribute malware or viruses, which enables them to steal private keys or siphon sensitive data without one’s knowledge.
Phishing attacks: Hackers may use social engineering techniques to trick individuals into divulging sensitive information, such as passwords or financial data.
Exploitation of software vulnerabilities: Hackers may leverage weaknesses or vulnerabilities in Smart Contract to gain access to assets or exploit the way those assets interact with the Smart Contract
Generally, the “hacker” category represents a significant cyber risk for organizations, and appropriate measures should be taken to mitigate these risks.
Benefit
Improved risk management: By identifying the specific risk posed by hackers and including it as a separate category, organizations can develop targeted risk management strategies to address these risks more effectively.
Enhanced compliance: Including a “Hacker” category in the smart contract can help organizations to comply with regulatory requirements around cybersecurity risk management.
More effective insurance coverage: By clearly defining the risks associated with hackers, organizations can ensure that their insurance coverage is more effective and provides appropriate coverage for cybersecurity risks.
Overall, including a “Hacker” category in the HAPI Protocol smart contract can help organizations to better manage and mitigate cybersecurity risks, improve transparency and compliance.
Potential Drawbacks
Uncertainty: The risk posed by hackers can be unpredictable and constantly evolving. Including a separate category for this risk may not capture all of the potential threats, leaving the organization vulnerable to attacks that were not accounted for in the smart contract.
Lack of standardization: There is currently no widely accepted standard for including cybersecurity risks in smart contracts, which could potentially lead to inconsistencies in how organizations approach risk management.
Conclusion
Including a “Hacker” category in the HAPI Protocol smart contract can have benefits, it’s important to weigh these against the potential drawbacks. HAPI community is urged to vote according to what is best for the HAPI Protocol based on their personal judgment
Thank you for your attention
Proposal Type explanation
Proposal type: 7 [IMPL] - this type of proposal has a direct impact on the HAPI Protocol. Read more about each proposal here: HAPI Governance Protocol
I would add that there’s already a category that covers hackers in general: it’s Illicit Organization. The question is do all the benefits compensate for potential ambiguity?
I can see the benefit in distinguishing between Hackers and illicit organizations. They pose different risk like laundering stolen fund or avoiding sanctions. This might help Hapi deploy the best solutions to help the most clients with limited resources.
Not all DEXs will want to simply block the category “illicit finance” because most want to stay true to the standard “Blockchain Ethos”. However, all DEXs or DeFi protocols should be able to get behind not accepting or even freezing funds that were attained by hacking other DEXs or DeFi in general.
(This is in their own self-interest as well because they know other DeFi protocols will support them if they themselves get exploited.)
In order to distinguish hacked funds from regular illicit finance, we do need a separate category.
Maybe this category should be specifically targeted for DEXs that got hacked. Therefore, only addresses with funds that are tied to a DeFi hack should be tagged. So, no Malware-/Phishing.
I see it like a somewhat agreed-on DeFi “Code of Honor” where everyone can get behind not accepting those funds.
I prefer the phrase “ill gotten gains”. It leaves enough ambiguity to define a category that describes “finances”. That category can be further divided into the method by which these malicious actors obtained these funds. Phishing, hacking, etc. This sub division of ill gotten gains allows for the addition of new scams and their methodology. It’s almost like a directory tree where the stolen money from each type of scam can be totaled and easily seen. The total pool of ill gotten gains would be at the top with each category branching off like a web. Interaction with those gains would trigger the type of attack that those funds came from and the addresses associated. It would seem like the “category” of ill gotten gains would stay hidden server side. The only information that the client would see would be the breakdown relative to the origin of the funds or address they are attempting to interact with. It would allow for an organized structure that can be indexed for retrieval of specific information related to each specific type of event once it has been properly identified and classed. The term “hacker” also seems crass in my opinion. “Malicious actor” is ambiguous enough to allow for distinction when necessary while retaining the essence of impropriety. I’m not strictly opposed to the verbiage used above, I’m just putting my thoughts out here for discussion if anyone sees fit.
Implementing a category tree would be a huge rework of the existing system, though. Also it’d lead to erasure of existing information. What would be the benefit of hiding the type of malicious activity from the user in this case?