Ark is the third major Layer 2 protocol to have some form of unilateral exit or enforcement mechanism at the base layer to approach the point of launch on Bitcoin. Lightning came first when C-Lightning went live in the Reckless campaign in 2018, Statechains in 2021 when Mercury Wallet went live, and now Ark Lab’s upcoming Arkade wallet implementation of clArk (covenantless Ark) is approaching the same goal line .
clArk has some shortcomings compared to a full Ark implementation, namely the requirement in a trusted version for each user within an individual Ark to co-sign the exit transactions in a huge n-of-n multisig as it is created. If we had CTV or another equivalent covenant, users would not have to participate in an interactive signing process, and the Ark Service Provider (ASP) could simply create the Ark using a covenant and users could be assured that they then have full control over their money. it is confirmed.
Ark offers an interesting trade-off compared to the Lightning Network; both require participants to have excess liquidity to receive payments. In the case of Lightning, however, it’s a complicated game where individual users have to figure out where to spend their own liquidity and how to obtain liquidity from others in order to send and receive functionally. It is an individual problem that each user must solve alone. Ark allows any ASP to freely allocate part of its liquidity to any of its users. They still have to solve the problem of sourcing it, but there is no longer the per-user problem of deciding whether it is worth allocating liquidity in that direction; it can simply be done at the time each individual user needs it. of a common liquidity pool.
However, there is still a problem with Ark’s liquidity problem. For every payment floating on an Ark that has not yet been closed, the ASP must collect liquidity for those payments so that users can receive them in a new Ark. When the ASP gets to a point where liquidity is running out, its fees will necessarily have to skyrocket to manage that issue until they are able to regain the locked up liquidity by closing Arks.
I think one way to address this tail curve of higher fees might be to explore some of the lessons learned from Lightning, namely a routable topology. This would be incredibly simple compared to Lightning. Lightning requires mapping and routing liquidity paths between pairs of individual users, while with Ark it is simply ASP to ASP.
An ASP facing a liquidity crisis can ‘punt’ payments from its own Ark to another ASP with more available liquidity, thus establishing the ATLC link between its own Ark where the payment is coming from and the Ark to be received from another ASP, saving user costs. In turn, other ASPs then facing a liquidity crunch can return the favor by steering payments back their way, as they are able to regain liquidity as they close existing Arks and their own fees fall.
This could create a kind of round-robin and easily analyzable “I scratch your back, you scratch mine” dynamic between ASPs, which while leaving some revenue on the table during high-fee liquidity crises, is generally a more would create a predictable and affordable experience for their customers. users.
This poses the risk that these types of payments between ASPs essentially tie Arks between different ASPs, meaning that non-cooperative closures would necessitate the closure of Arks managed by multiple entities, but given that cooperative closures depend on user behavior, I don’t think this is the case. the risk profile changes fundamentally if ASPs deliberately do not offend each other. However, this can be seen as analogous to Lightning’s channel interference problem.
There are some advantages and potential disadvantages, but I think this is a concept worth exploring in terms of improving Ark’s liquidity crisis.