2X)
Outstanding supply (verified)
* pDAI = canonical DAI at 0x6b175474e89094c44da98b954eedeac495271d0f (inherited at the May-2023 fork).
*totalSupply = 44,359,705,708 (÷1e18), read on-node. This settles the question definitively: outstanding pDAI is ~44.36B — not the "600B–1.4T" figure attributed to PulseChain developers. The only figures in that range are gross throughput (lifetime exits ≈ 340.9B, exits joins higher), not live supply.
The ERC20 mints (surface layer)
*A full-chain scan of Transfer from 0x0 found 456,902 mints totaling ~340.9B pDAI.
*First mint at block 8,928,674; minting effectively ended ~block 24M (consistent with "no inflation since last year"). Clustered in two bursts: 12M–14M ( ~94B) and 22M–24M ( ~136B).
*Gross minted (340.9B) far exceeds outstanding supply (44.36B) → most was burned back. Heavy mint/burn churn, not clean issuance.
*The top mint recipients hold ~0 today: 0xc108…74df3 (EOA) minted ~106B and holds 179; 0x619a…92882 (contract) minted ~62B and holds ~2,258; the rest hold 0. They are pass-through machinery, not beneficiaries. The 1inch v4 router (0x1111111254…097d) appears among recipients (routing).
Mechanism (proven by tx decode)
A sampled 0xc108 mint resolved to the canonical Maker exit path, with no burn in the same tx (net ERC20 issuance):
txto = 0x9759a6ac…391a28 = canonical MCD_JOIN_DAI (DaiJoin), the only ward of the DAI token.
Function 0xef693bed = exit(address,uint256).
Internal events: Vat.move (0xbb35783b) moving internal dai, then the ERC20 Transfer(0x0 → usr).
So pDAI is real Maker-issued DAI; the mints simply convert internal Vat dai into ERC20 form. The origin is upstream, in the Vat.
The Vat (the real source — verified)
Vat = 0x35d1b3f3d7966a1dfe207aa4514c12a259a0492b = canonical MCD_VAT.
live = 0 → the system is caged (global settlement). (The earlier "Maker is caged" read holds — but this corrects the "organic decay" framing: it is caged sitting on a mountain of thin-air debt.)
debt = 128.72B, vice = 107.76B (both ÷1e45). ~84% of all internal dai is vice — created by suck, uncollateralized. Only ~21B is collateral-backed.
vice is increased only by suck, so this is direct proof that ~107.76B of internal dai was conjured from nothing.
The suck loop (verified)
A full-chain scan of Vat.suck LogNotes (0xf24e23eb…) found 452,811 sucks — ≈ the mint count, confirming a tight suck → exit loop.
Largest single suck: 500,000,000 DAI at block 13,499,798 (tx 0x0fe25420…2331c92), driven by EOA 0x24354d31…cf866b through contract 0x961d2b69…a330d (custom fn 0x67c354b5). That contract is a 9,212-byte contract and is not a current ward — consistent with the temporary-ward / indirect-call pattern below.
Suck recipients (v) overlap the rely'd wards (see below), e.g. 0x197e90f9…d7cf7 and 0xbe8e3e36…e98fb — i.e. rely'd ward = minter = beneficiary.
The ward capture (verified)
A full-chain scan of Vat rely/deny LogNotes returned 146 events (133 rely, 13 deny). Because PulseChain only holds post-fork logs, every one of these is a post-fork authorization change — the legitimate inherited wards are invisible here.
Zero ward changes before block 8,928,152. The capture is a discrete event: at 8928152 a deny of prior ward 0x403689…788e5 is immediately followed by a batch of relys — ~500 blocks before the first mint at 8,928,674. Grants keep coming through ~block 23.2M.
The granted wards include the suck beneficiaries (0x197e90f9 rely'd at 8928160; 0xbe8e3e36 at 8928171).
0xbe8e3e3618f7474f8cb1d074a26affef007e98fb = the canonical MakerDAO Pause Proxy (governance root over all MCD contracts). It appears as a ward and a suck beneficiary; controlling it on this fork is controlling Maker.
A recurring rely → suck → deny cleanup pattern is visible (e.g. 0xbe8e3e36 rely'd at 23224995, deny'd at 23225241).
The operator (verified)
The capture transaction at block 8928152 (0xa39edcde…035b06a7) carried all three ward changes:
from EOA 0xddb108893104de4e1c6d0e47c42237db4e617acc — the operator.
to contract 0xbaa65281c2fa2baacb2cb550ba051525a480d3f4 (fn 0x2800a568) — the capture spell; itself rely'd at 8928152 and deny'd at 8928244 (a throwaway that wired in the wards then removed itself).
Relationship to the Compound / cDAI operations
The Maker operator 0xddb10889…617acc is a different EOA from the previously documented Compound governance-capture operator 0xd78d8f…dc3a0. At the address level these are distinct hands working the same dead fork. No hard tie (shared funder, deployer, or asset flow) has been established or ruled out — that would require a funding trace, not yet run. Per investigation discipline, they are treated as separate until such a tie is proven.