If I was incorrect, I would ask how they are different than CM?
Swapping your coins with another user does not result in an on-chain transaction, so technically it would be invisible to blockchain analysis, provided the withdrawal transactions don't leave any unique fingerprints such as by using unusual nlocktimes or similar (I've not examined the code closely enough to know if this is the case). This could be a good or a bad thing, depending on your specific use case. If you need to hide the fact you are using ChipMixer or a coinjoin, then this wallet could do that. However, this also means that unlike ChipMixer or a coinjoin, the coins you receive are not unlinked from their history. From a blockchain analysis point of view, any coins you receive from this wallet will still have their full history attached, and will simply have gone through a single intermediary address before arriving at your wallet or the final destination you are sending the coins to.
From my perspective, this is doing the same thing that CM does.
The process flow with CM is as follows from my perspective as a customer/user:
Bob deposits bitcoin to CM
CM splits Bob's deposit into various "chips" in amounts that are similarly available via Mercury
QS deposits bitcoin to CM
QS deposit is electronically credited to CM's database, rounded down to an amount that can be split up into various "chip" sizes
QS withdraws "chips" from CM session by obtaining various private keys of "chips" and spends the bitcoin to addresses whose private keys I generated
The process flow with Mercury is as follows from my perspective as a customer/user:
Alice deposits bitcoin to a Mercury "SE" in an amount that is the same as a "chip" used by CM
QS deposits bitcoin to a Mercury "SE" in an amount that is the same as a "chip" used by CM
Alice and QS swap "statecoins" via the Mercury wallet
QS "withdraw" from my Mercury wallet by spending the statecoin
The only difference between CM and Mercury is that CM allows the flexibility of allowing multiple "chips" to be purchased in one transaction. Mercury statecoins must be spent within a certain number of blocks because the nLockTime of the transaction given to the user in the event the SE becomes uncooperative expiring means that the statecoin is at risk of theft by prior owners. There will be two distinct fingerprints of Mercury transactions, 1) outputs of the funding transactions are in exact amounts available on the Mercury platform, and 2) that UTXOs are always spent within however many blocks Mercury requires users to spend the UTXO by.
There is another issue with Mercury that will potentially result in the loss of money:
Each time a statecoin is transferred, the backup transaction used in the event the SE becomes uncooperative has the nLockTime value decline by one. A malicious user could potentially send statecoins to himself multiple times to get the nLockTime value to be very low (after waiting for required transaction fees to be high). The malicious user, Bob could swap statecoins with Alice, and unless Alice nearly immidiately spends the statecoin with a transaction with a next block confirmation transaction fee, Bob can spend the UTXO with his most recent "backup" withdrawal transactions.