[Bug]: Edge-case inputs like zero, negative, empty, and degenerate values are not consistently blocked

[rahuldass19]

Summary

Severity: HIGH

Several qwed-tax guards do not consistently reject edge-case inputs such as negative monetary values, zero denominators, empty corporate substance, or economically impossible payloads. Instead of failing closed, some paths continue calculation, collapse degenerate values into defaults, or return a verified-looking result.

---

Problem

In a financial verifier, these are not harmless edge cases — they are high-risk manipulation points.

Affected patterns include:

• Negative amounts not being rejected
• Zero totals collapsing into ratios of 0
• Degenerate company-state inputs still producing residency determinations
• Zero-price valuation paths not being blocked before division/math

---

Why this violates QWED philosophy

QWED requires:

• All edge cases must fail closed
• No silent defaults that mask missing or invalid data
• Unproven results must never be treated as valid

If a system can still produce a success-like result when the underlying economic input is impossible or incomplete, the verification boundary is not safe.

---

Affected scope

This pattern appears across multiple guards:

• qwed_tax/guards/remittance_guard.py
• qwed_tax/guards/poem_guard.py
• qwed_tax/guards/valuation_guard.py
• Payroll and other money-handling verification paths

---

Attack scenario

Negative remittance amount:

verify_lrs_limit(amount_usd=-500000, purpose="education", financial_year_usage=200000)

A negative remittance can distort remaining-limit logic rather than being rejected immediately.

Degenerate corporate substance:

determine_residency(
    company_name="ShellCo",
    is_foreign_incorp=True,
    turnover_total=0,
    turnover_outside_india=0,
    assets_total=0,
    assets_outside_india=0,
    employees_total=0,
    employees_outside_india=0,
    payroll_total=0,
    payroll_outside_india=0,
    key_management_location="OUTSIDE"
)

This can still produce a residency result even though all economic substance inputs are zero.

Zero-cap valuation:

verify_conversion(
    investment="100000",
    cap="0",
    discount="1",
    next_round_price="100"
)

This can drive the effective price to zero and enter an invalid valuation path.

---

Security impact

This can enable:

• Manipulation of threshold logic with negative amounts
• False confidence from impossible economic states
• Crashes or undefined behavior in valuation math
• Legal/tax outcomes produced from nonsensical or insufficient inputs

These are high-risk because they sit at the exact place where an attacker would try to bend rule evaluation.

---

Fix direction

• Reject negative amounts, rates, and payments unless explicitly legal and modeled
• Reject zero or missing denominators in ratio-based tests
• Reject economically impossible all-zero corporate substance inputs
• Add explicit precondition checks before any division or threshold logic
• Treat empty/degenerate states as BLOCKED or UNVERIFIABLE, not as computable outcomes

---

Goal

qwed-tax should never produce a verified or usable financial/legal result from impossible, incomplete, or degenerate inputs.

Edge cases must be blocked before they influence tax logic.

[rahuldass19]

Audit findings — exact locations + severity reclassification

Ran a full edge-case audit on all guards mentioned. Two of the three are already partially fixed; one is confirmed vulnerable.

Finding 1: ValuationGuard — CONFIRMED VULNERABLE (M3 in audit)

guards/valuation_guard.py lines 10-45:

# Line 24: discount=2 → discounted_price = next * (1 - 2) = -next
discounted_price = d_next * (1 - d_disc)

# Line 35: min(cap, negative) = negative
final_price = min(d_cap, discounted_price)

# Line 38: shares = investment / negative = negative shares
shares = d_inv / final_price

# Line 40-44: returns verified=True with garbage economics
return {"verified": True, "deterministic_price": str(final_price), "shares_issued": str(shares), ...}

Missing validations:

• 0 <= discount <= 1 not checked — discount=2 produces negative price, negative shares, verified=True
• cap > 0 not checked — cap=0 → final_price=0 → DivisionByZero (uncaught, not InvalidOperation)
• next_round_price > 0 not checked
• investment > 0 not checked
• DivisionByZero not caught (only InvalidOperation at line 20)

Fix: Add range validation before computation:

if not (Decimal("0") <= d_disc <= Decimal("1")):
    return {"verified": False, "error": "Discount must be between 0 and 1."}
if d_cap <= 0 or d_next <= 0 or d_inv <= 0:
    return {"verified": False, "error": "Cap, next round price, and investment must be positive."}

Finding 2: RemittanceGuard — PARTIALLY FIXED

guards/remittance_guard.py lines 19-23:

try:
    current_txn = parse_decimal_input(amount_usd, "amount_usd")
    usage = parse_decimal_input(financial_year_usage, "financial_year_usage")
except ValueError as exc:
    return {"verified": False, "error": f"BLOCKED: {exc}"}

parse_decimal_input() rejects NaN, Infinity, booleans, and non-numeric strings. However:

Missing validation: Negative amounts are NOT rejected. parse_decimal_input(-500000, "amount_usd") succeeds, then line 34 if (usage + current_txn) > limit: — a negative current_txn always passes the limit check. verify_lrs_limit(-500000, "education", 200000) → verified=True. A negative remittance amount distorts the remaining-limit logic.

Fix: After parsing, add:

if current_txn < 0:
    return {"verified": False, "error": "BLOCKED: Remittance amount must be non-negative."}
if usage < 0:
    return {"verified": False, "error": "BLOCKED: Financial year usage must be non-negative."}

Finding 3: PoEMGuard — ALREADY FIXED (all-zero substance not a bypass)

guards/poem_guard.py:

The issue's attack scenario (all-zero corporate substance producing a residency result) is not exploitable:

• _validate_employee_counts() (line 134-143): rejects negative counts, rejects outside > total
• _validate_numeric_bounds() (line 145-162): rejects negative assets/payroll, rejects outside > total
• _compute_raw_ratios() (line 164-185): guards against division by zero with if values["assets_total"] > Decimal("0") else Decimal("0") — all-zero inputs produce ratio 0, which fails ABOI (all three ratios must be >= 0.50), then routes to key_management_location check

However: All-zero inputs (turnover=0, assets=0, employees=0, payroll=0) are structurally valid per current validation — they produce residency="NON_RESIDENT" (if key management outside India) because ABOI fails. This is arguably correct (a shell company with no substance is indeed non-resident under PoEM if management is outside), but the issue's concern is that "economically impossible all-zero substance" should be flagged for review. This is a policy question, not a fail-closed bug — the guard handles zero correctly per the PoEM rules.

Recommendation: Add an advisory flag for all-zero substance: {"verified": True, "residency": "NON_RESIDENT", "substance_warning": "All economic substance inputs are zero — manual review recommended"}. Not a block, but a transparency flag.

Additional finding not in this issue

jurisdictions/india/guards/crypto_guard.py lines 61-62:

if vda_income <= 0:
    return TaxResult(verified=True, message="No VDA Income", allowed_set_off=Decimal(0))

Negative vda_income (a loss) is treated identically to zero income — "No VDA Income" — instead of being routed to set-off/lapse logic. This is an edge-case classification bug (intersects with #17 and #18).

Summary

Guard	Issue scenario	Status	Severity
ValuationGuard	zero-cap, discount>1, negative shares	CONFIRMED — no range validation	MEDIUM→HIGH (division by zero crash + garbage verified)
RemittanceGuard	negative remittance amount	PARTIALLY FIXED — parse OK but no negativity check	MEDIUM
PoEMGuard	all-zero corporate substance	NOT A BUG — correctly handled, optional advisory flag	LOW (policy)
CryptoTaxGuard	negative vda_income = "no income"	ADDITIONAL — classification bug	MEDIUM