PYUSDX Issuance (IssuerGateway)
Purpose
Every mint of PYUSDX flows through the IssuerGateway. It enforces a time delay and a rate limit on mints, creating a security buffer that gives reviewers a window to catch a bad proposal before it executes.
Portal can also mint and burn PYUSDX, but it is not able to issue new PYUSDX under normal operation. See Cross-chain (Portal).Mint lifecycle
Mints move through a propose → delay → execute flow:
Propose
An account with OPERATOR_ROLE calls proposeMint(amount, recipient), which emits MintProposed(mintId, ..., activeAt, expiresAt). The proposal's activeAt and expiresAt timestamps are snapshotted at this point.
The original proposer can call cancelMint(mintId) any time before activeAt.
Execute
An account with EXECUTOR_ROLE calls mint(mintId) between activeAt and expiresAt.
If the proposal is not executed before expiresAt, it becomes expired and can no longer be minted.
activeAt and expiresAt are snapshotted at proposeMint time and read from storage in mint / cancelMint. Changes to the global mintDelay or mintTTL apply only to proposals created after the update.OPERATOR_ROLE revalidation
At execution, mint re-checks that the original proposer (proposal.minter) still holds OPERATOR_ROLE. If the role was revoked after the proposal was created, mint reverts with AccessControlUnauthorizedAccount. A proposer who loses operator privileges cannot have their pending mints executed.
Burn lifecycle
Burns have no delay. An account with OPERATOR_ROLE calls burn(amount) directly. The tokens are burned from the caller's own balance (burn(msg.sender, amount)), so the operator must hold at least amount of PYUSDX for the burn to succeed.
Roles
| Role | Powers |
|---|---|
DEFAULT_ADMIN_ROLE | Set mint delay, set mint TTL |
OPERATOR_ROLE | Propose mints, burn tokens |
EXECUTOR_ROLE | Execute mints after the delay |
Immutable reference
The pyusdx address is set in the constructor and cannot be changed.
Deployed contract addresses are listed on the PYUSDX platform deployments page.