A Borrowed Name and a Copied String: How New Market Trading's Clients Lost $3.98 Million

Much of the initial coverage described this as a Squid hack. That framing was wrong from the start.

In under two hours, 88 Gnosis Safes spread across Ethereum, Base, and Arbitrum lost a combined $3.98 million. Neither Squid nor Safe was compromised. The failure sat in a third-party module built by a little-known firm, running on a permission grant nobody had bothered to revoke.

That firm, New Market Trading, markets itself as offering a "next-era solution for onchain wealth" — non-custodial, secure, and backed by human support. Its own about page promises to "push boundaries, respect risks," and vows never to "shy away from telling you where the dangers lie."

The module at the center of the incident treated a string supplied by the caller as sufficient proof of a secure message — a check trivial to defeat for anyone willing to read the deployed source. Blockaid observed the drain happening in real time. Evidence suggests the attacker may have monitored the relevant permission contracts for as long as three months before striking, likely waiting until the exposed value made the attempt worthwhile.

By the time the actual developer of the module was publicly confirmed, the stolen funds had already been converted to DAI and parked in a single wallet, while New Market Trading tried to reach the attacker through an on-chain message.

When a platform whose entire pitch is security ships a module that hides what amounts to a hard-coded password in plain view of anyone reading the contract, the question worth asking is what clients believed they were actually paying for.

01A Fast, Multi-Chain Drain — and a Misdirected Response

The attack began in the early hours of May 25th. Blockaid narrated it live as it happened: 88 Gnosis Safes being emptied across Ethereum, Base, and Arbitrum at essentially the same time, with stolen assets funneled through attacker-controlled Uniswap V3 pools and converted to DAI. The firm identified the exploiter's address, flagged the consolidation wallet, and posted an example transaction for reference.

Blockaid's first public damage estimate put losses at roughly $3 million within about two hours. Shortly after, PeckShield added a detail Blockaid hadn't yet surfaced: the operation had been bootstrapped with just 2.1 ETH withdrawn from Tornado Cash — seed capital that grew into a $3.98 million haul. By that point, the exploiter's wallet already held the proceeds.

What did the most damage in the first hours, though, was a name. The vulnerable contract was verified on Basescan as "SquidRouterModule." That alone was enough for crypto outlets to run headlines calling it a Squid Router exploit, amplified by social media threads that treated the label as fact. In reality, the coverage was pointing at a protocol that had never seen the code and had no relationship with whoever built it.

The verification badge, the name baked into the source, and the module's genuine integration with Squid's infrastructure all combined to send reporters toward the wrong party. It's worth stating plainly what block-explorer verification actually means: the source code is publicly readable. Nothing more. It is not an audit, not an endorsement, and it says nothing about who deployed the contract or whether it's safe. Here, that verification simply gave the attacker a string to copy and gave journalists a name to misattribute.

Squid's response, when it came, read like careful crisis messaging: "This incident is unrelated to Squid's core protocol and contracts. All Squid users and integrators are unaffected and no action is needed." The statement continued: "The vulnerable contract is verified on Basescan under the name 'SquidRouterModule' but this contract was not built, deployed, or operated by Squid. It is a third-party smart-wallet product that chose to integrate with Squid, among other protocols, but has not been in contact with us." It closed with a pointed line: "The contract shares our name but is not our code." Squid co-founder Fig was more direct on Twitter: "The contract called SquidRouterModule is unrelated to Squid. We don't know yet who wrote or deployed this." By the end of the day, everyone did.

Safe Labs CEO Rahul Rumalla posted his own four-part thread making a similar point from a different angle: Safe's core contracts were untouched, and only accounts that had manually opted into this specific third-party module were affected — accounts that didn't appear to originate from Safe's official products at all. He directed users toward Safe Shield, the company's risk-detection tool designed to flag unverified or risky modules like this one.

The identity everyone was waiting for arrived last. QuillAudits put the loss at $3.78 million attributable to New Market Trading — the highest of any estimate, a discrepancy tied to two tokens lacking price feeds at the time of initial accounting. Defimon's automated alert named NMT and its CEO, Frank Hepworth, as the party behind the contract. Common Prefix, an early observer of the incident, had been more guarded: "At the time of writing, the identity of the module deployer has not yet been confirmed, but given a recent Blockscan Chat message it's possible that NewMarketTrading is behind the SquidRouterModule."

