On January 31, 2026, Step Finance — one of Solana's most established analytics and yield aggregation platforms — lost approximately $40 million in digital assets. Three interconnected platforms (Step Finance, SolanaFloor, and Remora Markets) subsequently shut down permanently. The cause wasn't a reentrancy bug, oracle manipulation, or flash loan attack. It was something far more mundane and far more devastating: compromised executive devices.
This article breaks down what happened, why traditional multisig thinking failed, and provides a concrete operational security (OpSec) framework for Solana teams managing treasury funds in 2026.
What Happened: The Anatomy of the Step Finance Breach
The attack followed a depressingly common pattern in Web3 security — one that smart contract audits simply cannot catch:
- Initial Access: Attackers compromised devices belonging to Step Finance executives, likely through targeted phishing or social engineering
- Key Extraction: With device access, attackers extracted private keys and signing credentials from multiple team members
- Multisig Bypass: Because enough signers' keys were compromised simultaneously, the attackers bypassed the M-of-N multisig threshold
- Fund Drain: 261,854 SOL (~$40M) was unstaked and transferred from treasury and fee wallets
- Partial Recovery: Only ~$4.7M was recovered using Solana's Token-2022 protections — a 12% recovery rate
The Critical Insight
Step Finance had a multisig. They weren't negligent in the traditional sense. But their multisig operated on an implicit (and wrong) assumption: that compromising one device means compromising one key.
When multiple signers store keys on similar devices, use similar security practices, or fall victim to the same phishing campaign, the "multi" in multisig becomes theatrical rather than functional.
Why Smart Contract Audits Won't Save You
The security industry's fixation on smart contract vulnerabilities creates a dangerous blind spot. Consider the 2026 DeFi hack statistics:
- $137M+ lost across DeFi in Q1 2026 alone
- The largest single loss (Step Finance, $40M) was a key compromise, not a code bug
- Multiple other significant losses stem from operational failures, not technical ones
Your Solidity or Rust code can be formally verified, fuzz-tested, and audited by three firms — and you'll still lose everything if an executive's laptop runs malware.
A Practical OpSec Framework for Solana Teams
Based on the Step Finance post-mortem and current best practices from Squads Protocol (the leading Solana multisig solution securing $10B+), here's a concrete framework:
1. Hardware Wallet Isolation (Non-Negotiable)
Every signer in your multisig must use a dedicated hardware wallet (Ledger, Trezor, OneKey). "Dedicated" means:
- The hardware wallet is used only for multisig signing
- It is never connected to a device used for email, browsing, or messaging
- Signing happens on a clean machine or air-gapped device
❌ Bad: Keys on laptop → laptop compromised → keys stolen
✅ Good: Keys on hardware wallet → laptop compromised → attacker still can't sign
2. Geographic and Organizational Distribution
Your M-of-N threshold is meaningless if all signers:
- Work from the same office
- Use the same IT infrastructure
- Are vulnerable to the same social engineering campaign
Minimum standard for treasuries >$1M:
- Signers in at least 2 different physical locations
- At least 1 signer outside the core team (advisory board member, legal counsel)
- No two signers sharing the same email domain for communications
3. Time Locks: Your Emergency Brake
Squads Protocol supports configurable time locks between approval and execution. Use them:
| Wallet Type | Recommended Time Lock |
|---|---|
| Reserve/Treasury | 3600s+ (1 hour) |
| Program Upgrade | 600s+ (10 minutes) |
| Operations/Hot | 300s+ (5 minutes) |
Time locks don't prevent attacks — they give you a window to detect and cancel malicious transactions. Step Finance had no such window.
4. Role Separation with Squads
Squads Protocol provides three distinct roles that should never overlap on a single person:
- Proposer: Can initiate transactions (operations team)
- Voter: Can approve transactions (distributed signers)
- Executor: Can finalize approved transactions (automated or separate party)
This means even if a proposer's device is compromised, they cannot approve their own malicious transaction.
5. Active Monitoring and Alerting
Set up real-time alerts for:
- Any transaction proposed to the multisig
- Large token movements from associated accounts
- Changes to multisig membership or threshold
- Unusual unstaking activity
Tools: Squads' built-in notifications, Helius webhooks, or custom Solana account subscription monitors.
6. Regular Key Rotation
Implement mandatory key rotation:
- Quarterly: Rotate at least one signer
- Immediately: After any team member departure, device loss, or security incident
- Annually: Full rotation of all signers
7. Test Your Recovery Plan
The most overlooked step. Every quarter:
- Test the full signing flow with small amounts
- Simulate a "compromised signer" scenario — can you rotate them out fast enough?
- Verify all backup seed phrases still work
- Confirm your time lock configuration matches policy
The Solana-Specific Angle: Token-2022 as a Safety Net
One silver lining from the Step Finance incident: Solana's Token-2022 (Token Extensions) enabled partial fund recovery (~$4.7M). Token-2022 features relevant to security include:
- Transfer hooks: Custom logic executed on every transfer, enabling compliance checks
- Freeze authority: Ability to freeze compromised token accounts
- Confidential transfers: Reducing information leakage that aids attackers
If your project issues tokens, use Token-2022 instead of the legacy SPL Token program. The security extensions aren't optional anymore — they're table stakes.
Checklist: Is Your Solana Treasury Secure?
Score yourself honestly:
- [ ] All multisig signers use dedicated hardware wallets
- [ ] Signers are geographically distributed (≥2 locations)
- [ ] Time locks enabled on all treasury wallets
- [ ] Proposer/Voter/Executor roles are separated
- [ ] Real-time monitoring and alerting configured
- [ ] Key rotation policy documented and enforced
- [ ] Recovery plan tested in the last 90 days
- [ ] Token-2022 used for project tokens
- [ ] Phishing-resistant 2FA on all signer communications
- [ ] Incident response plan documented and accessible offline
Score: 8-10 = Strong. 5-7 = Needs work. Below 5 = You're one phishing email away from being the next headline.
Conclusion
The Step Finance hack wasn't sophisticated. It didn't require zero-days, MEV manipulation, or novel cryptographic attacks. It required patience, social engineering, and the assumption that busy executives probably have similar security hygiene.
Your multisig is a mathematical construct. Your signers are humans. Secure the humans.
The $40M wasn't lost because of bad code. It was lost because of bad assumptions about what "multi-signature" actually protects against. In 2026, with Squads Protocol, Token-2022, and the hard lessons of the past, there's no excuse for repeating Step Finance's mistakes.
DreamWork Security publishes weekly research on DeFi security, smart contract vulnerabilities, and operational security. Follow us for more.
Top comments (0)