Enum ArkadeSwapIntentType

Namespace

NArk.ArkadeIntents.Models

Assembly

NArk.ArkadeIntents.dll

Which direction a non-interactive swap runs in.

public enum ArkadeSwapIntentType

Fields

AssetToBtc = 1

Deposit an Arkade asset, receive Ark BTC.

BtcToAsset = 0

Deposit Ark BTC, receive an Arkade asset.

BtcToEvm = 6

Deposit Arkade BTC and receive an ERC20 on a configured EVM chain. Verified token delivery, rather than Arkade funding or spending, settles a merchant payment using this corridor.

BtcToLightning = 2

Deposit Ark BTC, have a BOLT11 invoice paid on the Lightning network. Negotiated by RFQ rather than by an offer on the stream, and settled against a covenant that pins the refund to the maker's own address — but from this layer's point of view the same thing: a covenant VTXO the maker funded and a solver fills without a round trip.

BtcToOnchain = 4

Deposit Ark BTC, take delivery on Bitcoin L1. Two contracts on two rails linked by one secret: the client funds an Arkade covenant, the solver funds an L1 HTLC paying the client, and the client's L1 claim publishes the preimage the solver needs for the Arkade side.

From the Arkade side this behaves exactly like BtcToLightning — a covenant the client funded and the solver fills. What differs is that the delivery leg is a chain this SDK must watch and spend on itself, rather than a payment network reporting back.

LightningToBtc = 3

Be paid over Lightning and take delivery on Arkade. The mirror of BtcToLightning, with the exposure mirrored too: here the solver funds the covenant first and is only paid once our claim publishes the preimage, which is why we — not the solver — choose that secret.

OnchainToBtc = 5

Deposit Bitcoin L1 sats, take delivery on Arkade. The mirror of BtcToOnchain, with the funding order and the exposure mirrored too: here the client funds an L1 HTLC first and the solver funds the Arkade covenant against it, collecting only once our claim publishes the preimage.

From the Arkade side this behaves like LightningToBtc — a lockup somebody else funded, ours to claim on a clock. What differs is the leg we are exposed on: it is a chain, and our recourse there is the L1 HTLC's own refund leaf rather than anything on Arkade.

So the deadlines run the other way round from BtcToOnchain. The solver's Arkade reclaim opens first and closes our claim window; our L1 refund opens last.