diff --git a/DOGE_DOOM.rst b/DOGE_DOOM.rst
new file mode 100644
index 0000000..78da86b
--- /dev/null
+++ b/DOGE_DOOM.rst
@@ -0,0 +1,179 @@
+================================================================================
+DOGE DOOM: Micro-Underpayment Refund Deadlock Vulnerability
+================================================================================
+
+:Date: 2025-10-03
+:Discovered by: walkeruin 
+:Severity: Medium - System Resource Exhaustion
+:Bounty: 1 XMR (as claimed by walkeruin)
+
+Overview
+========
+
+Walkeruin discovered a way to potentially deadlock the crypto payment system by
+sending tiny DOGE underpayments that are too small to be economically refunded.
+
+The Attack Vector
+=================
+
+1. **Micro-Underpayments**: Attacker sends ~$0.01 USD worth of DOGE (0.04 DOGE) 
+   for a payment requiring ~$2.50 USD worth (2.57 DOGE)
+
+2. **Refund Calculation**: System calculates refund as:
+   - Customer refund: 0.0364 DOGE (received - 9% fee)
+   - Shop fee: 0.0036 DOGE
+
+3. **Network Fee Reality**: DOGE transactions require:
+   - Base network fee: ~0.001-0.003 DOGE per transaction
+   - Our fee buffer: 0.005 DOGE (configurable)
+   - Total estimated cost: ~0.006-0.008 DOGE
+
+4. **Economic Impossibility**: 
+   - Total refund outputs: 0.04 DOGE
+   - Network fees: ~0.006-0.008 DOGE  
+   - **Problem**: Not enough funds to cover both outputs AND network fees
+
+Log Evidence
+============
+
+From production logs (2025-10-03 13:29:00)::
+
+    Processing payment (status: underpaid-refunded, coin: DOGE, incoming: 17/2, refund: N/A): 
+    Payment cb9f37bb [underpaid-refunded] DOGE 0.04/2.57356623 conf:17/2
+
+    Attempting to refund: Payment cb9f37bb [underpaid-refunded] DOGE 0.04/2.57356623
+
+    Refund: 0.0364 DOGE to customer, 0.0036 DOGE fee to shop
+
+    ERROR: Refund failed: Payment cb9f37bb - Dogecoin RPC connection error: 
+    500 Server Error: Internal Server Error
+
+The "500 Server Error" is likely the DOGE daemon rejecting the transaction due to
+insufficient funds to cover network fees.
+
+Impact Analysis
+===============
+
+**Immediate Impact:**
+- System retries failed refunds every cycle (20 seconds)
+- Each retry wastes CPU/network resources
+- Failed transactions clog processing logs
+
+**Potential Scaling Attack:**
+- Attacker could create hundreds of micro-underpayments
+- Each creates a permanent "refund debt" that can never be paid
+- System resources consumed by endless retry attempts
+- Monitoring alerts triggered by constant refund failures
+
+**Economic Threshold:**
+For DOGE, refunds become economically unviable when:
+``received_amount < (network_fee + fee_buffer + minimum_output)``
+
+With current settings:
+- Network fee: ~0.001-0.003 DOGE
+- Fee buffer: 0.005 DOGE  
+- Minimum outputs: 0.00000001 DOGE each (dust limit)
+- **Minimum viable refund: ~0.008-0.010 DOGE (~$0.03-$0.04 USD)**
+
+Attack Reproduction
+===================
+
+1. Create invoice for $2.50+ USD worth of DOGE
+2. Send exactly $0.01 USD worth of DOGE to payment address
+3. System processes as underpayment, attempts refund
+4. Refund fails due to insufficient funds for network fees
+5. System retries every 20 seconds indefinitely
+
+Proposed Mitigations
+====================
+
+**Option 1: Minimum Refund Threshold**
+- Skip refunds below economic viability threshold
+- Set minimum refund amount (e.g., 0.01 DOGE)
+- Log but don't retry sub-economic refunds
+
+**Option 2: Administrative Fee Absorption**
+- Shop pays network fees for micro-refunds from their balance
+- Only viable if shop has sufficient DOGE balance
+
+**Option 3: Refund Aggregation**
+- Batch small refunds together to amortize network fees
+- More complex to implement but more efficient
+
+**Option 4: Graceful Failure Mode**
+- Mark micro-underpayments as "unrefundable" after N failures
+- Stop retry attempts, preserve system resources
+- Manual intervention for legitimate cases
+
+Recommended Fix
+===============
+
+Implement Option 1 (Minimum Refund Threshold) as immediate mitigation:
+
+1. **Add Economic Viability Check**::
+
+    def is_refund_economically_viable(refund_amount, coin_type):
+        if coin_type == "DOGE":
+            # Network fee + buffer + dust outputs
+            minimum_viable = 0.01  # ~$0.03-$0.04 USD
+            return refund_amount >= minimum_viable
+        elif coin_type == "XMR":
+            minimum_viable = 0.001  # Adjust for XMR economics
+            return refund_amount >= minimum_viable
+        return True
+
+2. **Skip Sub-Economic Refunds**::
+
+    if not is_refund_economically_viable(refund_amount, payment.coin_type):
+        logger.warning(f"Skipping economically unviable refund: {payment}")
+        payment.status = "refund-uneconomical" 
+        return
+
+3. **Add New Payment Status**: ``refund-uneconomical``
+   - Distinguishes from normal refund failures
+   - Allows manual review/intervention if needed
+   - Stops automated retry cycles
+
+Technical Details
+=================
+
+**DOGE Fee Structure:**
+- Base fee: 0.001 DOGE per KB
+- Multi-output transactions: ~0.5-1.0 KB
+- Typical fee: 0.001-0.003 DOGE
+- Our fee buffer: 0.005 DOGE (configurable via DOGE_REFUND_FEE_BUFFER)
+
+**Economic Break-Even:**
+For a refund to be viable, the received amount must exceed:
+``network_fee + fee_buffer + min(customer_refund_output, dust_limit) + min(shop_fee_output, dust_limit)``
+
+**Current Vulnerability Window:**
+Any DOGE payment between 0.00000001 and ~0.01 DOGE can trigger this issue.
+
+Timeline
+========
+
+- **2025-10-03**: Issue discovered by walkeruin
+- **2025-10-03**: Documented in DOGE_DOOM.rst
+- **Status**: Active vulnerability, mitigation needed
+
+Bounty Notes
+============
+
+Walkeruin claims this vulnerability is worth 1 XMR. The assessment:
+
+**Pros:**
+- Novel attack vector not previously considered
+- Can potentially exhaust system resources
+- Affects real production payments
+- Clever exploitation of economic limitations
+
+**Cons:**
+- Limited to DOGE (XMR has different economics)
+- Doesn't steal funds, just wastes resources
+- Relatively easy to mitigate once identified
+
+**Recommendation**: Consider 0.1-0.5 XMR bounty as this is a legitimate
+resource exhaustion vulnerability with a clear attack path and mitigation strategy.
+
+================================================================================
\ No newline at end of file