By the time the real builder was named publicly, the attacker had already been sitting on 3.07 million DAI for hours. When multiple security firms manage to identify the victim, the attacker, and the root cause before the responsible team even confirms authorship, it raises a fair question about who was actually monitoring this infrastructure.

02The Access Control That Wasn't

New Market Trading's platform design was straightforward: client funds sit in individual Gnosis Safes, while an off-chain delegate bot executes actions on the user's behalf — swaps, approvals, yield strategies. To connect that off-chain logic to on-chain Safe execution, NMT built the SquidRouterModule on top of Axelar's cross-chain messaging stack. That architectural choice is where things broke down.

Axelar's expressExecuteWithToken() function is designed to skip gateway validation, intended for relayers pre-executing legitimate cross-chain messages. The attack did route through Axelar's Express Execution — that's how the malicious calls reached the module — but it wasn't the underlying flaw. NMT had repurposed this fast-path function as the entry point for privileged Safe actions without layering any additional access control on top, then shipped it to production.

Two checks were supposed to guard this path, and neither one worked. The first compared sourceAddress to squidRouter — but sourceAddress was just a string supplied by the caller. No signature, no cryptographic proof, no on-chain identity check backed it. Anyone could pass it, like a password printed directly on the lock it protects.

The second check looked more substantial: hasPermission(safe, delegate, APPROVE/SWAP), which queried NMT's own PermissionsManager contract. Real delegates were genuinely registered there, and real permissions were genuinely recorded. But the delegate value being checked came from the caller's own payload rather than from msg.sender. An attacker didn't need to be a registered delegate — only to know the address of one, which was readable directly from the public PermissionsManager contract. Encode that address into the payload, call the function, and the check would pass every time, because it verified a real delegate's credentials without ever confirming who was actually making the call.

The single missing line that would have stopped it was require(msg.sender == delegate). Its absence made every client's Safe drainable by anyone who understood the module. The final tally: 308 successful drain transactions across 88 distinct Safes and three chains.

Foundry-based exploit contracts deployed by the attacker called the module's DelegateBundler path to impersonate registered delegates. Each malicious payload bundled the genuine delegate's address with an APPROVE action, a PERMIT2 authorization, and a SWAP instruction. The module then executed all three against the victim Safe in sequence — approving tokens, authorizing Permit2, and forcing a full-balance swap into a pool the attacker controlled.

Every drained Safe's balance was routed into a worthless token labeled "u", which had a maximum of 42 holders, while the attacker sat as sole liquidity provider on the other side of each pool. Every swap carried amountOutMin = 0 — slippage protection is irrelevant when you own the pool on both sides.

The attack unfolded across three chains in quick succession. Base transactions began first, at 06:11:37 UTC, with 17 transactions in the opening minute. Ethereum followed 34 seconds later, with 13 transactions landing in a single block. Arbitrum was hit at the same time, contributing 51 successful drains before the operation wound down. The entire drain phase took under 15 minutes.

229 additional Safes were exposed but never touched — either because Blockaid's detection cut the attack short, or because the attacker simply ran out of time. The underlying permissions had been active for nearly three months: Base since February 24, Ethereum since February 26. That window gives weight to the theory that the attacker had been watching the PermissionsManager contracts, waiting for exposed value to reach a worthwhile threshold.

Axelar built its express function for bridge relayers. New Market Trading used it as a vault door instead — and apparently no one stopped to ask whether those two uses were equivalent.

03An Exit Planned Weeks Ahead

The attacker's cash-out mechanism wasn't improvised — it was constructed well before the first drain transaction. Five separate wallets handled distinct roles in the operation:

• Main operator — deployed the attacker's contracts, executed the bulk of the calls, handled cross-chain consolidation via Relay, and deployed the fake "u" token: 0x7c82cb4b2909c50c7c0f2b696eee7565e0a23bb8
• Co-operator — received two separate 1 ETH Tornado Cash withdrawals and supplied operational gas to the main wallet across all three chains: 0x9bdc730183821b6bb2b51be30b77c964fa645b91
• Third wallet — made direct calls to the module and deployed 19 fake token contracts spanning Ethereum, Base, and Arbitrum: 0x7e54c729148a95bca651f3214ac9ebefd3fb1271
• Fourth wallet — used a separate set of fake tokens ("sasx," "sas," "ddxx v3"), funded through the Orbiter Finance Bridge: 0xc8ef4003d9db3863b9af26afcf2275378bfa83e4
• Holding wallet — the final destination for consolidated DAI: 0xa447f71782135ab96a71374271a749ff7aa54859

