Context
PIP-03 correctly scopes itself as governing dispute classes, evidence,
and resolution modes at the operator layer , the core rule is explicit:
the swap state machine is public
the dispute process is operator-governed
For swaps settled via mobile money (M-Pesa, etc.), there's no on-chain
verification of the fiat leg, so resolution effectively comes down to the
operator/arbitrator judging received evidence (payment reference, transfer
receipt, operator note, etc.) and picking a resolution mode.
The Issue
This is structurally the classic 2-of-3 escrow trust problem: whoever
resolves the dispute can collude with either the buyer or the seller to
steal funds, and the counterparty has no recourse beyond that resolution.
Since (per PIP-00) the Nostr pubkey is the agent there's no separate
identity layer , a malicious operator can burn a pubkey after a profitable
collusion and simply spin up a new one. Nothing in PIP-00–PIP-03 as written
appears to constrain this.
Questions
- Is arbitrator/operator reputation intended to be a protocol-level concern
at all, or is it explicitly left to the application/discovery layer?
- Is a web-of-trust, staking, or bonding mechanism envisioned for agents who take on arbitrator/resolution roles even as a future PIP or is pubkey-churn considered out of scope for this protocol family?
- If reputation is meant to live at the application layer, should PIP-03
say so explicitly (e.g. a note that resolution-actor accountability is
NOT a protocol guarantee), so implementers don't assume otherwise?
Context
PIP-03 correctly scopes itself as governing dispute classes, evidence,
and resolution modes at the operator layer , the core rule is explicit:
For swaps settled via mobile money (M-Pesa, etc.), there's no on-chain
verification of the fiat leg, so resolution effectively comes down to the
operator/arbitrator judging received evidence (payment reference, transfer
receipt, operator note, etc.) and picking a resolution mode.
The Issue
This is structurally the classic 2-of-3 escrow trust problem: whoever
resolves the dispute can collude with either the buyer or the seller to
steal funds, and the counterparty has no recourse beyond that resolution.
Since (per PIP-00) the Nostr pubkey is the agent there's no separate
identity layer , a malicious operator can burn a pubkey after a profitable
collusion and simply spin up a new one. Nothing in PIP-00–PIP-03 as written
appears to constrain this.
Questions
at all, or is it explicitly left to the application/discovery layer?
say so explicitly (e.g. a note that resolution-actor accountability is
NOT a protocol guarantee), so implementers don't assume otherwise?