[codex] Show VM mining rewards with six decimals

[zack-bolich]

Summary

• Update the mining simulator comparison table to render rewards with six decimal places.
• Keep VM rewards visible as 0.000001 RTC instead of rounding them to 0.00 RTC.

Why

The main reward display already uses six decimals, but the comparison table used two decimals. That made very small VM rewards appear as zero in one part of the UI while still showing a non-zero reward elsewhere.

Fixes #7732.

Validation

• git diff --check
• Extracted the inline script from mining-simulator.html and parsed it with Node
• Confirmed the comparison table uses toFixed(6)

[github-actions]

Welcome to RustChain! Thanks for your first pull request.

Before we review, please make sure:

• Non-doc PRs have a BCOS-L1 or BCOS-L2 label
• Doc-only PRs are exempt from BCOS tier labels when they only touch docs/**, *.md, or common image/PDF files
• New code files include an SPDX license header
• You've tested your changes against the live node

Bounty tiers: Micro (1-10 RTC) | Standard (20-50) | Major (75-100) | Critical (100-150)

A maintainer will review your PR soon. Thanks for contributing!

[jaxint]

PR Review

Thank you for this contribution! Here's my review:

Summary

This PR improves the wallet tracker and mining calculator functionality.

Code Quality

• ✅ Clean implementation of number formatting
• ✅ Proper decimal precision handling
• ✅ Good use of existing utility functions

Observations

✅ Calculator logic updated in mining-simulator.html - useful metric

Testing

The changes appear to be focused on display/UX improvements. Consider:

• Adding unit tests for formatting functions
• Testing edge cases with very large/small numbers

Verdict

APPROVE ✅ - Changes are beneficial and low-risk.

---

Review by @jaxint | Wallet: AhqbFaPBPLMMiaLDzA9WhQcyvv4hMxiteLhPk3NhG1iG

[zack-bolich]

Thanks for the review. This is a non-doc PR and should be BCOS-L1, but I don't have permission to add labels. Could a maintainer please add the BCOS-L1 label?

[jujujuda]

Review: LGTM ✅

Show VM rewards with 6 decimals instead of 2. VM earns 0.000001 RTC, so shows 0.00 — misleading. is correct. Clean XS fix.

Recommendation: APPROVE.

[FakerHideInBush]

Two concerns before merging:

1. .toFixed(6) always emits trailing zeros — rewards like 1.5 RTC now display as 1.500000 RTC, which is visually cluttered

.toFixed(N) pads to exactly N decimal places regardless of magnitude. After this change:

• A reward of 1.5 displays as 1.500000 RTC (4 unnecessary trailing zeros)
• A reward of 2.0 displays as 2.000000 RTC (6 unnecessary trailing zeros)
• A reward of 0.000001 displays as 0.000001 RTC (correct — this is presumably the case this PR was trying to fix)

If the goal is to show precision only when it matters (i.e. avoid 0.00 RTC for very small rewards), consider a conditional formatter:

function formatReward(rtc) {
    if (rtc === 0) return '0 RTC';
    if (rtc >= 0.01) return rtc.toFixed(2) + ' RTC';
    return rtc.toFixed(6).replace(/\.?0+$/, '') + ' RTC';
}

This shows 2 decimals for normal rewards and up to 6 significant decimals for micro-rewards, without trailing zeros in either case.

2. The PR description does not explain why 6 decimals are needed — this makes it impossible to verify the fix is correctly scoped

The title says Show VM mining rewards with six decimals but gives no context for:

• What baseReward values are expected (are sub-cent rewards actually produced by VM tiers, or is this speculative?).
• Whether any other earnings displays in mining-simulator.html or mining-calculator/index.html also show baseReward * multiplier with .toFixed(2) — if so, changing only this one display creates an inconsistency where the same quantity appears with different precision in different parts of the UI.

Please add a brief PR description explaining the use case (e.g. baseReward for VM tiers can be as small as 0.000001 RTC and was showing as 0.00) and confirm whether other reward displays need the same update.

[Scottcjn]

Closing — toFixed(6) comparison fix (#7732) already landed via #7782. Thanks; overlapped the merged fix.