Contents

pDAI Exploit Deep Dive — pMaker and pCOMP

Date compiled: 2026-05-17

Sources:

• PDAI_REPEG_WORKBOOK.md — on-chain forensic research, 2026-04-13
• PDAI_MASTER_RESEARCH.md — compiled master document, 2026-05-17
• Telegram pDAI Chat Export 2026-05-14 — "DAI on PulseChain" group (881 HTML pages)
  • Reliable contributors cited here: IronClad (verified step-by-step of Proposal 162), NineIronCapital (ongoing technical analysis), Marsman (technical corroboration of 5996 mechanics), SigewulfCW3 (on-chain research and wallet analysis)

Evidence standards used throughout:

• Verified — directly confirmed from on-chain RPC or primary-source code
• Supported — consistent with evidence, not directly proven
• Unverified — plausible lead not confirmed
• Telegram-sourced — community intelligence; treat as informed speculation unless corroborated

Table of Contents

1. The pMaker Exploit — Full Technical Breakdown

   • 1.1 Background: Why pMaker Was Vulnerable From Day One
   • 1.2 Phase 1 — The Fork Oracle Mismatch (Mid-2023)
   • 1.3 Phase 2 — Controlled Vault Cleanup (2024–2025)
   • 1.4 The Self-Liquidation / Vault Extraction Stack — Verified Mechanics
   • 1.5 5996's On-Chain Message — A Direct Explanation
   • 1.6 The Helper Contract Stack
   • 1.7 Marsman's Technical Corroboration (Telegram)
   • 1.8 NineIronCapital's Interpretation
   • 1.9 Who Was Accused — The "Vietnamese Kid" Narrative
   • 1.10 Pulse Wallet's Police Report and the LUSD Connection
   • 1.11 Richard Heart's Public Position and Tweet Deletions
   • 1.11b Kotryna (Catty), Surfacing, and the Flop Auction / ESM Period
   • 1.12 Debated Questions and Open Status

2. The pCOMP Governance Capture — Proposal 162

3. The Wallet Cluster: 5996 → 0000 → 1967

   • 3.1 Cluster Overview
   • 3.2 Wallet 5996 — The Master Orchestrator
   • 3.3 Wallet 0000 — The pCOMP Governance Bridge
   • 3.4 Wallet 1967 — The Active Operations Bot
   • 3.5 How the Wallets Are Linked
   • 3.6 Recent 1967 Activity (May 2026)
   • 3.7 5996's Admin Control Over the Forked Arbitrum L2
   • 2.1 Overview: What Kind of Attack This Was
   • 2.2 Attack Wallets
   • 2.3 Background: How Compound Governance Works
   • 2.4 Phase 1 — Acquiring COMP Voting Power
   • 2.5 Phase 2 — Capturing the Timelock via Proposal 162
   • 2.6 Phase 3 — Draining Compound v3 (Comet)
   • 2.7 Phase 4 — Final Asset Drain
   • 2.8 Why It Worked — IronClad's Analysis
   • 2.9 Post-Capture Activity by 0x5aE20b
   • 2.10 The July 2025 Early Warning That Was Ignored
   • 2.11 The cDAI Overhang — What Remains
   • 2.12 Community Reaction and Ongoing Observations

1. The pMaker Exploit — Full Technical Breakdown

1.1 Background: Why pMaker Was Vulnerable From Day One

When Richard Heart forked Ethereum to create PulseChain in May 2023, every Ethereum smart contract was copied to the same address. This included the entire MakerDAO stack:

The oracle contracts were copied in their frozen state. The MakerDAO Spotter/OSM system was never connected to any live PulseChain price feeds after the fork. The oracle price for assets like pWETH inside the copied Spotter remained frozen at Ethereum-era valuations — approximately $1,800–$2,200 per pWETH — while pWETH's actual PulseChain market price was a tiny fraction of that (PulseChain assets launched at massive discounts relative to their Ethereum counterparts).

This created a massive structural gap: the system would accept pWETH as collateral valued at Ethereum prices, while the real cost of acquiring that pWETH was far lower. The system had no mechanism to close this gap on its own.

"When the fork happened, pDAI had an inflation bug as the oracles were broken. This caused a lot of vaults to be able to mint pDAI using pWETH, and completely over leverage them. Once the oracles were updated, these vaults broke and became bad debts." — NineIronCapital, Telegram, 11 Mar 2025

1.2 Phase 1 — The Fork Oracle Mismatch (Mid-2023)

What happened: In the weeks and months after the fork, anyone who understood the Maker vault system could open vaults directly (bypassing any front-end), deposit cheap pWETH as collateral, receive pDAI at Ethereum-era valuations, and sell that pDAI on PulseX. No front-end existed. No governance was monitoring supply. No on-chain alarm system triggered an emergency.

The scale of the inflation:

• pDAI supply at fork: approximately 5.4 billion (copied from Ethereum DAI supply)
• pDAI supply by March 2025: approximately 24.5 billion
• Net inflation: approximately +19 billion pDAI minted beyond the original supply

The vast majority of this inflation was driven by the oracle mismatch. Anyone with access to PulseChain and knowledge of the MakerDAO vault system could participate — no special keys required, just the ability to interact with the Vat directly.

The governance response: At some point (the community dates this to around July 2023), a pMKR governance vote was passed to set restrictive debt ceilings or disable certain vault types. NineIronCapital references this in the Telegram group:

"These debt ceilings were exceeded well before July 2023 when there was a minting exploit. This was shut down with the governance vote." — NineIronCapital, Telegram, 20 Mar 2025

After this governance action, Phase 1 effectively ended — new over-leveraged vaults could no longer be opened. But the Phase 1 legacy remained: thousands of vaults that had minted pDAI against pWETH at Ethereum-era prices were now massively under-collateralized, since the oracle prices had since been adjusted or the gap was too large to sustain. These became the "bad debt" vaults that Phase 2 addressed.

Status: Supported. The supply inflation is directly verifiable on-chain. The oracle mechanism is verified. The exact set of participants and the precise governance timeline are documented in community sources but not independently confirmed from primary on-chain data in this pass.

1.3 Phase 2 — Controlled Vault Cleanup (2024–2025)

The thesis: Beginning in late 2024 and accelerating through March 2025, wallet 0xB8698CfFFdAAf26ca21fE8aA560c18cc2b2f5996 (known in the community as "5996") systematically identified and liquidated the bad vaults created in Phase 1. Each liquidation:

1. Triggered the Maker auction mechanism (Clipper)
2. Settled the under-collateralized debt against the system's surplus buffer (Vow)
3. Generated pDAI paid to the liquidation keeper (5996 or associated wallets)
4. That pDAI was then sold on PulseX, which is why the community and Richard Heart observed ongoing pDAI sales during this period

From the outside — especially to someone watching PulseX charts and wallet activity but not reading on-chain traces — this looked identical to "someone minting pDAI from thin air and dumping it." The mechanics were fundamentally different, but the visible market effect (new pDAI appearing and being sold) was the same.

NineIronCapital's summary:

"The wallets are going through all of the bad debts in the vaults that the original minters setup and cleaning them up." — Telegram community, Mar 2025

"He is being paid by pMKR to help. It was excess in there from before the fork. This is the contract working perfectly. We need this guy to rip through the surplus to get us into deficit." — NineIronCapital, Telegram, Mar 2025

The significance of the surplus: The pMaker Vow contract had accumulated a large "Joy" buffer — pDAI received from stability fees on the Phase 1 vaults. The MakerDAO system is designed to pay vault cleanup operators (keepers) from this surplus. Once the surplus hits zero, the system enters deficit, and the Flop auction mechanism activates: new pMKR is minted and auctioned for pDAI, which burns the pDAI, pulling the supply down toward the peg.

"It is unknown at this point. It really looks like the guys minting are the guys rebuilding pMKR." — NineIronCapital, Telegram

Status: Supported (not proven). The vault cleanup framing is the most coherent technical explanation for the on-chain traces. Whether it was a deliberate orchestrated repair program paid by pMKR governance, an opportunistic extraction by someone who understood Maker better than anyone watching, or both simultaneously, remains contested.

1.4 The Self-Liquidation / Vault Extraction Stack — Verified Mechanics

The following is confirmed by direct PulseChain RPC on transactions 0x33db7984ec22284c57e60df3cde6f6a9f9c63f4eeccb68c96b01bd9e199d4cbb and 0x61cc8981f767ed2c263607976fe39952144f992f786fdd76815a25e7f70a5241, both from 27 March 2025.

The execution path, step by step:

1. 4f70.execute(address) is called by wallet 5996 (or associated wallet B51d). The address passed is the Clipper contract.

2. Inside 4f70.execute():

   • DssCdpManager.cdpAllow(cdpId, 0xcb7581, 1) — grants the second helper (cb7581) permission to act on a specific CDP (vault) in the manager registry.

3. 4f70 then calls cb7581.execute(Clipper, cdpId).

4. Inside cb7581.execute():

   • Clipper.list() — retrieves the list of active auctions
   • Clipper.getStatus(auctionId) — checks the current state of a target auction
   • Clipper.take(auctionId, amt, max, who, data) — executes the purchase of collateral at the current auction price

5. Additional Maker system primitives also touched in the same trace:

   • Jug.drip(ilk) — accrues stability fees for the vault type
   • Dog.bark(ilk, urn, kpr) — triggers formal liquidation of an under-collateralized vault
   • Clipper.kick(tab, lot, usr, kpr, coin) — creates the auction for the liquidated vault
   • DssCdpManager.frob(cdp, dink, dart) — adjusts collateral and debt for a CDP
   • DssCdpManager.move(cdp, dst, rad) — moves internal DAI balance within the Vat
   • Vat.can(usr, caller), Vat.dai(usr), Vat.gem(ilk, usr), Vat.ilks(ilk), Vat.urns(ilk, usr), Vat.move(src, dst, rad), Vat.flux(ilk, src, dst, wad) — core accounting reads and writes

6. Price data flow:

   • Clipper reads Spotter.par() for the reference DAI price
   • Clipper reads OSM.peek() for the collateral asset price

What this proves: This is a real Maker liquidation and vault-management execution stack, self-built by wallet 5996 using custom helper contracts. It is not an "arbitrary mint button," a hidden admin backdoor, or a simple flash-loan exploit. The verified path shows a sophisticated operator working through the standard Maker auction and vault mechanics — just without the front-end that normal users would use, and with a level of technical depth that no retail participant would have had.

"Basically it's official now? There never was a minting bug or an exploit. Just someone who is smart enough to utilize the maker dao auctions without a front end, so that he currently has no competition for the auctions." — Telegram community, Mar 2025

Status: Verified. The "free mint" framing is materially misleading. The most precise description is: a custom helper-driven Maker liquidation / vault extraction / internal-balance recycling strategy.

Why No One Else Could Replicate It

A question that ran through the Telegram community for weeks: if the auctions were open protocol functions, why could no one else compete with 5996?

The technical answer (community consensus, messages249–252 and Surfacing8671 in messages292–296):

The Maker liquidation auctions on PulseChain had no front-end. No interface existed for a normal user to browse open auctions, bid on collateral, or manage vault liquidations. Interacting with them required:

1. Raw knowledge of the Maker Clipper/Vat/Dog/DssCdpManager ABI
2. The ability to construct and send transactions against these contracts directly
3. Custom execution infrastructure to handle the multi-step flow (trigger liquidation → create auction → bid → settle Vat balance → exit)

5996 had spent months building exactly this infrastructure. Its helper contracts (4f70 and cb7581, then extended to five helpers by early April 2025) automated the entire sequence. The helpers had addWhitelist(address) functions — meaning only addresses 5996 had explicitly whitelisted could use the stack. No one else could piggyback on 5996's helper contracts without being added to the whitelist.

However — and this is the key nuance — the auctions themselves were technically open to anyone. The whitelist only gated 5996's specific execution stack. A sufficiently skilled operator could have built their own competing helper set.

The barrier was therefore not cryptographic or administrative, but practical:

"He is just getting a good deal on the arb because he's the only one who figured out how to do it so far. Once we figure it out then people can compete with him on the auctions and he can't loop them and Joy will go to zero." — Community member "Red", Telegram, messages249.html

"Since no one else is bidding on his vaults going down as the auction goes on he just bids when it's low enough to profit and has no competition." — Royson Heart, Telegram, messages250.html

"And so far the exploiter is the only one who can bid, that's why its not an exploit, its working properly. But we will be able to bid on new auctions." — Telegram community, messages251.html

"Anyone can do said transactions." — Surfacing8671, Telegram, messages296.html

Surfacing8671 also explained the whitelist specifically in messages292.html:

"Yes it is a contract that he is adding other contracts to its whitelist so the contracts can interact with each other... each contract could hit the vaults and vats at a single time maxing out the debt when it drops below the ceiling. Honestly its probably an ease of use kinda thing. Because if I were to set that up, I would do it so that I just click one function to execute instead of having to put in all of the other parameters by hand."

Summary: 5996 had a de facto monopoly on the auctions for technical reasons — no front-end existed, no competing infrastructure had been built, and no one else had the deep Maker mechanics knowledge to do it without a helper stack. The auctions were not locked; they just required expertise that no one else in the community had deployed. 5996 was, in practice, the only active participant.

Important caveat: Proving the path was a legitimate Maker liquidation strategy does not prove there was no exploitable misconfiguration in the system. The oracle mismatch at fork-time that enabled vastly over-leveraged Phase 1 vaults is still the root cause of the supply inflation. Whether that oracle mismatch was foreseeable, accidental, or deliberate is not proven by this evidence.

1.5 5996's On-Chain Message — A Direct Explanation

On 25 March 2025, wallet 5996 sent transaction 0xd264c4a19a282fcdf2c242f60e5d86a0058b2b23be3824a9a8d4a66df01d9b38 — a 1-wei transfer with a long ASCII message embedded in the calldata.

The message was addressed to the pDAI community. Key claims made:

• Explicitly denied "unlimited mint rights" or a special mint key
• Explained that profit came from bidding on collateral in Clipper.take(...) auctions
• Described using the Vat internal DAI balance (move function) to transfer value between vaults without withdrawing to the open market
• Named the helper contracts it had deployed: 0x4f70...fa460 and 0xcb75...a1e6
• Explained that the cdpAllow() mechanism was used to grant helper permission to act on CDPs

The fact that this message was sent at all — a self-identifying, publicly readable, technically detailed explanation — is significant. It is consistent with an operator who believed their activity was legitimate and wanted the community to understand the mechanics rather than continue attributing them to malicious free-minting.

Richard Heart acknowledged this message in his tweet on 25 March 2025:

"One exploiter is even messaging you on chain today, explaining how he's doing it! One of the new accts minted $180k worth today, and the one that sent this message only minted like $12K?"

RH's framing continued to describe 5996 as an "exploiter," dismissing the technical explanation.

Status: Verified. The transaction and its calldata are confirmed on-chain. The helper contracts named in the message were confirmed as deployed by 5996 on 2025-03-11.

1.6 The Helper Contract Stack

Wallet 5996 built and maintained a growing stack of helper contracts throughout the Phase 2 period:

A critical observation: By 3 April 2025, address 0x27ded4...10ECc — a wallet not previously associated with 5996 — was independently using and extending the helper path (calling cb7581.execute() and cb7581.addWhitelist()). This means the helper stack had already been shared with or replicated by at least one other operator within three weeks of its deployment. This directly complicates the "single rogue exploiter" narrative that dominated public discussion.

Richard Heart himself noted this in his 26 March 2025 tweet:

"Congratulations to the multiple exploiters minting pDAI out of thin air today and selling it on PulseChain! One exploiter is even messaging you on chain today, explaining how he's doing it!"

The community at this point began speculating about whether there was a "final boss" beyond 5996 — potentially an Ethereum-side MKR holder who could access the Maker governance contracts.

1.7 Marsman's Technical Corroboration (Telegram)

Community member Marsman provided independent on-chain analysis in the Telegram group that corroborated 5996's self-description. Marsman's analysis, shared 14 March 2025:

"5996 is using move function to give the authority to the seller wallet to use the exit function from the vault. I can confirm it's the same entity. It's not minting from thin air. Look at the raw data of 5996 move transactions." — Marsman, Telegram, 14 Mar 2025

Marsman's analysis was based on reading the raw Vat move transaction data — the same internal accounting function that 5996's on-chain message later described. The key insight was that "minting" was not occurring in the traditional sense; internal DAI balances were being moved within the Vat accounting system, with the exit function then used to convert those internal balances to the ERC-20 pDAI that could be sold.

This independently verified 5996's explanation before 5996 published the on-chain message.

1.8 NineIronCapital's Interpretation

NineIronCapital was one of the most technically informed voices in the Telegram group throughout the pMaker period. Their running analysis across multiple message files consistently held that:

1. The Phase 1 inflation was the real exploit — the oracle mismatch that let vaults be over-collateralized
2. Phase 2 (wallet 5996) was controlled vault cleanup, not a new exploit
3. Wallet 5996 was operating under pMKR governance authorization, essentially acting as a keeper being paid from the system surplus

Selected quotes from NineIronCapital, Telegram (March 2025):

"When the fork happened, pDAI had an inflation bug as the oracles were broken. This caused a lot of vaults to be able to mint pDAI using pWETH, and completely over leverage them. Once the oracles were updated, these vaults broke and became bad debts." (11 Mar 2025)

"These debt ceilings were exceeded well before July 2023 when there was a minting exploit. This was shut down with the governance vote." (20 Mar 2025)

"It is unknown at this point. It really looks like the guys minting are the guys rebuilding pMKR." (Mar 2025)

"He is being paid by pMKR to help. It was excess in there from before the fork. This is the contract working perfectly. We need this guy to rip through the surplus to get us into deficit." (Mar 2025)

Quantified surplus drawdown (NineIronCapital tweet thread, March 2025):

NineIronCapital's Twitter analysis published in March 2025 put precise numbers on the surplus trajectory during the vault cleanup period:

• System surplus (pMaker Vow "Joy") at the start of the active cleanup: approximately 411M pDAI
• System surplus at the time of analysis: approximately 126M pDAI
• Implied drawdown: approximately 285M pDAI — consistent with 5996 having paid down roughly 250M pDAI of bad debt during the cleanup phase

This quantification is significant for two reasons. First, it confirms the scale of the vault cleanup: a quarter of a billion pDAI in bad debt resolved in a relatively short active phase. Second, it implies the system was still materially above zero at the time of writing — the Flop auction threshold (surplus reaching zero) had not yet been crossed. NineIronCapital's interpretation throughout was that this threshold crossing was the next structural event in the peg restoration sequence.

NineIronCapital's August 2024 tweet on RH governance control:

A separate NineIronCapital tweet published 25 August 2024 captures a broader observation about the governance capture:

"RH has control of pMKR, pCOMP, pBAL and many others." — NineIronCapital, Twitter, 25 Aug 2024

This tweet predates the March 2025 public awareness period and suggests that the governance control picture was understood by at least some analysts considerably earlier. The reference to pBAL (the PulseChain fork of Balancer governance) alongside pMKR and pCOMP suggests the governance capture was not limited to just the two protocols documented in detail in this file — it extended to the full stack of forked DeFi governance tokens.

Status: Telegram-sourced for March 2025 quotes; Twitter-sourced for surplus quantification and August 2024 governance observation.

1.9 Who Was Accused — The "Vietnamese Kid" Narrative

As the pDAI situation gained public attention in March 2025 — amplified significantly by Richard Heart's 29 tweets on the subject — a specific identity accusation emerged in the broader community.

The origin of the narrative:

Richard Heart's tweets repeatedly described watching "the exploiter" sell pDAI in real time, with language that implied a single identifiable bad actor:

"You can watch the exploiter sell his newly minted pDAI in real time." — Richard Heart, tweet (later deleted), ~Mar 2025

This framing, combined with the fact that the pDAI supply inflation was a known event with on-chain footprints, led portions of the community outside the Telegram group to speculate about the exploiter's identity. The specific accusation that emerged publicly was that the exploiter was a "Vietnamese kid" — sometimes referenced with the name "Do Soh Ann" in the repeg workbook's community notes.

The community's reaction:

Inside the "DAI on PulseChain" Telegram group, this narrative was treated with significant skepticism and mockery:

"Vietnam's most wanted" — community member, Mar 2025

"The narrative of the Vietnamese kid is hilarious" — community member, Mar 2025

"He's using them new high tek vietnamese flash loans" — community member (mockingly), Mar 2025

"We are all Vietnam Dong" — community member

Status of the "Do Soh Ann" claim: Unverified. The repeg workbook explicitly labels this identity attribution as "Unverified." No corroborating on-chain metadata, local-file evidence, or source-backed public reference was found for this identity claim. It appears to have been a community-generated narrative circulating on social media rather than a claim backed by on-chain or investigative evidence.

The mockery of the narrative inside the more technically informed Telegram group suggests that community members who had actually analyzed the wallet mechanics did not take the specific identity attribution seriously.

1.10 Pulse Wallet's Police Report and the LUSD Connection

The most serious escalation of the identity accusations came from a separate party: the Pulse Wallet team (a PulseChain wallet application).

On approximately 25 March 2025 (messages245.html), community member "His HEXellency" posted:

"Pulse Wallet is claiming that 5996 was behind the LUSD infinite mint and also exploited other chains. They are filing police reports, they know his address and banking. This has gone too far if he is a white hat actor."

Another community member responded:

"he did rug LUSD, but good luck to them nothing will probably come of it"

Key points from this claim:

1. The LUSD connection: LUSD is the stablecoin of the Liquity protocol. An "infinite mint" exploit on another chain involving wallet 5996 would be a far more serious allegation than the pDAI situation — it would suggest 5996 was exploiting systems across multiple chains, not just serving as a pMaker keeper.

2. Police reports: Pulse Wallet claimed to have filed formal police reports, asserting they knew the physical address and banking information of the wallet operator.

3. "White hat actor" concern: The community member's framing — "this has gone too far if he is a white hat actor" — reflects the dominant Telegram interpretation that 5996 was doing legitimate vault cleanup, not malicious exploitation. If Pulse Wallet was filing police reports based on a misunderstanding of the mechanics, the community considered this a serious injustice risk.

Status of the LUSD claim: The LUSD connection is Telegram-sourced only. No on-chain verification of this claim was performed in the repeg workbook. It is plausible that wallet 5996 or an associated operator applied similar Maker-style liquidation mechanics on other chains, but this remains unverified.

What happened with Richard Heart's tweets: Shortly after the police report claims emerged, Richard Heart deleted the specific tweet in which he had said people could "watch the exploiter sell in real time." The Telegram community speculated this was because the tweet was being used by people attempting to report the "Vietnamese Kid" to authorities:

"Richard Heart just deleted his pDAI posts where he said: 'You can watch the exploiter sell his newly minted pDAI in real time.' Maybe its because people are trying to report the Vietnamese Kid to the authorities and it went too far?" — Telegram bot alert, Mar 2025

The deletion was confirmed by multiple Telegram members. RH subsequently scaled back the "exploiter" language in his tweets, though he continued to post about pDAI.

Status: Telegram-sourced. The deletion is corroborated by multiple community members. The motive for deletion (police report risk) is community speculation, not confirmed by RH.

1.11 Richard Heart's Public Position and Tweet Deletions

Richard Heart posted approximately 29 tweets about pDAI in March 2025 alone, plus additional posts in April and later. His framing evolved somewhat over time but consistently treated the vault activity as "exploitation":

Key RH statements:

"Something has inflated the pDAI supply by multiples. (free DAI fork). pDAI has 24.5B supply now. DAI had under 10B at the Ethereum fork. Who's minting that supply and why are they, it's rumored, dumping it and bridging out?" (21 Mar 2025)

"Stop buying pDAI?" (22 Mar 2025)

"TLDR; pDAI had 6B supply at fork, now it has 24B, you didn't get that inflation, exploiters did." (26 Mar 2025)

"Life would be better if everyone would remove all liquidity for pDAI vs everything else." (28 Mar 2025)

"The pDAI cancer may be coming to an end. 22 hours ago someone ran the fire function on the ESM module, which runs the cage function in the end contract, which begins the shut down of the system." (17 Apr 2025)

By October 2025, RH's tone had shifted from active concern to retrospective dismissal:

"pdai is literal garbage, but lots of literal garbage has had price go up in crypto, so good luck" (14 Oct 2025)

"Are you retarded? pdai exploiter appeared like a year or two after someone else already free minted tons and tons and even built a whole ecosystem around it." (14 Oct 2025)

This later framing notably acknowledges two distinct phases ("someone else already free minted tons and tons" before the "exploiter appeared") — more consistent with the Phase 1 / Phase 2 community analysis than his original "single exploiter" framing.

1.11b Kotryna (Catty), Surfacing, and the Flop Auction / ESM Period

Who Catty and Surfacing are:

Kotryna, known in the Telegram group as "Catty" or "K_Cattie", and community member Surfacing8671 were two of the most technically informed non-operator voices in the pDAI community during March–April 2025. Both had prior history with the Maria/xUSD ecosystem on PulseChain:

"Kotryna is very educated on stable coins as well surfacing who is another member of xusd has worked aside maria as well and helped with code. Their education on the protocol makes a big difference on their explanations." — Telegram community, messages285.html

They were coordinating on a community-driven governance spell and ESM response — working on oracle fixes, spell deployment, and evaluating whether an emergency shutdown would protect the community. Their GitHub repo (Surfacing-8671/pmakerSpell) was referenced in the Telegram as containing their spell work.

The governance attack risk Catty identified:

On approximately 11 April 2025, Kotryna posted a detailed, candid analysis (messages324.html) of what she and Surfacing had concluded after weeks of working on the problem:

"At this point there is nothing that could be done to prevent 5996 from taking over Maker governance... If 5996 is malevolent that's what he can do: 1. Win flop auctions with not that much capital needed and have the maker to back the hats as quickly as within a day of joy hitting 0. 2. Cast a spell to mint himself whatever amount of Maker he wants from DSPause and set debt ceiling to like 200b on eth b and use 100m (about 2.2k atm) pulse to mint 150b of Dai (can be trillions) and drain all the liquidity from all Dai + withdraw all the collateral from the vaults. Esm would stop that."

Her analysis concluded:

• 5996 already held roughly 25% of the circulating pMKR supply (possibly more via clean wallets)
• The Flop auction system — which would kick in when Joy (surplus) hit zero — would mint new pMKR and auction it for pDAI
• Whoever won those Flop auctions would accumulate governance-grade pMKR rapidly
• Any spell proposal would only delay the threat; the ESM was the only clean solution
• She and Surfacing were both doxed (publicly identifiable), and feared personal consequences if their spell triggered an ESM that "killed pDAI" — so they chose to step back and make the work available to others

"We both are doxxed, and do not want to take responsibility for his gov attack making it in the end. But, the stuff we did for the spell proposal is available for you guys in the github including all the contracts we have deployed." — Kotryna (Cattie), Telegram, messages324.html

Surfacing confirmed they would not deploy it:

"But we won't deploy it. It's very easy to do it though." — Surfacing8671, Telegram, messages301.html

The community's read on this:

