# Kinto ($K) exploit — July 2025, Arbitrum

Sources are numbered in section 5 and cited inline as [n].

## 1. What happened
- Date: attack executed **10 July 2025 ~08:40 UTC** on Arbitrum, about 12h after the underlying proxy-slot flaw was publicly disclosed on 9 July 2025 20:17 UTC [1][4]. The post-mortem's own TL;DR also says the upgrade was "9 July 2025, 20:17 UTC" while its timeline says 10 July 08:40 — it contradicts itself; rekt and The Defiant date the attack 10 July [1][4][5].
- Chain: **Arbitrum**. The victim was the Arbitrum-deployed `$K` ERC-20 (Kinto is an Arbitrum-Nitro L2; its L2, bridge and wallet were not breached) [5].
- Loss: **~$1.55M = 577 ETH**, drained from a Uniswap v4 pool and a Morpho Blue vault [1][4]. The Block rounded to ~$1.6M [7]. Morpho suppliers were left with bad debt: [1] cites ~$3.2M owed vs ~$2.4M loans.
- Taken: the attacker **minted 110,000 counterfeit `$K`** on demand and dumped them to drain ETH from the Uniswap v4 pool and Morpho Blue vault [5][4]. `$K` fell ~90–95% in under an hour (~$7.69 to ~$0.50), erasing ~$13M of market value [4][5].
- Disagreement on mint size: early reporting (CoinJournal, relayed) said **"nearly 7 million"** `$K`, >3x the <2M circulating supply [7][8]. The team post-mortem, rekt and The Defiant say **110,000** [1][4][5].

## 2. Root cause
Not a Kinto business-logic bug, and not a stolen key or tricked signer: a **deployment/configuration flaw in an off-the-shelf ERC-1967 upgradeable proxy**, exploited as the "CPIMP" (Clandestine Proxy In The Middle of Proxy) attack [1][2][3]. `$K`'s Arbitrum token used a transparent-proxy ERC-20 whose proxy was **deployed without being initialized in the same transaction**, leaving it on-chain uninitialized in a "danger zone" [1][3]. An attacker front-ran the intended `initialize()`, writing a malicious "CPIMP" implementation into a proxy storage slot. The CPIMP forwarded normal calls to the legitimate implementation so the protocol looked healthy, restored itself in the implementation slot after every transaction (surviving upgrades), and spoofed the storage slot / `Upgraded` events that Etherscan and Arbiscan read, so explorers showed the legitimate implementation — hiding the backdoor for weeks [2]. On activation the attacker repointed the proxy to a malicious minter, minted `$K`, and drained liquidity [1]. Dozens of contracts across chains (EtherFi, Pendle, Berachain, Orderly, KIP, MYX) shared the flaw; Kinto was missed during a 36-hour mitigation war room and hit ~12h after public disclosure [2][4].

## 3. Pattern
**Uninitialized proxy / initialization front-running (CPIMP).** Missing or non-atomic proxy initialization, compounded by a mis-written storage slot and block-explorer misreporting. Vulnerable shape (pseudocode, not a working attack):

```
impl  = new TokenLogic();
proxy = new ERC1967Proxy(impl, "");  // deployed with EMPTY init data
// ---- uninitialized window; attacker front-runs ----
attacker.initProxy();                // writes attacker implementation
TokenLogic(proxy).initialize(admin); // legit init, but slot already hijacked
```

The flaw: a state-bearing proxy exists between deployment and initialization with no atomic guard, so the first caller of initialization can seize the implementation slot and lie dormant [3][2].

## 4. The check that would have caught it
- **Atomic-deployment unit test:** assert the proxy is constructed with non-empty init data and initialized inside the constructor, e.g. `new ERC1967Proxy(impl, abi.encodeCall(Logic.initialize, (admin)))`, and that the EIP-1967 implementation slot already equals the legitimate implementation immediately after deployment (no window) [3].
- **Review rule / invariant:** require every upgradeable proxy to deploy and `initialize()` in one transaction (or via `CREATE2` precomputed addresses for circular deps); add a monitoring invariant that the implementation slot never changes outside an expected event-logged upgrade and that an uninitialized proxy is never observable on-chain. Where delayed init is unavoidable, restrict `initialize()` to a single hard-coded deployer as a last resort [3].

## 5. Sources
1. https://medium.com/mamori-finance/%EF%B8%8F-post-mortem-k-proxy-hack-our-path-forward-c2c3809882c6 (Kinto/Ramon Recuero post-mortem)
2. https://dedaub.com/blog/the-cpimp-attack-an-insanely-far-reaching-vulnerability-successfully-mitigated/
3. https://www.nethermind.io/blog/cpimp-attack-how-uninitialized-proxies-are-exploited-during-deployment
4. https://rekt.news/just-bad-luck
5. https://thedefiant.io/news/blockchains/kinto-token-tanks-90-as-backdoor-disclosure-lets-attacker-mint-110-000-tokens-and-drain
6. https://thedefiant.io/news/blockchains/ethereum-l2-kinto-shuts-down-months-after-exploit-as-fundraising-options-disappeared (Sep-2025 shutdown; 577 ETH)
7. https://itokenly.com/hacks/kinto (aggregator; The Block's ~$1.6M)
8. https://vcpcryptonews.com/2025/07/10/kinto-coin-crashes-99-after-arbitrum-contract-exploit/ (early "nearly 7M" report)

Note: no Kinto-specific analysis from BlockSec/SlowMist/CertiK/Halborn/Verichains/QuillAudits was found; the technical write-ups above come from Dedaub, Nethermind and the Venn/Dedaub researchers, plus rekt.news.