Skip to content

Instantly share code, notes, and snippets.

@aruokhai
Last active January 26, 2026 10:04
Show Gist options
  • Select an option

  • Save aruokhai/7ae61a9344aab5d33be4aee399709543 to your computer and use it in GitHub Desktop.

Select an option

Save aruokhai/7ae61a9344aab5d33be4aee399709543 to your computer and use it in GitHub Desktop.

Liquidity Provisioning for Arkade Using a Bradt Auction System

Liquidity provisioning for Arkade via a Bradt-style auction requires m providers, each committing x units of liquidity.

This model aligns naturally with the Commitment Transaction format, which is composed of multiple batches organized as commitnent outputs. In this setup, each provider’s liquidity can be assigned to a specific batch, effectively capping the exposure of any single branch and improving system reliability.

The connector tree can also be simplified. The first level has radix y, representing the number of liquidity providers, while the second level contains the providers's connector outputs used across all forfeit transactions.


The Core Challenge: Trustless Redemption

The real difficulty arises in enabling trustless redemption of liquidity. To simplify the problem, we exclude interest payment, and only highlight principal repayment.

Suppose a batch output is committed to:

A + 0 --> [ (Con) -- [A + Timelock]] . This specify the repayment transaction, which is bound by the presence of the connectors outpoints, where A is the liquidity provider and O is the Operator. The connector (conn) input is necessary to bind a single claim path to the provider while both the repayment path and the forfeit path are stil valid. However the spending of a single forfeit path, nullifies the repayment path, due to an invalid connector input.

In the event of a batch expiry, the Provider can trustlessly retrieve its principal repayment, but in the case of partial unroll of a batch,the repayment path is nullified, but this can be mitigated if repayment transactions were created for all branch leading to Ark Transaction and excluding it.

The big problem however, pertains to a unilateral exit, in this case, the provider’s funds would be at risk. This is because past funds cannot to be locked to a future liquidity provider. Assuming that is cryptographically possible, where would such funds be gotten. If we trace through previous batches to find idle funds, we would arrive at the boarding outputs, which is the source of new vtxos, who claims this, how therefore can this be pledged to fututre liquidty providers in a trustless manner.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment