DAO Maker Vesting Contracts Were Exploited Across Four Token Projects

Ethereum transactions on September 4, 2021 recorded an attacker taking control of DAO Maker-linked vesting contracts and withdrawing tokens assigned to several launchpad projects. The incident exposed a basic authorization failure in infrastructure used to distribute locked tokens: a public initialization function could be called without confirming that the contract had already been initialized or that the caller was permitted to initialize it.

The central fact is narrower than some early descriptions. The affected system belonged to DAO Maker, a fundraising and token-distribution business, not MakerDAO, the protocol associated with the DAI stablecoin. The attack involved project-token vesting contracts rather than the DAO token’s entire network or all funds using the platform.

How the contract path was abused

Contemporaneous security analysis identified the attacker address as 0x2708cace7b42302af26f1ab896111d87faeff92f. The reviewed Ethereum transaction records show calls associated with the affected contracts, including transactions later identified as withdrawals through an `emergencyExit` path.

SlowMist’s September 4 analysis said the vesting implementation’s `init` function did not authenticate its caller. By invoking that function, the attacker could set key parameters and become the contract owner. The owner privilege then made the emergency-withdrawal function available. Separate swaps converted withdrawn project tokens into DAI.

That sequence is important because it was not a consensus failure in Ethereum and did not require reversing blocks or defeating the network’s cryptography. It was an application-layer access-control failure. The blockchain executed calls accepted by the deployed contracts; the defect was that those contracts granted authority too freely.

Four token projects were subsequently identified as affected: DeRace, CoinsPaid, Ternoa and Showcase. Their tokens were DERC, CPD, CAPS and SHO, respectively. DAO Maker later described the affected instruments more specifically as vested public-sale tokens held in four claim bridges. That distinction limits the claim: it does not establish that every token in circulation, every holder or every DAO Maker contract was compromised.

Why the incident mattered

Vesting and claim contracts sat between token issuers and purchasers, holding inventory until scheduled distribution. A flaw in that shared layer could therefore transmit one implementation mistake across several otherwise separate projects. The September 4 incident showed the concentration risk created when multiple issuers relied on the same token-distribution code and operational provider.

It also complicated loss measurement. Later security summaries commonly valued the incident near $4 million, but the attacker withdrew several relatively small project tokens and sold into decentralized liquidity. A dollar estimate depends on the timestamp, reference price, available liquidity and whether value is measured before or after the sales moved markets. The reviewed primary record does not provide a reproducible event-time valuation methodology, so this reconstruction does not adopt a fixed loss figure.

For the same reason, token-price declines cannot be cleanly attributed to the exploit without a defined venue, observation window and benchmark. The on-chain withdrawals and swaps are verifiable; the counterfactual price of the tokens absent the attack is not.

Later-record context

On September 6, 2021, DAO Maker founder Christoph Zaknun said the company had worked over the weekend with the four affected projects and had begun shutting down unaffected claim bridges. He reported that, within 24 hours of the hack, 95% of projects using those bridges had collaborated on moving tokens to project-controlled multisignature wallets. Those are company-reported response figures, not independently audited measurements.

A separate DAO Maker account dated the first attacks to about 21:00 UTC on September 4 and attributed the vulnerability to the unchecked initialization function. Those later statements clarified scope and response; they were not information fully established in public at the first malicious transaction. The durable conclusion is that shared vesting infrastructure failed at access control, allowing owner privileges to be reassigned and project tokens to be withdrawn across four claim bridges.