We manage your security to weather the AI storm →

← Resource Hub

Paxos PYUSD Minting Error: Lessons for Stablecoin Issuers

By Owen Thurm Published 6 min read

Paxos PYUSD Minting Error: Lessons for Stablecoin Issuers

Quick answer. On October 15, 2025, Paxos minted 300 trillion PYUSD by mistake during an internal transfer, then burned it about 20 minutes later. Issuers prevent repeats with onchain mint caps, multi-party approval, simulation and alerts on supply jumps.

Watch: Paxos PYUSD Minting Error: Lessons for Stablecoin Issuers 1:45
Video transcript

One Paxos transaction minted 300 trillion PYUSD by mistake on October 15, 2025. Paxos says there was no breach, and that is the point.

By Guardian's arithmetic, that mint was about 115,000 times PYUSD's market cap of roughly 2.6 billion dollars.

Paxos burned the excess about 20 minutes later. Aave temporarily froze PYUSD markets as a precaution.

Paxos says there was no security breach, and whatever limits applied, none rejected the mint. Mint controls must stop honest mistakes, not only thieves.

Start with limits in the contract. Set a per-call maximum, a refilling rate limit, a shrinking allowance, a recipient allowlist and a supply ceiling.

Separate who requests, approves and executes, and require a second approver above a threshold. Then simulate on a fork, and block the broadcast if any check fails.

Alert on supply jumps, and know what your pause stops. In Paxos's design, a pause does not stop a minter. A kill switch must revoke the minter role or zero its limit.

The OCC's final rule asks for dual controls, and the Fed's proposal flags coding errors as operational risk. Neither prescribes mint caps.

Guardian reviews high-risk transactions before they run. Its review of USDT zero's queued migration found a plan that would create an insolvency case. It was fixed before the transactions ran.

Read the full article, or talk to Guardian about testing your mint controls.

At 19:12 UTC on October 15, 2025, a Paxos wallet called increaseSupply on the PYUSD contract. One transaction created 300 trillion tokens.

PYUSD's market cap was about $2.6 billion, The Block reported. By our arithmetic, the mint was about 115,000 times that.

Paxos says there was no security breach. That is why it is worth studying: mint controls must stop honest mistakes, not only thieves.

Where this article discusses regulation, it covers the technical and security side only. It is not legal advice; confirm how the rules apply to you with counsel.

What Happened

When (Oct 15, 2025)EventSource
19:12 UTCA Paxos wallet mints 300 trillion PYUSDEtherscan
About 20 minutes laterPaxos burns the excessCNBC, from Etherscan data
Same dayAave temporarily freezes PYUSD marketsThe Block
Same dayPaxos says the error is fixedPaxos on X

Paxos said it "mistakenly minted excess PYUSD as part of an internal transfer" and "immediately identified the error and burned the excess PYUSD."

It added: "This was an internal technical error. There is no security breach. Customer funds are safe. We have addressed the root cause."

PYUSD briefly traded away from $1 and stabilized after the burn, The Block reported. American Banker put the gap between mint and burn at 22 minutes.

Why Controls Did Not Stop It

Paxos's statement did not say which control failed. The public record shows this much:

  • One transaction from a Paxos wallet created the full amount.
  • Paxos's token repository, which covers PYUSD, says supply controllers "can optionally have rate limits."
  • The statement did not say whether a limit was set for that wallet.

Whatever limits applied, none rejected the mint.

Detection did work. Omid Malekan, quoted by American Banker, contrasted it with Citi's $81 trillion error in February 2025, which surfaced because Citi self-reported.

The Paxos error, he noted, was spotted independently by many people. A public ledger shows every mint to everyone.

Same gap, different cause

Five months later, a mint with no effective cap was abused on purpose. An attacker deposited 100,000 USDC into Resolv's minting contract and received 50 million USR, about 500 times the expected amount, The Block reported.

A second mint added 30 million more. Our stablecoin security guide covers that incident and the wider issuer risk map.

Mint Caps and Approvals

Put limits in the contract, where a wrong number cannot pass them.

  • Per-call maximum: the largest single mint you would ever issue.
  • Rate limit: a capacity per minter that refills over time.
  • Allowance: a budget that shrinks with each mint.
  • Recipient allowlist: mints only to known treasury addresses.
  • Supply ceiling: total supply bounded near reserves, raised by a separate role.