"Basically surfacing is saying that since they are both doxed, they know people would likely come looking for them if 'they' launch a spell that leads to an ESM and kills pDAI. But he is also saying, they quit because they now don't fully know that they are right about it." — RandalMeThis, Telegram, messages301.html

Surfacing was subsequently banned from the Telegram group (messages302.html).

5996 "letting Catty win" the Flop auctions:

When Joy hit zero and the Flop auction system activated, Kotryna's group participated in the auctions — bidding pDAI to receive pMKR. With 5996 being the only other participant with the technical capability to bid aggressively, the critical question was whether 5996 would counter-bid and accumulate governance control.

5996 chose not to counter-bid.

By standing aside, 5996 allowed Kotryna's group to win the Flop auctions and accumulate approximately 46,000 pMKR — enough to pass a governance spell. NineIronCapital noted that Catty's wallet had minted approximately 10 billion pDAI using the pMKR won from those auctions and the subsequent spell.

Kotryna's own summary of what this meant, in direct language:

"If 5996 didn't let us win he would have full rugged it." — Kotryna (Cattie), Telegram, messages345.html

And from messages319.html, Kotryna explaining what her group did with the 46k pMKR:

"We just got enough gov tokens to pass a winning spell in. There are 780k other gov tokens on the chain that could have done the same what we did with just 46k. We just redistributed the funds into something that actually is supposed to work in pulse eco in our opinion."

The community observed: "But then they didn't fkn even try to counter-bid Kotryna." (messages323.html)

NineIronCapital's assessment of what Catty's mint represented:

"If you have a look at the pDAI holders list, you will see that half of the 10bn pDAI that Cattie minted is no longer in their wallet. I don't know where it is being moved too. 3CRV definitely and a few others. But it's worth considering that there is a plan." — NineIronCapital, Telegram, messages324.html

Kotryna herself reflected on the broader significance:

"I am pretty sure even if RH was somewhat behind it, it's all related to not letting these protocols have weaknesses. Maker was a deadly risk to pulsechain during joy 0. Like someone could have left the keys and have a permanent extraction point." — Kotryna (Cattie), Telegram, messages345.html

Status: Telegram-sourced throughout. The Flop auction mechanics and the pMKR accumulation are consistent with verified system behavior. The characterization of 5996 "letting Catty win" is Kotryna's own direct statement. The 10 billion pDAI minting figure comes from NineIronCapital's observation. Neither the specific auction transactions nor the wallet-level pMKR flows are independently verified in the repeg workbook.

1.12 Debated Questions and Open Status

2. The pCOMP Governance Capture — Proposal 162

2.1 Overview: What Kind of Attack This Was

Between July 2025 and January 2026, an attacker took complete control of PulseChain's forked Compound Finance governance, then used that control to drain multiple markets.

This is fundamentally different from the pMaker situation. The pCOMP capture was not a technical exploit, not a bug, and not an oracle mismatch. It was a governance manipulation — the attacker used the Compound governance system exactly as designed, but maliciously. No code was broken. No vulnerability was found. The governance process itself was weaponized.

IronClad's framing (Telegram, 25 January 2026, reliable source per user):

"Nothing was hacked. Every function worked exactly as designed. The attacker: Didn't exploit a bug. Didn't find a vulnerability. Didn't break any code. They just asked nicely (via governance) and nobody said no." — IronClad, Telegram, 25 Jan 2026

"The code was secure. The governance wasn't." — IronClad, Telegram, 25 Jan 2026

2.2 Attack Wallets

2.3 Background: How Compound Governance Works

For context, the pCOMP governance system (a copy of Compound Finance) operates as follows:

1. Proposals: Any wallet holding enough COMP tokens can submit a governance proposal — a set of on-chain actions to be executed if the proposal passes.

2. Voting: COMP holders vote yes or no. The proposal passes if enough votes accrue before the deadline.

3. Timelock: If a proposal passes, it enters a mandatory 48-hour waiting period (the Timelock) before it can be executed. This is a safety mechanism: if a malicious proposal passes, the 48-hour window is supposed to give the community time to respond.

4. Execution: After the 48-hour delay, anyone can trigger execution of the proposal's actions.

The Timelock is the master key. The Timelock contract controls all administrative functions in the Compound protocol — oracle changes, market listings, collateral factors, and everything else. Whoever controls the Timelock admin key controls everything.

2.4 Phase 1 — Acquiring COMP Voting Power

This is the entry point that made the entire attack possible. The attacker found a vulnerable contract (0xe6df4ca...) that had accrued COMP rewards but had no protection against being drained.

Step-by-step, per IronClad's verified walkthrough:

Step 1: Attacker's drainer contract (0x8f0cd46c6873decedbc891f9099123ebdade681a) interacted with the victim contract (0xe6df4ca...).

Step 2: Set unlimited COMP approval from the victim contract to the attacker's drainer contract.

• This allowed the attacker to transferFrom any amount of COMP from the victim in subsequent steps.

Step 3: Called claimComp() on the Compound Comptroller.

• This function harvests all accrued COMP rewards for a given account across all COMP-earning markets.
• Markets drained: cBAT, cDAI, cETH, cUSDC, cUSDT, cWBTC, cZRX, cSAI, cUNI
• All COMP rewards that had accumulated in the victim contract across all these markets were sent to the victim's wallet by the Comptroller.

Step 4: Called transferFrom(victimContract, attackerWallet, ~71,000 COMP).

• Using the unlimited approval set in Step 2, the attacker drained approximately 71,000 COMP from the victim contract to the main attack wallet.

Result: The attacker now held approximately 71,000 COMP. In a governance system with low participation (as is typical on forked PulseChain protocols), this was enough to submit and unilaterally pass governance proposals.

Why the victim contract was vulnerable: The victim contract (0xe6df4ca...) was apparently a contract that earned COMP rewards but had no access controls preventing a third party from setting approvals on its behalf or claiming its rewards. This is the entry-point bug — not a Compound core contract flaw, but a poorly designed or abandoned peripheral contract that had been earning COMP since the fork with no one watching it.

2.5 Phase 2 — Capturing the Timelock via Proposal 162

With 71,000 COMP in hand, the attacker moved to the governance takeover.

Step 5: Attacker submitted Governance Proposal 162.

• The proposal contained multiple actions — some potentially legitimate-looking, some hidden within the complexity.
• The critical hidden action: Timelock.setPendingAdmin(0x5aE20bfad1039CE1Fa1eD7B2308c18F3f0B9c06a)
• This single action, if executed, would designate 0x5aE20b as the pending new admin of the Timelock. The pending admin then has the power to finalize the takeover by calling acceptAdmin().

Step 6: Proposal 162 passed.

• Either the attacker's 71,000 COMP provided enough votes to pass unilaterally, or voters failed to audit the proposal's contents before voting yes.
• In a forked protocol with low community engagement, governance proposals rarely receive serious scrutiny.

Step 7: Mandatory 48-hour Timelock delay begins.

• This is the safety window. The community had 48 hours to notice the malicious setPendingAdmin action, mount a challenge, or otherwise respond.
• No meaningful response occurred.

Step 8: Attacker executed the proposal via the multicall contract (0x658c3130...).

• The Timelock processed the proposal's actions.
• Timelock.setPendingAdmin(0x5aE20b) executed, setting 0x5aE20b as pending admin.

Step 9: 0x5aE20b called acceptAdmin() on the Timelock.

• By calling this function, 0x5aE20b confirmed acceptance of the admin role.
• From this point on, 0x5aE20b is the absolute admin of the pCOMP Timelock — and through it, the entire pCOMP protocol.

Verified on-chain (from repeg workbook):

• Proposal 162 executed: 2025-12-29
• acceptAdmin() called by 0x5aE20b: 2026-01-03
• Current timelock state: admin() = 0x5aE20bfad1039CE1Fa1eD7B2308c18F3f0B9c06a ✓

2.6 Phase 3 — Draining Compound v3 (Comet)

With Timelock control secured, the attacker used it to approve their drainer wallet for unlimited access to the Comet (Compound v3) reserves.

Step 10: Timelock executed Comet.approveThis(drainerWallet, COMP, type(uint256).max) — unlimited COMP approval from Comet to the drainer.

Step 11: Timelock executed Comet.approveThis(drainerWallet, pWBTC, type(uint256).max) — unlimited pWBTC approval.

Step 12: Timelock executed Comet.approveThis(drainerWallet, pWETH, type(uint256).max) — unlimited pWETH approval.

Comet.approveThis() is a Compound v3 governance-only function that lets the admin grant arbitrary ERC-20 allowances from the Comet contract to any recipient. It is designed for legitimate governance operations (e.g., paying grants, funding insurance). Here it was used to grant the attacker's drainer wallet access to all assets in the pool.

2.7 Phase 4 — Final Asset Drain

Step 13: transferFrom(Comet, attackerWallet, ~2,960 COMP) — drained remaining COMP from Comet.

Step 14: Test transfer: transferFrom(Comet, attackerWallet, 1 satoshi pWBTC) — tested the pWBTC approval.

Step 15: transferFrom(Comet, attackerWallet, ~6,295 pWBTC) — drained the full pWBTC balance from Comet.

