Table of Contents
- Key Takeaways
- 1. Background - Introducing Injective EVM
- 1.1 Why EVM?
- 1.2 Injective EVM Deep Dive
- 2. Takeaway - Injective EVM, What’s Next?
- 2.1 Injective is still one of the fastest blockchains in this industry.
- 2.2 Appeal to Developers Is Necessary
- 2.3 If Pursuing Multi-VM, Go Beyond EVM
- 2.4 Conclusion: Now Is Truly Injective's Time
- 3. Resource
Researcher
Related Projects
Key Takeaways
Injective Labs announced Injective EVM in January 2025. Injective EVM is being implemented directly into Injective's core rather than as separate off-chain computation, and is viewed as a move to secure a broader developer ecosystem.
However, this doesn't mean abandoning WASM, which was Injective's existing smart contract platform. Rather, it should be seen as an initiative to adopt multiple VMs and remove various barriers for developers when onboarding to Injective.
If the EVM implementation successfully expands the developer ecosystem, the next step could be considering the introduction of other VMs. For example, the rapidly growing MoveVM or SVM, which could leverage the vast Solana ecosystem, are potential candidates. Let's observe how Injective's native EVM implementation might influence the growth of the Injective ecosystem going forward.
1. Background - Introducing Injective EVM
1.1 Why EVM?
Injective Labs, one of the core contributors to Injective Network, announced in January 2025 that they will integrate a native EVM execution environment directly into the Injective chain core. This strategic decision aims to leverage Ethereum's vast developer community and mature tooling ecosystem.
While Injective has successfully introduced numerous innovative technologies and established partnerships with prominent protocols through aggressive business expansion, growing a larger developer community and enhancing the developer experience have remained crucial pillars for their strategy. Given this focus, Injective has naturally targeted the Ethereum Virtual Machine (EVM) ecosystem, which continues to be the most widely adopted virtual machine environment in the blockchain space today.
This native EVM integration demonstrates Injective's pragmatic vision—recognizing that technological superiority alone isn't sufficient without widespread adoption. By preserving their unique performance advantages while offering familiar tools and workflows to Ethereum developers, Injective creates a compelling migration path for projects seeking higher throughput without sacrificing compatibility. The approach effectively serves both their technical ambitions and market expansion goals simultaneously.
Source: Electric Capital
This motivation is actually proven by statistics. According to a developer report published by Electric Capital, approximately 74% of developers working across multiple chains are developing on EVM chains, and Ethereum still ranks first in developer activity across all continents worldwide. This means that even as developer ecosystem diversity continues to increase, EVM developers using Solidity remain the mainstream in the blockchain industry.
To elaborate further, chains that don't support EVM must bear the cost of investing enormous capital and time to cultivate a new developer ecosystem and attract developers to their ecosystem. In contrast, chains that support EVM can more easily recruit developers already familiar with blockchain. Additionally, from a developer's perspective, being able to create applications in a familiar development environment without additional technical barriers to learn means greater productivity advantages.
As evidence of this, Injective Labs reports that numerous developers requested the implementation of an EVM execution environment during their developer onboarding process. I believe that listening to developers' requests and implementing them into the product is highly desirable, as Layer 1's direct customers should be developers rather than users. The most important customers for Layer 1 are builders, as excellent builders will ultimately attract users.
1.2 Injective EVM Deep Dive
1.2.1 Not Just EVM, But Multi-VM
Before diving deeper into Injective's native EVM, one thing that needs to be clarified is that Injective continues to implement WASM contracts as well. In other words, they are deploying a multi-VM strategy that maintains the existing WASM development environment while also implementing EVM, rather than pivoting to EVM.
In Injective, the EVM is implemented in the core of the chain like other EVM chains, creating a deep execution environment, but it is also implemented in a form that harmonizes with the existing WASM-based execution environment. Additionally, it uses the EVM implementation from the latest Geth (Go-Ethereum) Ethereum client, making it perfectly compatible with Ethereum's latest tooling (such as Foundry or Hardhat) and standards.
1.2.2 Atomity of Transaction
Transaction atomicity is extremely important. Especially in cases where transactions need to be processed sequentially to achieve desired results (such as in flash loans), if even one transaction fails among multiple stages, this causes the entire process to fail in achieving the desired outcome, potentially resulting in unnecessary transaction costs or asset losses.
Conversely, in environments where atomicity is guaranteed, if one transaction fails, all other transactions are rolled back, allowing the system state to remain consistent. In Injective, even with multi-message transactions (structures where multiple messages are sequentially executed within a single transaction), if one step fails, the entire transaction can be reverted, ensuring data integrity and consistency (this applies to both WASM and EVM environments).
These characteristics provide several benefits: 1) errors can be identified much more efficiently through complete rollbacks, 2) stability for financial applications is enhanced because there are no unexpected state changes from partial failures, 3) the risk of state inconsistencies is reduced even with complex workflows, and 4) system consistency can be guaranteed by applying the same rollback rules regardless of which virtual machine is used.
This transaction atomicity is an especially important value because Injective is a finance-specialized blockchain.
1.2.3 Module Compatibility
While Injective Network differentiates itself from other Layer 1 blockchains in many ways, what makes Injective stand out from a developer's perspective is the existence of various "modules" that help make application development easier. Since this EVM update implements the EVM environment in the Injective core, EVM developers can also leverage Injective's built-in modules using Exchange Precompile (a wrapper that allows simple calls to exchange module messages from EVM).
This means that EVM developers can also leverage Injective's CLOB, batch auction (FBA), and shared liquidity environments to implement various finance-related applications.
1.2.4. AI-Ready VM
Additionally, Injective's EVM enables AI inference to be executed directly on-chain, allowing for the deployment of AI Agents and various AI and blockchain-related initiatives. Being able to execute AI-related inference directly on-chain reduces dependency on off-chain computations and enables more in-depth utilization of Injective's financial applications, such as using AI to manage portfolios, analyze financial data, or allow agents to manage resources for organizations like DAOs.
Injective had already developed various initiatives and partnerships related to AI even before introducing native EVM, and these initiatives also represent benefits that EVM developers can enjoy.
1.2.5 Multi-VM, One Token
Finally, there's token representation unification. With Injective supporting multiple VMs, there might be concerns about having too many token standards that are difficult to make compatible with each other. However, Injective has already recognized this issue and aims to solve it with Bank Precompile and ERC20 Module. Their characteristics are as follows:
Bank Precompile
A smart contract interface that allows EVM's ERC-20 tokens to interact directly with Injective's
x/bankmodulePreviously, token replication or escrow was inevitable when transferring tokens to other chains, but now unified management in ERC-20 form is possible directly on-chain
All token activities (transfers, minting, burning, etc.) are synchronized in real-time between WASM and EVM environments, fundamentally preventing double accounting issues
ERC20 Module
Maps Injective's native assets to the ERC-20 standard, allowing various assets like IBC, Peggy, and TokenFactory to naturally integrate with EVM
Stores and manages mappings between Bank denoms and ERC-20 tokens
Tokens can be created and managed from either WASM or EVM, increasing development flexibility
Enables developers to manage Injective's tokens using the ERC-20 standard, supporting a broader ecosystem
The combination of Bank Precompile and ERC20 Module allows tokens to be used consistently in a unified way in Injective's multi-VM environment. This approach enables users to handle tokens efficiently and safely without complicated cross-chain procedures, implementing the integrated and simple ecosystem that Injective pursues.
2. Takeaway - Injective EVM, What’s Next?
2.1 Injective is still one of the fastest blockchains in this industry.
There are several "fast blockchains" now, but Injective can be considered the pioneer of this narrative. They quickly recognized Tendermint's potential before others, redesigned it to fit their purpose, and provided various precedents for the industry. This performance continues even after EVM adoption.
Injective actually tested the performance of Injective EVM in two major test environments: in a real network environment (network-centric throughput) that includes communication between distributed nodes, they achieved approximately 4,500 TPS, and in an ideal environment with no network constraints, they implemented up to 12,500 TPS. This represents performance several times faster than existing high-performance EVMs.
With its speed and compatibility with the latest Geth, I believe Injective is not technically behind compared to other EVM chains. So what does Injective need now?
2.2 Appeal to Developers Is Necessary
The most urgent thing for Injective to do after EVM adoption is to bring excellent EVM developers to Injective. However, the problem is that EVM developers have countless options. And certain development groups are "grant hunters" who only aim for grants or temporary benefits, build just a product PoC, receive the grant, and then move to another chain.
To solve these problems, it would be good to conduct hackathons that provide appropriate incentives to developers while giving grants in stages, and it may also be necessary to communicate long-term with conferences where many developers are distributed.
Of course, Injective has its advantages. Injective has built a loyal community group (called Ninjas) over the past three years. Ultimately, application builders will prefer chains with many potential users who can utilize the applications they build, so Injective's community can be a significant advantage in onboarding developers. I think the important thing is to actively inform builders that Injective now natively supports EVM.
2.3 If Pursuing Multi-VM, Go Beyond EVM
If Injective had simply pivoted from WASM to EVM, it might not be such a remarkable change, but since they have declared "building a multi-VM ecosystem" through this upgrade, there's a possibility that Injective won't end with just EVM adoption.
In fact, they aimed to build not only the EVM ecosystem (inEVM) through rollups but also the SVM ecosystem (inSVM), and subsequently collaborated with Sonic, one of the most prominent SVM chains, to establish an environment where Injective developers can deploy Solana-based applications. Given Injective's trajectory, it is reasonable to expect that they may offer native support for SVM in the future, depending on the growth of their developer ecosystem. Ultimately, the ability to stably integrate diverse developer ecosystems into a single core will likely be a critical factor for success.
As I mentioned earlier, this is because the customer of a smart contract platform should ultimately be the builder, not the user. People dislike learning new things. They prefer what's familiar. Therefore, providing an environment where developers can easily create something will be a challenge for all smart contract platforms going forward.
In that sense, I think Injective's current direction is excellent. Will we see Injective SVM, Injective MoveVM?
2.4 Conclusion: Now Is Truly Injective's Time
Even as I write this article, various EVM chains are emerging. And they are attracting developers and users with their respective characteristics and features. Nevertheless, I believe Injective has many values to offer.
First, Injective has not experienced any network-level issues in the past 4 years since launching its mainnet. This is a value that can sufficiently appeal to institutions that prioritize network stability and consistency. Additionally, the fact that they support WASM in addition to EVM can be a differentiating point compared to other "fast EVMs."
Technically, the various modules they have built, Injective's unique tokenomics (a unique tokenomics drawing a flywheel where $INJ burns as more users join the ecosystem and more usage occurs), and speed and performance that are not behind compared to other chains are aspects that can sufficiently appeal to developers and users.
In some ways, I think now is the best timing for Injective to make a leap. Can Injective bring its achievements of the past 4 years to fruition?
3. Resource
Related Articles, News, Tweets etc. :
