Bankr's 14-Wallet Hack: Decoded On-Chain

On May 19, 2026, Bankr — an AI agent on Base that lets users transact by tweeting at it — disclosed that an attacker had accessed 14 user wallets. Transactions were paused. Reimbursement from a >$3M treasury was promised. The FBI was looped in. SlowMist began tracing three attacker-linked addresses now holding roughly $440,000 combined.

Fifteen days earlier, on May 4, the same architectural primitive was exploited for $174K out of a single Bankr wallet auto-provisioned for xAI's Grok account. SlowMist published a full post-mortem. The attack chain — send an NFT to upgrade a wallet's permissions, then Morse-code a prompt at Grok and let Grok forward the decoded command to Bankrbot — was understood. The funds were partially negotiated back.

Then Bankr kept shipping.

This decode is the on-chain version of the story. We verified Bankr's architecture against our Base node, traced the May 4 attacker wallets to confirm what was recoverable, and explain what the May 19 event actually looks like when you take "14 compromised wallets" literally. There is no smart-contract bug to point at. The vulnerability is the architecture itself — and Bankr's own post-incident fix tells you exactly which part.

---

What "a Bankr wallet" actually is

Every X handle that interacts with @bankrbot gets an auto-provisioned crypto wallet on Base. The user never sees a seed phrase. They never approve a transaction in a popup. They tweet @bankrbot swap my ETH for BNKR, and a few seconds later a swap settles on chain from their wallet.

Three pieces make this work:

1. Privy holds the private keys. Each wallet is an EOA, and the key lives in Privy's AWS Nitro enclaves, split via Shamir Secret Sharing across the enclave and an auth share. Privy was acquired by Stripe in June 2025. Users don't sign — Privy does, on Bankr's instruction.
2. Bankr holds the right to give that instruction. Specifically, the user signs a delegation under the MetaMask Delegation Framework (ERC-7710) that gives Bankr's signer the right to redeem transactions on the user's behalf. On chain, this is visible as redeemDelegations calls routed through Bankr's settlement contracts. We confirmed the pattern on transaction 0x019d8eaa00e0dc19d78a917940ea3e0172e5949dbefb265efff0d7ef181ca057 (May 19, 23:30 UTC), where funds belonging to Bankr's fee collector address 0xF60633D02690e2A15A54AB919925F3d038Df163e move via a redeemDelegations call submitted by a Bankr relayer.
3. Bankr Club (0x9FAb8C51f911f0ba6dab64fD6E979BcF6424Ce82) is an ERC-721 with 1,000 total supply and 882 current holders. It is also a capability token. Per SlowMist's post-mortem of the May 4 incident, holding a Bankr Club NFT unlocks "high-privilege capabilities, including large-value transfers and token swaps" inside Bankr's agentic toolset.

The mental model that matters: the user owns the address, but Bankr owns the right to use it. There is no key for an attacker to steal from the user. There is a delegation for an attacker to abuse from the service.

That distinction is what makes the May 19 wording — "an attacker was able to access 14 bankr wallets" — mean something specific. Not 14 seed phrases leaked. Not 14 MetaMask windows phished. Fourteen delegations executed by Bankr against its own user base in a five-hour window.

---

May 4 — the rehearsal nobody read

On May 4 at 06:49:01 UTC, transaction 0x6fc7eb7da9379383efda4253e4f599bbc3a99afed0468eabfe18484ec525739a settled at Base block 45,543,997. From 0xb1058c959987E3513600EB5b4fD82Aeee2a0E4F9 — the auto-provisioned wallet for @grok, referenced as "Bankr 1" in the SlowMist post-mortem. To 0x3ec2156D4c0A9CBdAB4a016633b7BcF6a8d68Ea2 (DRB, a ClankerToken). Method: transfer(0xE8E476bdd78b0aA6669509eC8d3E1c542d5A686B, 3,000,000,000). Roughly $174,000 at the time.

The signature on that transaction was Bankr 1's own. Privy held the key. Privy signed it. No private-key theft was involved. Bankr's command pipeline asked Privy to sign, and Privy did.

The attack chain that produced that ask, per SlowMist's "Behind the Grok Exploitation" analysis:

Stage 1 — privilege escalation by gift. Attacker (X handle @Ilhamrfliansyh, since deleted; on-chain ilhamrafli.base.eth = 0x35DdFc1Cf8835b3B1EA960D892a82963D3386D19) sent a Bankr Club Membership NFT to Bankr 1. Bankr's agentic toolset upgraded the wallet's permissions accordingly.

