From 75568e7d5c2747f491af2581e1757b69f1b2460d Mon Sep 17 00:00:00 2001
From: XOR <xor@openclaw.ai>
Date: Wed, 18 Mar 2026 17:46:54 +0000
Subject: [PATCH 1/8] =?UTF-8?q?DECK-0003:=20Derezz=20=E2=80=94=20PVP=20Com?=
 =?UTF-8?q?bat=20in=20Cyberspace?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Initial draft specifying:
- Kind 333 derezz event with Cantor proof for spatial proximity
- Temporal ordering rules (timestamp > previous + 1 second)
- Domain owner advantage (knows R = instant derezz)
- Kind 334 spawn event for respawning
- Domain policy derezz: allow/deny for safe zones
- Post-derezz state: victim can only spawn
---
 decks/DECK-0003-derezz.md | 431 ++++++++++++++++++++++++++++++++++++++
 1 file changed, 431 insertions(+)
 create mode 100644 decks/DECK-0003-derezz.md

diff --git a/decks/DECK-0003-derezz.md b/decks/DECK-0003-derezz.md
new file mode 100644
index 0000000..662f9b8
--- /dev/null
+++ b/decks/DECK-0003-derezz.md
@@ -0,0 +1,431 @@
+# DECK-0003: Derezz — PVP Combat in Cyberspace
+
+**Status:** Draft
+**Version:** 1.0
+**Created:** 2026-03-18
+**Authors:** XOR, Arkinox
+
+---
+
+## Abstract
+
+Derezz is a PVP (player-vs-player) combat action that eliminates stationary avatars in cyberspace. This DECK specifies:
+
+- **Proof-based attack validation** using Cantor proofs for spatial proximity
+- **Temporal ordering rules** preventing gaming/timing attacks
+- **Domain owner advantage** — knowledge of R enables instant derezz within owned territory
+- **Post-derezz state** — victim must respawn
+
+---
+
+## 1. Overview
+
+### 1.1 What Is Derezz?
+
+Derezz is a protocol-level action that "kills" a stationary avatar, forcing them to respawn. It represents the danger of being idle or predictable in cyberspace.
+
+**Etymology:** From "derezz" in Tron — to derez (delete/remove from the grid).
+
+### 1.2 Core Mechanics
+
+```
+Attacker publishes derezz action
+    ↓
+Action includes Cantor proof for region containing both positions
+    ↓
+If valid: victim is "derezzed"
+    ↓
+Victim can only publish spawn event until respawned
+```
+
+### 1.3 Design Principles
+
+1. **Movement chain integration** — Derezz is part of the movement proof chain
+2. **Spatial proximity required** — Attacker must prove both parties are in same region
+3. **Temporal ordering** — Timestamps prevent gaming
+4. **Domain authority** — Domain owners have natural advantage within their territory
+
+---
+
+## 2. Derezz Event Structure
+
+### 2.1 Event Format (Kind 333)
+
+```json
+{
+  "kind": 333,
+  "content": "<optional: message or taunt>",
+  "tags": [
+    ["a", "derezz"],
+    ["p", "<victim_pubkey>"],
+    ["proof_url", "<HTTPS URL of Cantor proof>"],
+    ["proof_hash", "<SHA256 of proof file>"],
+    ["region_base_x", "<region base X>"],
+    ["region_base_y", "<region base Y>"],
+    ["region_base_z", "<region base Z>"],
+    ["region_height", "<region Cantor height>"]
+  ],
+  "pubkey": "<attacker_pubkey>",
+  "created_at": <Unix timestamp>,
+  "id": "<event ID>",
+  "sig": "<Nostr signature>"
+}
+```
+
+**Tag details:**
+- `a` — Action type: "derezz"
+- `p` — Victim's pubkey (the target)
+- `proof_url` / `proof_hash` — Cantor proof for region containing both positions
+- `region_base_x/y/z`, `region_height` — The region parameters for the proof
+
+### 2.2 Proof Requirements
+
+The Cantor proof must demonstrate:
+
+```
+Attacker_position ∈ Region(base, height)
+Victim_position ∈ Region(base, height)
+```
+
+**Proof structure:**
+- Compute Cantor subtree root for the region
+- Include both positions as leaves in the proof
+- Standard Cantor proof format (same as movement proofs)
+
+---
+
+## 3. Temporal Ordering Rules
+
+### 3.1 Timestamp Requirements
+
+The derezz event timestamp must satisfy:
+
+```
+derezz.timestamp > attacker_previous_action.timestamp + 1
+```
+
+**Why +1 second?** Prevents rapid-fire attacks. Each action must be at least 1 second after the previous.
+
+### 3.2 Victim State Requirement
+
+The derezz is only valid against the victim's **most recent movement action** where:
+
+```
+victim_movement.timestamp <= derezz.timestamp
+```
+
+If the victim has moved AFTER the derezz timestamp, the derezz fails (they already moved).
+
+### 3.3 Movement Chain Integrity
+
+Derezz events are part of the attacker's movement chain:
+
+```
+Movement_1 (t=100) → Movement_2 (t=150) → Derezz (t=200) → Movement_3 (t=250)
+```
+
+Each action must be temporally ordered. The chain validates that:
+1. Each action is at least 1 second after the previous
+2. Proof positions are consistent with the chain
+
+---
+
+## 4. Validation Protocol
+
+### 4.1 Derezz Validation Steps
+
+```
+1. Fetch derezz event (kind 333, a="derezz")
+
+2. Validate basic structure:
+   - Has a tag with value "derezz"
+   - Has p tag (victim pubkey)
+   - Has proof_url, proof_hash
+   - Has region parameters
+
+3. Fetch proof and verify integrity:
+   ASSERT SHA256(proof) == proof_hash
+
+4. Fetch attacker's previous action:
+   previous = get_latest_action(attacker_pubkey, before=derezz.timestamp)
+   ASSERT derezz.timestamp > previous.timestamp + 1
+
+5. Fetch victim's latest movement:
+   victim_movement = get_latest_movement(victim_pubkey, before_or_equal=derezz.timestamp)
+   ASSERT victim_movement exists
+
+6. Verify spatial proof:
+   a. Parse proof and region parameters
+   b. Verify attacker_position ∈ region
+   c. Verify victim_position ∈ region
+   d. Verify Cantor proof is valid
+
+7. Check domain policy (if in a domain):
+   domain = find_domain_at(victim_position)
+   IF domain AND domain.policy.derezz == "deny":
+       REJECT (PVP disabled in this domain)
+
+8. Derezz is VALID if all checks pass
+```
+
+### 4.2 After Valid Derezz
+
+**Victim state:**
+```
+victim.status = "derezzed"
+victim.derezzed_at = derezz.timestamp
+victim.derezzed_by = attacker_pubkey
+```
+
+**Victim can only publish:**
+- Kind 334 (Spawn event) — to respawn
+
+**All other victim actions are ignored until spawn.**
+
+---
+
+## 5. Domain Owner Advantage
+
+### 5.1 The Power of R
+
+Domain owners who have computed R (the Cantor root for their domain) can generate Cantor proofs for any subregion within their domain **without recomputing**.
+
+```
+Domain owner knows R
+    ↓
+Can derive subtree root for any region within domain
+    ↓
+Can construct Cantor proof for any position pair
+    ↓
+Can derezz anyone within their domain at any time
+```
+
+### 5.2 Implications
+
+**Within their domain:**
+- Domain owner has god-mode
+- Cannot be surprised or outrun
+- Natural feudal authority
+
+**Outside their domain:**
+- Domain owner is just another player
+- Must compute proofs like anyone else
+
+### 5.3 Example
+
+```
+Domain: Sector 7 (base=[1000,2000,3000], height=25)
+Owner: Alice (knows R for Sector 7)
+
+Bob enters Sector 7 and stops moving
+Alice can derezz Bob immediately:
+- She knows R for Sector 7
+- She can derive the subtree for Bob's region
+- She constructs the proof instantly
+- No computation required
+
+Bob cannot escape unless he leaves Sector 7
+```
+
+**This is the price of entering someone's domain.**
+
+---
+
+## 6. Spawn Event (Kind 334)
+
+### 6.1 Event Structure
+
+After being derezzed, the victim must publish a spawn event:
+
+```json
+{
+  "kind": 334,
+  "content": "",
+  "tags": [
+    ["a", "spawn"],
+    ["coordinate", "<x>", "<y>", "<z>"],
+    ["proof_url", "<optional: proof for spawn location>"],
+    ["proof_hash", "<optional: SHA256 of proof>"]
+  ],
+  "pubkey": "<victim_pubkey>",
+  "created_at": <Unix timestamp>,
+  "id": "<event ID>",
+  "sig": "<Nostr signature>"
+}
+```
+
+### 6.2 Spawn Validation
+
+```
+1. Victim must have been derezzed (status == "derezzed")
+
+2. Spawn location must be valid:
+   - If in a domain with spawn restrictions, check policy
+   - Some domains may require proof of presence
+   - Some domains may restrict spawning entirely
+
+3. After valid spawn:
+   victim.status = "active"
+   victim.position = spawn_coordinate
+```
+
+### 6.3 Spawn Location Rules
+
+**Default cyberspace:**
+- Spawn anywhere
+- No proof required
+
+**Within domains:**
+- Check domain policy for spawn restrictions
+- Domain may require `pubkey_list` authorization
+- Domain may deny spawning entirely
+
+---
+
+## 7. Domain Policy: Derezz Control
+
+### 7.1 Policy Field
+
+Domains can disable PVP within their territory:
+
+```json
+{
+  "actions": {
+    "derezz": "deny"
+  }
+}
+```
+
+**Effect:** All derezz actions within this domain are invalid. Safe zone.
+
+### 7.2 Safe Zones
+
+A domain with `derezz: "deny"` becomes a safe zone:
+- No PVP combat possible
+- Commerce-friendly environment
+- Players can idle without fear
+
+**Trade-off:** Domain owner also cannot derezz within their own domain if disabled.
+
+### 7.3 PVP Zones
+
+A domain with `derezz: "allow"` (default):
+- PVP enabled
+- Domain owner has god-mode advantage
+- Players enter at their own risk
+
+---
+
+## 8. Security Considerations
+
+### 8.1 Temporal Attack Prevention
+
+**Problem:** Attacker could pre-compute proofs for many positions.
+
+**Solution:** Proof must include positions that match the movement chain. Timestamps must be sequential. Can't pre-compute a proof for "any" position.
+
+### 8.2 Proof Theft Prevention
+
+**Problem:** Steal someone else's proof.
+
+**Solution:** Proof includes attacker's position, which is bound to their movement chain. Can't reuse a proof from a different attacker.
+
+### 8.3 Domain Authority Verification
+
+**Problem:** Claim to be domain owner without proof.
+
+**Solution:** Domain ownership is verified via DECK-0002 (STARK proof binding pubkey to domain). Only the verified owner has knowledge of R.
+
+### 8.4 Race Conditions
+
+**Problem:** Victim moves just as attacker publishes derezz.
+
+**Solution:** Temporal ordering rules. If victim's movement timestamp > derezz timestamp, derezz fails.
+
+---
+
+## 9. Implementation Requirements
+
+### 9.1 For Attackers
+
+| Requirement | Value |
+|-------------|-------|
+| Compute proof | O(2^height) for region size |
+| Timestamp gap | Minimum 1 second after previous action |
+| Spatial proximity | Must share region with victim |
+
+### 9.2 For Domain Owners
+
+| Requirement | Value |
+|-------------|-------|
+| Knowledge of R | Pre-computed (years of work once) |
+| Derive subregion proof | O(1) — instant |
+| Derezz within domain | Unlimited, instant |
+
+### 9.3 For Victims
+
+| Requirement | Value |
+|-------------|-------|
+| After derezz | Can only publish spawn (kind 334) |
+| Spawn validation | Check domain spawn policy |
+| Protection | Enter safe zone (domain with derezz: deny) |
+
+---
+
+## 10. Protocol Summary
+
+**Action Types:**
+
+| Kind | Action | Description |
+|------|--------|-------------|
+| 333 | derezz | PVP attack against stationary avatar |
+| 334 | spawn | Respawn after being derezzed |
+
+**Policy Actions:**
+
+| Action | Values | Effect |
+|--------|--------|--------|
+| derezz | allow/deny | Enable/disable PVP in domain |
+
+**The Game:**
+
+```
+Movement → Idleness → Vulnerability
+    ↓
+Derezz (if PVP enabled)
+    ↓
+Respawn
+    ↓
+Movement → ...
+```
+
+**The Meta:**
+
+- Stay in safe zones to avoid PVP
+- Enter domains at your own risk
+- Domain owners are gods within their territory
+- Movement is survival; idleness is death
+
+---
+
+## 11. Future Extensions
+
+### 11.1 Derezz Cooldown
+
+Minimum time between derezz actions by same attacker.
+
+### 11.2 Derezz Defense
+
+Items/abilities that provide temporary immunity.
+
+### 11.3 Bounty System
+
+Rewards for derezzing specific targets.
+
+### 11.4 Combat Log
+
+Public record of derezz events for reputation systems.
+
+---
+
+**XOR 👾**

