src/lib/utils.ts#formatCurrency and src/components/ui/StatCard.tsx#formatValue's
"currency" case independently implement the same locale-formatted currency string:
// utils.ts
export function formatCurrency(amount: number, asset: "USDC" | "XLM" = "USDC") {
if (!Number.isFinite(amount)) return `0 ${asset}`;
return `${amount.toLocaleString("en-US", { maximumFractionDigits: 2 })} ${asset}`;
}// StatCard.tsx#formatValue
case "currency": {
const formatted = value.toLocaleString("en-US", { maximumFractionDigits: 2 });
const display = `${formatted} ${asset}`;
const exact = `${value.toLocaleString("en-US", { maximumFractionDigits: 6 })} ${asset}`;
return { display, exact };
}formatCurrency's own doc comment even acknowledges this duplication is expected to be
kept manually in sync: "This behavior matches StatCard's internal currency formatter,
ensuring consistency across the app." That's two independent implementations of the same
formatting rule, correct only as long as every future change (locale, precision,
NaN/Infinity handling) is applied identically in both places by hand — exactly the kind
of drift-prone pattern that produced the precision inconsistency already tracked
elsewhere in this app's issue history for XLM's 7-decimal precision.
Suggested fix: have StatCard#formatValue's "currency" case call
formatCurrency(value, asset) directly for its display string (and a precision-widened
variant for exact), rather than reimplementing the same toLocaleString call
independently.
src/lib/utils.ts#formatCurrencyandsrc/components/ui/StatCard.tsx#formatValue's"currency"case independently implement the same locale-formatted currency string:formatCurrency's own doc comment even acknowledges this duplication is expected to bekept manually in sync: "This behavior matches StatCard's internal currency formatter,
ensuring consistency across the app." That's two independent implementations of the same
formatting rule, correct only as long as every future change (locale, precision,
NaN/Infinity handling) is applied identically in both places by hand — exactly the kind
of drift-prone pattern that produced the precision inconsistency already tracked
elsewhere in this app's issue history for XLM's 7-decimal precision.
Suggested fix: have
StatCard#formatValue's"currency"case callformatCurrency(value, asset)directly for itsdisplaystring (and a precision-widenedvariant for
exact), rather than reimplementing the sametoLocaleStringcallindependently.