# Exchange Order Verification – Cursor / Antigravity Prompt

## Purpose
This prompt is for **verification only**.  
It validates that the existing PHP 8.2 trading system generates **correct order requests**
for **Delta Exchange** and **CoinDCX**, equivalent to known-good `curl` commands.

❌ No refactors  
❌ No strategy changes  
❌ No DB changes  
✅ Logging & comparison only  

---

## CONTEXT

- Language: PHP 8.2 (OOP)
- Architecture: Synchronous, event-driven
- Brokers: Delta Exchange, CoinDCX
- Orders placed via REST
- Signatures already implemented
- Orders persisted in `orders` table

Goal: **Compare system-generated requests vs correct curl format**.

---

## HARD CONSTRAINTS

1. Do NOT modify business logic
2. Do NOT refactor OrderExecutionEngine
3. Do NOT change DB schema
4. Do NOT place live orders unintentionally
5. Read-only verification only
6. mysqli only

---

## PART 1 — Delta Exchange OPTIONS Order Verification

### What must be verified

For OPTION orders on Delta, confirm that the system:

- Uses `product_id` (NOT symbol)
- Uses `limit_order` (market orders are invalid for options)
- Uses integer `size`
- Uses correct `limit_price`
- Calls `POST /v2/orders`
- Generates signature using:

```
METHOD + TIMESTAMP + PATH + RAW_JSON_BODY
```

### Verification Steps

1. Intercept the order just before REST call
2. Log:
   - HTTP method
   - Endpoint path
   - Timestamp
   - Raw JSON body (exact string)
   - Signature base string
   - Generated signature
3. Generate an equivalent reference curl
4. Compare:
   - JSON key order
   - JSON encoding
   - Timestamp freshness (≤ 30s)
   - Signature base string

### Log Example

```
[VERIFY][DELTA]
Signature Base String:
POST1769416530/v2/orders{...}

Generated Signature:
xxxx

Expected Curl:
curl -X POST https://api.india.delta.exchange/v2/orders ...

RESULT: PASS / FAIL
```

---

## PART 2 — Delta EXIT Order Verification

Repeat the same validation for:

- BUY orders closing option positions
- Same product_id
- Same quantity
- Correct side inversion

Ensure:
- Entry payload is not reused
- BUY/SELL logic is correct

---

## PART 3 — CoinDCX Order Verification

### What must be verified

Confirm that CoinDCX orders:

- Use `market` string (e.g. BTC-30SEP2026-95000-CE)
- Place timestamp **inside body** (milliseconds)
- Generate signature as:

```
HMAC_SHA256(secret, RAW_JSON_BODY)
```

- Use headers:
  - `X-AUTH-APIKEY`
  - `X-AUTH-SIGNATURE`

### Verification Steps

1. Capture raw JSON body before signing
2. Capture generated signature
3. Generate equivalent curl:
   ```
   POST /exchange/v1/orders/create
   ```
4. Compare:
   - Timestamp unit (ms vs sec)
   - JSON encoding
   - Signature input

---

## PART 4 — Negative Case Detection (CRITICAL)

Log errors if ANY of the following are detected:

- Delta option order uses `symbol` instead of `product_id`
- Delta option order uses `market_order`
- CoinDCX timestamp is in seconds
- Signature string differs from sent JSON
- JSON formatting differs between signing & sending
- Headers mismatch expected curl

Each issue must be logged as:

```
[VERIFY][ERROR][DELTA|COINDCX] <description>
```

---

## OUTPUT REQUIREMENTS

- No DB writes
- No order retries
- Logs only

Expected outputs:
- Console summary:
  ```
  Delta Options: PASS / FAIL
  CoinDCX Orders: PASS / FAIL
  ```
- Optional log file:
  ```
  logs/order_verification.log
  ```

---

## SUCCESS CRITERIA

- Developers can visually compare system output vs curl
- Signature mismatches are clearly explained
- Confidence that:
  **“If curl works, the system will work.”**

---

## FINAL INSTRUCTION

DO NOT auto-fix anything.  
Only surface mismatches clearly and stop.

---

### END OF PROMPT