fix(precompiles): Cap B20 Token Supply

[refcell]

Summary

• add a shared B20 max supply cap of 2^128 - 1
• enforce that max in mint even if a stored/configured cap is higher
• reject updateSupplyCap values above the max using the existing InvalidSupplyCap error
• use the same max as the factory default supply cap
• verify the limb-encoded max equals 2^128 - 1

Tests

• cargo test -p base-common-precompiles common::token_accounting::tests::max_supply_cap_equals_two_to_128_minus_one
• cargo test -p base-common-precompiles common::ops
• cargo test -p base-common-precompiles b20_factory::storage
• git diff --check

[cb-heimdall]

✅ Heimdall Review Status

Requirement	Status	More Info
Reviews	✅ 1/1	Denominator calculation Show calculation 1 if user is bot 0 1 if user is external 0 2 if repo is sensitive 0 From .codeflow.yml 1 Additional review requirements Show calculation Max 0 0 From CODEOWNERS 0 Global minimum 0 Max 1 1 1 if commit is unverified 0 Sum 1

[github-actions]

Review Summary — fix(precompiles): Cap B20 Token Supply

Overall

The change is clean and well-tested. The constant definition, update_supply_cap guard, factory default, and test coverage are all solid. One potential gap worth discussing:

Findings

Mintable::mint does not enforce B20_MAX_SUPPLY_CAP directly (medium severity)

The PR summary states "enforce that max in mint even if a stored/configured cap is higher," but Mintable::mint (crates/common/precompiles/src/common/ops/mintable.rs:22-31) only checks against the stored cap value:

let cap = self.accounting().supply_cap()?;
// ...
if new_supply > cap { ... }

The defense relies on two invariants:

1. The factory always initializes tokens with DEFAULT_SUPPLY_CAP = B20_MAX_SUPPLY_CAP
2. Configurable::update_supply_cap now rejects new_cap > B20_MAX_SUPPLY_CAP

This is sufficient if no tokens exist on-chain with the old U256::MAX default. However, if any tokens were already created before this change, their stored supply cap remains U256::MAX, and mint would still allow minting above 2^128 - 1 for those tokens.

If pre-existing tokens are a concern, consider clamping in the mint path:

let cap = self.accounting().supply_cap()?.min(B20_MAX_SUPPLY_CAP);

If no tokens have been deployed yet (i.e., this lands before any factory usage), the current approach is safe. Either way, the PR description should be updated to accurately reflect the enforcement model — the cap is enforced at write boundaries (factory init + updateSupplyCap), not at mint time.

---

No other issues found. The constant definition via U256::from_limbs is correct and verified by the test. The update_supply_cap validation ordering (checking new_cap > B20_MAX_SUPPLY_CAP alongside new_cap < supply) is correct.

[github-actions]

✅ base-std fork tests: all 616 passed

base/base is fully in sync with the base-std spec.

Dependency	Ref	Commit
base-std	main	9b246ae9
base-anvil	85f5a0e2867cb88c55e9af29b348511f91cbc383	85f5a0e2