Step 16: transferFrom(Timelock, attackerWallet, ~7.12 pWBTC) — drained the Timelock's own treasury balance of pWBTC.

Total assets drained:

Note on pWETH: The pWETH approval was set (Step 12) but the Comet pool had already been substantially drained of ETH collateral by this point, or the attacker chose not to drain it in the initial pass.

2.8 Why It Worked — IronClad's Analysis

IronClad's complete breakdown identifies six reasons the attack succeeded. This analysis is considered reliable by the user and is reproduced here in full from the Telegram post of 25 January 2026:

1. Vulnerable victim contract: 0xe6df4ca... allowed the attacker to set unlimited COMP approvals and claim COMP rewards on its behalf. This was the entry point — not a Compound core contract flaw.

2. Governance trust: Community members assume that passed proposals are safe. Nobody systematically reads proposal actions before voting ends. The technical barrier to reviewing setPendingAdmin() buried inside a proposal is real.

3. Proposal complexity: The malicious setPendingAdmin action was hidden among other actions in the proposal. A complex multi-action proposal is much harder to audit than a single-action one.

4. Voter apathy: On PulseChain forks, governance participation is near zero. There is no active governance community. The protocol was running headlessly — nobody was watching.

5. Timelock inadequacy: The 48-hour delay is only a safety net if someone is watching and capable of responding within that window. With no active community, the window passed silently.

6. Powerful admin functions: approveThis() in Compound v3 lets governance approve any token spending from the protocol. In legitimate use this is fine. As an attack primitive it is catastrophic.

7. Forked protocol, no community: PulseChain forks typically have no active governance participation. The original Compound community does not monitor PulseChain. The PulseChain pCOMP community was small and not organized around governance security.

IronClad's one-liner summary:

"Attacker drained 71k COMP from a vulnerable contract, used it to pass a governance proposal making themselves admin, then drained millions more from Compound v2 and v3."

2.9 Post-Capture Activity by 0x5aE20b

The most significant finding in the repeg workbook is what happened after the Timelock was captured. Rather than simply extracting assets and going quiet, 0x5aE20b used the Timelock admin power to actively re-engineer the pCOMP protocol.

On 2026-01-11 — eight days after accepting admin — 0x5aE20b executed four Timelock transactions:

This is active protocol engineering, not passive trophy-holding.

The oracle replacement is particularly significant. The oracle is the mechanism that prices all collateral in the lending system. Installing a custom oracle is the foundation for controlling what any collateral is worth within the protocol — which directly affects borrowing capacity, liquidation triggers, and the entire market logic.

The listing of a new market (cTRL) with an 80% collateral factor suggests the new admin is preparing pCOMP to support specific assets — potentially as part of the broader repeg infrastructure described in the master research document.

Community member observations from the Telegram group (messages795.html, messages800.html, January 2026) confirmed these 0x5aE20b timelock transactions were visible and being watched by community members in real time.

2.10 The July 2025 Early Warning That Was Ignored

The Telegram group received a warning about a Compound governance takeover attempt in July 2025 — approximately six months before the January 2026 cleanup:

A message forwarded from "Ted (Never DM You First)" warned:

"Someone recently submitted a governance proposal on PulseChain's version of Compound that quietly hands over control of the entire protocol to a new, unknown address... The proposal used setPendingAdmin(address) to name 0xA47eE7afD7F0a5D0C9A1A8c9966Cb6c2bdD4d9D2 as the pending new admin... starting July 14, this address will be able to finalize the takeover by calling acceptAdmin()." — Ted (Never DM You First), forwarded in Telegram, July 2025

This warning described the same mechanics as Proposal 162 — setPendingAdmin() used to designate a new admin, with the takeover finalized via acceptAdmin(). The address named in the July 2025 warning (0xA47eE7...) is different from the January 2026 takeover address (0x5aE20b), which suggests either:

1. The July 2025 attempt was a different, earlier proposal that failed or was abandoned
2. The attacker changed their execution wallet between attempts
3. The July 2025 warning referred to the same attacker but a different phase of the operation

What's clear: The community was warned in July 2025 that exactly this attack was possible and in progress. By January 2026, the final version executed successfully. Whether the July 2025 warning was acted upon, whether countermeasures were attempted, and exactly how many proposals preceded Proposal 162 are not fully documented in the available record.

2.11 The cDAI Overhang — What Remains

Even after the drain, the pCOMP system carries an enormous stranded debt position:

The getCash() = 0 figure means the cDAI market has no actual pDAI left in it — all liquidity was drained. Yet the system still records 19.632 trillion pDAI in outstanding borrows and 261 trillion cDAI in circulating supply. These represent phantom positions that exist on-chain but correspond to no real backing.

The D3MHub connection makes this significant beyond pCOMP: the Pulse D3MHub has a live ilk DIRECT-COMPV2-DAI, and the D3MCompoundPool contract's constructor args point directly to cDAI = 0x5d3a536E4D6DbD6114cc1Ead35777bAB948E3643. This is the bridge between the pCOMP overhang and the pMaker system — if the D3M direct-deposit path is reactivated under the new oracle regime installed by 0x5aE20b, the cDAI ghost debt could theoretically be turned into a real pDAI burn mechanism.

The repeg workbook notes that three uncull(bytes32) attempts were made on D3MHub on 2025-07-08 against DIRECT-SPARK-DAI, all of which reverted — suggesting the path is actively being explored but not yet reopened.

2.12 Community Reaction and Ongoing Observations

The Telegram community's reaction to the pCOMP capture was markedly different from the reaction to the pMaker situation. While the pMaker debate involved genuine technical disagreement about whether 5996 was an exploiter or a keeper, the pCOMP capture generated less controversy about the mechanics (which were unambiguous) and more concern about the implications.

Key community threads (January 2026):

• "Is stuff happening with compound or anything you watching? stress testing wBTC?" — community member to NineIronCapital
• The community was watching wallet 0x5aE20b's timelock transactions in real time and discussing what the oracle replacement and new market listings implied for the broader pDAI repeg narrative
• Community member IronClad published the full step-by-step breakdown on 25 January 2026, which became the authoritative reference for understanding the attack

The pCOMP governance wallet 0x48fc8b22ae5319786a8e25ef49b1b49942000000 was Telegram-identified as "working hard to fix pCOMP" — a framing consistent with the interpretation that the capture was not simply extractive but part of a larger protocol rehabilitation effort.

3. The Wallet Cluster: 5996 → 0000 → 1967

3.1 Cluster Overview

The community's analysis — corroborated across NineIronCapital, SigewulfCW3, IronClad, and multiple anonymous on-chain researchers in the Telegram group — converges on a three-wallet operational cluster that spans the entire arc of the pDAI story: pMaker vault cleanup, pCOMP governance capture, and ongoing post-ESM protocol operations.

Community characterization of the broader wallet network (messages880.html, May 2026):

"The wallet network: • 5996 — master orchestrator, funds all operations • 86FF — official PulseChain airdrop wallet, RH-confirmed, supplied the pCOMP that enabled the Compound takeover • 0x…c71967 — vanity wallet named after the ERC-1967 proxy standard, running liquidations and deploying contracts, active today May 12 • 2822 — RH's primary wallet, largest pWBTC holder, the collateral reserve"

Note: The attributions of 86FF and 2822 to RH are community-level claims, not chain-proven. They are included here as the community's stated framing but should be treated as Unverified pending independent on-chain confirmation.

3.2 Wallet 5996 — The Master Orchestrator

Full address: 0xB8698CfFFdAAf26ca21fE8aA560c18cc2b2f5996

This is the most extensively documented wallet in the entire pDAI story. Research from the dedicated pDAI Research Group chat (export dated 17 May 2026) has filled in the earliest chapter of 5996's history — pushing its confirmed activity back to PulseChain's first weeks.

Origin: PulseChain launch (May 2023)

NineIronCapital, in a message forwarded to the research group on 18 January 2026 (messages83.html), established the timeline:

"What is taking my time at the minute is that 5996 transferred all of its vaults into one vault that it created (with a different wallet) in May 2023. Isn't it crazy to learn that the main minter of pDAI in the early weeks of PLS was 5996?" — NineIronCapital, messages83.html (research group), 18 Jan 2026

This is significant on two counts. First, 5996 was not a late entrant — it was present and minting pDAI from the earliest days of PulseChain's mainnet. Second, it was already using an alternate wallet to set up infrastructure at the fork, suggesting the operation was pre-planned before PulseChain even launched.

Three coordinated smart contract wallets

The research group's most important structural finding is that 5996 does not operate alone — it is one of three coordinated smart contract wallets, each assigned to a specific forked protocol:

"Even crazier to learn that it has been using a sophisticated smart contract enabled wallet. There have only been three wallets created using this software on PulseChain. 5996 used it to mint from the ETH and wsTETH vaults. The second used it to set up a vault using only stETH. The third used it to vote on the Compound takeover. I haven't been able to connect all three wallets outside of using the same software. But it is interesting to note that three wallets were built. One tackled Maker. One tackled wstETH. One tackled Compound. It's just another coincidence I guess." — NineIronCapital, messages83.html (research group), 18 Jan 2026

The Daredevil, another research group member, confirmed: "I discovered this smart contract wallet months ago. I knew this was gonna happen."

