Stratos (stratos-1) Exploit and Chain Halt: Post-Mortem

As of 2026-10-14. All figures read on-chain with stchaind against public stratos-1 RPC nodes, and with Ethereum JSON-RPC for the bridge side.

Summary

An attacker stole 83,616,206 STOS from stratos-1 in two drains through an unauthenticated EVM precompile. Then they halted the chain themselves. They bonded 13.5M STOS to a validator that had been abandoned and jailed since 2023, and forged its unjail. That validator now holds 66.18% of voting power with no node behind it, so the remaining 33.82% can never reach the 2/3 quorum. The last block is 16,008,475 (2026-10-13 05:21:19 UTC).

• Drain 1, block 15,986,214: 50,616,206 STOS from 11 accounts in one transaction.
• Drain 2, block 16,008,276: 32,999,999 STOS from the WSTOS bridge contract's reserve.
• Exits: 40M STOS went to Osmosis over IBC (10M came back). 40M was deposited into the WSTOS bridge, minted as STOS tokens on Ethereum, and sold on Uniswap within minutes for only about 2.9 ETH.
• Halt: 13,516,254 STOS bonded to the hijacked validator jxd02. It stays frozen on stratos-1.

No private keys were stolen. The chain executed messages in other accounts' names without checking ownership.

Timeline

All times UTC. Stratos blocks unless marked ETH.

Root cause

The address 0x0000000000000000000077656233636f736d6f73 (its bytes spell "web3cosmos" in ASCII) is a Stratos-specific feature added in v0.12.0 (stratos-chain, x/evm/types/msg_cosmos.go). An Ethereum-style transaction sent to it carries a Cosmos message, which the chain then executes as the account named inside that message.

The code does contain an ownership check. MsgCosmosData.ValidateBasic rejects the message unless its signer equals the Ethereum transaction's sender. That check is wired up in only two places, and both can be bypassed:

1. The ante handler (app/ante/eth.go, EthTxCosmosMsgVerifierDecorator) is the gatekeeper that inspects a transaction before execution. It only looks at the transaction's top-level message.
2. The execution path (x/evm/keeper/state_transition.go, RunSdkMsgFn) repeats the check only in simulation (if simulate { … }). Real execution relies on the ante handler having done it.

The authz module is enabled on stratos-1, and nothing on the chain blocks a MsgEthereumTx from being wrapped inside an authz MsgExec. Wrapped that way, the Ethereum transaction is no longer the top-level message, so the ante check never runs, and execution skips the check as designed. The message then runs as whichever account it names. Bank sends, staking, slashing and any other message type can be forged this way.

Timeline in the code: the feature was added in March 2024, released in v0.12.0 (tagged 2024-05-24) and activated on-chain by the v012 upgrade at block 3,543,000 (2024-05-28). It stayed exploitable for about 2 years and 4 months, until the first drain on 2026-10-11.

On-chain evidence:

• Every attack transaction is an authz MsgExec wrapping a MsgEthereumTx to the precompile, and the calldata decodes to a Cosmos message. None of the accounts named as senders ever granted the attacker anything.
• One signature moved 11 accounts' funds. The drain-1 transaction carries a single signer, the operator st13v7q…, yet it sent STOS out of 11 different accounts.
• The WSTOS bridge is a smart contract (an EthAccount with a code_hash). No private key exists for it, yet a MsgSend with it as the sender went through.
• The jxd02 operator account st1qr0t2…nzrgl5 has sequence 1. Its only transaction ever is its 2023 create-validator, yet a MsgUnjail in its name went through at block 16,008,474.

The fix: enforce the signer check in the execution path itself, not only in the ante handler. Also block MsgEthereumTx inside authz MsgExec with an authz-limiter ante decorator, as other Ethermint-based chains do, and accept only an allowlist of message types. Security checks that live only in the ante handler, and that authz nesting can therefore skip, are a known pitfall on Ethermint-based chains. The August 2026 incidents on MANTRA, KiiChain and TAC were a different bug: an accounting underflow in the standard Cosmos EVM staking precompile.

Impact and fund flows

Victims

The attacker left each drain-1 victim exactly 1 STOS. Most drain-1 wallets were not individual community holders. They were part of the team's split of the migrated ~70M into multiple wallets.

Drain 1 therefore mostly hit project-structured funds. Drain 2 hit the bridge reserve, which backs users' bridged tokens.

Collector ledger (st12lsj78… / 0x57e12f…)

