I'm not politically or economically involved, but having read the Ark research paper (Ark: A UTXO-based Transaction Batching Protocol by Marco Argentieri, Zeta Avarikioti, Andrew Camilleri, Pim Keer, and Matteo Maffe) I found it rather sane, but I'm not an bitcoin expert, and also cannot vouch for the congruence between that paper and Arklabs's implementation. I have since then also seen examinations and projections of quantities related to the questions posed. Haven't really bookmarked those as I mostly looked at it motivated by curiosity. Running an ASP is not something I aim for yet. But finding insight-giving analyses ought be doable.

How far can Ark - when being used for Bitcoin payments - scale?

Will not. Because the whole interaction with the rest of the world is through LN.
Ark's wrong assumption is that people will just drop the whole LN and use Ark.
That will never happen.
That means Ark will be just a niche feature used by such poor users that cannot open a damn LN channel.

I keep my view on Ark:

and also

We are overcomplicate it with Ark. We are still didn't explored all the beauty of LN. For example I do not see many people using 0-conf channels...

Disclaimer: The following answer was created with the help of an LLM - though I checked and verfied it to the best of my ability

How Ark spending actually pulls on ASP liquidityHow Ark spending actually pulls on ASP liquidity

• In each round, users “spend” one or more vTXOs and receive new vTXOs (recipient + usually a change vTXO). Conceptually this mirrors UTXOs on L1: inputs are destroyed, outputs are created. (Ark Protocol)
• Who fronts the outputs? The ASP does. Users forfeit their input vTXOs to the ASP, and the ASP “fronts” the on-chain liquidity that backs all the new vTXOs created in that round. The ASP can only unlock (reclaim) that forfeited value later, when the forfeited vTXOs expire. Think of it as the ASP advancing short-term working capital and receiving IOUs that mature at the vTXO expiry. (Ark Protocol)
• Expiry / duration: vTXOs have an absolute timelock. In the reference docs it’s shown as 14 days; some write-ups (and implementations) discuss ~4 weeks. The mechanism is the same: before expiry, users must roll their vTXOs into a new round; after expiry, the ASP can sweep the funds, recovering the fronted liquidity. So the ASP’s liquidity is tied up roughly until the expiry window elapses for the inputs of that round. (Ark Protocol)

“At least one vTXO created, potentially destroying several”—what that implies“At least one vTXO created, potentially destroying several”—what that implies

Yes. A single payment typically:

1. consumes one or more input vTXOs, and
2. creates at least two outputs: the receiver’s vTXO and the sender’s change vTXO (unless it’s perfectly exact). Because the ASP must fund every new output in the round (including change), ASP liquidity consumed per payment can be larger than the payment amount. This “change amplification” is a big deal. (Blog - Ark Labs)

How much liquidity—and for how long?How much liquidity—and for how long?

A practical mental model:

• Define M = total user funds “inside this ASP’s Ark” (sum of users’ vTXOs).
• Define V = “velocity” over the expiry window = total value spent by users within that window divided by M.
• First-order demand on ASP working capital across a window is on the order of V × M (the value of outputs the ASP must front for internal transfers during that window).
• But because most payments create a receiver output and a change output, the ASP fronts more than just the transferred amount. With naïve splitting, the multiplier can be several-fold. Concrete simulations from Ark Labs show cases where spending ~0.33 BTC of a 1 BTC balance required 2.67 BTC of ASP liquidity (≈8× the actually traded amount) — and with many small splits it got worse (≈25×). That’s the “change amplification” effect. (Blog - Ark Labs)
• Tenor: that fronted liquidity is tied up until the forfeited inputs expire (the vTXO expiry, e.g., ~14 days / ~4 weeks), at which point the ASP can reclaim it. So the ASP’s “peak liquidity” is the maximum net value of new outputs it has created minus the value of forfeits that have already matured—measured over the expiry horizon. (Ark Protocol)

What if two Ark users ping-pong lots of tiny payments?What if two Ark users ping-pong lots of tiny payments?

• Each tiny payment tends to create two new outputs (receiver + change). If they ping-pong within the same expiry window, the ASP keeps fronting more outputs while the forfeited inputs from previous rounds haven’t matured yet.
• Net effect: the ASP’s outstanding working capital keeps climbing roughly with the number of times those coins circulate during the window, multiplied by the change-amplification factor from poor denomination/coin-selection. That’s exactly the pathological case highlighted in the liquidity write-up. (Blog - Ark Labs)

Is ASP liquidity proportional to user payment volume?Is ASP liquidity proportional to user payment volume?

• Roughly, yes—but with important caveats.
  • Proportional to payment volume over the expiry window (that’s the V×M intuition).
  • Super-linear when payments fragment balances and produce lots of change outputs (amplification factor).
  • Bounded in time by the expiry: once inputs roll past expiry, the ASP’s forfeits mature and liquidity recycles. (Blog - Ark Labs)

TL;DR answerTL;DR answer

• How much liquidity and for how long? Enough to cover the sum of all new outputs created in rounds (receiver + change) across the expiry window, until forfeited inputs expire and can be swept by the ASP. Tenor ≈ the vTXO expiry (e.g., ~14 days or ~4 weeks, depending on policy/implementation). (Ark Protocol)
• What if two users send back and forth small payments? Liquidity requirements can blow up because each tiny payment creates multiple outputs; the ASP keeps fronting outputs while forfeits are unspendable. This can require multiples of the actually traded value within the window. (Blog - Ark Labs)
• Are requirements proportional to payment volume within the vTXO timelock? Approximately proportional to volume over the window (velocity × total user funds), but amplified by change/fragmentation; good denomination and policies can bring it closer to linear. (Blog - Ark Labs)