HostHostDeFi › Is 1inch safe
Is 1inch safe? The aggregator that lost its own funds, twice, while user funds stayed safe
1inch is the boundary case this family needed: an aggregator with real, disclosed incidents — a stolen resolver key in Dec 2024, an obsolete-Fusion-V1 exploit in Mar 2025 — in which the losses always stopped exactly at the custody boundary the architecture promised. Twice, 1inch-side money walked; zero times, user money did.
What 1inch is
1inch is a DEX aggregator: instead of hosting liquidity, it splits your order across hundreds of liquidity sources (Uniswap, Curve, its own Fusion mode resolvers, and more) to return a better net price than any single venue. Operating since 2020, it is one of the most-integrated swap layers in DeFi — its routers and APIs sit under a large share of the ecosystem's wallets and frontends.
Its custody shape is the standard non-custodial DEX one: your wallet signs, the Aggregation Router settles, nothing is held. Which makes its incident record uniquely clarifying — because 1inch has had real incidents, and they all stayed on one side of that boundary.
December 9, 2024: the stolen resolver key
1inch disclosed that an attacker had obtained the private key belonging to the owner account of a 1inch Labs resolver smart contract. With that key the attacker changed resolver settings and transferred out funds — widely reported at roughly $5 million. The response was textbook: compromised access revoked, multisig requirements added wherever the design allowed, a detailed public postmortem, and a $250,000 reward offer.
The load-bearing fact: resolvers are 1inch-side settlement/market-making infrastructure — professional operators (including 1inch Labs itself) that fulfill Fusion-mode orders. They are not user deposit accounts. The money that walked belonged to the resolver operator — 1inch's own side of the table. The disclosure stated plainly that user funds were not affected, and the architecture explains why: there is no custody path from a resolver's owner key to a user's wallet.
March 5, 2025: the obsolete Fusion V1 exploit
Three months later, a second disclosed incident: a vulnerability in the long-deprecated Fusion V1 resolver integration — unsafe reconstruction of calldata — was exploited against outdated third-party resolver contracts that still carried stale configurations and approvals. Again the affected funds belonged to resolver operators who hadn't migrated, not to swappers; Fusion V2 had long been the live path; 1inch stated no end users were impacted and worked with affected resolvers on recovery.
This one is the hygiene lesson rather than the custody lesson: deprecated code with live approvals stays exploitable forever. The vulnerable surface existed only because old integrations kept old authorizations — the same mechanism (stale approvals on old contracts) that drained SushiSwap users in 2023. The difference is whose approvals were stale: the resolvers', not the users'.
Reading the boundary correctly
Two real incidents, both disclosed with postmortems, both funded from the operator side, zero user losses — the honest scoring for a user:
| Incident | Whose money | User-side lesson |
|---|---|---|
| Dec 2024 — resolver owner key stolen | 1inch Labs resolver (~$5M reported) | Operator-key risk is real but doesn't reach user custody |
| Mar 2025 — obsolete Fusion V1 calldata bug | Stale third-party resolvers | Deprecate + revoke: old approvals on old contracts stay live |
| End-user custody | — | Untouched in both — the architecture's promise held |
The correct mental model: 1inch the company infrastructure has an attack surface (operator keys, legacy deployments) and has paid real money for it. 1inch the user custody path has so far absorbed both events without loss — the blast radius stayed where the docs said it would.
The risk stack, ranked by what actually loses user money
| Layer | Frequency | Fix |
|---|---|---|
| Signature/approval phishing (cloned 1inch UIs, Permit scams) | Dominant daily vector, class-wide | You — read spender, scope, expiry |
| Stale router allowances | Persistent until revoked | You — revoke old approvals periodically |
| Frontend trust | Class-wide | You — verified domain only |
| Resolver/operator incidents | Two documented, both disclosed | 1inch-side; users untouched to date |
| Router contract exploit on users | None documented | — |
What both incidents prove together
Put side by side, Dec-2024 and Mar-2025 describe one architecture doing its job under two different attacks. In the first, a stolen operator key reached exactly what that key controlled — a resolver — and nothing else. In the second, legacy code reached exactly what had stayed configured to trust it — stale resolvers — and nothing else. In both, the property a non-custodial venue sells held: there is no path from an operator-side compromise to a user wallet, because the user never delegated anything but a transaction-scoped signature and a token allowance. The incidents also leave one durable instruction for users themselves: the approvals you hand routers outlive the interfaces that asked for them. Revoking stale allowances is the user-side mirror of 1inch deprecating V1 — the same hygiene, applied to your wallet.
What would change the answer
Watch for the incident that crosses the boundary: an exploit in a current Aggregation Router or Fusion V2 path that reaches user-approved funds, or a key compromise that can mint user-side transactions. Neither has occurred. The dated read: an aggregator with two honest, bounded, operator-side losses and a user-custody record that stayed clean through both — safer than its incident count sounds, and a standing reminder that stale approvals are forever.
The verdict in one line: 1inch has lost money twice — both times its own side of the table, both times disclosed, and user funds stayed untouched because the architecture gives attackers nothing to reach; the real risk to a user remains the signature, not the resolver.
Frequently asked questions
Is 1inch a legitimate aggregator?
Yes — 1inch is one of the oldest and most-integrated DEX aggregators, routing split orders across hundreds of sources since 2020, with a non-custodial architecture throughout. Its security record has a specific and honest shape: twice it lost funds on its own resolver side — never on the end-user side. Both incidents are documented, disclosed, and instructive about where an aggregator's risk boundary actually sits.
What happened in the December 2024 1inch incident?
An attacker obtained the private key of the owner account of a 1inch Labs resolver contract, changed resolver settings, and transferred out funds (~$5M in the widely-reported accounting). Critically: resolvers are 1inch-side market-making/settlement infrastructure — not user deposit accounts. 1inch revoked the compromised access, added multisig requirements where possible, published a disclosure, and offered a $250K reward. End-user funds were untouched because no custody path reaches them.
What was the March 2025 Fusion V1 vulnerability?
A bug in the obsolete Fusion V1 resolver integration code — unsafe calldata reconstruction — let an attacker drain outdated third-party resolver contracts that had kept stale approvals/configurations. 1inch's disclosure stated no end users were affected; Fusion V2 was already the live path. The affected funds belonged to resolver operators who had not migrated — an inventory-hygiene failure on the integration layer, again not a user-custody event.
Who holds your keys on 1inch?
Nobody — 1inch is non-custodial end-to-end for users: your wallet signs swap transactions, the Aggregation Router settles them, no balances or keys are held for you. What 1inch does run is its own infrastructure side — resolvers, routers, operator keys — and the two documented incidents show that layer can lose its own money. The architecture keeps that blast radius away from users, which is exactly what both postmortems verified.
If 1inch got hacked twice, is it safe?
The incidents deserve precise weighting. Both hit 1inch-side resolver infrastructure (a stolen operator key; stale V1 resolvers) — the equivalent of the exchange's own trading desk losing funds, not customer accounts being drained. For a user the honest read is: the custody boundary has held through two real events, the disclosures were prompt and detailed, and the fixes (multisig, V1 deprecation) targeted the actual failure. The residual user-side risk is the class-standard one: signatures and approvals you sign.
What are the real risks for a 1inch user?
In order: (1) approval/signature phishing — cloned 1inch frontends and Permit-style scams, the same dominant vector as every DEX; (2) router allowance hygiene — approvals you've granted to 1inch routers persist until revoked, so stale approvals are the one thing the Fusion V1 incident warns about at user level; (3) frontend trust — the aggregator contracts are trustless, the domain isn't. The resolver incidents themselves sit in 1inch's blast radius, not yours.