🟡 Inconsistent validation and error codes between single and batch creation paths

[Ejirowebfi]

Area: Smart contract · lib.rs (create_token_inner, validate_batch_params, create_token)

Description

The two creation paths have drifted:

• Error codes differ for identical faults: single-path returns InvalidTokenParams for bad
  name/symbol but InvalidParameters for bad decimals; the batch path returns InvalidParameters
  for all of them. Client error mapping (utils/contractErrors.ts) can't render consistent
  messages, and documented ABI behavior differs by entrypoint for the same user mistake.
• Type asymmetry: single-path initial_supply is u128 (with two duplicated > i128::MAX
  guards at lib.rs:383 and lib.rs:396 — dead code from a merge), batch initial_supply is
  i128 (negative rejected at validation). Same concept, two types, two validation shapes.
• Feature asymmetry: only the batch path supports max_supply; a single-token creator cannot cap
  supply at all (the README documents this as a caveat rather than it being fixed), and the
  single-path always writes max_supply: None.
• Fee-check ordering differs: batch validates all params before charging; single-path interleaves.

These asymmetries are where bugs like Issue 2 breed — the paths must share one validation and one
bookkeeping routine.

Tasks

• Extract a single shared validate_token_params + record_token used by both paths; delete the
  duplicated i128::MAX guard.
• Unify initial_supply typing (recommend i128 with >= 0 validation to match the batch path
  and the SDK's mint signature) — note this is an ABI change; coordinate with the frontend
  (Issue 5's audit) and bump documented ABI.
• Add max_supply: Option<i128> to single create_token for parity.
• Normalize error codes: one documented code per fault class across both paths; update
  docs/contract-abi.md and frontend/src/utils/contractErrors.ts.
• Property tests asserting single-path and batch-path accept/reject exactly the same parameter
  sets with the same error codes.

Acceptance criteria

• For every invalid parameter set, both creation paths return the identical error code, proven by a
  shared property-based test matrix.
• Single-token creation supports max_supply with the Issue 2-corrected accounting.
• No duplicated validation logic remains (one shared routine, verified by review).

---

Issue 18 of 20 from the codebase audit tracked in ISSUES.md.

[ebubeb683-ship-it]

Hello boss, Please assign this issue to me. i checked it out and im confident i will solve it
my eta is 4 hours

[mxrtins04]

Hi maintainer, can i be assigned this issue pleasee?

[JoesWalker]

Hello maintainer i would like to work on this issue i have gone through the issue and know how to solve the issue

[grantfox-oss]

🦊 GrantFox — @JoesWalker has been assigned to this issue as part of the Official Campaign | FWC26 campaign!

Next steps:

1. Open a Pull Request referencing this issue (e.g., Closes #1022)
2. Your PR will be reviewed by the Favourorg maintainers

Good luck! Track your progress on GrantFox.

[grantfox-oss]

🎉 This issue has been marked as completed on GrantFox as part of the Official Campaign | FWC26 campaign!

@JoesWalker's PR #1060 was approved and merged by @Ejirowebfi.

🏆 @JoesWalker: You earned 35 FoxPoints for this contribution! Your current tier: Explorer (414 total points). Track your full progress on GrantFox.

👏 Great work, @JoesWalker! Keep contributing to Favourorg.

[github-actions]

🎉 This issue has been resolved in version 1.3.2 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