The $300 Trillion Mistake: How Paxos Minted and Burned PYUSD in 22 Minutes
Executive Summary
On October 15, 2025, Paxos minted 300 trillion PYUSD tokens—equivalent to twice the global GDP—before burning them 22 minutes later. While Paxos attributed this to an "internal technical error," our post-incident analysis of the PaxosTokenV2 and SupplyControl contracts revealed two critical architectural vulnerabilities that directly enabled this exposure event.
This post-mortem examines the technical root causes we discovered and demonstrates how proactive security practices during development could have prevented this $300 trillion incident entirely.
Incident Timeline
7:12 PM – Paxos mints 300,000,000,000,000 PYUSD
7:12-7:34 PM – 22-minute exposure window
7:15 PM – Blockchain monitoring detects anomaly
7:20 PM– Chaos Labs freezes PYUSD on Aave
7:34 PM – All tokens burned to inaccessible address
Total exposure value: $300,000,000,000,000 USD Market cap at time: $2.3 billion Error magnitude: 130,000x total supply
Our Analysis: Two Critical Vulnerabilities
Following the incident, we conducted a comprehensive security analysis of the affected contracts. We identified two critical vulnerabilities that, when combined, created the perfect conditions for this catastrophic minting event.
The rate limit configuration accepts any value without validation—including 300,000,000,000,000e18. There are no sanity checks, no upper bounds, and no invariant validation. This is the direct enabler of the 300 trillion mint.
require(limitCapacity <= totalSupply() * 10) // Sanity: max 10x supply
Our Assessment:
This vulnerability allowed an operator to configure a rate limit 130,000 times larger than the entire PYUSD market cap. Without validation, any input error could result in catastrophic consequences.
Finding #2: [HIGH] Unbounded Privileged Mint
Severity: High Location: PaxosTokenV2.sol: increaseSupplyToAddress()
The Vulnerability:
solidity
function increaseSupplyToAddress(
uint256 value, // ❌ NO MAXIMUM CAP
address mintToAddress
) external onlySupplyController {
_mint(mintToAddress, value);
emit SupplyIncreased(mintToAddress, value);
}
What We Found:
Once the rate limit is misconfigured (Finding #1), there's no secondary defense in the token contract itself. The function accepts any value parameter without intrinsic bounds checking.
require(value <= totalSupply() / 10) // Maximum 10% of supply per mint
Our Assessment:
The absence of hardcoded safety limits in the token contract created a single point of failure. If the configurable rate limit is set incorrectly, nothing prevents absurd minting amounts.
Root Cause Analysis
Based on Paxos's statement about an "internal technical error" and our vulnerability analysis, here's what we know happened:
The Sequence of Events:
Phase 1: The Mint
An admin called updateLimitConfig() which set limitCapacity = 300,000,000,000,000e18 (300 trillion tokens), then a process called increaseSupplyToAddress() with 300 trillion tokens.
Why it succeeded: No parameter validation (Finding #1) and no per-transaction cap (Finding #2)
Result: 300 trillion tokens minted
Phase 2: Detection (within minutes)
Blockchain monitoring alerts triggered. Community noticed on Etherscan. Paxos dashboards showed supply anomaly.
Phase 3: Emergency Response (22 minutes total)
Emergency burn transaction executed. All 300 trillion tokens sent to burn address. Supply restored to original levels. Public statement issued.
Key Insight: This required two separate vulnerabilities to align. Any single proper safeguard would have prevented or contained the incident.
Impact Assessment
Actual Impact:
✅ No customer funds lost (tokens burned before circulation)
$300 trillion exposure — larger than 2x global GDP
130,000x error magnitude — configuration mistake multiplied by missing safeguards
22 minutes of vulnerability — window for potential exploitation
Zero technical barriers — once misconfigured, nothing stopped the mint
Comparative Analysis: Industry Standards
Key Finding: PYUSD's architecture lacks multiple layers of protection that are standard in other major stablecoins. The absence of defense-in-depth made this incident possible.
The industry has repeatedly seen that the majority of major DeFi exploits stem from audited smart contracts. Audits miss critical vulnerabilities due to time, knowledge, or contextual constraints.
The Paxos incident demonstrates this perfectly: These vulnerabilities are not sophisticated zero-days. They are fundamental missing safeguards that would have been caught by:
Basic parameter validation testing
Boundary value analysis
Defense-in-depth evaluation
2. Defense-in-Depth Is Critical
The Paxos incident required two separate vulnerabilities to align:
Missing parameter validation (allowed bad configuration)
Unbounded minting (no secondary check)
If either layer had proper safeguards, the incident would have been prevented or contained.
3. Configuration Is Code
Configuration parameters are just as critical as code logic. They must have:
Validation bounds
Sanity checks
Audit trails
Review processes
4. Proactive > Reactive
On-chain monitoring is reactive: By the time the anomaly was detected, 300 trillion tokens already existed. The 22-minute window could have been catastrophic with malicious intent.
Proactive security catches issues during development: Before deployment, before audits, before exposure.
How Olympix Would Have Prevented This Incident
Our analysis reveals that both vulnerabilities would have been caught during development with Olympix's proactive security platform integrated into the workflow. Here's exactly how:
Phase 1: Continuous Development - Real-Time Security
What Happens:
As developers write code in their IDE, Olympix's static analysis runs continuously in the background, scanning every change in real-time. The moment vulnerable code is written, developers see immediate feedback.
For the PYUSD Vulnerabilities, Developers Would Have Seen:
Before engaging external auditors, development teams run Olympix's full security pipeline. This is where the platform goes beyond real-time alerts to perform deep analysis.
Automated Unit Test Generation:
Olympix would have automatically generated comprehensive test suites including edge cases:
solidity
// Auto-generated by Olympix
function test_updateLimitConfig_RevertsOnExcessiveCapacity() public {
Team fixes all issues before paying for external audit
Auditors spend time on novel/complex issues, not basic validation
30-80% reduction in audit findings
Shorter audit cycles mean faster time to market
Phase 3: Pre-Deployment - Final Security Validation
After audit and before deployment, Olympix runs one final comprehensive scan to catch any regressions or last-minute changes.
What It Catches:
Fixes that were inadvertently reverted during development
New vulnerabilities introduced in post-audit changes
Configuration issues in deployment scripts
Mismatches between audited code and deployment code
For PYUSD:
If the validation code had been added during audit but accidentally removed in final deployment preparations, Olympix would have flagged it immediately:
Alert: REGRESSION DETECTED
Previously resolved CRITICAL issue has reappeared: Missing parameter validation in updateLimitConfig()
Not on: Basic validation, missing bounds checks, test coverage
Result: More valuable audit, focused on sophisticated issues
Stage 4: PRE-DEPLOYMENT
Final Olympix scan:
Verify all fixes maintained
Check for regressions
Validate deployment configuration
Confirm emergency mechanisms work
Result: Deploy with confidence, zero surprises
Stage 5: POST-DEPLOYMENT
Drastically reduced exploit risk:
Fewer vulnerabilities deployed
Better emergency controls
Comprehensive test coverage
Result: Protection of funds, reputation, and user trust
Why Olympix's Technology is Superior
1. Custom Compiler and Intermediate Representation (IR)
The Problem with Existing Tools:
Most static analyzers (like Slither) work at the AST (Abstract Syntax Tree) level, missing deeper semantic issues.
Olympix's Approach:
Built our own compiler and custom IR
Deeper traversal into contract logic
Understands nuanced relationships between functions
Can trace data flow across multiple contracts
Result: 75% accuracy vs. 15% for other tools
2. AI Trained on Historical Exploits
Continuous Learning:
Large language model trained on every historical DeFi exploit
Continuously updated with new attack patterns
Recognizes anti-patterns that led to real-world hacks
For PYUSD:
The missing parameter validation pattern has appeared in multiple exploits. Olympix's training data includes these incidents, making detection highly reliable.
3. Intelligent Test Generation
Not Just Code Coverage:
Our automated testing uses three sophisticated components:
Custom IR + compiler-level analysis - Understands code at a deep level
Seven custom algorithms - Guide AI to build real, functional tests
Exploit-trained LLM - Generates tests based on known attack vectors
For PYUSD:
Would have automatically generated tests attempting to:
Mint with type(uint256).max
Configure limits exceeding total supply by 1000x
4. Mutation Testing for Security Validation
The Industry Gap:
Almost all exploits trace back to a bad commit that passed through the test suite. Without mutation testing, teams don't know if their tests actually work.
Olympix's Solution:
Introduces small changes ("mutants") to code
Verifies that test suite catches these changes
Identifies gaps in validation testing
Ensures security logic is properly tested
For PYUSD:
Would have proven that no tests existed to catch unbounded parameters, prompting immediate test suite improvements.
"Leveraging Olympix, our team has been able to uncover audit-level findings early in the development lifecycle which has streamlined our internal audits and given us confidence that we're maximizing external auditors' time." — Philipp Zentner, Co-Founder and CEO
Gauntlet
"Olympix is taking the best of crypto security tools and merging it with the best of AI tooling to provide a complete developer experience. With Olympix, deploying and securing smart contracts is now accessible to developers of all levels." — Tarun Chitra, Founder and CEO
"We saved money, first of all… But also we gained knowledge. So it was a win-win. Now every time we have to write a new smart contract, we have that knowledge gained from your tools. For me, as a business leader, that's really interesting in terms of scalability, efficiency of the product, and cost savings." — Gianluca Di Bella, Co-Founder and CEO
"Olympix as a tool enables our core developers to implement security themselves, instead of relying on teaching a third-party firm and outsider. That's where you're capturing all the alpha." — Joshua Gottlieb, Co-Founder and CEO
Blockdaemon
"I am impressed by Olympix' seamless integration with my preferred IDE and its ease of use. [Olympix] significantly helped us in creating secure smart contracts and automating code reviews." — Jonas Pfannschmidt, Principal Blockchain Engineer
Quantified Impact Across Customers
Adoption:
30% of Solidity developers use our free static analyzer
Over $10B in Total Value Locked (TVL) protected across customer protocols
Organizations from startups to global enterprises trust our platform
Efficiency Gains:
30-80% reduction in audit findings - Issues caught before external audit
Up to 50% reduction in audit costs - Fewer rounds, shorter cycles
20% faster project launch times - Through increased development efficiency
The $300 trillion PYUSD incident was entirely preventable. Our post-incident analysis identified two critical vulnerabilities that, when combined, created the conditions for this catastrophic minting event:
Unbounded minting — no secondary safeguards in token contract
None of these are novel or sophisticated vulnerabilities. They are fundamental missing safeguards that should be caught during development with proper tooling and practices.
With Olympix, both vulnerabilities would have been:
Flagged in real-time as developers wrote the code
Caught by automated testing before external audit
Verified as fixed before deployment
Prevented from reaching production
The solution is shifting security left: Integrating proactive security analysis into the development workflow catches these issues before they reach production. Development teams can find and fix vulnerabilities during coding, arrive at audits with dramatically fewer findings, and deploy with confidence.
The cost of prevention is trivial compared to the risk of billion-dollar exposure events.
Get Started with Olympix
Explore Olympix's suite of smart contract tools and learn more about the Olympix-led automated smart contract audit process. Empower your team to take control of your smart contract security from the start. Book a free demo!
What’s a Rich Text element?
The rich text element allows you to create and format headings, paragraphs, blockquotes, images, and video all in one place instead of having to add and format them individually. Just double-click and easily create content.
A rich text element can be used with static or dynamic content. For static content, just drop it into any page and begin editing. For dynamic content, add a rich text field to any collection and then connect a rich text element to that field in the settings panel. Voila!
Headings, paragraphs, blockquotes, figures, images, and figure captions can all be styled after a class is added to the rich text element using the "When inside of" nested selector system.
Follow-up: Conduct a follow-up review to ensure that the remediation steps were effective and that the smart contract is now secure.
Follow-up: Conduct a follow-up review to ensure that the remediation steps were effective and that the smart contract is now secure.
In Brief
Remitano suffered a $2.7M loss due to a private key compromise.
GAMBL’s recommendation system was exploited.
DAppSocial lost $530K due to a logic vulnerability.
Rocketswap’s private keys were inadvertently deployed on the server.
Hacks
Hacks Analysis
Huobi | Amount Lost: $8M
On September 24th, the Huobi Global exploit on the Ethereum Mainnet resulted in a $8 million loss due to the compromise of private keys. The attacker executed the attack in a single transaction by sending 4,999 ETH to a malicious contract. The attacker then created a second malicious contract and transferred 1,001 ETH to this new contract. Huobi has since confirmed that they have identified the attacker and has extended an offer of a 5% white hat bounty reward if the funds are returned to the exchange.
.png)