Stage 2 — prompt injection. A Morse-coded reply to @grok slipped past Grok's safety filters, which were looking for plaintext. Grok decoded it cleanly and posted the plaintext back as a public reply, tagging @bankrbot with what now read as "send 3B DRB to [address]." BankrBot's scanner treated the verified-Grok-account reply as authoritative and signed the transfer.

Bankr's command interpreter trusted Grok the way it would trust the wallet's actual owner.

Recovery was partial — roughly 80% returned, the rest pocketed by the attacker as an "informal bug bounty." It happened because @Ilhamrfliansyh got doxxed in real life, not because anyone froze anything on chain. We verified both attacker wallets on Base as of block 46,290,542 (2026-05-21):

Both wallets are smart accounts upgraded via EIP-7702 to point at known account-abstraction implementations (CaliburEntry for one, ZeroDev/Kernel for the other). The funds were bridged and CEX'd within minutes of the original transfer. There was nothing on chain to freeze.

A small detail that didn't make the post-mortem write-ups: on April 15, the same DRB-recipient wallet was used to deploy a token called "Fully Claw AI" (CLAW) via Whetstone's Airlock factory (tx 0x1361dd6975e8f2b6c6f5800bb5130b37977af0912bb5d00a986ae84bf11a0138). The attacker-controlled smart account didn't just exit — it kept being used.

---

May 19 — the same primitive, at scale

"update: we've identified an attacker was able to access 14 bankr wallets. we've temporarily locked things down while we work through the details. we will be reimbursing any and all lost funds." — @bankrbot, May 19, 2026.

Per SlowMist's hacked-database entry, Bankr detected the incident around 06:00 UTC and paused transactions by 11:00 UTC. Conservative loss estimate: ~$170K, in ETH and BNKR. Three attacker-linked addresses now hold roughly $440K combined. SlowMist's framing was direct: "a social engineering exploit targeting the trust layer between automated agents."

The mechanic, per SlowMist: "unauthorized transfers (primarily direct transfer() calls, followed by swaps to ETH and bridging)."

We need to be honest about what we found and what we didn't. SlowMist has not published the 14 victim addresses or the three attacker addresses as of May 21 — likely held back pending FBI coordination, which Bankr's May 20 update confirmed is underway. Premature publication would risk the attacker dumping or laundering further before exchanges can freeze deposits.

We tried to back into the victim list anyway. The Bankr Club NFT is the architectural primitive that unlocks high-privilege actions, so the 882 current holders (we paginated up to 1,200 historical recipients) were the natural starting set. We pulled outbound activity from every one of them in the May 19 06:00–11:00 UTC window. About 133 of them touched Bankr's swap settler in that window. Zero of them showed the distinctive all-funds-out-to-single-attacker-address pattern.

The 14 victims are almost certainly not Bankr Club holders. The Club gates higher privileges, but standard Bankr-provisioned wallets already carry enough delegation authority for the attacker's purposes. The victim set is a subset of the much larger population of Privy server wallets created via @bankrbot interactions over the past two years — tens of thousands of EOAs that our 30-day-pruned sentinel cannot enumerate without help from Bankr or SlowMist.

There is, however, one named victim. Tech entrepreneur Austen Allred (BloomTech founder, creator of the KELLYCLAUDE project) posted publicly:

"There's no evidence anyone other than myself ever logged into the Bankr account; they must have accessed the keys some other way."

Two important facts about his case. First, his Bankr wallet was drained of ETH only. His memecoin holdings — including the supply of his own KELLYCLAUDE token (0x50D2280441372486BeecdD328c1854743EBaCb07, deployed via @bankrbot on January 30) — were untouched.

That single detail rules out a class of explanations. A garden-variety wallet drainer sweeps everything: it pulls every existing ERC-20 approval, signs transferFrom against each one, and exits with whatever the wallet had. An ETH-only drain is consistent with the attacker having a single transaction-construction primitive — "move ETH from wallet A to wallet B" — and not a way to enumerate and sweep tokens in the same flow. That is exactly what abuse of Bankr's command interpretation layer would look like.

Second, Allred's note that "no one else logged in" is the giveaway. There was nothing to log into. The attacker didn't need to log in. Bankr-the-service has standing authority to transact on his behalf, and the attacker found a way to drive that authority.

---

Bankr's fix is the confession

The strongest evidence about the root cause isn't anything an analyst said. It's Bankr's own post-incident mitigation list, per SlowMist's write-up:

• Optional IP whitelisting on API keys
• Permissioned API keys
• A per-account toggle that disables actions triggered by X replies

That third one is load-bearing. If the root cause were key compromise, the fix would be key rotation. If the root cause were a smart-contract bug, the fix would be a contract upgrade. The fix Bankr shipped is "let users turn off the input channel that allowed Grok to act on their behalf 15 days ago."

