Parallel

We’re proud to announce that Parallel V3 is live, starting with USDp! What’s new? A lot! - A modular architecture for stablecoins issuance - Depeg protection - Native saving assets - Crosschain by design - and more. blog.parallel.best/parallel-v3-is…

One week after the failed exploit attempt on May 7, we are sharing a status update on Parallel Protocol operations. Following internal verification by Cooper Labs, sign-off from our auditors, and the tightening of bridging, minting, and burning limits by the DAO multisig as an additional precaution, the following modules have been unpaused on all chains: - Parallelizer Module: USDp minting and burning is fully restored - Bridging Module: crosschain USDp transfers are fully restored The Savings Module (sUSDp) remains paused until the vault accounting patch is audited and implemented in production. USDp itself has remained fully transferable throughout the entire incident. We will provide a further update when the Savings Module is back online. A complete public post-mortem will follow shortly thereafter.

PGP-42, which aims to redirect sPRL PAR distribution toward PRL buyback and burn for a 3-month period, is now live on Snapshot until May 18th, 2026. To vote ↓

Proposal: gov.parallel.best/t/pip-69-usdp-…

A proposal has been published on the governance forum to update USDp Parallelizer backing asset parameters across four chains and tighten USDp Bridging Module limits across 24 chains. Read more ↓

Proposal: gov.parallel.best/t/pgp-42-redir…

A proposal has been published on the governance forum to redirect the PAR distribution currently allocated to sPRL holders toward PRL buyback and burn for a 3-month period. Read more ↓

PIP-68, which aims to introduce Parallel Tokenomics v2.1, is now live on Snapshot. To vote ↓

Results: vote.parallel.best/#/proposal/0x0…

PGP-41, which proposes to launch Phase II of Parallel’s Marketing & Growth Strategy with renewed liquidity growth incentives, continued ad deployment, and a new agentic payments cashback program, has been approved by the DAO. In accordance with the vote, Parallel will allocate a new budget to extend liquidity growth initiatives and bootstrap USDp usage for AI agent payments, while continuing ad deployment from the remaining Phase I budget.

Results: vote.parallel.best/#/proposal/0x2…

PIP-67, which proposes to introduce Parallel v3.2 by adding EIP-3009 support for USDp and sUSDp to enable compatibility with x402 and MPP payment flows, has been approved by the DAO. In accordance with the vote, Parallel v3.2 will be deployed across all active chains, and funds will be transferred to Cooper Labs to reimburse audit costs and cover deployment.

