Class OnchainSwapMetadata
- Namespace
- NArk.ArkadeIntents.Models
- Assembly
- NArk.ArkadeIntents.dll
What an onchain corridor swap keeps beyond the fields every corridor has.
public sealed record OnchainSwapMetadata : IEquatable<OnchainSwapMetadata>
- Inheritance
-
OnchainSwapMetadata
- Implements
- Inherited Members
Remarks
One record for both directions, because both keep the same four things. What each MEANS follows the direction, and the fields say so individually rather than the corridor carrying two near-identical records that would have to be kept in step.
Constructors
OnchainSwapMetadata(string?, string?, long?, string?, int?)
What an onchain corridor swap keeps beyond the fields every corridor has.
public OnchainSwapMetadata(string? Preimage, string? HtlcPubkey, long? HtlcLocktime, string? PayoutAddress, int? MinConfirmations = null)
Parameters
PreimagestringThe secret linking the two rails, hex. Derived from the wallet's seed.
HtlcPubkeystringThe counterparty's x-only key on the L1 HTLC — its refund leaf on an off-board, its claim leaf on an on-board. This and
HtlcLocktimeare the only parts of the L1 leg nobody can re-derive: everything else about that contract comes from the payment hash and the wallet's own key. The address is deliberately not kept, so a derived value cannot drift from what derived it.HtlcLocktimelong?Unix seconds at which the L1 refund leaf opens. On an off-board that is the counterparty's way out and falls BEFORE the Arkade refund; on an on-board it is ours and falls AFTER it. Either way the ordering is what the corridor refuses to fund without.
PayoutAddressstringWhere this swap's own L1 spend pays. The spend chooses it, not the HTLC, so neither contract commits to it and it has to be remembered: a swap whose row is lost can still be rebuilt, but the sats land wherever that rebuild names.
MinConfirmationsint?What the quote asked for on the L1 funding, kept because the counterparty sized its own deadline from this number and nothing else records it. The off-board's
htlcLocktimeis computed from it, so a claim that waits for more confirmations than were quoted is spending a margin the counterparty measured out for a shorter wait.
Remarks
One record for both directions, because both keep the same four things. What each MEANS follows the direction, and the fields say so individually rather than the corridor carrying two near-identical records that would have to be kept in step.
Properties
HtlcLocktime
Unix seconds at which the L1 refund leaf opens. On an off-board that is the counterparty's way out and falls BEFORE the Arkade refund; on an on-board it is ours and falls AFTER it. Either way the ordering is what the corridor refuses to fund without.
public long? HtlcLocktime { get; init; }
Property Value
- long?
HtlcPubkey
The counterparty's x-only key on the L1 HTLC — its refund leaf on an off-board, its claim leaf on
an on-board. This and HtlcLocktime are the only parts of the L1 leg nobody can
re-derive: everything else about that contract comes from the payment hash and the wallet's own
key. The address is deliberately not kept, so a derived value cannot drift from what derived it.
public string? HtlcPubkey { get; init; }
Property Value
MinConfirmations
What the quote asked for on the L1 funding, kept because the counterparty sized its own deadline
from this number and nothing else records it. The off-board's htlcLocktime is computed
from it, so a claim that waits for more confirmations than were quoted is spending a margin the
counterparty measured out for a shorter wait.
public int? MinConfirmations { get; init; }
Property Value
- int?
PayoutAddress
Where this swap's own L1 spend pays. The spend chooses it, not the HTLC, so neither contract commits to it and it has to be remembered: a swap whose row is lost can still be rebuilt, but the sats land wherever that rebuild names.
public string? PayoutAddress { get; init; }
Property Value
Preimage
The secret linking the two rails, hex. Derived from the wallet's seed.
public string? Preimage { get; init; }