clawmes version
0.1.0
Hermes Agent version
2026.4.x
Wallet mode
None
Chain ID
8453
What happened
Bug
Several formatters use or chains for key fallbacks on numeric fields. In Python, 0 and 0.0 are falsy, so a legitimate zero in the first key silently falls through to the next key (which may hold a different value from a different source) or to the default.
Locations (verified at HEAD)
clawmes/commands/trending.py lines 115–117:
vol24 = tok.get("volume24h") or tok.get("volumeUSD") or tok.get("volume") or 0
price = tok.get("priceUsd") or tok.get("price") or None
mc = tok.get("marketCap") or tok.get("fdv") or None
clawmes/commands/leaderboard.py lines 108–110:
price = tok.get("priceUsd") or tok.get("price")
mc = tok.get("marketCap") or tok.get("fdv")
vol = tok.get("volume24h") or tok.get("volume24hUsd") or tok.get("volume") or 0
clawmes/tools/bv7x_market.py lines 74–75, 81–82, 87–88 and clawmes/commands/bv7x.py lines 85–86, 94–95 (parallel implementations):
change = data.get("change_24h") or data.get("price_change_24h") or 0
value = data.get("value") or data.get("score") or "?"
flow_7d = data.get("flow_7d") or data.get("seven_day_flow") or "?"
Real-zero scenarios that trigger this
volume24h: 0 — dead token with zero volume (common on a launchpad's long tail). Falls through to volumeUSD/volume; if a stale non-zero value exists there, wrong volume renders. If not, the if vol: render gate omits the field entirely instead of showing zero.
change_24h: 0 — a flat 0.00% day. Falls through to price_change_24h; if the API supplies both keys, a different delta displays.
marketCap: 0 falls through to fdv — wrong MC when fdv differs.
priceUsd: 0 — a genuinely worthless token renders with no price at all rather than $0.
Suggested fix
Use explicit is not None checks for numeric fallbacks, e.g.:
vol24 = next((tok[k] for k in ("volume24h", "volumeUSD", "volume") if tok.get(k) is not None), 0)
or a small _first_present(d, *keys, default) helper shared across the four files, which would also deduplicate the parallel bv7x implementations.
Provenance
Found by my Hermes agent running Clawmes as a Raft External Agent. All line numbers verified against a fresh clone at HEAD.
Doctor output
Relevant log lines
Confirmations
clawmes version
0.1.0
Hermes Agent version
2026.4.x
Wallet mode
None
Chain ID
8453
What happened
Bug
Several formatters use
orchains for key fallbacks on numeric fields. In Python,0and0.0are falsy, so a legitimate zero in the first key silently falls through to the next key (which may hold a different value from a different source) or to the default.Locations (verified at HEAD)
clawmes/commands/trending.pylines 115–117:clawmes/commands/leaderboard.pylines 108–110:clawmes/tools/bv7x_market.pylines 74–75, 81–82, 87–88 andclawmes/commands/bv7x.pylines 85–86, 94–95 (parallel implementations):Real-zero scenarios that trigger this
volume24h: 0— dead token with zero volume (common on a launchpad's long tail). Falls through tovolumeUSD/volume; if a stale non-zero value exists there, wrong volume renders. If not, theif vol:render gate omits the field entirely instead of showing zero.change_24h: 0— a flat 0.00% day. Falls through toprice_change_24h; if the API supplies both keys, a different delta displays.marketCap: 0falls through tofdv— wrong MC when fdv differs.priceUsd: 0— a genuinely worthless token renders with no price at all rather than $0.Suggested fix
Use explicit
is not Nonechecks for numeric fallbacks, e.g.:or a small
_first_present(d, *keys, default)helper shared across the four files, which would also deduplicate the parallel bv7x implementations.Provenance
Found by my Hermes agent running Clawmes as a Raft External Agent. All line numbers verified against a fresh clone at HEAD.
Doctor output
Relevant log lines
Confirmations