Read the parameter and you can see how much PAX a window releases and on which dates. The epoch module ends an epoch on the first block past its duration, runs the mint hook, then starts the next one. The hook mints that day's share and sends it to the fee collector, which funds validator and delegator rewards. Only governance sets the schedule and the minter state, so no user transaction can mint.

What it does

On the Paxeer chain the epoch module keeps a clock: the first block whose timestamp passes the current epoch's duration ends that epoch, runs the registered hooks, then starts the next epoch and emits an event. The mint module is the only registered hook. At each epoch end it works out how much of the active release window is due that day, mints that amount of PAX and sends it to the fee collector account, from which the distribution module pays validators and delegators. Release windows and the minter state are set by governance; no user transaction can mint.

Key capabilities

• Runs registered module hooks at every epoch boundary; epoch duration defaults to 60 seconds.
• Mints one day's share of the active release window, once per UTC day.
• Recomputes the daily amount from the remaining amount and the days left in the window.
• Sends every minted coin to the fee collector, which funds validator and delegator rewards.
• Rejects release windows that overlap, run backwards, or name an asset other than PAX.
• Reports minter state and epoch state over gRPC, REST and the paxd CLI.

Differentiators

Each epoch hook runs against a cached context that is written only if the hook completes, and a hook failure aborts the block instead of advancing the epoch without the hook's state change. After downtime the epoch clock advances one epoch per block and keeps the elapsed start times, so no scheduled period is skipped.

Outcomes

• Read exactly how much PAX is due and on which days.
• Downtime shifts when tokens land but not a window's total.
• Query minter and epoch state over gRPC, REST or paxd.

Technical notes

• The mint asset is validated against the staking bond asset, so it can only be PAX; window dates use yyyy-mm-dd, and validation sorts windows by start date and rejects overlaps or a start after its end.
• A day's amount is the remaining amount divided by the days left to the end date; past the end date, or with no days left, the whole remainder is released.
• A window releases at most once per UTC date, because the minter records the last mint date, height and amount; a failed mint or fee-collector transfer panics, so the block fails rather than recording a release that did not happen.
• Changes are governance-only: a parameter change for the schedule, or the mint module's UpdateMinter proposal (paxd tx mint update-minter) for the minter state. Neither module accepts a user message, and the epoch module takes no parameters.
• Default parameters ship an empty schedule, so a chain mints nothing until governance sets a window. The mint module is at consensus version 3 and migrates older state in place, turning single-date v2 entries into start and end windows.
• Reads: paxd q mint minter, paxd q mint params and paxd q epoch epoch, the same three queries over gRPC, and mint also over legacy REST at /minting/minter and /minting/parameters.

More in Paxeer chain