Follow-up to our earlier post: On May 7, 2026 at 19:50:47 UTC, an attacker attempted to exploit an accounting edge case in the sUSDp savings vault on Ethereum. The attempt failed. No funds were lost. User funds are safe. The vector was an ERC4626 inflation / donation-style attack against the sUSDp vault's accounting. In simple terms, the attacker tried to capture an inflated share of the vault's assets by first accumulating a very large percentage of the sUSDp vault supply, then attempting to trigger an inflation event and redeem against an accounting imbalance. This type of attack only becomes economically viable under very specific conditions, all of which had to hold simultaneously: 1. The attacker must control a very high percentage of the vault supply (>99% of totalSupply on the target chain), so that most of the inflated assets accrue to them rather than being diluted across other holders. 2. The vault must have had a long inactivity window (several weeks with no interaction), so that the dormant accrued yield accumulates and is minted in a single lump during the next interaction. These conditions were uniquely met on the Ethereum sUSDp vault: a small total supply (~2.7k sUSDp), no accrual for ~40 days (since March 29, 2026), and an attacker who had spent the previous 57 days quietly building a position of 2,672 sUSDp (~99% of the Ethereum supply), split across two independently funded addresses: - 0xfa8ba3b8ee8691847fbbc9532116ba3f21278b49 (372 sUSDp) - 0xb6747DF4D24338fD8e1C2b366D23825B35ADc4F3 (2,300 sUSDp) These two positions were funded from sources not directly linked on-chain to the attacker's operating address, which is the address used to deploy the exploit contracts and submit the attack transactions: 0x6375c37761a26fac9b201af9f527caa9627aea11 Estimated impact. Based on our auditors' analysis of the attack transaction, had the exploit succeeded, the attacker would have ended up with over 1.52M USDp. The mechanism would have unfolded as follows: 1. The attacker contract first transfers the sUSDp shares from the two preparation wallets, giving it 99.88% of the vault's totalSupply. 2. The contract then deposits 223.83M USDp into the savings vault. 3. The dormant fixed-rate interest accrual on the inflated balance mints an additional 1.525M USDp into the vault, bringing total assets to 225.355M USDp. 4. The contract redeems its 99.88% share, walking away with approximately 1.52M USDp. Forensic timeline (UTC): - A few hours before the attack: the attacker created a Safe (etherscan.io/tx/0x62d2d9041…). We are not certain of the intent, but our working hypothesis is that this was an attempt to disguise the on-chain pattern from monitoring systems such as Hypernative. - 19:50:47: The attacker initiated his first attempt by deploying an exploit contract (etherscan.io/tx/0xad04da7a5…). The attack transaction was submitted shortly thereafter and reverted on-chain. Based on our current analysis (still being confirmed), the revert was caused either by insufficient gas to cover the LayerZero fee for the bridge leg of the exploit, or by attempting to bridge an amount exceeding our daily cross-chain limit (2.5M USDp). Either way, the exploit did not execute. - ~30 to 45 seconds later: @HypernativeLabs' live monitoring detected the pattern, and the relevant contracts were paused within a few blocks of the failed transaction. - 20:52:23: The attacker deployed a second exploit contract (etherscan.io/tx/0x6b05092f7…) and submitted a second attack transaction. This one reverted because the contracts were already paused. - After the second failure: the attacker forwarded his remaining ETH through several intermediary wallets in sequence before sending it to what we believe to be a KuCoin address (etherscan.io/tx/0x203ec3aff…). This appears to be another attempt to obscure the trail. Why the attack failed: defense in depth. The attempt was stopped by three independent layers, any one of which would have been sufficient on its own. 1. The attacker's own attack transaction failed on-chain. Based on our preliminary analysis (still being confirmed), the failure was caused either by insufficient gas for the LayerZero fee, or by hitting the 2.5M USDp daily cross-chain bridge limit. The exploit therefore never executed. 2. @HypernativeLabs' live monitoring detected the pattern shortly after, and the relevant contracts were paused within a few blocks (~30 to 45 seconds) of the failed transaction. By the time the attacker re-attempted at 20:52:23 UTC, the contracts were already paused. 3. Bridge finality would have trapped the funds. Even in the counterfactual where the first transaction had succeeded and the bridge had been triggered, LayerZero finality from Ethereum to Base takes ~4 minutes. The pause of lz-USDp (within ~30 to 45 seconds) would have caught the in-flight bridge message well before delivery on Base, and the exploited USDp would have been frozen in the bridge. In other words, the attacker needed his transaction to land, the contracts to stay live for the next 4+ minutes, and the bridge to deliver. All three failed. Status of the attacker's position. With sUSDp paused, the attacker's 2,672 sUSDp are frozen. He cannot redeem, transfer, or otherwise access these funds. The address at the end of the on-chain trail, which we believe to be a KuCoin address, is subject to KYC, so the attacker is potentially identifiable. Why this is bounded. The same conditions that made sUSDp on Ethereum exploitable (small supply, multi-week inactivity, adversary holding ~all of it) do not currently exist on our other deployments: Base, HyperEVM, and Avalanche. The attack vector requires both a supply concentration and a dormancy window that are easy to monitor and prevent. Current status: - No funds were lost - User funds are safe - USDp remains transferable - The Savings Module (sUSDp) remains paused - The Bridging Module (lz-USDp) and Parallelizer Module remain paused for now as a precaution Based on the auditors' recommendations, the Bridging Module and Parallelizer Module will be unpaused once the DAO multisig signers tighten the bridging, minting, and burning limits. The Savings Module will remain paused until the vault accounting patch is finalized and audited. As an immediate operational measure, on the auditors' recommendation we have already issued a setRate() call across all four deployments (Ethereum, Base, HyperEVM, Avalanche) to reset the accrual state and clear any accumulated dormant lump. Two independent audits will be performed on the patched contracts, by @bailsecurity and @cyfrin, before redeployment. The module will only resume once we and our partners are fully confident the vector is closed. This is exactly why we operate with multiple layers of security: audits, bug bounty, live monitoring, emergency pause procedures, backup domains, and additional operational safeguards. Today, every layer was tested and held. A full post-mortem will follow in the coming days with the complete technical write-up, timeline, remediation steps, and next actions.