The collector's flows reconcile to its current balance to within about 25 STOS of fees.

Ethereum cash-out

The bridge contract on Ethereum (0xa04b06ee86130c471d0c275403ad5516d7fff91e) minted all four 10M deposits as STOS ERC-20 tokens (0x08c32b0726c5684024ea6e141c50ade9690bbdcc) to the attacker's address. The first sale emptied the STOS liquidity on Uniswap:

The total is about 2.88 ETH, roughly $7,200 at Etherscan's displayed ETH price. The attacker's Ethereum address now holds 0 STOS. Where the ETH went afterwards has not been traced. First mint: 0x162473ed….

Supply and bridge backing

STOS started as a 100M ERC-20 on Ethereum. stratos-1 launched on 2023-09-08 with all 100M STOS created natively in genesis, and native supply is still exactly 100,000,000 STOS with 0% inflation. The attack moved existing STOS and created none on stratos-1.

• Genesis account st1fm94… (68.93M) paid out 69.88M STOS through an EVM contract during 2023. That is the migration of about 70M tokens from Ethereum.
• Genesis account st12dwj… (27.54M) seeded the WSTOS bridge reserve with 7.54M.

Each STOS token on Ethereum should be backed by native STOS locked on stratos-1. Normal bridge use moves tokens and reserve together, so the gap between Ethereum supply and the bridge reserve stays fixed:

The attack added 40M tokens on Ethereum but only 7M net to the reserve (33M stolen, 40M deposited). About 3M of the pre-attack gap is unexplained.

Halt mechanism

The attacker turned a dormant validator into a 66.18% holder of voting power with no node behind it. Blocks need signatures from more than 2/3 of voting power, so block 16,008,476 can never be finalized. More than 1/3 is enough to halt a chain. With 66.18%, the attacker is far past that, though just short of the 2/3 needed to produce blocks alone.

Steps:

1. jxd02 was jailed, so the 13.5M delegation at block 16,008,373 changed nothing in consensus.
2. The forged unjail at block 16,008,474 emitted a validator update.
3. CometBFT locked the new set into block 16,008,475's header (next_validators_hash).
4. The network itself was healthy: 5 of the 8 old validators signed that last block.

The chain cannot be fixed on-chain, even with a patched binary. Every node checks signatures for block 16,008,476 against the locked set, and jxd02 never signs. Removing jxd02 would itself need a block.

About jxd02

jxd02 (stvaloper1qr0t2pcut8etqf4k7qlnclyf9zjn5yt7yw2grl) was not created by the attacker. It was one of ten throwaway validators, jxd01 to jxd10:

• All ten operator accounts were funded with ~1.04 STOS each at block 92,200 (2023-09-28) by st1f22ldwfn8ekhze2vynqduuk4fwjf8j7pnu43dk. That account was itself funded by st10jnx5v… (10.5 STOS) and st18kj0uux… (1 STOS).
• jxd02 was created at block 105,377 (2023-09-29) with a 1 STOS self-bond, 5% commission and an empty description. It was jailed for downtime within a day (jailed_until 2023-10-01).
• jxd01 and jxd03 to jxd10 are still jailed and unbonded with about 1 STOS each.
• No link was found between the 2023 jxd funding accounts and the attacker's accounts.

A validator's IP address is not recorded on-chain, and no live peer announces a jxd moniker. Whoever holds jxd02's 2023 consensus key could restart the chain by running a node with it, and the exploit would still be live.

Attacker cluster

Drain 2 and the unjail used the collector itself as the MsgExec grantee. Drain 1 used the operator account, which the collector had funded and granted one block earlier.

What a restart would take

The Stratos core team is no longer active, so any restart would have to be led by the validators and the community.

1. Patch the binary (currently stchain v0.12.1) to disable the web3cosmos precompile entirely.
2. Export state at height 16,008,475 (stchaind export --height 16008475).
3. Edit the genesis:
   • Remove jxd02 from the validator set (jail or tombstone it).
   • Freeze the attacker's 13.5M delegation and the collector's balance.
   • Keep chain-id stratos-1 with initial_height 16,008,476.
4. Verify and start: every validator reproduces the same genesis hash, then all start together.

Other issues:

• IBC: Osmosis's light client for Stratos will expire after its trusting period. Reviving it needs an Osmosis governance proposal.
• The bridge: it likely depended on the former team's relayer.
• Ethereum STOS holders: the reserve now backs far fewer of the tokens.
• Validators: until a coordinated restart, do not run unofficial builds or unjail.