Component: Minter module (minter::minter)

Description

This module governs a mint and redeem gateway between stablecoin pool A and RWA pool B on Sui. It stores pool addresses, token whitelists, and version data; enforces request timing; routes funds; and emits events for off-chain processors.

What it does

This module does the following.

• State management: It keeps a single State object with owner, version, pool addresses, and two token-acceptance tables.

• Admin control: It provides owner-only functions to transfer ownership, migrate version, set pool addresses, and add or remove accepted tokens.

• User flows: request_to_mint<T> and request_to_redeem<T>.

  • Validates a token against the relevant whitelist.

  • Enforces a timestamp within delay and checks coin balance.

  • Splits the user coin and sends the requested amount to the correct pool.

  • Emits the MintRequest or RedeemRequest event.

• View helpers: It provides constant-time getters for public state.

How it does it

It uses Move primitives such as assert!, coin::split, transfer::public_transfer, and event::emit. Generic type introspection converts the type parameter into an address for whitelist checks. Private helpers check_version and check_owner centralize validation logic.

Invariants

• state.version equals VERSION after every successful entry (except migrate, which sets it).

• Only state.owner may call admin entries — enforced by check_owner.

• request_to_mint accepts only tokens in accepted_by_a, and request_to_redeem accepts only tokens in accepted_by_b.

• timestamp in requests must be within 59 seconds of clock.

• The amount cannot exceed transferred_token.value.

• On success, the exact amount moves to the target pool, and the caller’s remaining balance is intact.

Test coverage

Cases covered

• Initialization sets the version to one, sets the owner, and sets empty whitelists.

• The owner updates pool addresses and whitelists; getters return expected values.

• Positive mint requests with whitelisted USDT to pool A.

• Checks that balance is reduced, event fields are correct, and the pool receives funds.

• Positive redeem request with whitelisted SUI to pool B (mirror of above).

• Minting with token not whitelisted triggers EInvalidTokenForMint.

• Minting with stale timestamp triggers EInvalidTimestamp.

• Minting after removing token from whitelist triggers EInvalidTokenForMint.

Cases not covered

• Redeeming with a token not whitelisted (EInvalidTokenForRedeem).

• Insufficient coin balance (EInsufficientBalance).

• Owner-guard violations (ENotOwner).

• Upgrading path logic (migrate, transfer_ownership with UpgradeCap).

However, MatrixDock updated the test suite to support such cases in commit dd655f3↗.

Attack surface

• User-supplied generic type T: Whitelist check aborts unaccepted tokens.

• Timestamp spoofing: Allowed window is limited to 59 seconds.

• Amount field: u64 checks and balances comparison block overflow.

• UpgradeCap misuse: Incorrect cap address aborts with EUpgradeCapInvalid.

External inputs are limited to coins, type, amount, and timestamp; each is checked before state mutation.