DamageBDD Payment Flows and Custody Boundaries
Distinguish Lightning top-ups, DAMAGE execution spend, contractor payments, swap jobs and remote wallet permissions.
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 requires maintainer review and a recorded payment |
| Swap/hold-invoice job | Coordinate a conditional invoice, job state and contract action | The integration reference 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 does not establish complete L402 or NWC support in a deployment |
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.
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.
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 defines units and policy; the pricing guide explains quotes. The capability matrix records implementation and validation scope. Transaction-related obligations depend on the actual service, not on the labels used in this documentation.