How the Anti-money Laundering (AML) mechanism works
The AML mechanism implemented by HYC is based on a game-theoretical approach that allows the dapp to keep out malicious users while still preserving the identity of all users.
The Allowlist
The base requirement for anyone to interact with HYC is that money depositors need to be registered on the allowlist.
The allowlist is a merkle tree containing all approved accounts as tree leaves. The contract only accepts deposits from accounts that are members of the tree, and only allows withdrawals if the original account that deposited the funds is still on the allowlist at the time of withdrawing.
The reasoning behind this is that the app has to hinder the flow of illicit funds - that is, smart contract hacks, scams, money laundering, etc. - from entering the contract and being mixed.
When applying to the allowlist, the account will be queried against a cybersecurity risk database, to figure out if the account has the material risk of being associated with illicit activities. If the account is denied, it cannot bring the funds into the mixer - if it tries to transfer funds to other accounts to them enter the mixer, those accounts are also going to become tainted and will be denied - we'll dive further into this mechanics in the next section.
Edge case
The protocol also has to consider the case where a savvy hacker takes an account that has not been involved in any cybercrime, first applies to the allowslist, gets accepted, and then takes part in a smart contract hack and tries to use the mixer to launder the funds.
In this case, the contract implements a special ZK circuit that is going to lock the user's funds as soon as the account that deposited them is implicated in the cybersecurity database.
The protocol exposes a special denylist
method that performs a new database query for an account that is already in the allowlist and, in case the account is now flagged as a risk, removes the account from the allowlist merkle tree - which locks the funds into the contract, no one will be able to claim them anymore.
This entire setup exposes the hacker to an impossible dilemma, in case they deposit their illicit funds into the protocol:
They withdraw the money rapidly before the cybersecurity database can flag the accounts -> in this case, law enforcement will have an easy time figuring out where the money went since mixers only guarantee anonymity against advanced analytics algorithms if the funds are kept in the mixer for a considerate amount of time
They wait for the recommended time until transactions can be considered safely private --> in this case the cybersecurity database is going to pick up the implicated wallets, they will be removed from the allowlist and the funds will be locked inside the contract
Cybersecurity Database
HYC has been designed to work in partnership with any Know-Your-Transactions (KYT) partner. Those firms provide risk scores for accounts based on the history of the blockchain transaction graph and known risk factors, such as exploits, scams, sanction lists, etc. To understand more about how these companies operate, check this article.
At present, HYC is integrated with hapi.one, the first decentralized cybersecurity data provider. Their solution is fully integrated with NEAR protocol, and they also aggregate data from multiple other reputable data providers such as Elliptic and Chainanalysis.
Hapi.one also possesses a manual process that allows accounts that may eventually be wrongly flagged by the system to submit a dispute with proving documents and lift the block from HYC services.
Last updated