Before touching a single client Safe, the main operator wallet had already deployed 19 Uniswap V3 liquidity pools — one for every token type held across the intended targets. Each pool paired a genuine asset against the same fabricated token, "u."

Fake token "u": 0xe6Ff0FE017D09D690493deC0F0f55E8f9Cdc3512

The module's flawed access control was merely the trigger; the pre-built pool infrastructure was the actual mechanism of theft. When each drain fired, the victim Safe never transferred tokens directly to the attacker — instead it was forced to swap its full balance through the corresponding attacker-owned pool, handing over real assets and receiving worthless "u" tokens in return, again with amountOutMin set to zero.

Once the drains were complete, the operator wallet pulled liquidity from all 19 pools, collected the legitimate assets, and used Relay to consolidate everything cross-chain before sweeping the proceeds into the holding wallet. Because the protocol's own swap mechanics did the actual token movement, there was no direct transfer trail linking victims to the attacker.

Additional attacker-linked contracts identified during the investigation:

• Ethereum: 0xfac7459683cdb9b6f367b42eedfebd745dc8760c
• Ethereum: 0xe1d5fcfbba4d46f4937de369de415dd7e2d3265a
• Base: 0x2d450322e3526f489afcc8c49923b35d355c70bc
• Arbitrum: 0x2d450322e3526f489afcc8c49923b35d355c70bc
• Arbitrum: 0x35b94f725bfdc1d00ef15df99dafadf6ecf3a0e9
• Vulnerable Safe Module: 0x1f1d37a3Bf840e35c6a860c7C2dA71Fe555123ca
• Sample attack transaction: 0x59d17fd31e31959b2d562508bf91c4fc1271682ba7d61a6209865e1151b69aea

The combined haul across all three chains broke down roughly as: ~1.18M USDC ($1.18M), ~12.44 cbBTC ($961K), ~181 WETH ($383K), ~371K apyUSD ($371K), ~257K gtUSDCp ($257K), ~97K cbXRP ($132K), ~111K sUSDat ($111K), ~107K steakUSDC ($107K), ~1.243 WBTC ($95K), ~286 wTAO ($82K), ~25.2 steakETH ($55K), ~45K SYRUP ($52K), ~19.3 wstETH ($50K), ~375K BNKR ($37K), ~14.5K sparkUSDC ($14.5K), ~151 AAVE ($13K), ~9.5K LIT ($12K), ~23K ONDO ($9.8K), ~2.6K UNI ($8.7K), ~25K CFG ($7.7K), ~3K MORPHO ($7.2K), ~56K ENA ($5.7K), ~1.4K FLUID ($4.2K), ~3.5K USDT ($3.5K), plus smaller amounts of EUL, LBTC, ZRO, LINK, WLD and others totaling roughly $12K.

Common Prefix's post-incident review settled on approximately $3.98 million across 308 successful drains affecting 88 distinct Safes. Base accounted for roughly 71% of the total loss, Ethereum for roughly 27%, and Arbitrum for the remaining 2%. Everything was ultimately converted to DAI and consolidated into one wallet: 0xa447f71782135ab96a71374271a749ff7aa54859, which held $3,070,767 in DAI as of publication. Those funds have not moved.

The attacker's various EOAs show near-zero ETH balances — consolidation happened quickly, conversion was clean, and the trail ends visibly at one on-chain address, with no bridge hops and no mixing observed afterward.

Of the Safes that were spared, 229 were exposed but never drained, whether due to detection or the attacker running low on time. Breaking it down by chain: on Ethereum, 151 Safes carried active permissions and 24 were hit; on Base, 148 were exposed and 46 were drained. The gap between exposure and actual loss suggests the potential damage could have been considerably larger. The Dune dashboard tracking the incident captured measurable USD losses on Ethereum and Base but excluded apyUSD and cbXRP for lack of price feeds; accounting for Arbitrum and those unpriced tokens brings the total in line with Common Prefix's confirmed count of 88 victim Safes.

04A Security Review That Never Reached the Vulnerable Code

