Native EVM went live on mainnet on Nov 11, 2025. Its point of difference is that a Solidity contract can call Injective's native modules, an on-chain order book, oracle, bank, and RWA logic, directly through precompiles at fixed addresses. That opened the whole Solidity developer population to a finance chain, and the surrounding RPC, indexer, wallet, and oracle infra has not caught up. This page is my read of the mechanism, the exact integration surface, the competitive map, and what I would build first to turn that opening into shipped integrations.
Injective is a Cosmos-SDK L1 built for finance, with the order book, oracle, auction, bank, and RWA logic as native chain modules written in Go. On Nov 11, 2025 it added a native EVM, and those modules are exposed to Solidity as precompiles at fixed addresses, so an Ethereum team can deploy with Foundry or Hardhat and call the on-chain order book from a contract. That is a large top-of-funnel expansion and also a set of gaps: the public EVM RPC is a shared endpoint not meant for production, EVM event indexing is thin, oracle-in-Solidity examples are sparse, and the precompile composition path (the reason to pick Injective over a plain EVM chain) is underdocumented. A Growth / Integration Engineer converts the new developers by closing those gaps: template repos, RPC and indexer wiring, oracle samples on the precompile, and a clean path from a stock Ethereum dApp to one that uses the exchange and RWA modules.
My fit, stated plainly: I come in strong on JavaScript and Python, EVM tooling, integration ownership, and developer support, which is most of this surface. Go, Rust, and CosmWasm I ramp on the job, paired with the SDK team, and I prove the ramp with a shipped sample early rather than claiming the seat.
injective-1)Injective is an application-specific L1 built with the Cosmos SDK and CometBFT proof-of-stake, live since 2021, incubated by Binance and backed by Pantera, Jump Crypto, and Mark Cuban. What sets it apart is that finance primitives are native chain modules, not app-level contracts: a fully on-chain central limit order book (the exchange module), a native oracle module, a weekly burn auction, and an RWA and permissions module behind iAssets (tokenized equities, and pre-IPO perpetuals for OpenAI, SpaceX, and Anthropic launched Oct 1, 2025). CosmWasm contracts have been live since 2022; the native EVM added in November 2025 runs over the same state and liquidity, and reaches those Go modules through precompiles. So the developer surface widened from Rust and CosmWasm to include all of Solidity and standard Ethereum tooling.
The block-time figure is Injective's published number and moves over time; I keep the qualifier rather than presenting a marketed figure as observed. The RWA figure is cumulative RWA-perpetual volume as reported by Messari in late 2025.
The mechanism matters, and it is often described loosely. Injective's order book, oracle, and bank logic are Go Cosmos-SDK modules, not smart contracts. The native EVM exposes them to Solidity as precompiles: system contracts at fixed addresses that a contract calls like any other. That is different from an EVM contract calling a CosmWasm (WASM) contract, which is the other, separate interop path.
// viem, Injective EVM mainnet import { defineChain } from 'viem' export const injective = defineChain({ id: 1776, name: 'Injective', nativeCurrency: { name: 'Injective', symbol: 'INJ', decimals: 18 }, rpcUrls: { default: { http: ['https://sentry.evm-rpc.injective.network'] } }, blockExplorers: { default: { name: 'Blockscout', url: 'https://blockscout.injective.network' } }, })
// the exchange module, exposed as a precompile address constant EXCHANGE = 0x0000000000000000000000000000000000000065; // interface mirrors the documented Exchange.sol interface IExchange { function createDerivativeLimitOrder(/* order */) external returns (bytes32 orderHash); } // a plain Solidity dApp placing a native order IExchange(EXCHANGE).createDerivativeLimitOrder(order);
On a plain EVM chain an integrator wires a dApp to pools and generic infra. On Injective the higher-value integration is teaching an EVM contract to compose with the native order book, oracle, and RWA modules through the precompiles, and to pair a bank-module denom with its ERC-20 view. That surface is the newest, the thinnest on docs, and the hardest for another chain to copy. It is also the reason a Solidity team picks Injective over cheaper blockspace, which makes it the integration story worth getting right, once I have ramped enough to write the reference contract with the SDK team.
The JD lists the exact components: JSON-RPC providers, indexers, wallets, bridges, storage, analytics, and applications. Here is that surface on Injective today, what exists, and the gap in each row that an integration engineer closes.
| Surface | What exists today | The gap I would work on |
|---|---|---|
| JSON-RPC | Public sentry RPC at sentry.evm-rpc.injective.network, plus QuickNode and thirdweb | The public endpoint is shared and best-effort, not for production load, so builders hit throttling silently. A clear "which RPC, when" reference and a client with retry and failover shared |
| Indexers / data | Injective's own Exchange API (gRPC and REST) is the real source for order book and market data; Blockscout API covers EVM logs | The EVM event-indexing story (subgraph-style) is thin post-launch. Document when to use the Exchange API vs EVM-log indexing, and confirm a Graph or Goldsky path thin |
| Wallets | Keplr, Leap, Ledger, Cosmostation; MetaMask and any EVM wallet since the EVM launch | The 0x address and its Cosmos bech32 form derive deterministically from the same key; new EVM users still find it confusing. A mapping guide plus wallet-strategy sample code |
| Bridges | Peggy (native Ethereum bridge), IBC (Cosmos), Wormhole (broad messaging) | Making a bridged asset usable identically in EVM and WASM: the bank-module denom surfaced as an ERC-20 through the bank precompile, no wrapper step |
| Oracles | Pyth, Chainlink Data Streams, API3, reachable by the oracle module and, from Solidity, an oracle precompile | Solidity-side usage examples are sparse; builders need copy-paste price-feed patterns per provider on top of the oracle precompile sparse |
| SDK / tooling | injective-ts, plus Python and Go SDKs; Hardhat and Foundry work unmodified; Exchange.sol interfaces for the precompiles | Two doc sets (protocol vs TS) and an EVM era that outpaced them; quickstart templates and freshness are the gap |
| Explorers / analytics | Blockscout (EVM), injscan (EVM and Cosmos) | A single "where do I look" answer and a clean verification flow for builders spanning both environments |
Every row has a concrete gap that maps to a shippable artifact. That is the job: not abstract growth, but wiring each row into a path a developer can follow without a support ticket, then removing the ticket that remains.
Injective competes for the same DeFi and derivatives developers as a handful of L1s. Knowing the differentiation, at the mechanism level, is how you pitch a builder on why to integrate here.
| Competitor | What it is | Where Injective differs |
|---|---|---|
| Hyperliquid vol leader | Perp DEX on a custom HyperBFT L1, with HyperEVM alongside HyperCore | The closest architectural rival: HyperEVM also lets Solidity reach a native order book, via HyperCore read precompiles and the CoreWriter system contract (0x3333…3333). It leads perp volume (a plurality after a late-2025 Aster challenge) and dominates open interest. Injective's edge is breadth: spot, derivatives, an RWA and permissions module, IBC, and general CosmWasm, not a perps-centric core. |
| dYdX v4 | Cosmos-SDK perp appchain | Its order book lives off-chain in validator memory; only fills settle on-chain. Injective's order book is fully on-chain, and it spans spot, perps, RWA, and general contracts, not perps only. |
| Sei | Parallelized EVM L1 (Cosmos-based) | Competes on raw EVM speed and parallelization. Injective competes on finance-native modules reachable from Solidity, which a fast general EVM does not have. |
| Solana | High-throughput monolithic L1 | Huge liquidity and developer base; order books via apps (Phoenix, Drift). Injective is adding SVM to court that same population onto a shared-liquidity finance chain. |
| Aptos / Sui | Move-based high-performance L1s | General L1s courting DeFi and RWA on a different VM (Move), without a native on-chain order book exposed to contracts. |
| Base / Arbitrum | General-purpose Ethereum L2s | The default home for a Solidity team. Injective's counter is composing with native finance and RWA modules, not just cheaper blockspace. |
Injective's honest position: not the highest perp volume (Hyperliquid leads that), and not the only chain exposing a native order book to Solidity (HyperEVM does too). Its distinctive combination is an on-chain order book plus a native oracle, an RWA and permissions module with tokenized equities, IBC, and general CosmWasm, all reachable from one EVM environment. The integration job is to make that combination easy to reach.
Native EVM going live is the event that reframes this role. Before it, building on Injective meant learning Rust and CosmWasm. After it, any Ethereum team can deploy with Foundry, Hardhat, and MetaMask, unchanged, and reach the finance modules through precompiles. The addressable developer population went from a niche to all of Solidity, and the surrounding infra has not caught up.
| What changed | What it opens | The integration work it creates |
|---|---|---|
| Solidity runs natively, native modules via precompiles | Ethereum dApps port with no rewrite, then call the order book, oracle, and RWA modules | Migration templates and a precompile composition reference (exchange, oracle, bank) |
| MetaMask and standard tooling work | Millions of EVM users and dev workflows are compatible day one | Wallet-strategy samples and the dual-address (0x and bech32) guide |
| MultiVM token standard | One canonical token across EVM and WASM, no wrapper reconciliation | Reference flows for bridged and issued assets usable in both VMs |
| 30+ dApps and infra live at launch | A base ecosystem, but early and gap-filled | RPC, indexer, and oracle wiring so the next teams do not each file the same ticket |
A growth or integration engineer hired now is hired into a specific window: a new EVM ecosystem where the developer funnel is wide open and the tooling is immature. The compounding move is to build the templates, references, and sample code once so each new Solidity team self-serves, and to spend the saved time on the higher-value integrations that use the finance modules. That is where I would start, and the build list in section 07 ladders up to it.
Sources: Injective native EVM launch announcement and The Block coverage (Nov 2025); precompiles and EVM integration docs, docs.injective.network.
The posting lists what the role does. Each responsibility, turned into a concrete plan, with where it shows up on this page.
| JD responsibility | My plan | On this page |
|---|---|---|
| Build components integrating Injective with RPC providers, indexers, wallets, bridges, storage, analytics, and applications | Vetted RPC path, an EVM indexing reference, wallet and dual-address samples, and bridge-arrival flows over the bank precompile and MultiVM token standard. | §03, §07 |
| Own partner integrations end-to-end, from discovery and architecture through testing, deployment, and production support | Run each integration as a pipeline: discovery, architecture, build, test, deploy, support. The same shape I ran at deBridge and BOB. | §06 |
| Improve integration tooling and processes: deployment workflows, testing frameworks, scripts, security controls, monitoring, alerting | One MultiVM test harness and monitoring baseline, reused across partners, not rebuilt per deal. Same failover and scheduled-job patterns as my data-API product. | §07 |
| Provide prompt technical support to developers: troubleshooting, technical queries, integration challenges | Root-caused developer support, my full-time work at BOB. Turn each recurring ticket into a doc or sample so it stops recurring. | §06 |
| Update and maintain technical documentation | Reconcile the two doc sets for the EVM era. At BOB, docs I wrote measurably cut repeat queries. | §03 |
| Create tutorials, sample code, and developer resources | Foundry and Hardhat quickstarts and dual-address samples first, then oracle and exchange-precompile samples with the SDK team. | §07 |
| Gather developer feedback and influence the product roadmap | Carry the friction I hit building the samples back to product as prioritized, reproducible feedback. | §06 |
| Support developer onboarding, including hackathons and grants | High-touch unblocking of hackathon and grant builders (DoraHacks, ecosystem programs) to seed real integrations. | §07 |
On the stack: I build in JavaScript and Python and read Solidity daily (I run an on-chain agent on Aave V3 with wagmi and viem). Go, Rust, and CosmWasm are where I ramp; the honest plan is in section 06.
The JD asks for end-to-end ownership from discovery to production support. This is the pipeline I would run for each partner, and it is the same shape I have already run: partner integrations at deBridge, ticket-to-resolution support at a Bitcoin L2, and shipping and operating my own multi-service infra.
I ran the full partner path at deBridge (identify, scope, integrate; for example, wallets and 1inch) and the full ticket lifecycle at BOB (triage, root-cause via logs and status codes, resolve). Same ownership, applied to Injective integrations.
I build and operate my own services (a data-API product that consumes and serves REST APIs with keys, rate limits, and scheduled refresh; a multi-site Docker and nginx stack; a RAG support bot). Deployment scripts, monitoring, and test harnesses are day-to-day work, not a new skill.
Every integration surfaces friction. I file clean, prioritized reproductions to engineering. This is the voice-of-developer loop that both retains builders and improves the product, and the JD names it directly.
On ramp-up: I am strongest on JS, Python, EVM tooling, and developer support. For Go, Rust, and CosmWasm I would pair the first weeks with the SDK maintainers and ship a small sample early to prove the ramp rather than claim the seat.
Each item ties to a real gap from the integration surface (section 03) or the EVM moment. I split them by what I can own solo on day one and what I build with the protocol and SDK team as I ramp, so the near-term commitments are the ones I can unambiguously ship.
The public sentry RPC is shared and best-effort, and new builders hit throttling silently. Ship a decision guide (public vs QuickNode vs thirdweb vs self-host) plus a drop-in client with retry and failover, the same pattern I run in my own data-API product.
Two template repos that deploy a first contract to Injective EVM with the right chain config, Blockscout verification, and a passing test, in one clone and one command. A direct path from curious to deployed.
The 0x and bech32 forms derive from the same key, but it trips up every incoming EVM user. A clear explainer plus wallet-strategy sample code (MetaMask, Keplr, Ledger) a front-end team can lift directly.
A reusable harness that asserts Injective-specific behavior on testnet (the same balance visible via an ERC-20 and the bank precompile; an exchange-precompile order round-trip) and a monitoring baseline that watches precompile call success and latency and RPC headroom. Answers the JD's testing, deployment, and alerting bullets, and reuses the ticket-to-doc loop I ran at BOB.
Worked price-feed examples on top of the oracle precompile for Pyth, Chainlink Data Streams, and API3, with a "price a simple perp" walkthrough. The docs are thin here; the samples are the fix.
A tutorial and reference contract showing a Solidity dApp composing with the exchange, oracle, and bank precompiles, the combination that gives a builder a concrete reason to build here rather than on cheaper blockspace. I co-author this with the protocol team while I ramp Go and the module internals.
A guide for porting a stock EVM dApp to Injective and then wiring it into the native modules, turning a lift-and-shift into a reason to stay.
Embed with hackathon and grant builders (DoraHacks, ecosystem programs): unblock them live, then turn every recurring question into a doc or sample. An effective way to convert the new EVM funnel into shipped, referenceable integrations, and where support and enablement, my strengths, meet the deep-module work.
Facts are drawn from public sources as of mid-2026 and checked against the official docs: Injective's docs and blog (Cosmos SDK architecture, the exchange and oracle modules, CosmWasm, the native EVM and MultiVM launch, and the precompiles that expose native modules to Solidity), the EVM integration docs (chain ID, RPC, explorers, oracle and wallet support, the exchange precompile at 0x…65), The Block on the November 2025 EVM launch and the RWA and pre-IPO perp markets, Messari on the RWA infrastructure and volume, and Hyperliquid's docs for the HyperEVM and CoreWriter comparison. Throughput and block-time figures are Injective's published numbers, quoted with qualifiers. This is unsolicited engineering homework, not a client deliverable, and I am happy to walk through any section or the sample code behind it.
Precompiles: docs.injective.network, precompiles
Exchange precompile: docs.injective.network, exchange precompile
EVM launch: injective.com, the Injective era
RWA infra: Messari, RWA derivatives
HyperEVM / CoreWriter: Hyperliquid docs
Grants: DoraHacks, Injective Grant DAO
Independent engineering homework for the Injective Labs Growth / Integration Engineer role · 2026 · edwardtay.com