The division of labour across the three wallets:

Smart contract wallets (as opposed to standard EOAs) are programmable and typically require multiple signatories — suggesting an organised team rather than a single individual operating across all three.

The smart contract wallet used for L2 bridge operations was identified by The Daredevil (messages50.html, research group, Oct 2025): 0xeE688CB52a41D2943AdacA1adc8116BA6dd93583

pMaker vault cleanup (2024–2025):

• Deployed five helper contracts beginning 11 March 2025 (4f70, cb7581, ccc7, d4f4, a40a)
• Executed real Maker liquidations via Clipper, Dog, Vat using the helper stack (Verified)
• Sent the on-chain ASCII message on 25 March 2025 explaining its mechanics (Verified)
• Called DssAutoLine.exec(PSM-USDC-A) on 10 April 2025 (Verified)
• Received a 10,000-coin transfer from c000 on a specific transaction (Verified)
• Entered repeated bidirectional value flow with BAD9 across Jan–Feb 2025 (Verified)

pCOMP governance period (2024):

• Wallet 0000 called D3M exec functions on 2024-07-05, 2024-09-02, and 2024-09-13 — in the same D3M execution context as 5996 and the other bridge wallets (Verified)
• 5996 funded 1967 on 15 July 2025 with 21M PLS, then transferred COMP to 1967 (Telegram-sourced, consistent with on-chain traces)

NineIronCapital's assessment:

"It is unknown at this point. It really looks like the guys minting are the guys rebuilding pMKR." — NineIronCapital, Telegram

The community label for 5996 in the "Pioneer watchlist" used by on-chain researchers: "Bad Debt Cleanup" (messages880.html, May 2026).

3.3 Wallet 0000 — The pCOMP Governance Bridge

Full address: 0x48Fc8b22ae5319786a8e25ef49b1b49942000000

This wallet links the 5996 pMaker world to the pCOMP governance capture. Its documented roles:

D3M execution (2024): The repeg workbook documents three D3M exec call dates for this wallet: 2024-07-05, 2024-09-02, and 2024-09-13. These are the same type of D3M execution calls made by c000 and BAD9, placing 0000 inside the verified D3M execution cluster. The D3MHub at 0x12F36cdEA3A28C35aC8C6Cc71D9265c17C74A27F has live ilks including DIRECT-COMPV2-DAI — directly bridging the Compound D3M path with pMaker debt mechanics.

pCOMP governance: The Telegram community identified 0x48fc8b22ae5319786a8e25ef49b1b49942000000 as "working hard to fix pCOMP" during the January 2026 period following the Proposal 162 takeover. This framing — "fix" rather than "exploit" — is consistent with the broader interpretation that the governance capture was a controlled rehabilitation rather than a pure hostile drain.

The BAD9/c000/0000 bridge: The repeg workbook explicitly identifies these as the bridge wallets between the 5996 / D3M execution branch and the 9e6f governance branch:

BAD9 queued proposal 225 for the 9e6f control bundle on 2024-10-11; appears as a later direct public D3M exec caller; entered repeated bidirectional value flow with 5996.

c000 is a later direct public D3M exec caller; receives a direct 10,000-coin transfer from 5996; sent 20,000 coins to BAD9 on 2025-01-29.

0000 sits in this same D3M execution cluster (same call types, overlapping dates), making it part of the same operational layer.

Status: Verified for D3M exec calls. Telegram-sourced for pCOMP governance role.

3.4 Wallet 1967 — The Active Operations Bot

Full address: 0xFdbEE32bCf68bB0Ced033200373384A619c71967

This wallet is the most recently active member of the cluster, still operating as of May 12, 2026 — two days before the Telegram export was collected.

Name origin: The community debated whether "1967" referred to the ERC-1967 proxy standard or was a wallet vanity label. The consensus from messages880.html, including a community researcher's explicit statement: it is a wallet address ending in 1967 — a vanity address named after the ERC-1967 proxy standard, which is the standard used to upgrade Compound's contract implementations.

"0x…c71967 — vanity wallet named after the ERC-1967 proxy standard, running liquidations and deploying contracts, active today May 12" — Telegram community analysis, messages880.html, May 2026

Funding origin (Telegram-sourced):

"1967 is an EOA funded on 15 Jul 2025 with 21M PLS from Pioneer wallet 5996 (0xb8698cff...2f5996, Pioneer watchlist 'Bad Debt Cleanup')." — Community researcher, messages880.html, May 2026

5996 also transferred COMP to 1967 directly. 1967 then routes COMP through 0xDA9aBA4eACF54E0273f56dfFee6B8F1e20B23Bba (PulseX router), with proceeds going to intermediate wallets 0x57251492b7f9b8ecd8a7209c9eef555501c268bb and 0x49b0120030762aaefb2ffaf4b19e9f7b75f64586.

Documented operations:

Community characterization:

"1967 is an operator bot funded by the 5996 Pioneer team that: liquidates forgotten pre-fork lending positions on PulseChain (Gearbox V3, Compound v3 Comet); extracts profits to mainnet via OmniBridge; uses mainnet stash wallets (1327... vanity cluster) for token layering; is launching a new operations wave TODAY targeting Sapphire/Sturdy V2 (MozartCoreV2 CDP engine); has expanded cross-chain onto Arbitrum since 08 May 2026." — Community researcher, messages880.html, May 2026

A separate community researcher noted a contract deployed by 1967 worth examining further: 0xfF0805c55cB322bFc03c0910c640D1922e32dfce.

Status: Telegram-sourced throughout. The funding link from 5996 to 1967 is consistently cited by multiple researchers in messages880.html but has not been independently chain-verified in the repeg workbook (which predates the discovery). The activity described is consistent with a continuation of the helper-based extraction pattern established by 5996 in early 2025.

3.5 How the Wallets Are Linked

The three wallets form a layered operational structure:

5996 (Master Orchestrator) — active since PulseChain genesis, May 2023
├── Main pDAI minter in earliest weeks of PulseChain (Telegram-sourced, research group)
├── Created consolidated vault via alternate wallet, May 2023 (Telegram-sourced, research group)
├── One of three coordinated smart contract wallets (pMaker / wstETH / pCompound) (Telegram-sourced, research group)
├── Deploys helper contracts for pMaker vault cleanup (Verified)
├── Calls DssAutoLine.exec() for PSM-USDC-A (Verified)
├── Direct coin transfers to/from BAD9, c000 (Verified)
├── Funds 0000 cluster for D3M exec calls (Supported)
├── Funds 1967 on 15 Jul 2025 with 21M PLS + COMP transfer (Telegram-sourced)
├── Took ownership of L1 gateway proxy admin on forked Arbitrum L2 (Telegram-sourced)
└── Bond token bridge operations via SCW 0xeE688CB52...93583 (Telegram-sourced, research group)

0000 (D3M / pCOMP Bridge)
├── Calls D3M exec() Jul, Sep 2024 (Verified via repeg workbook)
├── Sits in same execution cluster as BAD9, c000 (Supported)
└── Identified in Telegram as "working hard to fix pCOMP" (Telegram-sourced)

1967 (Active Operations Bot)
├── Funded by 5996, Jul 2025 (Telegram-sourced)
├── Routes COMP via PulseX (Telegram-sourced)
├── Deploys helper contracts for Gearbox V3 liquidations (Telegram-sourced)
├── Active on PulseChain + Arbitrum as of May 2026 (Telegram-sourced)
└── Named after ERC-1967 proxy standard (community consensus)

Key linkages and their strength:

The repeg workbook's overall assessment:

"BAD9 is now the cleanest wallet-level bridge between the 9e6f governance story and the 5996 / D3M execution story. c000 strengthens that bridge by linking directly to both 5996 and BAD9."

0000 belongs to the same D3M execution layer as c000 and BAD9. 1967 extends the operational thread into mid-2026, running the same helper-based extraction pattern on new targets (Gearbox V3, Sapphire/Sturdy V2, cross-chain Arbitrum).

3.6 Recent 1967 Activity (May 2026)

The Telegram community identified a sharp uptick in 1967 wallet activity in the days immediately before the export was collected (export date: 14 May 2026). Messages from messages879.html and messages880.html, approximately 12 May 2026:

"Make sure you are watching 1967 wallet right now - things are heating up again." — Telegram community member, messages879.html, ~May 2026

"TODAY, a pre-operations setup is running for a new wave targeting Sapphire/Mozart (CDP fork on PulseChain)." — Community researcher, messages880.html, May 12, 2026

The reference to "Sapphire/Mozart" is shorthand for MozartCoreV2 — a CDP-based engine on PulseChain, described in community analysis as a fork of Sturdy V2. This is consistent with 1967's pattern: targeting stale or forgotten pre-fork lending positions that still hold value but have no active governance or user base watching them.

The ERC-1967 proxy connection: Separately from the wallet activity, the community was also watching an ERC-1967 proxy interaction in the pCOMP system itself. Community member "Grok analysis" forwarded in messages880.html:

