Research challenge: peer-to-peer escrow without a custodian or adjudicator

[okjodom]

Pontmore is an open, Nostr-native protocol for discovering Agents and coordinating economic activity through participant-signed, verifiable event chains. Its coordination layer can record who authorized an outcome; it cannot by itself make an escrow enforce that outcome.

This leaves a hard problem for peer-to-peer Bitcoin–fiat trades. The fiat payment happens outside the protocol, so cryptography cannot directly prove that a bank or mobile-money transfer arrived. With a Lightning hold invoice, the party controlling the preimage may be able to withhold it after receiving fiat, while the invoice eventually refunds the Bitcoin payer. A resolver's signed decision alone cannot change that lock.

Pontmore's resolver-recoverable preimage (RRP) draft explores giving a bound resolver the cryptographic ability to recover the preimage. That may make a ruling enforceable without giving the resolver custody, but it still relies on a third-party adjudicator and has unresolved security questions, including selective abort. It does not meet the stricter goal of a trade with neither a third-party custodian nor adjudicator.

Research challenge

Can two participants exchange Bitcoin for off-chain fiat with no trusted custodian or adjudicator, while ensuring that:

• neither party can unilaterally take both sides of the trade;
• a timeout or an unresponsive peer does not silently decide a disputed outcome;
• the accepted lock and its recovery path can be verified before fiat is sent; and
• the design fits real wallet capabilities, privacy needs, and lock-duration limits?

Please share protocol designs, relevant proofs or impossibility results, threat models, wallet experiments, and test vectors. If these goals cannot all be met together, what is the smallest trust, oracle, or incentive assumption required—and how should clients explain it?

Existing designs to learn from

• Bisq uses 2-of-2 trade escrow and a time-locked fallback, with separate mediation, arbitration, and DAO processes. It removes a third-party key from the escrow spend path, while retaining human dispute processes.
• Hodl Hodl uses 2-of-3 multisig with buyer, seller, and platform keys. It provides a concrete recovery model, with the platform as a trusted third signer.
• Mostro coordinates Lightning hold-invoice trades and operator-run dispute resolution. It shows a live Lightning approach, with the operator involved in settlement.

These systems make different trust trade-offs; none is presented here as solving the complete no-custodian, no-adjudicator challenge.

Pontmore context

• PIP-01: escrow descriptors
• PIP-02: coordination event chains
• pontmore/swap@1 profile
• Escrow policies and exchange patterns research
• Related: #22 accepted-swap recovery and #27 Spark hold-invoice escrow

This is an open research question, not a proposed normative change to the current PIPs.