There are two early implementations of Ark, one by ArkLabs (arklabs.to/) and one by Second (docs.second.tech/) I don't know what approach either implementation takes toward privacy, but I can share a few of my observations so far: - I've received payments from other Ark users and I can't see anything in the payment details that indicates who sent me that money. That is good for "sender privacy," but it's possible that info is leaked somewhere else, I'm not sure. - Both implementations of Ark seem to give each user a single pubkey for receiving payments. Pubkey reuse is bad for receiver privacy. On the other hand, I think you can fix this at the app level without requiring a change to the protocol. It seems to take only a second or two to spin up a new wallet with a new pubkey, so you could make a wallet app that gives you the option of generating a one-time-use pubkey for any payment you want that for. It would technically be spinning up a new wallet in the background, and then, after it receives money, the "new" wallet could forward the money to your "real" wallet and ignore any future payments to the "one-time-use" key. That might fix receiver privacy without requiring any changes to the protocol. - I suspect the ASP learns a lot about each "internal" Ark payment because the ASP serves as a kind of routing node between Ark users. Buraq originally proposed that "internal" payments should happen in a coinjoin, which would reduce the ability of the ASP to identify the sender and recipient of a payment, but I don't think that's implemented yet, and I would not be surprised if neither team *wants* to implement it, because coinjoins are very annoying for everyone involved. - The implementation by Second supports sending payments over lightning. These payments probably have a lot of the privacy benefits lightning brings, except I suspect the ASP knows the sender, the amount, the fee paid, and the recipient's node pubkey.