On January 31, 2026, Step Finance — one of Solana's most established DeFi analytics platforms — watched helplessly as 261,854 SOL walked out of its treasury wallets during APAC trading hours. Not through a flash loan. Not through a reentrancy bug. Through malware on executive laptops.
Three weeks later, Step Finance, SolanaFloor, and Remora Markets were all dead. The STEP token had cratered 93%. And the DeFi security community was left with an uncomfortable question: What good are audited smart contracts when the humans holding the keys get owned?
This article dissects the attack chain, maps it against common Solana treasury architectures, and presents a concrete 7-layer operational security playbook that would have stopped this exploit at multiple points.
The Attack: What Actually Happened
Phase 1: Initial Compromise (Days/Weeks Before Jan 31)
The attackers targeted Step Finance's executive team through what the team later described as a "well-known attack vector" — likely a targeted phishing campaign or trojanized software package. Malware was installed on multiple executive devices, giving the attackers:
- Visibility into internal transaction approval workflows
- Access to private keys stored on or accessible from those devices
- The ability to intercept or manipulate signing requests
This is a classic Advanced Persistent Threat (APT) pattern: compromise the endpoint, observe the operational flow, then strike when you understand the signing architecture.
Phase 2: The Unstaking (January 31, 2026)
With access to the treasury wallets' signing capabilities, the attackers initiated the unstaking of approximately 261,854 SOL tokens. On Solana, staked SOL typically has an unstaking cooldown period, which means the attackers either:
- Timed their attack to coincide with already-unstaked positions, or
- Initiated unstaking days before the actual drain and waited
Phase 3: The Drain
Once SOL was liquid, funds were transferred to attacker-controlled addresses in rapid succession. The team detected the unusual transaction patterns, but by then the damage was done:
- ~$40M in total confirmed losses
- $4.7M recovered through Token22 protections and partner coordination
- Net loss: ~$35.3M — enough to kill three projects
Phase 4: The Aftermath
On February 23, 2026, Step Finance announced the shutdown of all operations. The team explored financing and acquisition options, but the damage was terminal. They announced a buyback program for STEP holders based on a pre-hack snapshot — cold comfort for a 93% token crash.
Why This Matters More Than Another Smart Contract Bug
DeFi security discourse is dominated by smart contract vulnerabilities: reentrancy, oracle manipulation, flash loan attacks. Audit firms compete on Solidity bug detection. Bug bounties reward on-chain findings.
But look at the numbers. The Step Finance hack cost $40M — more than most smart contract exploits in Q1 2026. And it required zero knowledge of Solana's runtime, BPF bytecode, or the Anchor framework.
The uncomfortable truth: most DeFi projects are far more likely to lose funds through compromised keys than through contract bugs. A 2025 Chainalysis report estimated that private key compromises accounted for roughly 43% of all crypto theft by value — outpacing smart contract exploits.
Anatomy of Solana Treasury Architectures (And Where They Break)
Understanding why Step Finance fell requires understanding how Solana DeFi projects typically manage treasury funds:
Pattern 1: Single-Signer Hot Wallet (Worst Case)
Executive Device → Private Key → Treasury Wallet
If the device is compromised, the attacker has the key. Game over. This is almost certainly what happened at Step Finance for at least some of the affected wallets.
Pattern 2: Multisig via Squads Protocol
Executive Device A → Signs TX
Executive Device B → Signs TX
Executive Device C → Signs TX
→ Squads Multisig → Treasury Wallet
Improvement: Requires M-of-N signatures. But — if the same malware campaign compromises multiple executive devices (as happened at Step Finance), the attacker can gather enough signatures. Multisig is only as secure as the independence of its signers' devices.
Pattern 3: Hardware Wallet + Multisig (Best Practice)
Ledger/Trezor A → Signs TX (air-gapped)
Ledger/Trezor B → Signs TX (air-gapped)
Mobile HSM C → Signs TX (separate network)
→ Squads Multisig + Time-lock → Treasury Wallet
This is the minimum viable security for any treasury holding >$1M. Hardware wallets ensure that even fully compromised devices cannot extract the private key — the key never leaves the secure element.
The 7-Layer OpSec Playbook for Solana Treasury Teams
Layer 1: Hardware Wallet Mandate
Rule: No treasury key may exist on a general-purpose computing device. Period.
For Solana, this means using Ledger devices with the Solana app. Every signer must use a dedicated hardware wallet for treasury transactions. The key never touches the laptop.
Implementation:
# Verify Ledger connection for Solana CLI
solana config set --keypair usb://ledger?key=0
solana balance # Confirm it reads from Ledger
Layer 2: Independent Signer Environments
Rule: Each multisig signer must operate from an independently secured environment.
This means:
- Different devices (not just different accounts on the same laptop)
- Different networks (home office, mobile hotspot, corporate VPN — not all on the same WiFi)
- Different operating systems if possible (one macOS, one Linux, one mobile)
The Step Finance attackers compromised multiple executive devices. If those devices shared an IT environment (same MDM, same email domain, same Slack workspace used for phishing), one campaign could own them all.
Layer 3: Time-Locked Transactions
Rule: Any treasury transaction above a threshold must have a mandatory delay before execution.
Squads Protocol on Solana supports time-locks. A 24-hour delay on transactions >$100K would have given Step Finance's team time to detect and cancel the attackers' unstaking operations.
// Pseudo-configuration for Squads time-lock
{
"threshold": 3, // 3-of-5 multisig
"timeLock": 86400, // 24 hours in seconds for large TXs
"alertWebhook": "https://your-monitoring.endpoint/alert"
}
Layer 4: Transaction Simulation & Alerting
Rule: Every treasury transaction must be simulated before signing, and anomalous transactions must trigger alerts to all signers through an independent channel.
On Solana, you can use simulateTransaction via RPC to preview the effects of any transaction before it hits the chain:
const simulation = await connection.simulateTransaction(tx);
// Check: Does this unstake more than X SOL?
// Check: Does this transfer to a known address?
// Alert via Telegram/Signal/PagerDuty if anomalous
Step Finance detected "unusual transaction patterns" — but only after funds were already moving. Pre-signing simulation with automated alerts could have caught the unstaking operation hours or days earlier.
Layer 5: Dedicated Signing Devices
Rule: Treasury signers should use dedicated devices that are never used for email, web browsing, or installing arbitrary software.
A Chromebook in Developer Mode running only a terminal + Solana CLI + Ledger connection is a reasonable signing station. It never opens email. It never visits a website. It exists only to review and sign transactions.
Cost: ~$300 per signer. Step Finance lost $40M.
Layer 6: Social Engineering Resistance Training
Rule: All team members with signing authority must undergo regular social engineering testing.
The Step Finance compromise started with people, not code. Monthly phishing simulations, mandatory 2FA on all accounts, and a "verify out-of-band" policy for any unusual request would have raised the bar significantly.
Key practices:
- Never install software from unverified sources — this includes "helpful" developer tools shared in DMs
- Verify unusual requests through a different channel — if someone asks you to sign something via Slack, call them on the phone
- Report first, click never — establish a security channel where team members can forward suspicious messages
Layer 7: Catastrophe Planning
Rule: Have a documented, tested incident response plan that assumes a full key compromise.
Step Finance explored financing and acquisitions after the hack — but had no pre-built playbook. A catastrophe plan should include:
- Emergency pause mechanisms — program-level freeze authority that can halt all treasury operations
- Insurance coverage — DeFi insurance protocols like Nexus Mutual or InsurAce
- Communication templates — pre-drafted disclosure statements (every minute counts in crisis comms)
- Legal counsel on retainer — crypto-native legal teams ready to assist with fund tracing and law enforcement coordination
- Token holder protection mechanisms — snapshot capabilities and redemption processes
A Checklist for Solana Protocol Teams
| Layer | Control | Step Finance Had It? | Your Protocol? |
|---|---|---|---|
| 1 | Hardware wallets for all treasury keys | ❌ Likely not for all wallets | ☐ |
| 2 | Independent signer environments | ❌ Executive devices were co-compromised | ☐ |
| 3 | Time-locked transactions | ❌ Funds moved immediately | ☐ |
| 4 | Pre-signing simulation + alerts | ⚠️ Detected after the fact | ☐ |
| 5 | Dedicated signing-only devices | ❌ Executives used general-purpose devices | ☐ |
| 6 | Social engineering training | ❌ Phishing/malware succeeded | ☐ |
| 7 | Incident response plan | ⚠️ Partial — managed some recovery | ☐ |
The Bigger Picture: Bridging the On-Chain/Off-Chain Security Gap
The DeFi security industry has a blind spot. We spend millions on smart contract audits (rightfully so), but the operational security of the humans and devices that control privileged keys often receives a fraction of that attention.
Anatomist Security's AI agent earned $400K for finding a Solana runtime vulnerability. That's important work. But the Step Finance attackers didn't need to find a runtime vulnerability — they found something far easier to exploit: humans with admin keys on internet-connected laptops.
The real audit is the one that covers both the code and the people who deploy it.
For Solana teams managing significant treasuries, the investment in operational security infrastructure — hardware wallets, dedicated devices, time-locks, and incident response planning — is not a nice-to-have. After Step Finance, it's an existential requirement.
Key Takeaways
Off-chain security failures cause more dollar damage than most smart contract bugs. Step Finance lost $40M through compromised devices, not contract vulnerabilities.
Multisig alone is insufficient. If the same attack compromises multiple signers' devices, multisig provides no protection. Signer independence is the actual security property.
Hardware wallets are non-negotiable for treasury keys. At $300 per device, there is no rational justification for keeping treasury keys on general-purpose computers.
Time-locks are the kill switch the industry ignores. A 24-hour delay on large transactions would have given Step Finance's team time to intervene.
Your incident response plan is your survival plan. Step Finance had no viable path forward after the hack. The time to build that path is before you need it.
DreamWork Security provides security research, auditing, and operational security consulting for DeFi protocols on Solana, EVM, and cross-chain architectures. Follow us for weekly deep dives into the exploits and defense patterns shaping Web3 security in 2026.
Top comments (0)