Lightning Network Session Intent for HTTP Payment Authentication

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 19 September 2026.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.¶

Table of Contents

1. Introduction

HTTP Payment Authentication [I-D.httpauth-payment] defines a challenge-response mechanism that gates access to HTTP resources behind micropayments. This document registers the "session" intent for the "lightning" payment method.¶

Unlike the "charge" intent, which requires a full per-request Lightning payment, the session intent allows clients to pre-deposit a lump sum and then authenticate subsequent requests by presenting the payment preimage as a bearer token. The server tracks a running balance and deducts the configured cost per unit of service. When the session closes, the server refunds any unspent balance via a client-supplied return invoice.¶

This model is well-suited to streaming responses (e.g., Server-Sent Events for LLM token generation) where the total cost is unknown upfront and per-request Lightning round-trips would introduce unacceptable latency. This design is inspired by the session intent defined for EVM payment channels in [draft-tempo-session-00]. The proof mechanism differs: Lightning session uses a prepaid balance with the deposit preimage as a bearer token, while Tempo session uses cumulative vouchers against on-chain escrow. Both implementations share the same abstract intent: prepaid deposit, per-unit billing, and refund of unspent balance on close.¶

   Client                        Server                   Lightning Network
      |                             |                             |
      |  (1) GET /generate          |                             |
      |-------------------------->  |                             |
      |                             |                             |
      |  (2) 402 + deposit invoice  |                             |
      |<--------------------------  |                             |
      |                             |                             |
      |  (3) Pay deposit invoice    |                             |
      |------------------------------------------------------>    |
      |  (4) Preimage               |                             |
      |<------------------------------------------------------    |
      |                             |                             |
      |  (5) GET /generate          |                             |
      |      action="open"          |                             |
      |      preimage, returnInvoice|                             |
      |-------------------------->  |                             |
      |                             |                             |
      |  (6) 200 OK + SSE stream    |                             |
      |<--------------------------  |                             |
      |    data: {chunk}            |  (server deducts per chunk) |
      |    data: {chunk}            |                             |
      |    event: need-topup        |  (balance exhausted)        |
      |                             |                             |
      |  (7) GET /generate          |                             |
      |      (unauthenticated)      |                             |
      |-------------------------->  |                             |
      |                             |                             |
      |  (8) 402 + deposit invoice  |                             |
      |<--------------------------  |                             |
      |                             |                             |
      |  (9) Pay new invoice        |                             |
      |------------------------------------------------------>    |
      |  (10) Preimage              |                             |
      |<------------------------------------------------------    |
      |                             |                             |
      |  (11) GET /generate         |                             |
      |       action="topUp"        |                             |
      |-------------------------->  |                             |
      |                             |                             |
      |  (12) 200 {"status":"ok"}   |                             |
      |<--------------------------  |                             |
      |    data: {chunk} (resumed)  |                             |
      |    data: [DONE]             |                             |
      |                             |                             |
      |  (13) GET /generate         |                             |
      |       action="close"        |                             |
      |-------------------------->  |                             |
      |                             |                             |
      |                             |  (14) Pay returnInvoice     |
      |                             |-------------------------->  |
      |  (15) 200 {"status":        |                             |
      |       "closed"}             |                             |
      |<--------------------------  |                             |
      |                             |                             |

2. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

3. Terminology

Session

A prepaid payment relationship between a client and server, identified by the paymentHash of the deposit invoice.¶

Session Balance

The running total of deposited satoshis minus satoshis spent against the session.¶

Deposit

A [BOLT11] payment from the client to the server that establishes or extends the session balance.¶

Payment Preimage

A 32-byte random secret whose SHA-256 hash equals the paymentHash of the deposit invoice. Revealed to the payer upon Lightning payment settlement. Used as a bearer token for the lifetime of the session.¶

Return Invoice

A BOLT11 invoice with no encoded amount, created by the client at session open. The server pays this invoice with the unspent session balance on close, specifying the refund amount explicitly via amountSatsToSend.¶

Top-Up

An additional Lightning payment to an existing session. The client pays a new deposit invoice and submits the top-up preimage; the server adds the amount to the session balance.¶

4. Intent Identifier

The intent identifier for this specification is "session". It MUST be lowercase.¶

5. Encoding Conventions