"The devs are interacting with an ERC-1967 Proxy. In very easy words: A proxy is like a 'public box' that everyone uses (the address you see). Inside that box is the real contract (the 'implementation') that does all the actual work. ERC-1967 is a safe, standard way to change the inside contract without ever changing the public address. In short: they can update the code of the bank (pCompound) without anyone having to change anything — your cDAI, the reserves, the vaults, everything stays at the same address... This is a very good sign, and here's why: They are preparing the uncull. The protocol has been 'culled' (locked / broken) for a long time. To reactivate it (uncull), they need to update the contract safely. Using ERC-1967 is exactly the technical step required to call the uncull without breaking anything."

Whether the ERC-1967 proxy interaction and the 1967 wallet activity on the same date are directly related or coincidental is debated:

"Here's some nopium: ain't nothing to do with an erc-1967 proxy contract going on. The 1967 in question is the wallet ending in 1967. Worst case there's a serious active exploit in progress and y'all are all cheering for it just like last time with the Compound exploit." — Community skeptic, messages880.html, May 2026

The more technically measured Telegram response:

"1967 is an EOA/searcher-style wallet... My read: it's basically a forked-DeFi extraction/searcher wallet — harvesting stale protocol state, routing tokens, deploying helpers, doing liquidations/arbs. Not proof by itself of 'institutional control', but definitely not a random one-click degen wallet either." — Community researcher, messages880.html, May 2026

The updated pCompound system state at time of these discussions (from a community dashboard summary in messages880.html, ~12 May 2026):

The 20x jump in the exchange rate (from ~0.003659 to ~0.073531) is a significant internal system change. The exchange rate in cDAI represents the accumulated yield — a 20x increase suggests either a massive accumulation of reserves inside the protocol or a deliberate repricing event. This is consistent with the new oracle installed by 0x5aE20b on January 11, 2026 and with the community's "uncull" expectations.

Status of 1967 activity: Telegram-sourced. The wallet address is confirmed in community discussion. The specific transactions cited (Gearbox liquidations, COMP routing, Sapphire/MozartCoreV2 pre-ops) are community-analyzed and not independently chain-verified in this pass.

3.7 5996's Admin Control Over the Forked Arbitrum L2

While the pMaker and pCOMP activity drew most of the community's attention, a separate thread of research emerging in July–August 2025 documented something larger in scope: wallet 5996 had taken admin ownership of PulseChain's forked Arbitrum gateway infrastructure and upgraded it into what appears to be a functioning EVM Layer 2.

How it was discovered:

NineIronCapital announced the finding on 26 July 2025 (messages501.html):

"Things are good. Working hard over here. Very deep into the arbitrum L2 they have setup. Trying to make sense of it all." — NineIronCapital, messages501.html, 26 Jul 2025

When asked to clarify, NineIronCapital confirmed:

"They have taken control of the fork of Arbitrum and have upgraded it." — NineIronCapital, messages501.html, 26 Jul 2025

And, critically, in the same thread:

"While everyone was focused on the bridge moving assets out, 5996 took over Arbitrum. You will notice the nodes being operated from there over the past couple of weeks." — messages501.html, 26 Jul 2025

Sigewulf, one of the most technically reliable researchers in the group, then independently confirmed the on-chain finding:

"5996 does appear to have taken ownership of the L1 gateway proxy admin." — Sigewulf, messages527.html, 6 Aug 2025

What the forked Arbitrum is:

PulseChain forked Ethereum at a specific block. At the time of the fork, Ethereum's Arbitrum bridge and gateway contracts were part of the Ethereum state — meaning their bytecode and state were copied to PulseChain at genesis. These contracts include the L1 gateway proxy, which governs how assets and messages pass between the L1 (PulseChain) and whatever L2 is pointed at.

Skorn explained the architecture on 30 July 2025 (messages509.html):

"All I know is that the same contracts that were used to deploy the Compound protocol on Arbitrum have been used to set up an L1/L2 gateway. There's no way of knowing if that's all they intend to do on the new L2, or if it's going to be used for other purposes as well." — Skorn, messages509.html, 30 Jul 2025

And on the technical design of the proxy itself (messages527.html, 6 Aug 2025):

"More likely it is just the forked Arb One that doesn't need to be changed for any reason at this point. A new L2 could be redirected to by updating this variable... with the current implementation logic... not sure why they would change the logic if it's tested." — Sigewulf, messages527.html, 6 Aug 2025

The key line: "A new L2 could be redirected to by updating this variable." Whoever holds the L1 gateway proxy admin can redirect the gateway to point at a different L2 chain entirely — including a new, private one.

What 5996 has done with this control:

The specific upgrades and actions documented or discussed:

1. Took proxy admin ownership of the L1 gateway contract on PulseChain's forked Arbitrum infrastructure — confirmed by Sigewulf from on-chain data (6 Aug 2025)
2. Upgraded the forked Arbitrum — NineIronCapital confirmed an upgrade had been performed, though the specific change and purpose was not yet decoded at the time of discussion
3. Stood up nodes — "You will notice the nodes being operated from there over the past couple of weeks" suggests active infrastructure running against the L2, not just passive contract ownership
4. Used the same Compound deployment contracts to configure the L1/L2 gateway — the same contract templates used to deploy pCompound on Arbitrum were repurposed for gateway setup, creating an architectural link between the pCOMP governance capture and the L2 build-out

NineIronCapital's speculation on purpose:

"I don't believe it interacts with the Ethereum Arbitrum. I believe this has become a brand new EVM L2. It has been upgraded for a purpose. Privacy? CompoundV3? I don't know. Need to keep digging to find out." — NineIronCapital, messages501.html, 26 Jul 2025

Community interpretation:

The community response to this discovery was notably different from the pMaker and pCOMP discussions. Rather than reading it as extractive, Sigewulf and Skorn framed it as evidence of serious technical sophistication:

"Hard to believe 5996 is not employed or well equipped when you see the toying around being done all over the forked protocols." — Sigewulf, messages527.html, 6 Aug 2025

"100%. Definitely puts the extractor theory in the bin." — Skorn, messages527.html, 6 Aug 2025

This is a significant shift in framing. Where early community discussion debated whether 5996 was an opportunistic extractor or a legitimate vault cleanup operator, the Arbitrum L2 finding pushed the consensus toward: whoever 5996 is, they are building infrastructure, not just draining it.

The wallet 1967 connection:

The timing is notable. 5996 funded wallet 1967 on 15 July 2025 — approximately ten days before NineIronCapital's announcement that the Arbitrum L2 had been set up and nodes were running. By May 2026, 1967 was documented as active on Arbitrum as well as PulseChain. Whether 1967 is the operational wallet for the L2 — running liquidations and arb operations through the new gateway — is not confirmed but is consistent with the pattern.

Specific rollup contract addresses (research group, messages97.html, 14 May 2026):

Jack — a technical contributor in the research group — decoded a specific L2 staking transaction and identified the following contracts:

The decoded transaction (0xeb1d14f49307d6f75e9e0f4597bbf098872d9937a70749e06756ed8aa6fd5665, dated 16 September 2025) shows a newStakeOnExistingNode(uint64,bytes32) call on the RollupProxy — a Nitro/Arbitrum-style rollup staking action placing a validator stake on node 5335. Native PLS staking (not ERC-20), meaning the staker is a network validator on the forked L2.

The Cb4e wallet — rollup staker branch:

The research group's technical analysis identified a wallet Cb4e operating in the same Nitro/L2 surface as 5996 and 48Fc, with its own staking timeline on the RollupProxy:

• 31 July 2025: Cb4e stakes 100 PLS on an earlier node
• 25 August 2025: Old deposit returned/withdrawn
• 16 September 2025: Re-stakes 100 PLS on node 5335 (the transaction above)
• 12 May 2026: Cb4e calls withdrawStakerFunds() — withdrawable funds at that point: 0

Jack's note: "This belongs to the Cb4e rollup-staker branch. It relates to the broader Nitro/L2 surface where we also track 5996 and 48Fc, but this tx itself does not prove a direct wallet/funding link between Cb4e and 5996."

The 48Fc wallet:

48Fc is explicitly tracked alongside 5996 in the research group's Nitro/L2 surface monitoring. Note that 0x48Fc8b22ae5319786a8e25ef49b1b49942000000 is also the 0000 wallet (the pCOMP governance bridge from Section 3.3) — the 48Fc prefix is the same address. This means the wallet operating in the D3M execution cluster and pCOMP governance is also being tracked as an L2 rollup participant alongside 5996.

Bond token bridge operations:

The Daredevil (research group, messages50.html, Oct 2025) flagged a specific transaction where bond tokens were moved in or out of the L2 via the smart contract wallet (0xeE688CB52a41D2943AdacA1adc8116BA6dd93583) rather than a standard EOA. Transaction hash: 0x068b64d1a93b63da27d2f0422f6ad81bf11cbc11a47905f2fc651bb72c97261f. The 1967 wallet was confirmed to have multiple similar L2 bridge operations ("several of these going in and out of the L2").

On-chain references cited in the main Telegram:

• https://otter.pulsechain.com/tx/0x2ed551079b7f9ad318d4a38eac4de8aa18ba73c32472f867c7a485751cfedf6d
• https://otter.pulsechain.com/tx/0xd358f79692378fd56a7345ac14a2a0627437ea32a7a43fcf8ee64ee51fcee6f0/trace

