Building Pontmore: From Protocol Spec to Working Standalone Escrow POC

When I opened PR #12 on the Pontmore protocol repository, my objective was to determine if a standard method could be established for applications to interact directly with an escrow service, bypassing the need for a swap state machine. Indeed, the answer was affirmative, yet the journey from specification to a functional proof-of-concept (POC) and ultimately to a streamlined protocol taught me far more than I anticipated regarding the creation of interoperable financial infrastructure.

The Problem: PIP-01 Was Discovery-Only

PIP-01, or the Pontmore Escrow Descriptor, initially served a narrowly defined purpose: enabling agents to discover compatible escrow mechanisms for fiat-to-Bitcoin swaps. It functioned as a discovery tool, not an execution engine. An example descriptor from before PR #12 appeared as follows:

```json

{

"version": 1,

"escrow_type": "lightning_hold_invoice",

"networks": ["bitcoin", "lightning"],

"funding_rules": {

"required_confirmation": "invoice_held"

},

"release_rules": {

"release_trigger": "counterparty_fiat_payment_confirmed"

},

"dispute_rules": {

"policy": "operator_resolved"

}

}

```

This descriptor informed agents that the escrow existed and was compatible with Lightning hold invoices. However, it did not elucidate the process for a standalone application to create, fund, release, or cancel an escrow. Such details were implicitly defined within PIP-02's swap state machine, necessitating the use of a swap for escrow operations. No mechanism existed for an application to declare, "I require an escrow between two parties; please create one for me."

PR #12: The Standalone Service Interface

The catalyst behind this change was Issue #11: the need to define escrow service invocation within PIP-01. The resolution came in the form of an optional service block integrated into the descriptor. This addition provided applications with guidance on direct interaction with the escrow, encompassing endpoints, authentication, operations, funding models, and release decision formats. The revised specification outlined the following elements:

- **Transport:** HTTPS as the primary protocol, with provision for additional transport methods

- **Authentication:** Nostr HTTP authentication (NIP-98), utilizing Nostr public keys as unique identifiers, eliminating the need for bearer tokens

- **Canonical Operations:** Create, funding instructions, fund status, release, refund, split, cancel

- **Funding Models:** Single funder, two-party, and m-of-n configurations

- **Release Decisions:** Mutual consent, operator decision, oracle signature, application signature result, and threshold participant signatures

- **Wire Contract:** A schema URL referencing a normative OpenAPI document

The resulting descriptor now included a comprehensive service contract:

```json

{

"version": 1,

"escrow_type": "custodial_escrow",

"networks": ["lightning"],

"funding_rules": {

"required_confirmation": "invoice_paid",

"funding_timeout": 86400_seconds

},

"release_rules": {

"release_trigger": "application_signed_result",

"refund_trigger": "timeout_or_dispute_refund_decision"

},

"dispute_rules": {

"policy": "operator_resolved"

},

"service": {

"transport": ["https"],

"interface": "pontmore_escrow_http_v1",

"endpoint": "https://escrow.example.com/pontmore/v1",

"auth": ["nostr_http_auth"],

"operations": ["create", "funding_instructions", "fund_status", "release", "refund", "cancel"],

"funding_model": ["single_funder", "two_party", "m_of_n"],

"release_decisions": ["mutual_consent", "operator_decision", "application_signed_result"],

"schema_url": "https://escrow.example.com/pontmore/v1/openapi/v1.0.0.json"

}

}

```

This update also addressed structural loopholes identified during implementation, such as cross-instance replay protection (requiring oracle/threshold signatures to commit to the stable escrow ID), enforcement of funding-phase timeouts (ensuring refunds for partially-funded escrows), and deadlock prevention mechanisms (mandating non-consent fallbacks in timeout paths using mutual consent).

PR #12 was merged on August 11, 2026, following constructive review feedback that prompted the creation of PR #17. The feedback highlighted a deeper design tension: the specification could be simplified by deferring service, transport, and interface details to an OpenAPI schema document. Although PIP-01 was initially tasked with defining service behavior, endpoints, state machines, and decision formats, the reviewer advocated for these operational semantics to be contained within the referenced schema, thereby minimizing the scope of the generic PIP-01 spec.

The POC: Building Against PR #12

While the specification underwent review, I was tasked with constructing a functional implementation to substantiate the viability of the proposed concept. The outcome was pontmore-lightning-escrow, a custodial escrow service operating on Render, leveraging Blink Lightning custody and Supabase persistence. The service is accessible at standalone-escrow.onrender.com and has undergone real-world Lightning escrow transactions during testing.

Architecture

The architecture of pontmore-lightning-escrow includes:

- **Nostr Relays:** Facilitate communication using the Nostr protocol.

- **HTTPS Clients:** Interact with the escrow service via HTTPS, supporting tools like rollpot, curl, and third-party applications.

- **Express Server:** Acts as the central server, handling requests and responses in accordance with the defined OpenAPI schema.