Between 12 and 18 October, at least six blockchain projects lost money to flaws in their smart contracts or the systems around them. None of the incidents needed new cryptography or an unknown class of attack. What they shared was time: a test key that sat on a whitelist for 14 months, a system contract that had not changed since 2022, a lending market that had been idle for 36 days, and bridges that trusted a single component nobody had challenged. Together they make a simple point. A smart contract is not finished when it is deployed. Its assumptions keep aging, and someone has to keep rereading them.
A test key that never left
On 18 October, AlpsCon AI Trade Hub on BNB Chain lost about $152,000. Participation was limited to whitelisted wallets, but the whitelist included Hardhat's default account #0, a development wallet whose private key is publicly known. According to Telem, it had been added during a bulk import on 24 August 2025 and stayed there for roughly 14 months. The attacker used that publicly known key, together with an EIP-7702 delegation, to act as the trusted account, then exploited a reward bug that let a fresh deposit collect rewards accumulated before it existed. The address was removed from the whitelist about five hours after the attack.
Two separate weaknesses lined up: a configuration error from more than a year earlier and an accounting rule that had never been tested against a brand-new deposit.
Code nobody had read since 2022
On 17 October, an attacker used a flaw in the webauthn wallet system contract of XPR Network to make 67 accounts borrow 1,143,288 USDC in a single transaction. As Nexus Mutual's weekly security roundup notes, that contract had not changed since August 2022. The borrowed USDC never left the bridge and was returned, and block producers replaced the keys on the attacker's account by multisig, but users' liquidation losses remain unquantified.
The same day, the idle USDT market of the BiFi lending protocol on Ethereum was drained of about $165,400. The market had seen no activity for 36 days, and the interest owed for that idle period was applied again on every action within the same block instead of once. The arithmetic had worked for short gaps. It had never been tested against a gap of more than a month in production (Nexus Mutual).
No switch to turn it off
On 14 October, attackers drained UNCX's Vesting V2 contract, a shared service that holds tokens for other projects' vesting schedules. A share-accounting error in cancel() let an attacker remove already-released shares from the pool total a second time, so remaining shares claimed tokens that belonged to other schedules. Within a day the same bug had been used on Ethereum, BNB Chain, Base and Robinhood Chain, by the original attacker, copycats and bots. Blockaid's tally reached about $1.49 million, while UNCX's own recap put verified losses at $807,600 (Nexus Mutual).
What stands out in SigIntZero's analysis is what the contract lacked: it had no pause function. With identical code live on four chains, UNCX had to contain the damage by raising fees to levels that made the attack uneconomic. A few lines of tested emergency control would have given the team a direct way to stop it.
Bridges that trusted one component
Two bridge incidents followed the same pattern. On 12 October, an attacker minted 119 million unauthorized THEO tokens on Base through Autheo's bridge route, which was configured to accept any message delivered by a single trusted relayer (Nexus Mutual). Five days later, on 17 October, an attacker minted 10 million CYS tokens on BNB Chain through Cysic's bridge. Cysic said the attacker "gained unauthorized access to a database used by services supporting the bridge and exploited a vulnerability in the relevant processing logic to submit a fraudulent mint message." The attacker sold 7.2 million tokens and moved about $727,000 to Ethereum before Cysic blacklisted the address 76 minutes after the mint (The Block).
In both cases the contract itself did what it was told. The problem was what it chose to believe. A mint path that trusts one relayer or one database is only as strong as that relayer or database.
Five questions to ask of any deployed contract
These incidents are different in their mechanics, but the same questions would have surfaced most of them. We think every team running contracts in production should be able to answer them, and keep answering them over time:
- Who is on the list today? Whitelists, admin roles and trusted signers should be reviewed on a schedule, not only at launch. Development and test accounts have no place in production configuration.
- Do the numbers still add up after every action? Core invariants, such as total shares equalling the sum of all positions, should be written down and tested across every order of calls, including direct token transfers and long idle periods.
- Can it be stopped? A scoped, tested pause, and a prepared plan for using it on every chain where the code is deployed, can shorten an incident from hours to minutes.
- What does it believe without proof? Any message, relayer or database that can trigger a mint or a payout deserves the same protection as the contract itself.
- When was it last reread? Code that has not changed in years has still been running in a changing environment, with new standards such as EIP-7702, new integrations and new attackers. Age is a reason to review, not a reason to trust.
How we approach it
Through XDRIP Solutions, we build blockchain integrations for our own platforms and for clients, including smart contract development, DOTs systems, cross-chain work and on-chain verification. This week's incidents are a reminder that the work does not end at deployment. The contract, its configuration and the off-chain services around it form one system, and that system needs to be reread as it ages.
The same idea runs through our TRACE Protocol, currently in development: a record is only useful if changes to it are visible and its history can be checked later. Smart contracts deserve that same scrutiny, not just on the day they go live, but on every day after.