Status: Telegram-sourced (research group). The rollup contract addresses and Cb4e staking timeline come from Jack's technical analysis in the research group chat (messages97.html, 14 May 2026), a higher-signal source than the main chat. The RollupProxy address and decoded transaction parameters are specific enough to verify independently on otter.pulsechain.com.

Cross-Reference: The Two Events in Context

Document status: Research / analysis. Evidence standards from the repeg workbook apply throughout. Claims marked Verified are backed by on-chain data. Claims marked Telegram-sourced should be treated as informed community intelligence requiring independent corroboration. Reliable Telegram sources per user specification: IronClad, NineIronCapital, SigewulfCW3.

Section 4: The Maria / 414 / Atropa Ecosystem

4.1 Who Is Maria / 414 Dev?

"Maria" (IRC handle mariarahel, referred to in the community as "414 Dev") is the pseudonymous creator of the ATROPA token and its surrounding ecosystem on PulseChain. Her real identity is not publicly known. She operated primarily through:

• The #atropa IRC channel (C:\...\414\#atropa_chatlogged.log, 104,316 lines)
• The atropalog.vercel.app site (token-gated, requires holding ≥ 1 ATROPA)

Maria is explicitly a pStables maximalist — her entire ecosystem's value proposition is predicated on pDAI, pUSDC, and other PulseChain stablecoins eventually reaching their $1 pegs. In her own words from the IRC log:

"I could purchase and pair with liberty up to the value burned for any token that burns pDAI."

This statement captures the core mechanic: ATROPA is created by burning pStables, so any appreciation in pDAI's price directly increases the economic value of ATROPA already in circulation.

Financial position (IRC-sourced): Maria held ~100 million pUSDT. All investors in the Atropa ecosystem were reported to be in profit at the time of the IRC logs reviewed.

4.2 The ATROPA Token: Structure and Mechanics

ATROPA was not launched with a presale or VC backing. It was created by burning existing PulseChain stablecoins:

Key structural decisions:

• LP burned: Approximately 50% of the initial liquidity pool was burned — permanently removing the liquidity share from any individual's control
• Contracts renounced: Smart contract ownership was renounced after deployment; no admin keys
• No inflation pathway: No mint function accessible post-renouncement

The primary ATROPA/pDAI liquidity pool is at 0x5EF7aac0de4F2012CB36730Da140025b113FaDa4 on PulseX v2, reported at approximately $15.46 million in liquidity — making it one of the larger pDAI liquidity positions on PulseChain.

Core ecosystem tokens:

The architecture is described as "parent-child": ATROPA is the parent, and the other tokens derive value from or interact with it. All are reliant on the pDAI peg thesis holding.

Dysnomia Layer 2: Maria referenced a Layer 2 chain called "Dysnomia" under development. Details are sparse in the IRC log, but it is framed as an eventual settlement layer for the Atropa ecosystem.

4.3 Surfacing's Role in the Atropa Ecosystem

_surfacing8671 — the same developer who built pMaker's Flop auction infrastructure and the pmakerSpell repository (GitHub: Surfacing-8671/pmakerSpell) — is confirmed as an active contributor in Maria's #atropa IRC channel.

Surfacing's documented activities in the Atropa context:

• Built atropalog.vercel.app: A token-gated information site requiring proof of ≥ 1 ATROPA in a connected wallet to access
• Active IRC contributor: Present in the #atropa channel from at least October 2024; participated in discussions about token mechanics, pDAI burning, and protocol design
• Cross-ecosystem presence: Surfacing operated simultaneously as a pMaker spell developer and an Atropa community builder — the same technical individual bridging both ecosystems

This overlap is significant. Surfacing was in a position to understand both the pMaker liquidation machinery (as its developer and auction participant) and the Atropa ecosystem's dependency on pDAI price action. The community member Ella Amida made this connection explicit:

"eh idk man. I think it would make sense if he was talking about maria/atropa tbh. Do you really think this stuff w/ surface/cattie would be allowed to happen otherwise?" — Ella Amida, messages347.html, 22 Apr 2025

The implication: Surfacing and Catty's continued operation within the pMaker system was tolerated or facilitated because of their alignment with the Maria/Atropa ecosystem.

xUSD connection: Both Catty and Surfacing are described in community discussion as "members of xusd" — a separate stablecoin or yield instrument project. The xUSD connection links them organisationally outside the pMaker context, suggesting their collaboration pre-existed the pMaker Flop auction period.

4.4 Catty's Role as Maria's Spokesperson — and Her Atropa Transactions

Kotryna (Catty) occupied an unusual dual position: she was simultaneously the primary Flop auction winner accumulating pMKR governance tokens, and Maria's de facto community spokesperson.

Community consensus on this role was unambiguous:

"Catties is the one giving best scenario and explanations what Maria is doing. From the very begging all that has been done even to bring Dai to highs it reached not so long ago, it was accomplished partially because of Atropa LP web." — Cryptotree, messages347.html, 22 Apr 2025

"She pretty much speaks for Maria." — Berry Beats, messages347.html, 22 Apr 2025

Catty herself did not dispute this framing. This is consistent with the IRC log showing Surfacing as the technical contributor and Catty as the community-facing voice connecting the pMaker and Atropa communities.

Direct admission of Atropa transactions:

When community members began asking how to verify her wallet's activity, Catty responded:

"One of the transactions of the main wallet that sold and bought atropa, I'm sure you can find it in the tbill group we shared the burn txn there :)" — Kotryna (Cattie), messages347.html, 22 Apr 2025

This is a direct, first-person confirmation that Catty's main wallet both bought and sold ATROPA. She was not a passive bystander to the ecosystem — she was an active participant using pMaker proceeds to transact in Atropa.

4.5 Where Did the 10 Billion pDAI Go?

Catty minted approximately 10 billion pDAI through her Flop auction victories (winning pMKR and executing governance spells to mint pDAI). NineIronCapital tracked her wallet and noted the disappearance of roughly half:

"Yessir. This was based on another stable coin. This is possible. If you have a look at the pDAI holders list, you will see that half of the 10bn pDAI that Cattie minted is no longer in their wallet. I don't know where it is being moved too. 3CRV definitely and a few others. But it's worth considering that there is a plan. I just don't think any of us know just yet." — NineIronCapital, messages324.html, 17 Apr 2025

Status: Telegram-sourced. On-chain not independently verified in this pass.

The confirmed and probable destinations:

The 3CRV routing is notable: Curve's 3pool (or equivalent on PulseChain) provides deep liquidity and easy conversion between stablecoins. Routing pDAI through 3CRV would allow conversion to other stablecoins (pUSDC, pUSDT, pDAI variants) and potentially bridging out — the same exit pathway used by the Phase 1 exploiters Richard Heart documented.

The community member Cryptoshi offered the most accusatory framing:

"People like @NineIronCapital have volunteered… Cattie and Paving can't be called volunteers, they are vampires using Pdai for their own gain and to pump their own bags of xusd, atropa, and who knows what else." — Cryptoshi, messages324.html, 17 Apr 2025

Whether "vampires" is fair characterisation depends on whether Catty's Flop auction participation constituted legitimate governance or self-dealing extraction. Kotryna herself argued (messages319.html) that anyone with 46k pMKR could have done what she did, and that 780k other governance tokens on the chain sat idle while she acted.

4.6 The Convergence: What It All Means

The Maria/Atropa/pMaker nexus is not coincidental. A plausible reconstruction:

1. Surfacing builds pMaker spell infrastructure; simultaneously contributes to Maria's Atropa ecosystem
2. Catty wins Flop auctions (with Surfacing's auction tooling), accumulates ~10B pDAI and ~46k pMKR
3. Catty uses a portion of minted pDAI to transact in ATROPA — buying into and selling out of the ecosystem
4. Catty serves as Maria's public-facing voice in the pMaker Telegram, shaping the community narrative around pDAI→Atropa as the "plan"
5. NineIronCapital observes the on-chain wallet activity and notes the pDAI disappearing to 3CRV and other destinations without full clarity on intent

The community split on interpretation:

• Benign read: Catty and Surfacing genuinely believe in the pDAI repeg thesis; their Atropa participation reflects that belief; they used minted pDAI to build liquidity in an ecosystem that benefits from the repeg
• Hostile read: They extracted free pDAI via governance capture, routed it through DeFi (3CRV → Atropa → exits), and used the pMaker community to maintain interest in pDAI price while they sold

Both reads are present in the Telegram record. NineIronCapital's framing ("there is a plan, I just don't think any of us know just yet") suggests he was still assessing at the time.

Evidence status for this section:

• Catty's dual role as Flop auction winner and Maria's spokesperson: Telegram-sourced (multiple independent community members; Catty did not dispute it)
• Catty's direct Atropa transactions: Telegram-sourced (first-person admission)
• ~5B pDAI routing to 3CRV: Telegram-sourced (NineIronCapital, reliable)
• Surfacing's Atropa IRC presence and atropalog.vercel.app: Verified (IRC log direct evidence)
• xUSD connection for both Catty and Surfacing: Telegram-sourced (community description)
• ATROPA/pDAI pool size (~$15.46M): IRC-sourced; on-chain verification recommended