2.2 KiB
2.2 KiB
Design
Context
See proposal.md and issue #92. The constructor currently owns ordered reserve configuration and immutable UUID-indexed maxima. Candidate selection already rounds down before invoking Jupiter; pending recovery precedes selection.
Goals / Non-Goals
Goals: Extend existing token amount policy safely with a lower bound on actual attempted inputs.
Non-Goals: Introduce a configuration hierarchy, compatibility bypass, precision rounding for minima, or change execution/recovery behavior.
Decisions
- Add required minima between reserves and maxima. Reuse one private positive per-UUID amount validator for minima and maxima, copy them to immutable maps with canonical CurrencyType values, and reject minimum > maximum after both maps exist. Reserve order alone retains priority. A duplicated independent validator would unnecessarily duplicate the existing identity/set rules.
- Compare the unchanged rounded candidate with its minimum using
compareTo, preserving numeric equality across decimal scales. A pre-round comparison would permit attempted inputs below minimum; rounding upward or reserve top-up would violate existing spend bounds. Minima need not be representable at mint precision: they remain exact lower bounds, and an unachievable minimum simply makes that candidate ineligible. - Make production minima explicit MoneyAmount values in the existing Hub factory and update the single current call site. No old-signature overload bypasses the required policy.
- Keep offline verification temporary, covering issue examples, precision/scale edges, config validation/copying, direct EVE and the prior recovery harness with only its constructor adapted.
Risks / Trade-offs
- Incorrect UUID matching or list reordering → use canonical UUID maps and verify stale display metadata/reordered lists.
- Precision makes a configured minimum unachievable → skip the rounded candidate; never promote amount.
- Constructor signature changes → update the only current construction site and compile all existing main/test sources.
Migration Plan
Implementation adds explicit production configuration; deployment remains a separate task. No persistent data, ticker history or ValueTag migration is required.