“Not your keys, not your coins” evolved into “Not your API, not your security.” Welcome to 2025.
On Sept 8–9, 2025, SwissBorg’s SOL Earn product was drained for roughly 192.6K SOL (~$41–41.5M) after a partner API, attributed across reports to Kiln, the staking infrastructure vendor, was compromised. SwissBorg says <1% of users and about 2% of platform assets were impacted, and it’s committed to making users whole. Redemptions for SOL Earn were paused while the company engaged white-hats, exchanges, and law enforcement.
This wasn’t a smart-contract bug on Solana. It was something older and meaner: supply-chain/partner-plane compromise. The blast radius was “only” a single program, because a single counterparty wallet/API sat in the middle of the flow.
Who is SwissBorg, and What Exactly Got Hit?
SwissBorg is a Swiss crypto platform that packages yield products (“Earn”) for retail users. SOL Earn outsourced its staking/operations to a third-party provider (reported as Kiln), with SwissBorg interacting through that provider’s API. The external wallet tied to that program is what got siphoned. Core app balances and other assets remained unaffected, per the company.
Numbers recap
- ~192.6K SOL drained (≈$41–41.5M).
- Impact scope: <1% of users; ≈2% of total assets.
- Operational status: SOL Earn redemptions paused; other programs up; treasury covers losses.
The 10,000-ft Timeline (Compressed)
- Partner API compromised: Attackers gain the ability to issue/authorize actions against the counterparty wallet tied to SOL Earn.
- Drains executed: ~193K SOL moved to an attacker-controlled address (now labeled “SwissBorg Exploiter” on Solscan).
- Public disclosure + pause: SwissBorg posts recovery plan, pauses SOL Earn redemptions, commits to user restitution.
- Triage & coordination: Work with white-hats, exchanges, security firms, and LE; some transactions reportedly blocked mid-flight.
Dissection: How Does an “API Breach” Drain Funds?
Let’s translate PR into mechanics. When you outsource staking or wallet ops, you typically rely on a vendor-exposed API to:
- move funds between hot/cold/staking accounts,
- delegate/undelegate, restake, distribute rewards,
- and in some architectures, initiate withdrawals from a vendor-controlled wallet.
If that API (or the vendor’s auth boundary) is compromised, an attacker might gain:
- Transaction origination authority from the vendor’s side (i.e., “withdraw X from wallet Y”).
- Access tokens/keys that your platform trusts by design (service-to-service, not end-user).
- Workflow overrides (e.g., swapping destination/beneficiary addresses).
So the probable exploit path looks like this:
- Identity/Key takeover at vendor → attacker calls legitimate endpoints with valid tokens.
- Authorized but malicious withdrawals from the counterparty wallet that holds program assets.
- Funds hop to attacker wallets across Solana routes; some movement flagged/blocked later by exchanges.
Notice what’s not needed: no breaking SwissBorg’s consumer app, no cracking Solana, no zero-day on-chain. Just ride the trusted integration.
This is why “we weren’t hacked; our partner was” is consolation theater. Your users still bleed.
Why This Happened? (root-cause classes, not hand-waving)
1) Over-privileged integrations
If a partner API can unilaterally initiate withdrawals from a pooled wallet, your blast radius = partner compromise. Principle of Least Privilege died on the conference slide.
2) Weak transaction-level guardrails
Even if the vendor gets hit, well-architected rails can force per-movement policy checks: whitelisted destinations, velocity/amount caps, approvals, on-chain allowlists. If those aren’t enforced at the wallet layer, you’re one compromised token away from a wire-fraud machine.
3) Asymmetric monitoring
API logs at the vendor might scream. Your SOC might be deaf. Without independent anomaly detection on your side (volume spikes from the counterparty wallet, non-whitelist outputs, time-of-day anomalies), you learn from Twitter.
4) Hot-path custody
Yield products keep operational liquidity in hot or warm paths. That’s normal, but when a single vendor steers that path, attackers inherit your convenience.
Impact Analysis
- Funds: ~192.6K SOL out; SwissBorg says treasury will cover any gap and users won’t take losses. Redemptions for SOL Earn paused pending recovery.
- Containment: Work with security partners/LE; some transfers reportedly blocked; Solscan tags help taint tracking.
- Reputational: Even if made whole, this is a counterparty-model indictment. Users didn’t buy “your vendor’s API posture.” They bought your brand’s risk controls. (Ask any CISO how that conversation goes.)
If The Hacker Played It Longer: The Solana Drain Scenario
If the attacker had longer dwell-time and fewer freezes, the max pain route is boring and effective:
- Fan-out extraction
Split the 192.6K SOL across dozens of fresh wallets (reduce single-point freezes). - Mixing patterns
Route through Jupiter swaps into high-liquidity pairs → stablecoin diversification (USDC/USDT) → bridges/CEXes with weak/slow KYC. (Not prescriptive advice, this is why fast labeling/coordination matters.) - Obfuscation via program calls
Interact with popular programs to create activity noise; leverage Compute Budget tricks to frustrate naive heuristics. - Temporal staggering
Night-cycle bursts + weekends; coin-control to avoid clustering.
SwissBorg and partners short-circuited some of that by rapid disclosure + wallet labeling + exchange coordination, the boring, crucial stuff.
What SwissBorg Did Right? (and what’s missing)
✅ Rapid comms & commitment: publicly confirmed, paused SOL Earn, and promised to make users whole.
✅ Scoped the blast radius: emphasized it was an external counterparty wallet, not the core app or other Earn strategies.
✅ Engaged the ecosystem: white-hats, exchanges, LE; some txs blocked.
What we still need (from any serious post-mortem):
- Who held signing power for the counterparty wallet? (Vendor-only? MPC shared? HSM-gated?)
- Per-tx policy: Were destination allowlists/velocity caps enforced at the key layer?
- Vendor auth: What exact API credential model was compromised (token, OAuth client, service account)?
- Detection gap: How long between first malicious call and pause?
CoinDesk says a full incident report is coming. It needs to answer those, not just promise better days.
How This Could Have Been Prevented? (real controls, not platitudes)
Architecture
- MPC with dual-org quorum: Vendor can propose but not unilaterally sign withdrawals. Requires your co-signature and policy to execute.
- On-key policy engines: Enforce allowlists, amount ceilings, per-interval velocity, and time-based rules at the signer/HSM/MPC layer, not just in app code.
- Partitioned treasuries: Segregate Earn program funds into multiple shards with independent limits. One API token ≠ drain the whole pool.
Integration
- Short-lived, scoped API credentials with mutual TLS and IP pinning; rotate aggressively.
- Event-sourced approvals: Vendor calls open a pending request; your system approves via an out-of-band channel with human-in-the-loop for atypical routes/amounts.
- Independent telemetry: Your SIEM watches the counterparty wallet addresses as if they were your own validators, with anomaly scoring and paging.
Operations
- Kill-switches: Pre-wired ability to nuke vendor connectivity (network ACLs + credential revocation) and halt signing on policy breach.
Runbooks with named contacts at vendors and major CEXes; pre-signed legal templates for freeze requests. - Continuous crisis drills: Practice the “partner drained us” scenario quarterly. Measure MTTD/MTTR like your runway depends on it… because it does.
For Other Exchanges/Earn Platforms: Steal This Checklist
Before launch
- Counterparty threat model published: who signs, where, under what policy.
- Destination allowlist enforced at the key.
- Quorum: 2-of-N with at least one key under your direct, segregated control.
- Withdrawal controls: velocity caps, business-hour constraints, burst limits.
- Key ceremonies documented; HSM/MPC vendor audited.
During operations
- Real-time wallet analytics for the counterparty accounts.
- Shadow route: simulate every vendor-initiated withdrawal and diff against expected policy before signing.
- Vendor credential hygiene: rotate, scope, mTLS, IP pinning, and alerting on any new client fingerprints.
- Drill: quarterly partner-breach chaos test with exchanges on bridge/freeze speed.
When it hits the fan
- Immediate comms with amounts, addresses, tags (Solscan/Etherscan labels).
- Pause affected product, not the whole shop, unless contamination suspected.
- Publish IOCs + paths for the community to help block exits.
- Commit restitution if you marketed custody-like safety. Users didn’t pick your vendor, you did.
The Harsh Truth: Convenience Scales Risk Faster Than Yield
Crypto loves decentralization until it needs yield, then quietly centralizes around custodial pipes and vendor APIs. That’s not evil, but pretending it’s “DeFi” is how you sleepwalk into losses like this. The attacker didn’t innovate; they borrowed your trust boundary and cashed it out.
“In a bull market, convenience scales. In a bear market, risk scales.” Pick which one you’re architecting for.
Closing: What Should Readers Take Away?
- This wasn’t a Solana problem. It was a counterparty and key-policy problem.
- SwissBorg’s response (pause, disclose, reimburse) is the minimum viable grown-up move. Now ship the root-cause detail and hard policy changes.
- If you run an Earn product, your real security is the set of rules enforced where signatures are made, not in a PDF, not in your app server, and definitely not in someone else’s unaudited API gateway.
If your vendor can drain you, your vendor will eventually drain you… by accident, design, or compromise. But nothing to get scared about because Resonance Security can take care of your smart contracts as well as your API, cloud infrastructure, and everything else where a hacker can break in. Book a FREE consult and let’s find out your loopholes before a hacker does.
.png)