Hi everyone,
On 14 October, Theophilus (@extheo), Tobechukwuleta (@tobses), Brian (@bmosha) and I (@okjodom) met to compare SeD, ABSL and Pontmore proposals, and discuss how we could work together.
We agreed to focus our collaboration on Pontmore: bring SeD’s discovery ideas into its discovery layer, explore how ABSL’s settlement protections can complement its escrow and coordination model, and build tools that make the combined work usable.
This follows three conversations already underway here:
-
SeD: Decentralized Service Discovery & Evidence-Based Web of Trust
-
Introducing Pontmore: a Nostr-native protocol for agent discovery, escrow, and swaps
Our comparison helped clarify the different questions these proposals address:
| Proposal | Main question | Contribution to the collaboration |
|---|---|---|
| SeD | Who can I deal with, and who vouches for them? | Service discovery, capability signalling, identity management and locally evaluated reputation |
| Pontmore | What did we agree to, and what happened, in what order? | Shared discovery records, escrow descriptors and signed coordination histories |
| ABSL | What protection can a customer receive if a provider fails to deliver? | Exploring Bitcoin collateral, reserved capacity and remedies for provider default |
These responsibilities fit together across a transaction. A customer first needs to find a suitable provider, then agree on terms, coordinate execution and understand what protection applies if something goes wrong.
SeD brings useful ideas for finding providers by region, currency, payment rail and capacity, as well as separating permanent identity keys from operational keys. We discussed how these could strengthen Pontmore discovery for both commercial services and individual participants.
Pontmore provides the common coordination framework. Its current drafts separate Agent discovery, escrow compatibility and signed coordination chains, allowing applications to build around shared protocol records while retaining their own execution systems.
ABSL brings a valuable focus on the economics of a trade: whether a provider has capacity to accept an order, what collateral supports it, and what remedy is available after default. Its introduction also makes clear that this remains early prototype work. Incorporating these ideas will require further specification and validation.
The existing discussion on standalone escrows in Pontmore PIP-01 is particularly relevant here. It explores how clients can discover and use escrow services while keeping the descriptor, service implementation and transaction lifecycle clearly defined.
We agreed on the following initial responsibilities:
| Work | Lead |
|---|---|
| Distil SeD’s discovery ideas into Pontmore PIP-00 | Theo |
| Build a discovery SDK around the resulting specification | Tobe, following the discovery work |
| Distil relevant ABSL ideas into Pontmore PIP-01 and PIP-02 | Brian and Jodom |
| Share the direction and invite wider participation on OBA | Jodom |
These are starting responsibilities, and we welcome collaborators on each part.
Several questions still need careful work. How should reputation claims relate to verifiable interactions without exposing private transaction details? How can collateral requirements protect customers while remaining accessible to smaller providers? Which discovery concepts should be shared across applications, and which belong in specific profiles? How can the general protocol remain adaptable while making the security assumptions of each settlement mechanism explicit?
We would like to bring the wider Open Bitcoin Africa community into that work. Wallet builders, liquidity providers, payment operators, Nostr developers, escrow implementers and protocol reviewers all have practical experience that can improve the design.
You can contribute by reviewing the discovery proposal, helping build the SDK, mapping an ABSL order into a Pontmore coordination flow, or testing the model against a real corridor and payment rail. Independent implementations and concrete examples will help us identify where the specifications are clear and where assumptions remain.
Please join the discussion in this very thread, or open a focused issue in the Pontmore protocol repository. If you are already building something related, share the use case and the part you would like to work on.
Our next step is to turn this agreed direction into specifications and working implementations that we can review and test together.