Pennysia settlement contract exploited on Ethereum, users told to revoke approvals

Pennysia, an aggregator-style swap protocol on Ethereum, had its Settlement V1 contract exploited this week through an arbitrary external call vulnerability. Security firm SlowMist issued a public advisory on November 13 after receiving user reports of missing funds; the team paused swaps on Pennysia's own front-end before the SlowMist post went out. Users who ever approved tokens to the Settlement contract are told to revoke those approvals immediately — pausing swaps does not retire existing ERC-20 allowances. SlowMist's warning is relayed by PANews, The Defiant and TokenPost; the primary contract is verified on Etherscan as "Pennysia: Settlement V1."

What happened

SlowMist's investigation, posted to its X account and propagated through PANews, states the Pennysia Settlement contract on Ethereum contained an arbitrary external call that an attacker used to pull tokens users had pre-approved to the contract but had not yet routed through a swap. Four wallets have been identified as drained in the initial sweep. Reported losses across those wallets are small in dollar terms — roughly 5,000 USDC, ~0.05 wstETH and about 101,000 YUNO (YUNo.finance) per TokenPost's summary of SlowMist's figures — but the universe at risk is every wallet that has interacted with the contract since launch and still holds an active allowance.

Pennysia's project page describes the product as a non-custodial swap aggregator that routes against connected DEXs, aggregators, intent protocols and RFQ market makers; Pennysia Inc. states it "does not control, operate, or maintain" protocol instances. No incident disclosure has been posted on the project site at the time of writing.

The mechanism: arbitrary external call on a token-handling contract

An arbitrary external call in a settlement contract is exactly what it sounds like: a code path where caller-supplied data lets the contract invoke a function on an attacker-chosen target. In a settlement / router design that pulls ERC-20 tokens from user wallets via transferFrom, that primitive is enough to let a crafted call drain approved balances — the contract has permission to move them, and the exploit lets the attacker direct that permission at tokens of their choice.

Two implications follow directly:

1. Approvals, not balances, are the attack surface. Funds sitting in a wallet that never approved the Settlement contract are untouched. Funds in wallets that approved and forgot are at risk even after the team pauses swaps.
2. Pausing the front-end does not help holders. Pennysia disabled swaps on its UI before SlowMist went public, per on-chain telemetry cited by The Defiant. That action blocks new routing via Pennysia; it does not revoke a single existing ERC-20 allowance. The approval map is held by each token contract, not by Pennysia.

Action checklist

1. Open a revoker tool (Revoke.cash, Etherscan's token approval checker, or your wallet's native allowances screen) and filter for the Settlement V1 address 0x3aad97e5a91b8e43b7dc830aceb004307678795e.
2. Revoke any outstanding allowance to that address for every token, including dust.
3. Treat any new Pennysia front-end that reappears before an official post-mortem as unverified. SlowMist's recommendation is to stop interacting with the contract.
4. If you are a protocol that integrated Pennysia for routing or quoting, pause that integration until the team publishes a patched contract address and an audit of the fix.

Context

Pennysia joins a steady run of settlement- and router-style contracts whose approval surfaces have been monetised in 2026 — the pattern tracks back through the older DxSale locker drain (mid-2026, ~$7.3M across BNB Chain pools) and every "revoke your approvals" advisory SlowMist and PeckShield have published since. The lesson repeats: a single arbitrary call in a token-handling contract converts every live allowance into free liquidity. Front-end pauses buy time for users to revoke; they do not close the hole.

What's missing from public disclosure so far: the attacker address, the drain transaction hash, and Pennysia's own post-mortem. Until those land, the only safe assumption is that any approval granted to Settlement V1 is live and exploitable.