ÐMP Hardening Patch – All Five Areas

Status: Integrated into protocols/dmp/spec.md and protocols/dmp/changelog.md. This file is kept as a design record; normative text lives in the spec.

Original patch notes (pre-merge)

Apply to protocols/dmp/spec.md (pre-launch draft)

1. Bid / Accept Linkage (add to §7 Settlement and §15.3)

New MUST rules:

MUST-099: If a settle references an offer_id, the referenced offer op MUST exist, MUST be in PENDING or ACCEPTED state at the time of settlement, and its inscription_id MUST match the settle’s inscription_id.

MUST-100: If a settle references both list_id/auction_id and offer_id, the offer MUST be the one that was accepted against that listing/auction (indexers MUST verify the offer’s target_list_id or target_auction_id matches the referenced listing/auction).

MUST-101: A settle that references an offer_id MUST use the offer’s buyer as the settle buyer. Any mismatch is INVALID.

Placement suggestion: Add after existing MUST-097 / MUST-098 in the Settlement Integrity section.

2. Timestamp Sanity Checks (new subsection in §3 or §14)

New MUST rules:

MUST-102: All ts fields (in list, offer, accept, settle, cancel, bid, etc.) MUST be within ±2 hours of the median-time-past of the block containing the inscription. Indexers MUST reject any operation with ts outside this window as INVALID.

MUST-103: When comparing ts values (e.g. offer expiration checks), implementations MUST use the ts value from the inscription itself, not the containing block’s timestamp. This prevents miners from influencing expiration logic via block timestamp manipulation.

Placement suggestion: Add as new subsection “3.12 Timestamp Sanity” or merge into §14 Reorg & Finality.

3. Multi-Sig Cancel Ergonomics & Safety (add to §8 Cancel and §15)

New MUST rules:

MUST-104: A cancel operation on a multi-signer listing or auction MUST be signed by a sufficient number of the original signers as declared in the required_signatures field of the original operation. Indexers MUST verify both the signature count and the public keys.

MUST-105: Once a listing or auction has received any valid offer or bid, a cancel is only valid if signed by all original signers (no partial multi-sig cancels allowed after negotiation has started).

MUST-106: Every cancel operation MUST include a reason field using one of the following values: seller_request, expired, buyer_breach, admin_emergency, other. Indexers SHOULD display the reason for transparency.

Placement suggestion: Add to §8 (Cancel) and reference in §15 Security Considerations.

4. Royalty Edge Case – Zero Royalty (add to §4.3 Royalty)

New MUST rule:

MUST-107: If royalty_bps is set to 0 on a listing or collection, then royalty_paid on any corresponding settle MUST also be 0. Any non-zero royalty_paid value when royalty_bps = 0 is INVALID.

Placement suggestion: Add as final bullet in the Royalty subsection of §4.3.

5. Offer Expiration Clarity (add to §6.2 Offer Lifecycle)

New MUST rule:

MUST-108: An offer whose expires_at timestamp is in the past at the time the settle inscription is confirmed is INVALID for settlement, even if the offer was previously in ACCEPTED state. Indexers MUST check expires_at against the settlement inscription’s block time (or median-time-past).

Placement suggestion: Add after existing offer expiration language in §6.2.

Changelog Entry (add to protocols/dmp/changelog.md)

v1.1 (2026-05-08) – Pre-launch Hardening

• Added MUST-099–101: Strong bid/accept linkage rules for settlement.
• Added MUST-102–103: Timestamp sanity window (±2h) and requirement to use inscription ts (not block time).
• Added MUST-104–106: Multi-sig cancel safety (full signer requirement after negotiation starts + mandatory reason field).
• Added MUST-107: Zero royalty enforcement (royalty_paid must be 0 when royalty_bps = 0).
• Added MUST-108: Offer expiration is checked at settlement time against block time.
• Extended §15 Security Considerations with new §15.3 settlement reference edge cases.
• Updated reorg handling language in §14.1 for clarity.

Validation note: After applying, run python spec/scripts/validate_repo.py from the monorepo root to confirm no breakage.

This patch closes the highest-impact remaining vectors while keeping the spec readable and implementable. Ready to apply.