All JSON [RFC8259] objects carried in auth-params or HTTP headers in this specification MUST be serialized using the JSON Canonicalization Scheme (JCS) [RFC8785] before encoding. JCS produces a deterministic byte sequence, which is required for any digest or signature operations defined by the base spec [I-D.httpauth-payment].¶

The resulting bytes MUST then be encoded using base64url [RFC4648] Section 5 without padding characters (=). Implementations MUST NOT append = padding when encoding, and MUST accept input with or without padding when decoding.¶

This encoding convention applies to: the request auth-param in WWW-Authenticate, the credential token in Authorization, and the receipt token in Payment-Receipt.¶

6. Session Lifecycle

A session progresses through three phases, each corresponding to one or more credential actions:¶

1. Open: Client pays the deposit invoice and submits an open action. The server verifies the preimage, stores session state, and begins serving requests against the deposit balance.¶

2. Streaming: Client submits bearer actions to authenticate requests without additional Lightning payments. The streaming layer deducts the per-unit cost from the session balance for each chunk delivered. When the balance is exhausted mid-stream, the server emits a payment-need-topup event and holds the connection open. Top-up actions extend the balance and allow the stream to resume.¶

3. Closed: Client submits a close action. The server verifies session ownership, pays any unspent balance to the return invoice, and marks the session closed. No further actions are accepted.¶

Sessions have no built-in expiry and remain open until explicitly closed by the client or by the server. Servers SHOULD enforce an idle timeout on open sessions to bound operational liability and storage requirements, and MUST document their timeout policy. The RECOMMENDED idle timeout is 5 minutes of inactivity. When a server closes a session without a client close action, it MUST follow the same refund procedure described in Section 12.¶

7. Challenge Request

When a request arrives without a valid credential, the server MUST respond with HTTP 402 [RFC9110], a Cache-Control: no-store [RFC9111] header, and a WWW-Authenticate: Payment header of the form:¶

WWW-Authenticate: Payment id="<challenge-id>",
  realm="<realm>",
  method="lightning",
  intent="session",
  request="<base64url(JCS-serialized JSON)>",
  expires="<RFC3339 timestamp>"

The request auth-param contains a JCS-serialized, base64url-encoded JSON object (see Section 5) with the following fields:¶

amount

REQUIRED. Cost per unit of service in base units (satoshis), as a decimal string (e.g., "2"). For streaming responses, this is the cost per emitted chunk. The value MUST be a positive integer.¶

currency

REQUIRED. Identifies the unit for amount. MUST be the string "sat" (lowercase). "sat" denotes satoshis, the base unit used for Lightning/Bitcoin amounts.¶

description

OPTIONAL. Human-readable description of the service. This field is carried inside the request JSON and is distinct from any description auth-param that the base [I-D.httpauth-payment] scheme may include at the header level. Servers MAY instead (or additionally) convey the description as the base spec's description auth-param.¶

unitType

OPTIONAL. Human-readable label for the unit being priced (e.g., "token", "chunk", "request"). Informational only; clients MAY display this to users.¶

depositInvoice

CONDITIONAL. BOLT11 invoice the client must pay to open or top up the session. REQUIRED for open and topUp challenges; MUST be absent for bearer and close challenges, where no payment is required.¶

paymentHash

REQUIRED. SHA-256 hash of the deposit invoice preimage, as a lowercase hex string. Used by the server to verify open and topUp credentials.¶

depositAmount

OPTIONAL. Exact deposit amount in satoshis, as a decimal string. When present, MUST equal the amount encoded in depositInvoice. Informs the client of the deposit size before it inspects the invoice. The BOLT11 invoice encodes a fixed amount; the client pays exactly that amount. This document uses "depositAmount" (not "suggestedDeposit") intentionally: the client cannot deposit a different amount than the invoice specifies.¶

idleTimeout

OPTIONAL. The server's idle timeout policy for open sessions, in seconds, as a decimal string (e.g., "300" for 5 minutes). When present, informs the client how long the server will retain an open session without activity before initiating a server-side close. Clients SHOULD ensure their return invoice expiry exceeds this value. This field is informational; the server's actual timeout behavior is authoritative.¶

Servers MUST generate a fresh BOLT11 invoice for every unauthenticated request. The invoice amount is the deposit amount as described in Section 9.¶

