please consider reducing your dependence upon github as a discussion space! they have begun load-shedding archival requests, in a manner that makes the archival effort worse than useless... and meanwhile, they DDoS themselves through vibe coding the VScode integrations that overload their own infrastructure

find below, the lazy-stacker-friendly exfil of your proposal:

Enable an opt-in market where a fidelity-bond owner delegates a short-lived certificate key to a maker operator in exchange for payment, without transferring the bond key or allowing the operator to spend the bond.

This is already possible at the cryptographic layer: the bond key signs a certificate public key, and the certificate key signs maker nick proofs. Rental was also raised during the original fidelity-bond discussion: https://github.com/JoinMarket-Org/joinmarket-clientserver/issues/371

Proposed flow

The renter generates the certificate key locally.

The owner verifies the bond terms and signs fidelity-bond-cert|<cert_pub>|<expiry>.

The signature is delivered after Lightning payment, potentially using the payment preimage to decrypt it.

The renter imports the bond metadata and certificate and operates the maker until expiry.

The bond owner remains offline and retains sole spending control.

A baseline experiment does not require wire-protocol change.

Questions

Exclusivity: The owner can issue unlimited overlapping certificates. Existing certificates cannot prove an exclusive lease.

Revocation: A certificate is a bearer credential. The owner cannot revoke it before expiry.

Sybil resistance: JoinMarket NG deduplicates offers sharing one bond outpoint, so one bond cannot gain multiple slots in one orderbook snapshot. However, rental lowers the attacker's custody and coordination burden. The goal is for renting prices to still reflect the bond's opportunity cost.

Privacy: Every renter reveals the same bond outpoint. The renter can rotate from different FBs, and the bond owners should not really know who is renting it each time if contacted through Tor and paid over LN.. A positive side effect is that maker clustering becomes harder and bond renting breaks the heuristic of a FB always being linked to the same wallet.

Abuse: A dishonest owner can double-lease, while a dishonest renter can damage the bond's reputation or disrupt makers until expiry. Maybe we should consider some cheating proofs like !blacklist does with used PoDLE commitments.

Fair exchange: Pay-to-decrypt can make delivery conditional on payment, but does not prove exclusivity or prevent issuance of another certificate. And AFAIK can't be made really atomic. Is there a way for the operator to prove that the encrypted blob contains a valid signature for the renter's cert without a scrow?

This should remain experimental and opt-in until double-leasing and Sybil-cost effects are understood. But since it's already possible, it's probably better to embrace it and be aware of its effects.