Pennysia’s Ethereum Settlement contract was exploited through an arbitrary external call that used standing token approvals. One confirmed transaction moved assets from four user wallets and produced a reported loss of about $5,131.
The incident shows why transfer logs must be reconciled by asset and victim. The transaction contains several hops for the same tokens. Adding every transfer event would count the drained value multiple times.
The confirmed transaction
The attack transaction is 0x2716c50e450272240f68f2827bcb4a336c2ac520951e0e530154566c295b732d on Ethereum. It was included in block 26,399,314 at 13:59:11 UTC on November 12.
Some alerts described the event as occurring at 21:59. That is the same moment expressed in UTC plus eight hours. The chain timestamp provides the common reference used in this analysis.
The affected Settlement contract is 0x3aad97e5a91b8e43b7dc830aceb004307678795e. The sending account identified in the public alert is 0x813a5ab666adeba907548235fbac087642878300. These are public address references, not verified legal identities.
Assets moved once after hop reconciliation
| Asset | Unique quantity drained | Victim source |
|---|---|---|
| USDC | 5,006.133489 | Two wallets |
| wstETH | 0.05 | One wallet |
| YUNO | 101,000 | One wallet |
The transaction logs show each asset moving through the Settlement contract and an intermediate contract before reaching the final address in the alert. The 5,000 USDC and 6.133489 USDC transfers belong to two victim wallets and sum to 5,006.133489 USDC.
The same asset appears in multiple transfer rows because of the routing path. Those rows are not separate losses. FOLITIC counts the amount leaving each victim once and does not add the intermediate hops.
What SlowMist reported
SlowMist’s incident database lists PennysiaSettlement as an Ethereum smart contract vulnerability with a reported loss of $5,131 across four users. The security firm said an arbitrary external call in executeSwap allowed residual approvals to be used through transferFrom calls.
The public alert advised any wallet that had previously approved the Settlement contract to revoke the permission. Revocation can stop future use of an allowance. It cannot recover assets that already moved.
Why approvals created the exposure
An ERC 20 approval lets a spender contract move tokens from a wallet up to an allowance. The permission can remain active after the user finishes a transaction or stops using a protocol.
In this incident, the reported weakness was not limited to assets held inside a Pennysia pool. It exposed tokens in user wallets when those wallets still had an allowance for the Settlement contract. That is why the potential exposure population can be larger than the four wallets already observed in the confirmed transaction.
The number of wallets with remaining approvals and their token balances was not published in the sources reviewed. FOLITIC does not estimate an amount at risk without a complete allowance snapshot and current balances.
What the trace proves
- The transaction succeeded on Ethereum and generated the listed transfer events.
- Four source wallets supplied the unique asset quantities in the incident record.
- The assets passed through contracts before reaching the final address in the alert.
- The public contract and transaction references match the SlowMist report.
What the trace does not prove
The address called the attacker in public alerts is an onchain account label. The ledger does not reveal the person or organization controlling it. A later transfer to an exchange, bridge, or privacy tool would identify a route, not the legal owner or a criminal judgment.
The transaction also does not prove that all funds are recoverable. A visible balance can move, be swapped, or become illiquid. Funds are recovered only when control returns to the rightful owner or an authorized custodian completes a verified return.
Privacy and attribution limits
Address clustering can connect accounts using common behavior, but it remains an inference unless a controller confirms ownership or a strong independent record exists. Shared infrastructure, routers, relayers, and custodial services can cause unrelated users to touch the same contracts.
FOLITIC therefore stops the trace at the confirmed public route. It does not infer a private identity from an address label, token approval, or nearby transaction.
What to monitor next
The critical next evidence is whether Pennysia disables or replaces the vulnerable call path, whether more victim transactions appear, and whether a verified reimbursement or recovery occurs. A promise to reimburse should remain separate from funds actually returned.
Users reviewing past permissions should rely on trusted wallet or explorer tools and verify the exact Ethereum contract address. This analysis did not connect a wallet, sign a transaction, or interact with the contract.
FOLITIC assessment
The confirmed incident is limited in reported dollar size but important in design. A single Settlement contract weakness allowed existing approvals to reach tokens held by users. The reconciled loss record covers four wallets and three assets without counting intermediate transfer hops as new losses.
Image credit Yuri Samoilov via Wikimedia Commons, licensed under CC BY 3.0. The photograph is illustrative and does not depict the reported incident.
This article is for information and analysis only. It is not investment advice.