None of the conditions enabling this exploit were concealed. They existed in a publicly verified contract, a publicly readable permission registry, and an architecture that left its most sensitive function ungated. Simply, nobody looked closely enough before the attacker did.

New Market Trading's platform had undergone an audit by Burra Security in October 2025, but that engagement covered only the V1 system, and its results were kept private at NMT's request. Burra Security told Rekt News directly: "It was the V1 version of their system which did not have the vulnerable SquidRouterModule. Since our security review with them they made a bunch of changes and released V2 version of their contracts which included adding the SquidRouterModule."

In other words, a module containing two bypassable checks and a single missing access-control line was deployed to mainnet with full spending authority over client wallets, and left running for three months without a fresh security review. New Market Trading's own marketing promises clients it will "never shy away from telling you where the dangers lie" — but the danger, in this case, lived in its own codebase.

Frank Hepworth, NMT's founder and CEO, maintains a YouTube channel with roughly two dozen videos covering crypto strategy and onchain markets, including one titled "This Is How Smart People Get Rich with Crypto." That public profile didn't translate into commissioning a second audit when V2 introduced a new privileged execution path.

New Market Trading is not an isolated case, even within 2026. Just over a week prior, TrustedVolumes lost $5.87 million to an authorization boundary failure in a custom RFQ proxy — a permissionless signer-registration function, a validation check against the wrong address, and unlimited approvals granted to unaudited code, drained in a single transaction covering four assets before most security firms had even finished posting alerts. The similarity is striking: a custom module, broken caller validation, and no audit coverage on the component that actually failed.

Safe modules are intentionally powerful — once enabled, they can execute transactions on a Safe's behalf without requiring owner signatures. That's precisely what makes automated DeFi strategies viable, and precisely what turns an unreviewed module into a total drain vector for every asset the Safe holds. The victims here weren't phished and didn't click malicious links; they simply signed up for a wealth-management service, trusted its infrastructure, and had their funds swept by a contract that mistook "knowing who a valid delegate is" for "being a valid delegate."

On Tuesday, May 27th, Frank Hepworth issued an official statement on NMT's behalf:

"The funds that were taken through the exploit belong to our clients - real people. We are offering a formal white-hat bounty - return 90% of the drained funds to the address below by Saturday 30th of May at 12AM EST, and we commit in writing to no prosecution and no civil action. You may retain 10% as recognition for identifying the vulnerability. We have notified relevant authorities and blockchain analytics firms, and onchain activity is being monitored. However, our priority is the recovery of funds for our clients. We urge you to do the right thing."

Return wallet: 0xeF9cbA776E050a552a8089498c5A3C69B89cE9DC

Blockscan chat contact: 0xa7db9793d4978a26ee01c2a6cbf5ba154925a7532e31ae731f7f08ba4295ee70

Bounty details: newmarkettrading.com/bounty

As of publication, no post-mortem has been released and no response from the attacker has been confirmed. The DAI remains unmoved.

05The Broader Picture

No New Market Trading client was phished. No private key was compromised. Neither was necessary. The attacker simply read a public contract, copied a string, pulled a genuine delegate's address from an open permission registry, and invoked a function that was never meant to serve as an entry point.

The architecture itself did the rest: 88 Safes across three chains, a network of fake-token liquidity pools, one worthless token, and $3.98 million converted, consolidated, and left sitting untouched — all while the platform that had promised to safeguard those funds published a bounty page instead.

Three months of unrevoked permissions. A V1 audit that never touched the module responsible for the loss. A Basescan verification that sent an entire industry chasing the wrong protocol. Squid was forced to publicly disown a contract it had never laid eyes on, and Safe's CEO had to remind the market that modules enabled outside official channels carry risks that Safe's own tooling can't detect. Two uninvolved organizations spent a day doing damage control for code they had nothing to do with.

The underlying flaw — trusting attacker-supplied payload data over msg.sender — is a well-documented confused-deputy pattern, not a novel discovery. It's exactly the kind of issue a proper audit is meant to catch and a threat model is meant to anticipate, and it has drained other protocols before this one and will likely drain more after it.

$3,070,767.09 in DAI remains parked in a public wallet, with the official bounty window open until May 30th. When a wealth-management platform ships the module guarding client funds without a proper review, the exploit itself isn't really the failure — everything that led up to it is. The attacker didn't need to outsmart anyone; reading the available source code was sufficient, and NMT's clients never had a real chance to avoid it.