Which coin it uses is also fixed: the most worn-out one first. The measure is the amount minus the exit cost, that is, what I could actually salvage on the worst day. The coin where that number is lowest, or already negative, gets spent first. A coin whose exit cost has passed its amount has nothing left to salvage, so piling a hundred more payments onto it costs me nothing further. Spending from a clean coin, on the other hand, eats into money I could have recovered in full.
Done this way, no matter how fast exit cost builds up, it stays quarantined inside one hot coin, and ownership of most of the balance remains intact.
Here is the actual state of my ark wallet. At refresh I split it into three hot coins of 5,000 sats each and one cold coin, then routed every payment through one of the hot coins. While that coin's balance fell by about 600 sats, it accumulated 123 transactions, and its exit cost is now around 87,000 sats. That is 20 times the coin's value, and more than the wallet's entire balance of about 67,000. Had I been spending from one merged coin, everything I own would be impossible to exit (possible, strictly speaking, but pointless). Yet the 52,000-sat cold coin can still leave for about 2,400 sats, 5% of its amount.
As you can see, an Ark wallet has a lot to get right, especially if it is to guarantee ownership without sacrificing usability. But I don't count that as a weakness, because everything that has to be done sits on the local side. What matters for ownership is not whether the logic is complicated, but whether it has dependencies. Even the simplest thing isn't fully mine if it needs someone else's cooperation. Something a bit complicated that depends only on client logic just takes some care to build.
Once a coin has been refreshed, the worst an ASP can do is refuse to cooperate, and then I simply exit. But if that exit costs more than the money, the promise is hollow. Keeping the exit cost down to a reasonable level is what makes it real. And if users can walk away cheaply, the only one ruined by a refusal is the ASP itself, so it has no reason to refuse in the first place.
quotingOver the last four posts I looked at how Ark gains scalability while staying self-custodial. Today I want to look at another of its drawbacks: cost. In the first post I said that most criticisms of Ark are things a well-behaved client can overcome. This is the biggest of them.
nevent1q…e93d
Ark's self-custody rests on the right to exit unilaterally. But unlike Lightning, where a unilateral exit takes just two onchain transactions no matter how heavily the channel has been used, an Ark exit has no fixed size. To exit a VTXO, I have to replay its offchain transaction history onchain, in order. Not all the way back, of course; only as far as the last refresh. Still, if I've been spending actively offchain, that can mean dozens or even hundreds of transactions, and whoever exits pays the fees for all of them.
So every time a VTXO is spent, an "exit cost" quietly piles up behind it, separate from its face value. An onchain transaction costs a few hundred sats, so each time I pay a few dozen sats offchain, the onchain value of that coin drops by far more than what I spent. Keep going, and at some point the exit cost exceeds the amount of the coin itself. From then on, my cryptographic ownership of it is ownership in name only.
It gets worse, because exit cost is contagious. If I put a heavily used VTXO and a clean one into the same payment, the change inherits the history of both. Nothing I do offchain can shrink it. Only a refresh resets it to zero.
And a wallet left to its defaults drifts straight into the worst case. A refresh merges my whole balance into a single VTXO, so every small payment after that raises the exit cost of everything I own. Even when I do hold several VTXOs, the SDK's default coin selection reaches for the largest one first.
So is the unilateral exit an empty promise for anyone who actually uses Ark? No. And once again, the fix is entirely up to the client.
nevent1q…fdxg