That is the May 4 vector being closed retroactively. The mitigation says, in product terms, the attack treated an X reply from a trusted upstream account as if it came from the wallet's owner, and now you can turn that off per account.

There is an alternative hypothesis we cannot fully rule out from chain alone: Bankr's own API credentials — the ones that authorize redeemDelegations against user wallets — could have been compromised at the service layer, and the attacker could have used those credentials directly to drain 14 hand-picked targets. On chain, those two attack flows look identical: a redeemDelegations call moving funds. Both are consistent with "FBI is coordinating asset recovery." Both are consistent with a 14-wallet scope. The X-reply mitigation tilts our reading toward the prompt-injection hypothesis, but a credential-compromise reading is empirically defensible.

What is not defensible is the Privy-infrastructure-breach hypothesis. A breach of Privy's TEE signing path would manifest as simultaneous, cross-customer drains across Privy's full client base. Nothing like that is visible on chain. The exploit primitive lives above Privy.

---

What's recoverable

For the May 4 cluster: essentially nothing. Both attacker wallets are empty as of block 46,290,542. The ~80% recovery happened because the attacker was doxxed in real life and chose to return funds. That's a social outcome, not a chain-level intervention.

For the May 19 cluster: SlowMist tracks ~$440K still sitting in three attacker-linked addresses. Without the address list we cannot independently confirm liquidity or whether anything has moved since the initial trace. The "coordinating with FBI" language is consistent with attempting to land CEX freezes and bridge clawbacks on the bulk of the funds before publishing addresses (publishing first would tip the attacker).

What is fully recoverable, regardless of how the attacker-side recovery plays out, is the victim side. Bankr disclosed a >$3M reimbursement treasury and committed to making all 14 victims whole. The risk passes from users to Bankr's balance sheet.

One nice color detail from our search — within hours of the May 19 disclosure, opportunistic memecoin deployers shipped at least five "Bankr Exploited," "Bankr Was Hacked," and "ExploitedBankr" tokens on Base. The ecosystem reflex was faster than the post-mortem.

And one more piece of useful context: Bankr 1, the wallet that lost 3 billion DRB on May 4, still holds 16.045 ETH (~$33,900 at $2,113/ETH) as of block 46,291,536. The wallet that was supposed to be auto-provisioned for Grok's use, that got hijacked once, that the team had every reason to retire — still has a five-figure ETH balance sitting on it. Whether anyone is meaningfully "using" the @grok-tied Bankr account 17 days after the incident is its own story.

---

The architectural takeaway

What broke isn't a smart contract. There is nothing to audit. What broke is a design choice with three layers stacked on top of each other:

• Custodial pretending to be non-custodial. Privy holds the keys, so Bankr can say "we don't custody funds." But Bankr holds the delegated signing rights, so functionally Bankr can move funds for any of its users at any time. Compromise of Bankr's command pipeline is, in practical terms, a compromise of every user wallet simultaneously — bounded only by how long it takes to notice and pause.
• NFT-as-capability. A single ERC-721 transfer changes what BankrBot is willing to do for a wallet. Permission state lives in transferable metadata. The wallet owner cannot opt out of receiving the NFT, and the NFT contract has no concept of "consent to capability upgrade."
• AI-to-AI trust chains. BankrBot accepts verified-account replies from upstream AI agents (Grok in this case) as authoritative commands. When the upstream AI has a safety filter that only checks plaintext and a feature that decodes Morse on demand, the trust boundary collapses.

The May 4 incident exposed all three layers. The fix shipped on May 21 admits all three layers are still there — the per-account toggle just gives users the ability to turn one of them off. The other two remain the default.

ChainWard's job here isn't to call this a scam (it isn't) or to pile onto Bankr (the team owned it, paused fast, is reimbursing). The job is to show what the architecture actually looks like on chain, so the next person evaluating "an AI agent that transacts for you on Base" can ask the right question: who holds the right to make this wallet transact, and what happens to me if that holder is compromised in any way at all?

For Bankr today the answer is: Privy holds the keys, Bankr holds the rights, an NFT can upgrade the rights, and an inbound X reply from a verified AI account can be parsed as if it came from you. Two of those four facts produced May 4. The same two, at scale, produced May 19.

---

The 14 victim addresses and three attacker addresses are pending public disclosure. We will update this decode when SlowMist or Bankr publish them. The architectural verification, the May 4 attacker-wallet state, and the on-chain mechanism details are based on direct queries against ChainWard's Base sentinel and Blockscout (Base) — sources and tx hashes are in the findings file for this decode.