The “inEVM” roll-up via @arbitrum Orbit In May 2024, @injective announced a collaboration with Arbitrum Nitro/Orbit to build an EVM-compatible roll-up called inEVM, enabling Ethereum, Cosmos, Solana interoperability The announcement stated: “By customizing Arbitrum’s unique Orbit stack, Injective’s inEVM is now even more bespoke…” The aim was: allow Ethereum-style contracts to deploy, benefit from Injective’s speed/IBC/Cosmos modules, while using Orbit’s infrastructure So in this phase: inEVM = an Orbit-based EVM roll-up built in partnership 🧵👇 (1/4)

The shift to a native EVM layer on Injective’s main chain Later, on Jan 29 2025, Injective announced the launch of a native EVM layer embedded directly into its L1 chain (Cosmos/Tendermint-based) rather than relying on an external roll-up. On July 2 2025, the native EVM testnet went live, enabling Ethereum-compatible apps directly on Injective L1 The key difference: This architecture is built “solely on Injective’s infrastructure” instead of an external roll-up. They’re pursuing a Multi-VM strategy: EVM and WASM on one unified chain (2/4)

Why this matters & how to think of it Stage 1 (@arbitrum Orbit‐Rollup): provided a quick path to an EVM-compatible environment using Arbitrum tech Stage 2 (Native EVM): represents the strategic end-state: full EVM compatibility built into Injective’s architecture for better cohesion and performance Importantly: you’re not wrong, both phases exist. It’s just that the roll-up (inEVM) via Orbit was the earlier or parallel approach; then they shifted (or added) the native EVM layer (3/4)

This @injective EVM originally “came from” @arbitrum Orbit. But today, the strategic core is their own native EVM embedded into the L1, with Orbit as an earlier phase (and possibly still used for some app-specific chains) (4/4)