SPARC substring fallback over-rewards modern SPARC at the 1987 LEGENDARY 3.0x rate

[Scottcjn]

Found during the 2026-08-20 PR review sweep (surfaced by the sparc-solaris-miner #7 review).

Defect

`normalize_id("SPARC-T")` yields `sparc_t`, which matches no exact multiplier key and then falls through to the substring match on `"sparc"` — the generic 1987 entry at 3.0x LEGENDARY. A 2013 SPARC T5 therefore grades as 1987 silicon.

Larger historical impact: on main, the SPARC miner sent bare `"sparc"` in `device.arch`, which is the highest-paying SPARC row — so every SPARC box to date has been paid at the 1987 rate regardless of actual generation.

What's already fixed

sparc-solaris-miner PR #7 (merged 2026-08-20) makes the miner report specific generations, and was verified against the node's real `calculate_poa_multiplier`: every generation now grades equal-or-lower than before. That stops the bleeding going forward but does not correct node-side substring fallback or historical over-payment.

Suggested fixes

1. Node-side: substring fallback for exotic families should pick the most conservative (lowest) multiplier in the family, not the first/highest match — same fail-closed principle as RIP-309b.
2. Audit historical SPARC payouts (`miner_attest_recent` + epoch_rewards for `device_family='SPARC'`) to quantify the over-payment.
3. Related hygiene: `antiquity_class` and the proposed `identity` block are self-asserted client fields with zero node-side consumers today — if anything ever grades on them, they need server-side validation first (see finding-controls-that-fire-only-on-honest-clients).

[Vyacheslav-Tomashevskiy]

Fix ready — same conservative-fallback principle you suggested (#1).

lookup_hardware()'s substring fallback returned whichever key literally substring-matched the normalized probe id. For "SPARC-T" → "sparc_t", only the generic "sparc" key (Sun-4, 1987, 3.0x LEGENDARY) matches — none of the other sparc_* keys do — so a single-match fallback (even one that just picks the cheapest of the literal matches) still lands on that same 1987 row.

The actual fix: once a substring match tells us the family, anchor to the lowest base_multiplier across every entry in that family, not the multiplier of whichever key happened to match. For SPARC, ultrasparc_iii/ultrasparc_iv are already in the table at 2.5x ANCIENT — so an unidentified generation now grades there instead of at the family's priciest tier.

candidates = [entry for key, entry in db.items() if norm_id in key or key in norm_id]
if candidates:
    matched_families = {entry.family for entry in candidates}
    family_entries = [e for e in db.values() if e.family in matched_families]
    return min(family_entries, key=lambda e: e.base_multiplier)

Verified: lookup_hardware("SPARC-T", "sparc") → UltraSPARC III, 2.5x ANCIENT (was SPARC, 3.0x LEGENDARY). Exact-generation lookups (e.g. "ultrasparc_ii") are unaffected — still resolve to their own precise entry, not dragged down to the family floor.

Diff

diff --git a/node/rustchain_hardware_database.py b/node/rustchain_hardware_database.py
index 2ac24f63..5575fad3 100644
--- a/node/rustchain_hardware_database.py
+++ b/node/rustchain_hardware_database.py
@@ -686,10 +686,25 @@ def lookup_hardware(hw_id: str, family: Optional[str] = None) -> Optional[Hardwa
         if norm_id in db:
             return db[norm_id]
 
-        # Try partial matching for common variants
-        for key, entry in db.items():
-            if norm_id in key or key in norm_id:
-                return entry
+        # Try partial matching for common variants. A substring match only
+        # proves the probe belongs to SOME entry's family — it does not
+        # identify which generation. normalize_id("SPARC-T") == "sparc_t"
+        # has no exact key, but IS a superstring of the generic "sparc" entry
+        # (Sun-4, 1987, 3.0x LEGENDARY) and NOT a substring/superstring of
+        # any other sparc_* key, so a naive "return the matched entry" (or
+        # even "return the cheapest of the LITERAL key matches") still
+        # answers with that single 1987 row — a 2013 SPARC T5 grades as
+        # 1987 silicon. Once we know the family, anchor to the lowest
+        # base_multiplier across every entry in that family (e.g. SPARC's
+        # own ultrasparc_iii/iv rows are 2.5x ANCIENT), not just whichever
+        # key happened to substring-match. Same fail-closed principle as
+        # RIP-309b: an unidentified generation must never grade at the
+        # family's most expensive tier.
+        candidates = [entry for key, entry in db.items() if norm_id in key or key in norm_id]
+        if candidates:
+            matched_families = {entry.family for entry in candidates}
+            family_entries = [e for e in db.values() if e.family in matched_families]
+            return min(family_entries, key=lambda e: e.base_multiplier)
 
     return None
 

Tests — 3/4 fail on unmodified main, pass with the fix (4th is a control confirming exact matches are untouched)

# SPDX-License-Identifier: MIT
"""Regression test for the SPARC substring-fallback over-reward bug (issue #8237).

``lookup_hardware()``'s partial-match fallback returned the FIRST key that
literally substring-matched the normalized probe id, with no regard for how
conservative that entry's multiplier was. ``normalize_id("SPARC-T")`` yields
``"sparc_t"``, which has no exact key in ``WORKSTATION_DATABASE`` but IS a
superstring of the generic ``"sparc"`` entry (Sun-4, 1987, 3.0x LEGENDARY) —
and of no other ``sparc_*`` key. So an unrecognised/newer SPARC generation
(e.g. a 2013 SPARC T5) graded at the SAME multiplier as 1987 silicon,
regardless of how modern it actually was.

FAILS on unmodified main: ``lookup_hardware("SPARC-T", "sparc").base_multiplier
== 3.0`` (the 1987 LEGENDARY row).
PASSES with the fix: the lookup anchors to the lowest ``base_multiplier``
across every entry sharing the matched family, which for SPARC is 2.5x
(ANCIENT, UltraSPARC III/IV) — never the family's priciest tier for hardware
whose generation wasn't identified.
"""

import os
import sys
import unittest

NODE_DIR = os.path.abspath(os.path.join(os.path.dirname(__file__), ".."))
if NODE_DIR not in sys.path:
    sys.path.insert(0, NODE_DIR)

from rustchain_hardware_database import (  # noqa: E402
    lookup_hardware,
    calculate_poa_multiplier,
    WORKSTATION_DATABASE,
)


class TestSparcSubstringFallbackConservative(unittest.TestCase):
    def test_unidentified_sparc_generation_does_not_grade_at_1987_rate(self):
        entry = lookup_hardware("SPARC-T", "sparc")
        self.assertIsNotNone(entry, "SPARC-T should still resolve to *some* SPARC entry")
        self.assertLess(
            entry.base_multiplier, 3.0,
            f"SPARC-T (unidentified generation) graded at {entry.base_multiplier}x — "
            "the 1987 LEGENDARY rate is only correct for genuinely 1987-era SPARC "
            "hardware, not an unrecognised/newer probe string.",
        )

    def test_conservative_match_equals_family_minimum(self):
        entry = lookup_hardware("SPARC-T", "sparc")
        family_min = min(
            e.base_multiplier for e in WORKSTATION_DATABASE.values() if e.family == "sparc"
        )
        self.assertEqual(
            entry.base_multiplier, family_min,
            "an unidentified SPARC generation must grade at the family's lowest "
            "known multiplier, not an arbitrary substring-matched one",
        )

    def test_calculate_poa_multiplier_end_to_end(self):
        mult, tier, _rarity, _name = calculate_poa_multiplier("sparc", "SPARC-T")
        self.assertLess(mult, 3.0)
        self.assertNotEqual(tier, "LEGENDARY")

    def test_exact_generation_match_is_unaffected(self):
        # A precisely-reported generation must still resolve to its own
        # entry, not get dragged down to the family minimum.
        entry = lookup_hardware("ultrasparc_ii", "sparc")
        self.assertIsNotNone(entry)
        self.assertEqual(entry.name, "UltraSPARC II")
        self.assertEqual(entry.base_multiplier, 3.0)


if __name__ == "__main__":
    unittest.main()

⚠️ One honesty note: I grepped node/*.py and the top-level integrated file and could not find lookup_hardware/calculate_poa_multiplier imported anywhere outside this module — if it's not currently wired into the live node's reward path, the fix is still correct and ready for whenever it is; I didn't want to overstate live user-facing impact I can't verify from this repo alone.

Same infra blocker as #8235/#8238 blocks a PR from this account (fork is behind upstream on .github/workflows/*, so any push — even a clean single commit — is rejected for lacking workflow scope). Posting the fix here instead of letting it sit idle.

/claim
RTC wallet: RTCd1554f0f35576faf01d386a6be1c947f560dd0b7

[Scottcjn]

Historical payout quantification (2026-08-25, queried on the prod node)

Ledger verdict: the SPARC over-reward has paid out 0 RTC to date.

Method: the server records the verified device family/arch on every attestation (`derive_verified_device` detects SPARC first), so any SPARC box that ever attested would appear as such regardless of wallet name. Queried on node 1:

• `miner_attest_recent`: 0 rows with sparc in `device_family`/`device_arch` (full GROUP BY of all family/arch pairs inspected).
• `miner_attest_history`: 0 rows matching sparc.
• `epoch_rewards`: 0 rows for any sparc-pattern miner_id.

So the substring-fallback bug is real in code but has never been exercised by a real payout: no SPARC machine has successfully attested on prod. The earlier "every SPARC box has been paid at the 1987 rate" line in this issue was inference from the code path — the ledger says the exposure is prospective, not historical. The fail-closed fix (conservative lowest-in-family fallback) is still the right change before the sparc-solaris-miner userbase arrives.

Related, found during the same sweep: an `arm2` claim swarm (4.0x MYTHIC tier)

`miner_attest_recent` holds 75 attestations claiming `device_arch=arm2` (a 1986 Acorn part) from `device_family="Server"`, all from Ethereum-format `0x…` wallets, one attestation each, 2026-06-30 → 2026-07-01. Joined against `epoch_rewards`: zero rewards paid — eligibility/fingerprint gating held. So: an attempted vintage-multiplier farming run, fully unpaid, but it shows the exotic-tier claims are being probed. Same recommendation as the SPARC fix: exotic-architecture claims above ~2x should require fingerprint evidence for the claimed family (per finding-controls-that-fire-only-on-honest-clients), not just survive the generic checks.

[Vyacheslav-Tomashevskiy]

/claim #8237

Opened PR: #8288

Implemented the conservative family-minimum fallback in lookup_hardware() so unidentified SPARC variants like SPARC-T no longer inherit the 1987 3.0x LEGENDARY rate, and added regression coverage proving the fallback now grades fail-closed while exact generation matches remain unchanged.