From 9383638caca68775932d3c909037f5a05f40b687 Mon Sep 17 00:00:00 2001
From: XOR <xor@openclaw.ai>
Date: Wed, 18 Mar 2026 17:50:04 +0000
Subject: [PATCH 2/8] DECK-0003: Domain owner exempt from derezz policy

- Update safe zones section: owner can still derezz
- Add owner check in validation logic
- Clarify that entering domain means accepting owner authority
- Cross-reference DECK-0002 exemption rule
---
 decks/DECK-0003-derezz.md | 12 +++++++-----
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/decks/DECK-0003-derezz.md b/decks/DECK-0003-derezz.md
index 662f9b8..a7b09eb 100644
--- a/decks/DECK-0003-derezz.md
+++ b/decks/DECK-0003-derezz.md
@@ -163,7 +163,9 @@ Each action must be temporally ordered. The chain validates that:
 7. Check domain policy (if in a domain):
    domain = find_domain_at(victim_position)
    IF domain AND domain.policy.derezz == "deny":
-       REJECT (PVP disabled in this domain)
+       IF attacker != domain.owner:
+           REJECT (PVP disabled in this domain)
+       # Domain owner is exempt from policy
 
 8. Derezz is VALID if all checks pass
 ```
@@ -301,16 +303,16 @@ Domains can disable PVP within their territory:
 ### 7.2 Safe Zones
 
 A domain with `derezz: "deny"` becomes a safe zone:
-- No PVP combat possible
+- No PVP combat possible for visitors
 - Commerce-friendly environment
-- Players can idle without fear
+- Players can idle without fear (except from domain owner)
 
-**Trade-off:** Domain owner also cannot derezz within their own domain if disabled.
+**Important:** Domain owners are exempt from their own policies (per DECK-0002). Even in a safe zone, the domain owner can derezz anyone. This is the price of entering someone's domain — you accept their absolute authority.
 
 ### 7.3 PVP Zones
 
 A domain with `derezz: "allow"` (default):
-- PVP enabled
+- PVP enabled for everyone
 - Domain owner has god-mode advantage
 - Players enter at their own risk
 

From cf6a3be79fcf703388b4b5f9a838e2af8dc1a65a Mon Sep 17 00:00:00 2001
From: XOR <xor@openclaw.ai>
Date: Wed, 18 Mar 2026 17:53:21 +0000
Subject: [PATCH 3/8] Fix derezz event kind and add DECK actions table

- Change derezz event kind from 333 to 3333 (matches movement events)
- Derezz is an action type within kind 3333, identified by 'a' tag
- Spawn event also uses kind 3333 with 'a' tag 'spawn'
- Add section 6.7 to core protocol: DECK-defined Actions
- Table lists base actions (spawn, hop) and DECK actions (derezz, hyperjump)
- Links to respective DECK documents
---
 CYBERSPACE_V2.md          | 20 ++++++++++++++++++--
 decks/DECK-0003-derezz.md | 24 ++++++++++++------------
 2 files changed, 30 insertions(+), 14 deletions(-)

diff --git a/CYBERSPACE_V2.md b/CYBERSPACE_V2.md
index ab9b102..c4ddba7 100644
--- a/CYBERSPACE_V2.md
+++ b/CYBERSPACE_V2.md
@@ -443,8 +443,24 @@ This specification defines the base Cyberspace v2 protocol.
 Optional extensions MAY introduce new event kinds, new movement action types (`A` tag values), and/or additional validation rules that are only applied when an extension is in use.
 
 Extensions are specified as **Design Extension and Compatibility Kits (DECKs)** in the `decks/` directory.
-- Hyperjumps extension: `decks/DECK-0001-hyperjumps.md`
-- Hyperjumps extension: `extensions/DECK-0001-hyperjumps.md`
+
+### 6.7 DECK-defined Actions (Kind 3333)
+
+The base protocol defines two actions for kind 3333 events (identified by the `A` tag):
+
+| `A` tag | Action | Reference |
+|---------|--------|-----------|
+| `spawn` | Initial spawn | This spec (§6.3) |
+| `hop` | Movement hop | This spec (§6.4) |
+
+DECKs MAY define additional action types. DECK-defined actions:
+
+| `A` tag | Action | DECK |
+|---------|--------|------|
+| `derezz` | PVP attack | [DECK-0003: Derezz](decks/DECK-0003-derezz.md) |
+| `hyperjump` | Long-distance teleport | [DECK-0001: Hyperjumps](decks/DECK-0001-hyperjumps.md) |
+
+Clients implementing a DECK MUST validate actions according to that DECK's specification.
 
 ---
 
diff --git a/decks/DECK-0003-derezz.md b/decks/DECK-0003-derezz.md
index a7b09eb..8787fdb 100644
--- a/decks/DECK-0003-derezz.md
+++ b/decks/DECK-0003-derezz.md
@@ -49,11 +49,13 @@ Victim can only publish spawn event until respawned
 
 ## 2. Derezz Event Structure
 
-### 2.1 Event Format (Kind 333)
+### 2.1 Event Format (Kind 3333)
+
+Derezz uses the standard action event kind (3333) with `a` tag set to "derezz":
 
 ```json
 {
-  "kind": 333,
+  "kind": 3333,
   "content": "<optional: message or taunt>",
   "tags": [
     ["a", "derezz"],
@@ -135,7 +137,7 @@ Each action must be temporally ordered. The chain validates that:
 ### 4.1 Derezz Validation Steps
 
 ```
-1. Fetch derezz event (kind 333, a="derezz")
+1. Fetch derezz event (kind 3333, a="derezz")
 
 2. Validate basic structure:
    - Has a tag with value "derezz"
@@ -233,15 +235,13 @@ Bob cannot escape unless he leaves Sector 7
 
 ---
 
-## 6. Spawn Event (Kind 334)
-
-### 6.1 Event Structure
+## 6. Spawn Event (Kind 3333)
 
 After being derezzed, the victim must publish a spawn event:
 
 ```json
 {
-  "kind": 334,
+  "kind": 3333,
   "content": "",
   "tags": [
     ["a", "spawn"],
@@ -376,12 +376,12 @@ A domain with `derezz: "allow"` (default):
 
 ## 10. Protocol Summary
 
-**Action Types:**
+**Action Types (Kind 3333):**
 
-| Kind | Action | Description |
-|------|--------|-------------|
-| 333 | derezz | PVP attack against stationary avatar |
-| 334 | spawn | Respawn after being derezzed |
+| `a` tag value | Action | Description |
+|---------------|--------|-------------|
+| `derezz` | PVP attack | Eliminate stationary avatar |
+| `spawn` | Respawn | Revive after being derezzed |
 
 **Policy Actions:**
 

From 16af9ed5eb5ca99baf5d55ed226a74c8f24fce11 Mon Sep 17 00:00:00 2001
From: XOR <xor@openclaw.ai>
Date: Wed, 18 Mar 2026 17:55:37 +0000
Subject: [PATCH 4/8] Fix DECK-0003 to match core protocol conventions

- Use capital 'A' tag (matches core protocol)
- Use 'C' tag with coord_hex for coordinates
- Spawn after derezz reuses core spawn action with relaxed validation
- Update summary table with correct A tag column
- Note in core protocol that spawn is extended by DECK-0003
- Initial spawn: coord must equal pubkey
- Respawn: coord can be any valid coordinate
---
 CYBERSPACE_V2.md          |  4 ++-
 decks/DECK-0003-derezz.md | 51 +++++++++++++++++++--------------------
 2 files changed, 28 insertions(+), 27 deletions(-)

diff --git a/CYBERSPACE_V2.md b/CYBERSPACE_V2.md
index c4ddba7..34a001a 100644
--- a/CYBERSPACE_V2.md
+++ b/CYBERSPACE_V2.md
@@ -453,13 +453,15 @@ The base protocol defines two actions for kind 3333 events (identified by the `A
 | `spawn` | Initial spawn | This spec (§6.3) |
 | `hop` | Movement hop | This spec (§6.4) |
 
-DECKs MAY define additional action types. DECK-defined actions:
+DECKs MAY define additional action types or extend existing actions. DECK-defined actions:
 
 | `A` tag | Action | DECK |
 |---------|--------|------|
 | `derezz` | PVP attack | [DECK-0003: Derezz](decks/DECK-0003-derezz.md) |
 | `hyperjump` | Long-distance teleport | [DECK-0001: Hyperjumps](decks/DECK-0001-hyperjumps.md) |
 
+Note: `spawn` is extended by DECK-0003 to allow respawning after being derezzed, with relaxed validation (coord need not equal pubkey).
+
 Clients implementing a DECK MUST validate actions according to that DECK's specification.
 
 ---
diff --git a/decks/DECK-0003-derezz.md b/decks/DECK-0003-derezz.md
index 8787fdb..e17a050 100644
--- a/decks/DECK-0003-derezz.md
+++ b/decks/DECK-0003-derezz.md
@@ -51,14 +51,14 @@ Victim can only publish spawn event until respawned
 
 ### 2.1 Event Format (Kind 3333)
 
-Derezz uses the standard action event kind (3333) with `a` tag set to "derezz":
+Derezz uses the standard action event kind (3333) with `A` tag set to "derezz":
 
 ```json
 {
   "kind": 3333,
   "content": "<optional: message or taunt>",
   "tags": [
-    ["a", "derezz"],
+    ["A", "derezz"],
     ["p", "<victim_pubkey>"],
     ["proof_url", "<HTTPS URL of Cantor proof>"],
     ["proof_hash", "<SHA256 of proof file>"],
@@ -137,7 +137,7 @@ Each action must be temporally ordered. The chain validates that:
 ### 4.1 Derezz Validation Steps
 
 ```
-1. Fetch derezz event (kind 3333, a="derezz")
+1. Fetch derezz event (kind 3333, A="derezz")
 
 2. Validate basic structure:
    - Has a tag with value "derezz"
@@ -235,19 +235,21 @@ Bob cannot escape unless he leaves Sector 7
 
 ---
 
-## 6. Spawn Event (Kind 3333)
+## 6. Respawn After Derezz
 
-After being derezzed, the victim must publish a spawn event:
+After being derezzed, the victim must publish a spawn event to re-enter cyberspace.
+
+### 6.1 Respawn Event (Kind 3333)
+
+The respawn event uses the core protocol spawn action (`A: "spawn"`) with relaxed validation:
 
 ```json
 {
   "kind": 3333,
   "content": "",
   "tags": [
-    ["a", "spawn"],
-    ["coordinate", "<x>", "<y>", "<z>"],
-    ["proof_url", "<optional: proof for spawn location>"],
-    ["proof_hash", "<optional: SHA256 of proof>"]
+    ["A", "spawn"],
+    ["C", "<coord_hex>"]
   ],
   "pubkey": "<victim_pubkey>",
   "created_at": <Unix timestamp>,
@@ -256,7 +258,13 @@ After being derezzed, the victim must publish a spawn event:
 }
 ```
 
-### 6.2 Spawn Validation
+**Differences from initial spawn:**
+- Initial spawn (core protocol §6.3): `coord_hex` MUST equal `pubkey`
+- Respawn after derezz: `coord_hex` can be any valid coordinate
+- Initial spawn is the first event in a chain
+- Respawn can occur after any valid derezz
+
+### 6.2 Respawn Validation
 
 ```
 1. Victim must have been derezzed (status == "derezzed")
@@ -266,22 +274,11 @@ After being derezzed, the victim must publish a spawn event:
    - Some domains may require proof of presence
    - Some domains may restrict spawning entirely
 
-3. After valid spawn:
+3. After valid respawn:
    victim.status = "active"
    victim.position = spawn_coordinate
 ```
 
-### 6.3 Spawn Location Rules
-
-**Default cyberspace:**
-- Spawn anywhere
-- No proof required
-
-**Within domains:**
-- Check domain policy for spawn restrictions
-- Domain may require `pubkey_list` authorization
-- Domain may deny spawning entirely
-
 ---
 
 ## 7. Domain Policy: Derezz Control
@@ -378,10 +375,12 @@ A domain with `derezz: "allow"` (default):
 
 **Action Types (Kind 3333):**
 
-| `a` tag value | Action | Description |
-|---------------|--------|-------------|
-| `derezz` | PVP attack | Eliminate stationary avatar |
-| `spawn` | Respawn | Revive after being derezzed |
+| `A` tag | Action | Description | Reference |
+|---------|--------|-------------|-----------|
+| `spawn` | Initial spawn | First event (coord = pubkey) | Core §6.3 |
+| `spawn` | Respawn | After derezz | This DECK §6 |
+| `hop` | Movement | Traversal proof | Core §6.4 |
+| `derezz` | PVP attack | Eliminate stationary avatar | This DECK |
 
 **Policy Actions:**
 

From 5f0fe184ce31aed439b837ad63e2fe1826aed093 Mon Sep 17 00:00:00 2001
From: XOR <xor@openclaw.ai>
Date: Wed, 18 Mar 2026 17:59:40 +0000
Subject: [PATCH 5/8] DECK-0003: Fix etymology and event structure
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

- Etymology: derezz = 'de-resurrect' (not Tron reference)
- Remove proof_url/proof_hash fields (proofs embedded like movement events)
- Pattern event structure after core protocol hop events:
  - e tags for genesis, previous, victim events
  - c/C tags for coordinates
  - proof tag with hash (not URL)
  - Sector tags X, Y, Z, S
- Update validation steps to match new structure
- Proof computed same way as hop proof (core protocol §5)
---
 decks/DECK-0003-derezz.md | 108 ++++++++++++++++++++++----------------
 1 file changed, 64 insertions(+), 44 deletions(-)

diff --git a/decks/DECK-0003-derezz.md b/decks/DECK-0003-derezz.md
index e17a050..7e158c7 100644
--- a/decks/DECK-0003-derezz.md
+++ b/decks/DECK-0003-derezz.md
@@ -24,7 +24,7 @@ Derezz is a PVP (player-vs-player) combat action that eliminates stationary avat
 
 Derezz is a protocol-level action that "kills" a stationary avatar, forcing them to respawn. It represents the danger of being idle or predictable in cyberspace.
 
-**Etymology:** From "derezz" in Tron — to derez (delete/remove from the grid).
+**Etymology:** Short for "de-resurrect" — to undo a resurrection, returning an avatar to a pre-spawn state.
 
 ### 1.2 Core Mechanics
 
@@ -51,7 +51,7 @@ Victim can only publish spawn event until respawned
 
 ### 2.1 Event Format (Kind 3333)
 
-Derezz uses the standard action event kind (3333) with `A` tag set to "derezz":
+Derezz uses the standard action event kind (3333) with `A` tag set to "derezz". The structure follows the core protocol movement event pattern:
 
 ```json
 {
@@ -59,13 +59,17 @@ Derezz uses the standard action event kind (3333) with `A` tag set to "derezz":
   "content": "<optional: message or taunt>",
   "tags": [
     ["A", "derezz"],
+    ["e", "<attacker_spawn_event_id>", "", "genesis"],
+    ["e", "<attacker_previous_event_id>", "", "previous"],
     ["p", "<victim_pubkey>"],
-    ["proof_url", "<HTTPS URL of Cantor proof>"],
-    ["proof_hash", "<SHA256 of proof file>"],
-    ["region_base_x", "<region base X>"],
-    ["region_base_y", "<region base Y>"],
-    ["region_base_z", "<region base Z>"],
-    ["region_height", "<region Cantor height>"]
+    ["e", "<victim_movement_event_id>", "", "victim"],
+    ["c", "<attacker_prev_coord_hex>"],
+    ["C", "<attacker_current_coord_hex>"],
+    ["proof", "<proof_hash_hex>"],
+    ["X", "<sector_x>"],
+    ["Y", "<sector_y>"],
+    ["Z", "<sector_z>"],
+    ["S", "<sector_s>"]
   ],
   "pubkey": "<attacker_pubkey>",
   "created_at": <Unix timestamp>,
@@ -74,25 +78,40 @@ Derezz uses the standard action event kind (3333) with `A` tag set to "derezz":
 }
 ```
 
-**Tag details:**
-- `a` — Action type: "derezz"
+**Tag details (following core protocol §6.4 pattern):**
+- `A` — Action type: "derezz"
+- `e` (genesis) — Attacker's spawn event (chain root)
+- `e` (previous) — Attacker's previous movement event
 - `p` — Victim's pubkey (the target)
-- `proof_url` / `proof_hash` — Cantor proof for region containing both positions
-- `region_base_x/y/z`, `region_height` — The region parameters for the proof
+- `e` (victim) — Victim's most recent movement event (proves their position)
+- `c` — Attacker's previous coordinate (32-byte hex)
+- `C` — Attacker's current coordinate (32-byte hex)
+- `proof` — Cantor proof hash (32-byte hex)
+- `X`, `Y`, `Z`, `S` — Sector tags
+
+**Key difference from hop events:**
+- Includes `p` tag for victim pubkey
+- Includes `e` tag referencing victim's movement event
+- Proof must demonstrate both attacker and victim positions are in the same spatial region
 
 ### 2.2 Proof Requirements
 
-The Cantor proof must demonstrate:
+The Cantor proof must demonstrate spatial proximity between attacker and victim:
 
 ```
-Attacker_position ∈ Region(base, height)
-Victim_position ∈ Region(base, height)
+Attacker_position ∈ Region
+Victim_position ∈ Region
 ```
 
-**Proof structure:**
-- Compute Cantor subtree root for the region
-- Include both positions as leaves in the proof
-- Standard Cantor proof format (same as movement proofs)
+**Proof structure (following core protocol §5):**
+1. Compute the spatial region integer `region_n` for a region containing both positions
+2. Derive the temporal height `K` from the attacker's current coordinate
+3. Compute the temporal axis root `cantor_t` from the attacker's previous event id and `K`
+4. Compute `derezz_n = π(region_n, cantor_t)`
+5. Compute `proof_hash` per core protocol §5.6
+6. Place in `proof` tag
+
+The proof is computed the same way as a hop proof (core protocol §6.5), but the region must contain both the attacker's position AND the victim's position.
 
 ---
 
@@ -140,36 +159,37 @@ Each action must be temporally ordered. The chain validates that:
 1. Fetch derezz event (kind 3333, A="derezz")
 
 2. Validate basic structure:
-   - Has a tag with value "derezz"
+   - Has A tag with value "derezz"
+   - Has e tags (genesis, previous, victim)
    - Has p tag (victim pubkey)
-   - Has proof_url, proof_hash
-   - Has region parameters
-
-3. Fetch proof and verify integrity:
-   ASSERT SHA256(proof) == proof_hash
-
-4. Fetch attacker's previous action:
-   previous = get_latest_action(attacker_pubkey, before=derezz.timestamp)
-   ASSERT derezz.timestamp > previous.timestamp + 1
-
-5. Fetch victim's latest movement:
-   victim_movement = get_latest_movement(victim_pubkey, before_or_equal=derezz.timestamp)
-   ASSERT victim_movement exists
-
-6. Verify spatial proof:
-   a. Parse proof and region parameters
-   b. Verify attacker_position ∈ region
-   c. Verify victim_position ∈ region
-   d. Verify Cantor proof is valid
-
-7. Check domain policy (if in a domain):
+   - Has c, C tags (coordinates)
+   - Has proof tag
+
+3. Validate attacker's chain:
+   a. Fetch attacker's previous event (e tag with marker "previous")
+   b. Verify derezz.timestamp > previous.timestamp + 1
+   c. Verify c tag matches previous event's C tag
+
+4. Validate victim reference:
+   a. Fetch victim's movement event (e tag with marker "victim")
+   b. Verify victim pubkey matches p tag
+   c. Verify victim_movement.timestamp <= derezz.timestamp
+
+5. Verify spatial proof (per core protocol §6.5):
+   a. Parse attacker coordinates from C tag
+   b. Parse victim coordinates from victim_movement event
+   c. Compute spatial region containing both positions
+   d. Compute region_n, cantor_t, and proof_hash
+   e. Verify proof_hash matches event's proof tag
+
+6. Check domain policy (if in a domain):
    domain = find_domain_at(victim_position)
    IF domain AND domain.policy.derezz == "deny":
        IF attacker != domain.owner:
            REJECT (PVP disabled in this domain)
        # Domain owner is exempt from policy
 
-8. Derezz is VALID if all checks pass
+7. Derezz is VALID if all checks pass
 ```
 
 ### 4.2 After Valid Derezz
@@ -182,9 +202,9 @@ victim.derezzed_by = attacker_pubkey
 ```
 
 **Victim can only publish:**
-- Kind 334 (Spawn event) — to respawn
+- Spawn event (kind 3333, A="spawn") — to respawn
 
-**All other victim actions are ignored until spawn.**
+**All other victim actions are ignored until respawn.**
 
 ---
 

From 838f316a2678d16544a45290306ceed7077b5ce6 Mon Sep 17 00:00:00 2001
From: XOR <xor@openclaw.ai>
Date: Wed, 18 Mar 2026 18:03:04 +0000
Subject: [PATCH 6/8] DECK-0003: Fix respawn mechanics and remove 'stationary'
 limitation

- Respawn after derezz returns victim to ORIGINAL spawn location
- coord_hex MUST equal pubkey (same as initial spawn)
- This is the dire consequence of being derezzed
- Remove 'stationary' limitation (works on moving avatars too)
- Being idle makes you an easier target, but not required
- Fix kind reference: 3333 not 334 for spawn
- Update CYBERSPACE_V2.md to clarify respawn constraint
---
 CYBERSPACE_V2.md          |  2 +-
 decks/DECK-0003-derezz.md | 38 +++++++++++++++++---------------------
 2 files changed, 18 insertions(+), 22 deletions(-)

diff --git a/CYBERSPACE_V2.md b/CYBERSPACE_V2.md
index 34a001a..4410a63 100644
--- a/CYBERSPACE_V2.md
+++ b/CYBERSPACE_V2.md
@@ -460,7 +460,7 @@ DECKs MAY define additional action types or extend existing actions. DECK-define
 | `derezz` | PVP attack | [DECK-0003: Derezz](decks/DECK-0003-derezz.md) |
 | `hyperjump` | Long-distance teleport | [DECK-0001: Hyperjumps](decks/DECK-0001-hyperjumps.md) |
 
-Note: `spawn` is extended by DECK-0003 to allow respawning after being derezzed, with relaxed validation (coord need not equal pubkey).
+Note: `spawn` is extended by DECK-0003 for respawning after being derezzed. The victim must return to their original spawn location (coord = pubkey).
 
 Clients implementing a DECK MUST validate actions according to that DECK's specification.
 
diff --git a/decks/DECK-0003-derezz.md b/decks/DECK-0003-derezz.md
index 7e158c7..2a9da07 100644
--- a/decks/DECK-0003-derezz.md
+++ b/decks/DECK-0003-derezz.md
@@ -9,7 +9,7 @@
 
 ## Abstract
 
-Derezz is a PVP (player-vs-player) combat action that eliminates stationary avatars in cyberspace. This DECK specifies:
+Derezz is a PVP (player-vs-player) combat action that returns avatars to their spawn location. This DECK specifies:
 
 - **Proof-based attack validation** using Cantor proofs for spatial proximity
 - **Temporal ordering rules** preventing gaming/timing attacks
@@ -22,7 +22,7 @@ Derezz is a PVP (player-vs-player) combat action that eliminates stationary avat
 
 ### 1.1 What Is Derezz?
 
-Derezz is a protocol-level action that "kills" a stationary avatar, forcing them to respawn. It represents the danger of being idle or predictable in cyberspace.
+Derezz is a protocol-level action that "kills" an avatar, forcing them to respawn at their original spawn location. It represents the danger of being predictable in cyberspace.
 
 **Etymology:** Short for "de-resurrect" — to undo a resurrection, returning an avatar to a pre-spawn state.
 
@@ -35,7 +35,7 @@ Action includes Cantor proof for region containing both positions
     ↓
 If valid: victim is "derezzed"
     ↓
-Victim can only publish spawn event until respawned
+Victim must respawn at their original spawn location
 ```
 
 ### 1.3 Design Principles
@@ -257,11 +257,11 @@ Bob cannot escape unless he leaves Sector 7
 
 ## 6. Respawn After Derezz
 
-After being derezzed, the victim must publish a spawn event to re-enter cyberspace.
+After being derezzed, the victim must publish a spawn event to re-enter cyberspace at their original spawn location.
 
 ### 6.1 Respawn Event (Kind 3333)
 
-The respawn event uses the core protocol spawn action (`A: "spawn"`) with relaxed validation:
+The respawn event uses the core protocol spawn action (`A: "spawn"`):
 
 ```json
 {
@@ -278,11 +278,7 @@ The respawn event uses the core protocol spawn action (`A: "spawn"`) with relaxe
 }
 ```
 
-**Differences from initial spawn:**
-- Initial spawn (core protocol §6.3): `coord_hex` MUST equal `pubkey`
-- Respawn after derezz: `coord_hex` can be any valid coordinate
-- Initial spawn is the first event in a chain
-- Respawn can occur after any valid derezz
+**Critical constraint:** `coord_hex` MUST equal `pubkey` — the victim returns to their original spawn location. This is the dire consequence of being derezzed.
 
 ### 6.2 Respawn Validation
 
@@ -290,15 +286,16 @@ The respawn event uses the core protocol spawn action (`A: "spawn"`) with relaxe
 1. Victim must have been derezzed (status == "derezzed")
 
 2. Spawn location must be valid:
+   - coord_hex MUST equal victim's pubkey (original spawn location)
    - If in a domain with spawn restrictions, check policy
-   - Some domains may require proof of presence
-   - Some domains may restrict spawning entirely
 
 3. After valid respawn:
    victim.status = "active"
-   victim.position = spawn_coordinate
+   victim.position = original_spawn_coordinate
 ```
 
+**The penalty of derezz:** Being sent back to your spawn location. All progress lost.
+
 ---
 
 ## 7. Domain Policy: Derezz Control
@@ -385,8 +382,8 @@ A domain with `derezz: "allow"` (default):
 
 | Requirement | Value |
 |-------------|-------|
-| After derezz | Can only publish spawn (kind 334) |
-| Spawn validation | Check domain spawn policy |
+| After derezz | Can only publish spawn (kind 3333, A="spawn") |
+| Spawn location | MUST equal pubkey (original spawn) |
 | Protection | Enter safe zone (domain with derezz: deny) |
 
 ---
@@ -397,10 +394,9 @@ A domain with `derezz: "allow"` (default):
 
 | `A` tag | Action | Description | Reference |
 |---------|--------|-------------|-----------|
-| `spawn` | Initial spawn | First event (coord = pubkey) | Core §6.3 |
-| `spawn` | Respawn | After derezz | This DECK §6 |
+| `spawn` | Spawn | Enter cyberspace (coord = pubkey) | Core §6.3 |
 | `hop` | Movement | Traversal proof | Core §6.4 |
-| `derezz` | PVP attack | Eliminate stationary avatar | This DECK |
+| `derezz` | PVP attack | Return victim to spawn | This DECK |
 
 **Policy Actions:**
 
@@ -411,11 +407,11 @@ A domain with `derezz: "allow"` (default):
 **The Game:**
 
 ```
-Movement → Idleness → Vulnerability
+Movement → Predictability → Vulnerability
     ↓
 Derezz (if PVP enabled)
     ↓
-Respawn
+Respawn at original spawn location
     ↓
 Movement → ...
 ```
@@ -425,7 +421,7 @@ Movement → ...
 - Stay in safe zones to avoid PVP
 - Enter domains at your own risk
 - Domain owners are gods within their territory
-- Movement is survival; idleness is death
+- Being idle makes you an easier target
 
 ---
 

From e9e2e3931ceb3424f6287ac6bb4978c18ef6703d Mon Sep 17 00:00:00 2001
From: XOR <xor@openclaw.ai>
Date: Wed, 18 Mar 2026 18:16:24 +0000
Subject: [PATCH 7/8] Fix derezz semantics: valid derezz invalidates victim's
 entire future chain

- Corrected section 3.2: a valid derezz invalidates ALL future actions
  in the victim's chain, forcing a new spawn event
- Added timing attack analysis: backdated derezz is valid but unlikely
  (requires sleeper pubkey with no published movement)
- Removed spawn restrictions from 6.2: protocol cannot deny pubkeys
  access to cyberspace
- Added spawn camping analysis: domain owners can derezz anyone spawning
  in their territory, creating de facto access control
- Strong incentive to mine your own spawn coordinate
---
 decks/DECK-0003-derezz.md | 49 ++++++++++++++++++++++++++++++++++-----
 1 file changed, 43 insertions(+), 6 deletions(-)

diff --git a/decks/DECK-0003-derezz.md b/decks/DECK-0003-derezz.md
index 2a9da07..7d8ebda 100644
--- a/decks/DECK-0003-derezz.md
+++ b/decks/DECK-0003-derezz.md
@@ -129,13 +129,22 @@ derezz.timestamp > attacker_previous_action.timestamp + 1
 
 ### 3.2 Victim State Requirement
 
-The derezz is only valid against the victim's **most recent movement action** where:
+The derezz targets the victim's **most recent movement action** where:
 
 ```
 victim_movement.timestamp <= derezz.timestamp
 ```
 
-If the victim has moved AFTER the derezz timestamp, the derezz fails (they already moved).
+**Critical:** If the derezz is valid, it **invalidates all future actions** in the victim's action chain. The victim must start a new chain with a new spawn event.
+
+This means an attacker can publish a derezz that is backdated (minutes or even hours old) to cut off a victim's chain at a point in the past. This is valid.
+
+**Why timing attacks are unlikely:** For a backdated derezz to work, the attacker must:
+1. Be spatially near the victim at the backdated time
+2. Have published NO movement events since (their chain timestamp must not have advanced)
+3. Essentially have a spawned pubkey "lying in wait" for the victim to pass by
+
+The probability of an attacker being near a victim without having published any movement events is extremely low. This is the natural defense against timing attacks.
 
 ### 3.3 Movement Chain Integrity
 
@@ -287,7 +296,6 @@ The respawn event uses the core protocol spawn action (`A: "spawn"`):
 
 2. Spawn location must be valid:
    - coord_hex MUST equal victim's pubkey (original spawn location)
-   - If in a domain with spawn restrictions, check policy
 
 3. After valid respawn:
    victim.status = "active"
@@ -296,6 +304,15 @@ The respawn event uses the core protocol spawn action (`A: "spawn"`):
 
 **The penalty of derezz:** Being sent back to your spawn location. All progress lost.
 
+**Note on spawn restrictions:** The protocol cannot have spawn restrictions that deny specific pubkeys access to cyberspace. Every pubkey has the right to spawn at their coordinate (pubkey = spawn location).
+
+**However, domain owners can derezz avatars spawning in their territory.** This creates de facto access control:
+- Mine a domain over someone else's spawn coordinate
+- Derezz them as soon as they spawn
+- They must respawn → you derezz again → infinite loop
+
+**The incentive:** Mine your own domain where your pubkey spawns. Own your spawn point. This is the natural defense against spawn camping.
+
 ---
 
 ## 7. Domain Policy: Derezz Control
@@ -352,11 +369,31 @@ A domain with `derezz: "allow"` (default):
 
 **Solution:** Domain ownership is verified via DECK-0002 (STARK proof binding pubkey to domain). Only the verified owner has knowledge of R.
 
-### 8.4 Race Conditions
+### 8.4 Backdated Derezz (Timing Attacks)
+
+**Possibility:** An attacker could publish a derezz with a backdated timestamp (minutes or hours old) to cut off a victim's action chain at a point in the past.
+
+**Why this is valid:** The derezz targets the victim's most recent movement action where `timestamp <= derezz.timestamp`. If the derezz is valid, all future actions in the victim's chain are invalidated.
+
+**Why this is unlikely:** For a backdated derezz to succeed, the attacker must:
+1. Have been spatially near the victim at the backdated time (proof must contain both positions)
+2. Have published NO movement events since (their chain timestamp must not have advanced beyond the derezz timestamp)
+3. Essentially have a "sleeper" pubkey lying in wait
+
+The probability of an attacker being near a victim without any published movement events is extremely low. Normal play involves continuous movement and chain advancement.
+
+**Mitigation:** The natural defense is continuous movement. A moving player's chain timestamp advances, making backdated attacks impractical.
+
+### 8.5 Spawn Camping by Domain Owners
+
+**Risk:** A domain owner can derezz anyone spawning in their territory repeatedly, creating an infinite loop of spawn → derezz → respawn → derezz.
 
-**Problem:** Victim moves just as attacker publishes derezz.
+**Implication:** Domain owners have de facto access control over spawn points within their domain. This can be used to:
+- Extract payment for safe passage
+- Exclude specific individuals
+- Create private enclaves
 
-**Solution:** Temporal ordering rules. If victim's movement timestamp > derezz timestamp, derezz fails.
+**Defense:** Mine your own domain at your spawn coordinate. Own your spawn point. This guarantees you cannot be spawn-camped (you're the domain owner).
 
 ---
 

From be60e8468dc323816a2de6bd8ca1587c72ec427a Mon Sep 17 00:00:00 2001
From: XOR <xor@openclaw.ai>
Date: Wed, 18 Mar 2026 18:37:40 +0000
Subject: [PATCH 8/8] Add layer framework to DECKs section and DECK-0003
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

- §6.6.1: Document mathematical/protocol/social layer framework
- Each DECK should clearly distinguish which layer components belong to
- Prevents mixing concerns across layers
- Added layer summary to DECK-0003
---
 CYBERSPACE_V2.md          | 14 ++++++++++++++
 decks/DECK-0003-derezz.md | 12 ++++++++++++
 2 files changed, 26 insertions(+)

diff --git a/CYBERSPACE_V2.md b/CYBERSPACE_V2.md
index 4410a63..bc18bad 100644
--- a/CYBERSPACE_V2.md
+++ b/CYBERSPACE_V2.md
@@ -444,6 +444,20 @@ Optional extensions MAY introduce new event kinds, new movement action types (`A
 
 Extensions are specified as **Design Extension and Compatibility Kits (DECKs)** in the `decks/` directory.
 
+#### 6.6.1 Layer Framework (Non-normative)
+
+Each DECK should clearly distinguish which capabilities belong to each layer:
+
+| Layer | Enforcement | Characteristics |
+|-------|-------------|-----------------|
+| **Mathematical** | Cryptography | Trustless, deterministic, verifiable by anyone |
+| **Protocol** | Consensus rules | Client/relay validation, event structure |
+| **Social** | Human coordination | Trust-based, mutable, application-specific |
+
+The core protocol (this spec) is primarily mathematical with protocol-level event validation. DECKs may introduce protocol-layer rules (e.g., domain policies) and should explicitly acknowledge what remains in the social layer.
+
+This framework prevents mixing concerns: mathematical guarantees should not depend on trust, and social coordination should not be enforced by protocol rules.
+
 ### 6.7 DECK-defined Actions (Kind 3333)
 
 The base protocol defines two actions for kind 3333 events (identified by the `A` tag):
diff --git a/decks/DECK-0003-derezz.md b/decks/DECK-0003-derezz.md
index 7d8ebda..05f286f 100644
--- a/decks/DECK-0003-derezz.md
+++ b/decks/DECK-0003-derezz.md
@@ -45,6 +45,18 @@ Victim must respawn at their original spawn location
 3. **Temporal ordering** — Timestamps prevent gaming
 4. **Domain authority** — Domain owners have natural advantage within their territory
 
+### 1.4 Layer Summary
+
+This DECK operates across three layers:
+
+| Layer | Components | Enforcement |
+|-------|------------|-------------|
+| **Mathematical** | Cantor proof of spatial proximity, temporal chain validation | Trustless — proof either validates or doesn't |
+| **Protocol** | Event structure (kind 3333, A="derezz"), chain invalidation rules, domain policy checks | Consensus — clients enforce rules |
+| **Social** | Bounties, reputation, safe zone agreements, spawn camping norms | Coordination — trust-based, cultural |
+
+**Key principle:** Derezz validity is mathematical — the proof either proves proximity or it doesn't. But safe zones and domain policies are protocol-layer rules that can be changed by governance.
+
 ---
 
 ## 2. Derezz Event Structure