Problem
When a token has max_supply == None, mint state validation skips its supply-bound check entirely. A mint that would push total supply past i64::MAX (the GroveDB sum-item ceiling) is caught only by the low-level Drive checked_add, surfacing as an InternalError rather than a graceful consensus rejection.
Supply is not corrupted (the write is prevented), but the failure class is wrong.
Observed result:
InternalError("storage: drive: corrupted code execution error: trying to add an amount that would overflow total supply")
Where
token_mint_transition_action/state_v0/mod.rs — the supply check is wrapped in if let Some(max_supply) = token_configuration.max_supply(), so the None case has no validation-layer guard.- Guard that actually fires:
add_to_token_total_supply/v0/mod.rs (checked_add).
Expected
Reject at the validation layer with a graceful consensus error (treat i64::MAX as an implicit hard ceiling when max_supply is None).
Test
Current behavior is pinned by the characterization test test_token_mint_with_max_i64_base_supply_then_overflow_returns_internal_error_without_mutating_supply (batch/tests/token/mint/mod.rs). Adding the guard should break it — that is the signal to update it to expect the graceful rejection.
Related, distinct gap: base_supply > max_supply accepted at creation, documented by the #[ignore]d test_data_contract_creation_with_base_supply_over_max_supply_should_cause_error.
Problem
When a token has
max_supply == None, mint state validation skips its supply-bound check entirely. A mint that would push total supply pasti64::MAX(the GroveDB sum-item ceiling) is caught only by the low-level Drivechecked_add, surfacing as anInternalErrorrather than a graceful consensus rejection.Supply is not corrupted (the write is prevented), but the failure class is wrong.
Observed result:
Where
token_mint_transition_action/state_v0/mod.rs— the supply check is wrapped inif let Some(max_supply) = token_configuration.max_supply(), so theNonecase has no validation-layer guard.add_to_token_total_supply/v0/mod.rs(checked_add).Expected
Reject at the validation layer with a graceful consensus error (treat
i64::MAXas an implicit hard ceiling whenmax_supplyisNone).Test
Current behavior is pinned by the characterization test
test_token_mint_with_max_i64_base_supply_then_overflow_returns_internal_error_without_mutating_supply(batch/tests/token/mint/mod.rs). Adding the guard should break it — that is the signal to update it to expect the graceful rejection.Related, distinct gap:
base_supply > max_supplyaccepted at creation, documented by the#[ignore]dtest_data_contract_creation_with_base_supply_over_max_supply_should_cause_error.