Worked example · 2025-09
SwissBorg SOL-Earn third-party-API supply-chain compromise — Solana — 2025-09-08
Summary
SwissBorg is a Switzerland-based crypto investment / wealth-management platform serving retail users with staking, yield-earning, and asset-management products. The platform's SOL Earn program offered users a staking-backed yield product on Solana SOL tokens, with the underlying staking infrastructure operated by Kiln as a third-party staking-API provider. Kiln operates similar staking-infrastructure services for multiple platform-and-protocol customers across the broader DeFi / CeFi ecosystem.
On 2025-09-08, an attacker exploited a compromised third-party API at Kiln to execute an unstaking transaction against SwissBorg's SOL Earn program that drained approximately 192,600-193,000 SOL tokens (~$41M at the spot price). Per the SwissBorg post-incident statement and the corroborating Halborn post-mortem, the attacker had submitted eight authorisation instructions concealed within a standard unstaking transaction several days before the actual extraction, designed to transfer control over several of the platform's staking accounts from SwissBorg to attacker-controlled on-chain accounts. When the actual unstaking occurred, the previously-injected authorisation instructions activated and the staking account control was transferred, with the SOL drained to attacker-controlled addresses.
SwissBorg's response chain ran rapidly within hours of detection. The platform engaged with white-hat hackers, blockchain investigators, and ecosystem partners including Fireblocks (custody / institutional-asset-management infrastructure) and the Solana Foundation (chain-level coordination authority on Solana). Transactions linked to the exploit were blocked on multiple exchanges before they could be cashed out, materially limiting attacker-side liquidity realisation. Affected users were compensated from the SwissBorg treasury under operator-side reimbursement, producing a near-100% user-side recovery.
For OAK's purposes the case is a clean OAK-T11.001 third-party-staking-API supply-chain extraction with on-chain T9.004 multi-instruction-delayed-trigger as the extraction mechanism. The novel OAK contributions are: (a) documenting the third-party-staking-API sub-vector of OAK-T11.001 as distinct from the custody-vendor (WazirX), wallet-software-vendor (DMM Bitcoin), and developer-laptop (Radiant Capital) sub-vectors; (b) capturing the delayed-trigger malicious-instruction-injection pattern as an on-chain extraction sub-pattern with operational distinctiveness from same-transaction direct-call patterns; and (c) capturing the multi-actor cross-venue-coordinated blocking as a recovery primitive that produces partial recovery via attacker-side-liquidity-realisation friction rather than via on-chain unwinding.
Timeline (UTC)
| When | Event | OAK ref |
|---|---|---|
| Pre-event | SwissBorg deploys SOL Earn program on Solana with Kiln as third-party staking-API provider; Kiln's API surface is integrated with SwissBorg's user-side staking-account management | (T11.001 surface — third-party-staking-API integration) |
| Pre-event | Attacker compromises Kiln's API surface via undisclosed off-chain means; precise compromise vector not exhaustively detailed in the public record | T11.001 surface (broadly construed) |
| Pre-event (several days before extraction) | Attacker submits eight authorisation instructions concealed within a standard-appearing unstaking transaction, designed to transfer staking-account control from SwissBorg to attacker-controlled on-chain accounts on subsequent activation | (delayed-trigger malicious-instruction-injection setup) |
| 2025-09-08 (attack window) | Attacker activates the previously-injected authorisation instructions; staking-account control transferred to attacker-controlled accounts; |
T11.001 + T9.004 extraction |
| 2025-09-08 (within hours) | SwissBorg detects anomalous staking-account state; pauses affected program functionality; engages white-hat hackers and blockchain investigators | (operator response) |
| 2025-09-08 onward | SwissBorg coordinates with Fireblocks (custody / institutional-asset-management partner) and the Solana Foundation (chain-level authority); cross-venue blocking of attacker-linked transactions on multiple exchanges | (white-hat-coordinated cross-venue blocking) |
| 2025-09-08 / 2025-09-09 | SwissBorg publishes public acknowledgement; identifies Kiln third-party API breach as the entry vector; commits to user-side full reimbursement from SwissBorg treasury | (operator response / transparency) |
| 2025-09 onward | Industry detection chain: Halborn publishes defender-oriented post-mortem; PeckShield issues cumulative-loss aggregation; SlowMist attaches funding-source tracking; Cyvers corroborates the multi-instruction delayed-trigger pattern | (multi-investigator coverage) |
| 2025-09 onward | User-side reimbursement from SwissBorg treasury proceeds in stages; near-100% user-side recovery achieved | (operator-team reimbursement recovery primitive) |
| 2025-09 onward | Kiln publishes its own incident-response statements covering the third-party API surface compromise and remediation steps | (vendor-side response) |
| Continuing | Pseudonymous attribution; no civil-forfeiture action; no named-individual claim; no public OAK-G01 cluster correlation as of v0.1 | (recovery state) |
What defenders observed
- The third-party-staking-API supply-chain surface is operationally distinct from the third-party-custody and third-party-wallet-software surfaces. Kiln operates a staking-API service that integrates with multiple platform-and-protocol customers across DeFi / CeFi; the surface's structural property is that the API-provider holds operational authority to construct staking transactions on behalf of customer platforms. Compromise of the API surface produces transactions that customer platforms execute as if legitimate — analogous to but operationally distinct from custody-vendor compromise (where the vendor holds key authority directly) and wallet-software-vendor compromise (where the vendor produces signed transactions via compromised software). Defender / Mitigations-layer practice should treat staking-API providers as a discrete fourth third-party-vendor sub-vector under OAK-T11.001, with cohort-level monitoring of the staking-infrastructure-provider category (Kiln, Figment, Stakefish, Allnodes, P2P, Chorus One, etc.).
- The delayed-trigger malicious-instruction-injection is an operationally-distinctive on-chain pattern. The attacker submitted eight authorisation instructions concealed within a standard-appearing unstaking transaction several days before the actual extraction; the malicious instructions activated only on subsequent unstaking events. Defender / on-chain-monitoring practice for staking-account-control surfaces should include detection of (a) authorisation-instruction state divergence between current and prior transaction states, (b) staking-account ownership changes outside of expected upgrade / migration windows, and (c) anomalous instruction patterns within otherwise-standard unstaking flows. The Solana account-model architecture makes this category of analysis structurally feasible; the defender / Mitigations-layer lesson is that the analysis is not yet uniformly deployed across staking platforms.
- The multi-actor cross-venue-coordinated blocking is a working partial-recovery primitive. SwissBorg's coordination with Fireblocks and the Solana Foundation produced cross-venue transaction blocking on multiple exchanges before the attacker could cash out. The blocked transactions did not unwind on-chain extraction but did limit attacker-side liquidity realisation. Defender / Mitigations-layer practice should treat cross-venue-coordinated blocking as a real partial-recovery primitive — the realised recovery rate sits in the partial-recovery band (consistent with the Loopscale April 2025 ~50% partial-recovery profile) rather than near-full-recovery — with operator-team reimbursement from reserves filling the user-side gap.
- The detection chain combined operator-side rapid response with multi-investigator forensic coverage. Halborn, PeckShield, SlowMist, and Cyvers all published post-incident analyses within the first week, with substantially-converging root-cause attribution to the Kiln third-party API breach and the multi-instruction delayed-trigger pattern. The breadth of coverage reflects (a) the loss size ($41M), (b) the platform's CeFi / institutional reputation, and (c) the operational maturity of the 2025 forensic-provider ecosystem. Defender / operator-response practice should expect this multi-investigator coverage as the realistic 2025 baseline for $30M+ CeFi / Solana incidents.
- Operator-team reimbursement from treasury is a 2025 mature recovery class. SwissBorg's full user-side reimbursement is consistent with the DeltaPrime September 2024 (DeFi-protocol-side,
full reimbursement), Banana Gun September 2024 ($3M, full reimbursement), and GMX V1 July 2025 LP make-whole patterns. The recovery class is now well-documented across the 2024-2025 corpus and should be tracked explicitly in recovery-section content.
What this example tells contributors writing future Technique pages
- OAK-T11.001 covers the third-party-staking-API supply-chain sub-vector. SwissBorg September 2025 is the canonical 2025 worked example. The sub-vector is operationally distinct from custody-vendor (WazirX July 2024 / Liminal), wallet-software-vendor (DMM Bitcoin May 2024 / Ginco), and developer-laptop (Radiant Capital October 2024). The four principal sub-vectors of OAK-T11.001 are now: (a) third-party-custody-vendor, (b) third-party-wallet-software-vendor, (c) developer-laptop, and (d) third-party-staking-API-vendor (SwissBorg 2025).
- The delayed-trigger malicious-instruction-injection is a Solana-specific extraction sub-pattern that should be flagged in future Solana / Move-ecosystem worked examples. The pattern leverages Solana's account-model architecture and the multi-instruction-per-transaction primitive. Contributors writing future Solana-ecosystem worked examples (alongside the Loopscale April 2025 case at
/examples/2025-04-loopscale.md) should make the account-model-specific extraction sub-patterns explicit. - Multi-actor cross-venue-coordinated blocking is a sixth recovery primitive that should be tracked explicitly. Contributors writing recovery-section content should now distinguish: (a) on-chain protocol-coordinated recovery (Cetus 2025), (b) attacker-return-of-funds via bounty negotiation (KiloEx, ZKsync, GMX V1, Tapioca, Thala, Munchables), (c) operator-team reimbursement from reserves (DeltaPrime, Banana Gun, GMX V1, SwissBorg 2025), (d) validator-coordinated transaction-censorship freeze (Sui / Aptos), (e) validator-coordinated rollback / hard fork (Balancer V2 / Gnosis Chain), (f) attacker-side-phishing-accident recovery (UXLINK 2025), and (g) multi-actor cross-venue-coordinated blocking (SwissBorg 2025). The seventh class is operationally meaningful and is becoming a recognisable 2025 pattern for CeFi / institutional incidents.
- Solana / non-EVM-L1 coverage of OAK-T11.001 should expand alongside DeFi-native coverage. The corpus's OAK-T11.001 coverage through 2024 was substantially EVM-centric (DMM Bitcoin, WazirX, Radiant Capital, Bybit are all EVM-mainnet-or-Bitcoin-side cases). The SwissBorg case adds the Solana-side worked example, complementing the Loopscale April 2025 case at
/examples/2025-04-loopscale.mdas the second 2025 Solana worked example in the corpus. pseudonymous-with-OAK-G01-suspicionis a hybrid attribution status that should not be conflated withinferred-strongOAK-G01 attribution. The SwissBorg attribution is circumstantial — based on sector-targeting (vendor-side staking-API breach is structurally analogous to OAK-G01 cohort patterns) — without forensically-anchored cluster correlation. Contributors writing attribution-section content should preserve the distinction between (a) circumstantial OAK-G01 suspicion (SwissBorg, Balancer V2), (b) inferred-strong OAK-G01 attribution via forensic-provider-led wallet-cluster correlation (DMM Bitcoin, with Mandiant / Chainalysis), and (c) confirmed-via-FBI / Treasury / Mandiant public-record attribution (Radiant Capital).
Public references
[swissborgpostmortem2025]— SwissBorg operator-side public statement covering the September 2025 SOL Earn breach, the Kiln third-party API breach attribution, and the user-side reimbursement framework.[halbornswissborg2025]— Halborn defender-oriented post-mortem of the SwissBorg September 2025 hack, including the multi-instruction delayed-trigger pattern analysis.[swissborgsolrecovery2025]— SwissBorg follow-up statement on the SOL Earn incident recovery, including the Fireblocks / Solana Foundation coordination and the cross-venue-blocking outcome.[unchainedswissborg2025]— Unchained Crypto reporting on the $41M SOL Earn drain.[crowdfundinsiderswissborg2025]— Crowdfund Insider reporting on the SwissBorg $41M Solana theft including the third-party-vendor-attribution framing.[cointribuneswissborg2025]— Cointribune reporting on SwissBorg's confirmation of the Kiln third-party-vendor breach.[quillauditsswissborg2025]— QuillAudits analytical breakdown of the SwissBorg $41M exploit including the multi-instruction-delayed-trigger pattern.[cryptovalleyswissborg2025]— Crypto Valley Journal reporting on the SwissBorg incident and Swiss-jurisdiction implications.
Citations
[swissborgpostmortem2025]— SwissBorg operator-side public statement; primary source for the Kiln third-party API breach attribution and user-side reimbursement framework.[halbornswissborg2025]— Halborn defender-oriented post-mortem; primary technical source for the multi-instruction delayed-trigger pattern analysis.[swissborgsolrecovery2025]— SwissBorg recovery follow-up; primary source for the Fireblocks / Solana Foundation coordination and cross-venue-blocking outcome.[unchainedswissborg2025]— Unchained Crypto; secondary source for the cumulative-loss figure.[crowdfundinsiderswissborg2025]— Crowdfund Insider; secondary source for the third-party-vendor-attribution framing.[cointribuneswissborg2025]— Cointribune; secondary source for the Kiln-breach confirmation.[quillauditsswissborg2025]— QuillAudits; primary technical source for the multi-instruction-delayed-trigger pattern walkthrough.[cryptovalleyswissborg2025]— Crypto Valley Journal; secondary source for the Swiss-jurisdiction context.
Discussion
SwissBorg September 2025 is OAK's canonical case for the third-party-staking-API supply-chain sub-vector of OAK-T11.001 and for the multi-actor cross-venue-coordinated blocking recovery primitive. The case is the second-largest single September 2025 DeFi / CeFi incident (after UXLINK at ~$44M) and is the H2 2025 worked-example anchor for the staking-infrastructure-provider category, which has been thinly represented in the OAK corpus through 2024.
The structural lesson sits at three levels. First, at the vendor-category level: the OAK-T11.001 surface is now visible across four principal vendor categories — third-party-custody (Liminal / WazirX), third-party-wallet-software (Ginco / DMM Bitcoin), developer-laptop (Radiant Capital), and third-party-staking-API (Kiln / SwissBorg 2025). Defender / Mitigations-layer practice should now treat vendor-category-cohort-monitoring as a first-class operational discipline that spans all four categories. Second, at the on-chain-extraction-pattern level: the multi-instruction delayed-trigger pattern leverages Solana's account-model architecture in ways that are operationally distinct from same-transaction direct-call patterns; defender / on-chain-monitoring practice for staking-account-control surfaces should now explicitly cover delayed-trigger detection. Third, at the recovery-primitive level: multi-actor cross-venue-coordinated blocking, combined with operator-team reimbursement from treasury, produces a hybrid recovery profile that delivers near-100% user-side outcome with partial on-chain recovery and operator-treasury-cost residual.
The detection chain — Halborn, PeckShield, SlowMist, Cyvers — represents the realistic 2025 baseline for $30M+ CeFi / Solana incidents and is comparable in coverage breadth to the Balancer V2 November 2025 case (~8+ providers within 48 hours). Contributors writing future detection-chain sections for 2025 incidents at this scale should expect 4-8 independent forensic providers publishing within a week.
The attribution status pseudonymous-with-OAK-G01-suspicion is a hybrid status that requires careful framing. The vendor-side staking-API breach pattern shares structural features with the OAK-G01 / Lazarus-aligned 2024-2025 wave (DMM Bitcoin, WazirX, Radiant Capital, Bybit), but no public technical indicator anchors the attribution to a specific OAK-G01 cluster as of OAK v0.1. Contributors writing future attribution updates should monitor for forensic-provider-led wallet-cluster correlation that may move the attribution status; the Mandiant / Chainalysis-style on-device-or-cluster-correlation evidence that anchored Radiant Capital is the threshold for an upgrade to inferred-strong OAK-G01 attribution, and is not yet publicly available for the SwissBorg case.
For OAK's broader credibility, including SwissBorg in v0.1 closes three structural gaps: it adds a second September 2025 H2 worked-example anchor (alongside UXLINK), it documents the third-party-staking-API supply-chain sub-vector of OAK-T11.001 with a 2025 case, and it establishes the staking-infrastructure-provider category (Kiln, Figment, Stakefish, etc.) as a discrete OAK target-surface category alongside the long-documented custody-vendor and wallet-software-vendor categories.