Circle's USDC design shows the allowance model. "The minterAllowance will decrease by the amount of tokens minted," and a separate master minter raises allowances.

Size each cap to real flows. A cap at a few times your largest normal mint stops a typo without blocking business.

Multi-party approval

  • Require a second approver for any mint above a threshold.
  • Separate who requests a mint, who approves it and who executes it.
  • Show amounts in whole tokens and dollars, never raw base units.
  • Match each mint to a funded request: amount, recipient and chain.

Simulate Before You Sign

Simulation catches what approvers miss. Run each mint on a fork of the current chain before broadcast.

Then assert the result:

  • The change in totalSupply equals the approved amount, to the unit.
  • Supply after the mint stays under the cap and the reserve figure.
  • Tokens land only at the approved recipient.
  • No role, limit or other balance changed.

Block the broadcast if any check fails. Build it into the signing flow, so skipping it takes more effort than running it.

Monitoring and Kill Switches

Assume a bad mint will land one day. The goal is to see it in seconds and stop the next one.

Alert on:

  • any mint above a set size, or a totalSupply jump above a set percentage
  • a mint with no matching deposit or reserve entry
  • a mint from an unexpected wallet, or to an unexpected recipient
  • changes to minter roles, limits and allowances

Our guide to onchain monitoring covers how to route these alerts to someone who can act.

Know what your pause stops

Pauses differ. In USDC, "All transfers, minting, burning, and adding minters will be prevented while the contract is paused."

In Paxos's design, "While paused, the supply controller retains the ability to mint and burn tokens." There, a pause does not stop a minter.

A kill switch for minting must act on the mint path itself, such as revoking the minter role or zeroing its limit. Rehearse it, and the burn, on a fork.

Tell integrators how you will announce an error. Aave froze PYUSD markets as a precaution while this one played out.

What Regulators Expect

Neither U.S. text prescribes mint caps. Both treat minting as an operational risk.

The OCC's final rule was published October 23, 2026. It takes effect January 18, 2027.

  • Internal controls must provide for "appropriate segregation of duties and dual controls."
  • Its preamble says issuers "should ensure that they have sufficient controls to reliably address operational issues that may arise with burning and minting new stablecoins."
  • The OCC declined to set detailed smart contract controls for minting, or a real-time monitoring requirement.

The Federal Reserve's proposal was published September 29, 2026. Comments close November 30, 2026.

  • It notes that "many stablecoins rely on smart contracts to control minting and burning."
  • It lists "coding errors in smart contracts, and errors in transaction processing" among operational risks.
  • It says larger unauthorized mints are more likely to be detected, "either by the Board-supervised PPSI itself or by an external observer monitoring the blockchain."

In Guardian's reading, an issuer should see its own bad mint before outside observers do.

Our posts on the OCC's final rule and the Fed's proposal cover the full security programs.

How Guardian Helps

Guardian reviews high-risk transactions before they run. On Polygon in August 2025, its review of USDT0's queued migration found a plan that "will create an insolvency case."

The plan would have left more USDT0 circulating than USDT available to redeem it. It was fixed before the transactions ran; see the USDT0 client story.

Once a coin is live, Managed Security monitors its contracts on every block, including privileged calls, role changes and large fund movements. Guardian also reviews every multisig transaction before it is signed.

Frequently Asked Questions

What happened with the PYUSD minting error?

On October 15, 2025, Paxos minted 300 trillion PYUSD by mistake during an internal transfer, then burned the excess. Paxos said "This was an internal technical error" and that there was no security breach.

How long did the PYUSD over-mint last?

About 20 minutes, CNBC reported from Etherscan data, and American Banker put it at 22 minutes. Aave temporarily froze PYUSD markets as a precaution.

Did PYUSD holders lose money?

Paxos said "Customer funds are safe." None of the reports we read describe customer losses. PYUSD briefly traded away from $1 and stabilized after the burn, The Block reported.

How can stablecoin issuers prevent minting errors?

Cap mints in the contract per call and per period, require a second approver above a threshold, simulate each mint and check the supply change, and alert on supply jumps. Make sure your kill switch stops minting, not only transfers.

Sources

Test your mint controls with Guardian

Guardian reviews your mint caps, approvals and kill switches before launch, then watches every mint on every block once you are live.