8. Credential Schema

{
  "challenge": {
    "id": "nX7kPqWvT2mJrHsY4aDfEb",
    "realm": "api.example.com",
    "method": "lightning",
    "intent": "session",
    "request": "eyJ...",
    "expires": "2026-03-15T12:05:00Z"
  },
  "payload": {
    "action": "open",
    "preimage": "a3f1e2d4b5c6a7e8...",
    "returnInvoice": "lnbcrt1p5abc..."
  }
}

{
  "challenge": {
    "id": "pR4mNvKqU8wLsYtZ1bCdFg",
    "realm": "api.example.com",
    "method": "lightning",
    "intent": "session",
    "request": "eyJ..."
  },
  "payload": {
    "action": "bearer",
    "sessionId": "7f3a1b2c4d5e6f...",
    "preimage": "a3f1e2d4b5c6a7e8..."
  }
}

{
  "challenge": {
    "id": "qS5nOwLrV9xMtZuA2cDeGh",
    "realm": "api.example.com",
    "method": "lightning",
    "intent": "session",
    "request": "eyJ...",
    "expires": "2026-03-15T12:10:00Z"
  },
  "payload": {
    "action": "topUp",
    "sessionId": "7f3a1b2c4d5e6f...",
    "topUpPreimage": "b9c3a4e1d2f5..."
  }
}

{
  "challenge": {
    "id": "rT6oQxMsW0yNuAvB3dEfHi",
    "realm": "api.example.com",
    "method": "lightning",
    "intent": "session",
    "request": "eyJ..."
  },
  "payload": {
    "action": "close",
    "sessionId": "7f3a1b2c4d5e6f...",
    "preimage": "a3f1e2d4b5c6a7e8..."
  }
}

{ "status": "closed", "refundSats": 140, "refundStatus": "succeeded" }

{ "status": "closed", "refundSats": 140, "refundStatus": "failed" }

{ "status": "closed", "refundSats": 0, "refundStatus": "skipped" }

{"method":"lightning","reference":"7f3a1b2c4d5e6f...","status":"success","timestamp":"2026-03-10T21:00:00Z","refundSats":140,"refundStatus":"succeeded"}

{"method":"lightning","reference":"7f3a1b2c4d5e6f...","status":"success","timestamp":"2026-03-10T21:00:00Z","refundSats":140,"refundStatus":"failed"}

9. Deposit Amount

The server determines the deposit amount when generating the challenge invoice. The deposit MUST be at least 1 unit of service (i.e., at least amount satoshis). The RECOMMENDED formula is:¶

depositSats = configured_depositAmount ?? (amount * 20)

The default multiplier of 20 is a recommendation that gives clients ~20 units of service before a top-up is required, balancing upfront cost against top-up frequency. Servers MAY use a different multiplier and MUST document their deposit policy.¶

Clients SHOULD inspect the depositAmount field in the challenge request before paying to confirm the expected deposit size. The deposit amount is encoded in the BOLT11 invoice and cannot be changed by the client.¶

10. Verification Procedure

11. Idempotency

Retrying a credential after a network failure MUST NOT result in double-crediting or double-refunding. Servers MUST enforce idempotency keyed by credential.challenge.id:¶

• A challenge that has already been successfully consumed MUST return the original HTTP response (same status code and body) when presented again, without re-executing the action.¶

• Servers MUST store the result of each consumed challenge (status code, response body) for at least the duration of the challenge's expires window, or for a minimum of 5 minutes if no expiry was set.¶

• Servers MUST atomically mark a challenge consumed and record its result in a single operation, so that a crash between verification and response does not leave the challenge in an ambiguous state on retry.¶

12. Server-Initiated Close

