Ark operates similarly to the classic Chaumian eCash system in terms of anonymity. No one, not even the Ark Service Provider, can trace a payment from its payer to its payee. The significant difference between Ark and eCash is that every transaction made through Ark is backed by actual bitcoins, and ASPs cannot steal or inflate them by issuing payments to themselves.
Ark is a liquidity network similar to Lightning but without introducing liquidity constraints or a direct link between the sender and receiver. Therefore, recipients can receive payments without acquiring inbound liquidity or revealing their identity. Ark also consumes orders of magnitude less on-chain footprint than Lightning, as there is no concept of opening and closing channels.
Ark mimics the on-chain wallet UX in terms of getting paid from a dedicated address, async receiving, and not introducing inbound liquidity constraints. Ark is an off-chain protocol and thus transactions do not pollute on-chain. The link between the sender and receiver also obfuscated through plain tweaking and blinded mixing. The only downside is that Ark require users to come online and "refresh" their coins every few weeks, otherwise the ASP can sweep the funds.
Validity rollups require on-chain data per transaction, Ark doesnt. This means Ark has higher throughput. Both approaches require a soft-fork fork on the base layer; validity rollups require a ZKP verifier, while Ark doesn't require a soft-fork for the interactive version.
Ark service providers, can in theory, double-spend their pool transactions while they sit on mempool. However, in the meantime, recipients of the pool can pay lightning invoices with their incoming zero-conf vtxos, so it’s a footgun for the service operator to double spend in this case.
A transfer schedule from a sender to a receiver is atomic in nature. ASPs cannot redeem senders' vtxos if they double-spend recepients' vtxos under the mutually agreed coinjoin transaction id.
A future extension of Ark can utilize a hypothetical data manipulation opcode (OP_XOR or OP_CAT) to constrain the ASP's nonce in their signatures to disincentivize double-spending. If a double-spend occurs in a coinjoin transaction, users can forge ASP's signature to claim their previously redeemed vtxos. This is effectively an inbound liquidity-like tradeoff without compromising on the protocol design.