# DamageBDD Payment Flows and Custody Boundaries

Distinguish Lightning top-ups, DAMAGE execution spend, contractor payments, swap jobs and remote wallet permissions.

Canonical HTML: <https://damagebdd.com/payments.html>



<a id="identify-the-flow-before-making-a-payment-claim"></a>

## Identify the flow before making a payment claim

Bitcoin/Lightning is a payment rail; DAMAGE/Aeternity supplies the documented
execution-credit accounting path. They have different units, custody models
and confirmation records.

| Flow | Intended effect | Evidence and boundary |
| --- | --- | --- |
| Lightning top-up | Pay an invoice; the configured listener transfers DAMAGE credits | Invoice settlement and the token credit must both be confirmed; this does not establish an atomic swap |
| DAMAGE execution spend | Transfer execution cost to a node/operator with feature/report references | A token spend is separate from token burning and from any BTC payment |
| Contractor compensation | Pay agreed BTC or Lightning compensation for accepted work | The [contractor process](contractors.md) requires maintainer review and a recorded payment |
| Swap/hold-invoice job | Coordinate a conditional invoice, job state and contract action | The [integration reference](features/funding_swap.md) needs release-specific settlement, expiry and recovery evidence |
| Paid API access / remote wallet integration | Gate a service request or authorise a wallet method | The [evaluation guide](articles/lightning_api_economics.md) does not establish complete L402 or NWC support in a deployment |


<a id="keep-three-records"></a>

## Keep three records

A payment record answers whether an invoice or transfer settled. An execution
record answers what work ran. An evidence record identifies the result and
retained artifacts. Link them by a stable job reference and reconcile uncertain
states rather than treating any one as proof of the others.

For a paid service, state whether the price covers an execution attempt, a
report or acceptance of a result. Define retry, cancellation, expiry and refund
behaviour in that service's terms and verify it in the deployed release.


<a id="custody-depends-on-the-layer"></a>

## Custody depends on the layer

Hosted account documentation describes custodial Aeternity wallets. An external
wallet may keep its keys with the user. An operator-managed remote signer
restricts client actions but still has a key-custody boundary. A Lightning
payment can originate from either a custodial or a self-custodial wallet.

Document who controls keys or preimages, who can authorise or cancel an action,
and what happens on restart. Neither “Lightning” nor “utility token” establishes
a blanket non-custodial or non-escrow arrangement.


<a id="what-the-documentation-does-not-promise"></a>

## What the documentation does not promise

There is no general promise here of buybacks, instant token conversion,
reserve backing, guaranteed liquidity, automatic contractor settlement or
financial returns. A hold-invoice feature is not evidence that ordinary
top-ups escrow funds until a test passes.

The [token model](tokenomics.md) defines units and policy; the
[pricing guide](pricing.md) explains quotes. The
[capability matrix](articles/features_current.md) records implementation
and validation scope. Transaction-related obligations depend on the actual
service, not on the labels used in this documentation.