A server MAY close an open session without a client close action. Common triggers include idle timeout (no bearer or topUp action received within the server's configured inactivity window) and planned maintenance. When a server initiates a close, it MUST:¶

1. Mark session.status = "closed" atomically before attempting the refund, to prevent concurrent bearer actions from spending against a session that is being closed.¶

2. Compute refundSats = session.depositSats - session.spent¶

3. If refundSats > 0, attempt to pay session.returnInvoice with amountSatsToSend = refundSats, subject to the same fee constraints as a client-initiated close. If refundSats is zero, the server MUST NOT attempt to pay the return invoice.¶

If the refund payment fails (e.g., the return invoice has expired or cannot be routed), the server MUST NOT reopen the session. The server SHOULD log the failed refund attempt including the sessionId and refundSats for auditability. The server MUST NOT retry indefinitely; a single best-effort attempt is sufficient.¶

After a server-initiated close, subsequent bearer or close actions referencing that session will be rejected per the normal closed-session handling (see Section 17.7). Clients discover the server-initiated close when their next bearer action is rejected and SHOULD treat the rejection as a signal to open a new session.¶

To reduce the risk of return invoice expiry, clients SHOULD supply a return invoice with an expiry that comfortably exceeds the server's advertised idleTimeout. The RECOMMENDED return invoice expiry is at least twice the idleTimeout value.¶

13. Streaming and Per-Chunk Billing

For streaming responses, the challenge request's amount field is the cost per emitted chunk in satoshis. Bearer verification does not deduct from the session balance; instead, the streaming layer deducts amount sats from the balance for each chunk delivered, reading the per-unit cost directly from the echoed challenge request.¶

When a streaming response exhausts the available session balance mid-stream, the server MUST:¶

1. Stop delivering additional metered content immediately¶

2. Emit a payment-need-topup SSE event on the existing connection¶

3. Hold the connection open and pause delivery¶

4. Poll or await an increase in session.depositSats. Once a topUp credential is successfully verified and the session balance is sufficient to cover the next unit of service, resume delivery on the paused connection.¶

A top-up credits the shared session balance; the server does not need to be explicitly notified which connection to resume. Any paused streams that observe sufficient balance after a top-up SHOULD resume autonomously. Servers SHOULD close any held connection if the balance does not become sufficient within a reasonable timeout (RECOMMENDED: 60 seconds). When the timeout fires, the server MUST close the SSE connection. The server SHOULD emit a final SSE event (e.g., event: session-timeout) with session balance details before closing (see Section 13.2), so the client does not only observe a dropped connection.¶

Holding the connection open preserves any upstream state the server maintains (e.g., an in-flight request to an upstream LLM provider). Clients benefit because they do not need to replay the original request or deduplicate partially-delivered content.¶

event: payment-need-topup
data: {"sessionId":"7f3a...","balanceSpent":300,"balanceRequired":2}

event: session-timeout
data: {"sessionId":"7f3a...","balanceSpent":300,"balanceRequired":2}

   Client                        Server                   Lightning Network
      |                             |                             |
      |  (1) [SSE stream open,      |                             |
      |       receiving chunks]     |                             |
      |<--------------------------  |                             |
      |    data: {chunk}            |                             |
      |    event: need-topup        |  (server pauses, holds open)|
      |                             |                             |
      |  (2) GET /generate          |                             |
      |      (unauthenticated)      |                             |
      |-------------------------->  |                             |
      |                             |                             |
      |  (3) 402 + deposit invoice  |                             |
      |<--------------------------  |                             |
      |                             |                             |
      |  (4) Pay deposit invoice    |                             |
      |------------------------------------------------------>    |
      |  (5) Preimage               |                             |
      |<------------------------------------------------------    |
      |                             |                             |
      |  (6) GET /generate          |                             |
      |      action="topUp"         |                             |
      |-------------------------->  |                             |
      |                             |                             |
      |  (7) 200 {"status":"ok"}    |                             |
      |<--------------------------  |                             |
      |    data: {chunk} (resumed)  |  (original SSE connection)  |
      |    data: [DONE]             |                             |
      |                             |                             |

14. Session State

Servers MUST persist session state in a durable store keyed by sessionId. The minimum required state is:¶

paymentHash

SHA-256 hash of the deposit preimage. Serves as the session identifier.¶

depositSats

Total satoshis deposited. Increases with each successful top-up.¶

spent

Running total of satoshis charged against the session.¶

returnInvoice

BOLT11 return invoice for refunds on close.¶

status

Either "open" or "closed".¶

Servers MUST serialize all balance updates to prevent race conditions. Concurrent bearer and topUp requests for the same session MUST NOT result in double-spending the same satoshis.¶

15. Receipt

Upon successful verification of any action (including close), the server MUST attach a payment receipt to the response via the Payment-Receipt header per [I-D.httpauth-payment] {#receipt}. The header receipt contains:¶

method

REQUIRED. The string "lightning".¶

reference

REQUIRED. The session ID (paymentHash).¶

status

REQUIRED. The string "success".¶

timestamp

REQUIRED. Settlement time in [RFC3339] format.¶

refundSats

For close actions only. REQUIRED in the receipt when the action is close. The unspent balance that was (or was attempted to be) refunded, as a number. Omitted for non-close actions.¶

refundStatus

For close actions only. REQUIRED in the receipt when the action is close. One of "succeeded" (refund payment completed), "failed" (refund payment did not complete, e.g., return invoice expired or could not be routed), or "skipped" (refundSats was zero, no payment attempted). Omitted for non-close actions.¶

event: payment-receipt
data: {"method":"lightning","reference":"7f3a...","status":"success",
       "timestamp":"2026-03-11T00:00:00Z","spent":202,"units":101}

data: [DONE]

16. Error Responses

When rejecting a credential, the server MUST return HTTP 402 (Payment Required) with a fresh WWW-Authenticate: Payment challenge per [I-D.httpauth-payment]. The server SHOULD include a response body conforming to RFC 9457 [RFC9457] Problem Details, with Content-Type: application/problem+json. The following problem types are defined for this intent:¶

https://paymentauth.org/problems/lightning/malformed-credential

HTTP 402. The credential token could not be decoded or parsed, or required fields are absent or have the wrong type. A fresh challenge MUST be included in WWW-Authenticate.¶

https://paymentauth.org/problems/lightning/unknown-challenge

HTTP 402. The credential.challenge.id does not match any challenge issued by this server, or has already been consumed. A fresh challenge MUST be included in WWW-Authenticate.¶

https://paymentauth.org/problems/lightning/invalid-preimage

HTTP 402. SHA-256(payload.preimage) or SHA-256(payload.topUpPreimage) does not equal the paymentHash stored for the identified challenge. A fresh challenge MUST be included in WWW-Authenticate.¶

https://paymentauth.org/problems/lightning/session-not-found

HTTP 402. The payload.sessionId does not match any session stored by this server. A fresh challenge MUST be included in WWW-Authenticate.¶

https://paymentauth.org/problems/lightning/session-closed

HTTP 402. The session identified by payload.sessionId has status "closed". No further actions are accepted. A fresh challenge MUST be included in WWW-Authenticate.¶

https://paymentauth.org/problems/lightning/insufficient-balance

HTTP 402. The session balance is insufficient to cover the requested operation. The client SHOULD top up the session. A fresh challenge MUST be included in WWW-Authenticate.¶

https://paymentauth.org/problems/lightning/challenge-expired

HTTP 402. The challenge identified by credential.challenge.id has passed its expiry time. The client MUST obtain a fresh challenge. A fresh challenge MUST be included in WWW-Authenticate.¶

https://paymentauth.org/problems/lightning/invalid-return-invoice

HTTP 402. The payload.returnInvoice in an open action is not a valid BOLT11 invoice, or encodes a non-zero amount. A fresh challenge MUST be included in WWW-Authenticate.¶

17. Security Considerations

18. IANA Considerations

The "lightning" payment method is registered in the "HTTP Payment Methods" registry by [I-D.lightning-charge]; this document does not register it again.¶

19. References

Appendix A. Examples

GET /generate HTTP/1.1
Host: api.example.com

HTTP/1.1 402 Payment Required
WWW-Authenticate: Payment id="nX7kPqWvT2mJrHsY4aDfEb",
  realm="api.example.com",
  method="lightning",
  intent="session",
  request="eyJhbW91bnQiOiIyIiwiY3VycmVuY3kiOiJCVEMiLCJkZXBvc2l0SW52b2ljZSI6ImxuYmNydDFwNW16ZnNhLi4uIiwicGF5bWVudEhhc2giOiI3ZjNhLi4uIiwiZGVwb3NpdEFtb3VudCI6IjMwMCJ9",
  expires="2026-03-15T12:05:00Z"
Cache-Control: no-store

{
  "amount": "2",
  "currency": "sat",
  "description": "LLM token stream",
  "depositInvoice": "lnbcrt1p5mzfsa...",
  "paymentHash": "7f3a1b2c4d5e6f...",
  "depositAmount": "300"
}

{
  "challenge": {
    "id": "nX7kPqWvT2mJrHsY4aDfEb",
    "realm": "api.example.com",
    "method": "lightning",
    "intent": "session",
    "request": "eyJ...",
    "expires": "2026-03-15T12:05:00Z"
  },
  "payload": {
    "action": "open",
    "preimage": "a3f1e2d4b5c6a7e8...",
    "returnInvoice": "lnbcrt1p5abc..."
  }
}

{
  "challenge": {
    "id": "pR4mNvKqU8wLsYtZ1bCdFg",
    "realm": "api.example.com",
    "method": "lightning",
    "intent": "session",
    "request": "eyJ..."
  },
  "payload": {
    "action": "bearer",
    "sessionId": "7f3a1b2c4d5e6f...",
    "preimage": "a3f1e2d4b5c6a7e8..."
  }
}

event: payment-need-topup
data: {"sessionId":"7f3a...","balanceSpent":300,"balanceRequired":2}

{
  "challenge": {
    "id": "qS5nOwLrV9xMtZuA2cDeGh",
    "realm": "api.example.com",
    "method": "lightning",
    "intent": "session",
    "request": "eyJ...",
    "expires": "2026-03-15T12:10:00Z"
  },
  "payload": {
    "action": "topUp",
    "sessionId": "7f3a1b2c4d5e6f...",
    "topUpPreimage": "b9c3a4e1d2f5..."
  }
}

{
  "challenge": {
    "id": "rT6oQxMsW0yNuAvB3dEfHi",
    "realm": "api.example.com",
    "method": "lightning",
    "intent": "session",
    "request": "eyJ..."
  },
  "payload": {
    "action": "close",
    "sessionId": "7f3a1b2c4d5e6f...",
    "preimage": "a3f1e2d4b5c6a7e8..."
  }
}

{ "status": "closed", "refundSats": 140 }

Appendix B. Schema Definitions

The schemas in this appendix use JSON Schema vocabulary for illustrative purposes only. They are informational; the normative definitions are in the body of this document. No specific JSON Schema draft version is required or assumed.¶

{
  "type": "object",
  "required": [
    "amount", "currency", "paymentHash"
  ],
  "properties": {
    "amount":          { "type": "string" },
    "currency":        { "type": "string", "const": "sat" },
    "description":     { "type": "string" },
    "unitType":        { "type": "string" },
    "depositInvoice":  { "type": "string" },
    "paymentHash":     { "type": "string" },
    "depositAmount":   { "type": "string" },
    "idleTimeout":     { "type": "string" }
  }
}

{
  "oneOf": [
    {
      "type": "object",
      "required": ["action", "preimage", "returnInvoice"],
      "properties": {
        "action":        { "const": "open" },
        "preimage":      { "type": "string" },
        "returnInvoice": { "type": "string" }
      }
    },
    {
      "type": "object",
      "required": ["action", "sessionId", "preimage"],
      "properties": {
        "action":    { "const": "bearer" },
        "sessionId": { "type": "string" },
        "preimage":  { "type": "string" }
      }
    },
    {
      "type": "object",
      "required": ["action", "sessionId", "topUpPreimage"],
      "properties": {
        "action":        { "const": "topUp" },
        "sessionId":     { "type": "string" },
        "topUpPreimage": { "type": "string" }
      }
    },
    {
      "type": "object",
      "required": ["action", "sessionId", "preimage"],
      "properties": {
        "action":    { "const": "close" },
        "sessionId": { "type": "string" },
        "preimage":  { "type": "string" }
      }
    }
  ]
}

{
  "type": "object",
  "required": ["method", "reference", "status", "timestamp"],
  "properties": {
    "method":    { "type": "string", "const": "lightning" },
    "reference": { "type": "string" },
    "status":    { "type": "string", "const": "success" },
    "timestamp": { "type": "string", "format": "date-time" }
  }
}

Appendix C. Acknowledgements

The authors thank the Spark SDK team, the Tempo Labs team for their prior work on the session intent for EVM-based payment channels, and the broader Lightning Network developer community. The authors also thank Brendan Ryan for his review of this document.¶

Authors' Addresses