For 0x1004, how about making x402 on ICP support not only ERC-20, but also ERC-3009? Wouldn’t it be possible to do this simply by modifying the Solidity factory?
Something like this may already be in under the covers. You can gate your content with x402 and it supports ICRC-79 subscriptions…so if your smart contract authorizes the subscription canister to pull from your ERC-20/ICRC-1 combo account it should just work.
Sometimes I like to watch old movies, or play old games. Maybe it’s just nostalgia, but it’s just more comfortable and feels good sometimes when you know how the story goes, or you already mastered the mechanics.
To be serious for a moment, I understand the adoption argument: give Solidity developers MetaMask, Hardhat and familiar ERC interfaces while hiding the IC underneath. As a thin compatibility layer, that could be useful.
But if the EVM becomes the canonical execution and state layer, this doesn’t strip complexity away—it adds an EVM interpreter, JSON-RPC, Ethereum transaction/nonce/gas semantics, synthetic ERC-20s, bridges, privileged precompiles and ticket-based polling to adapt the IC’s asynchronous operations back into Solidity.
The IC’s advantages are native Wasm execution, asynchronous actors, canister isolation and horizontal scaling. Constraining those capabilities to the EVM’s sequential shared-state model seems like trading away the platform’s strongest features for developer familiarity.
So the important architectural question is: does canonical application state live inside ETHGent’s EVM, or is ETHGent merely an optional façade over native canisters?
If it’s the latter, I can see the value as an onboarding adapter. If it’s the former, I’d like to understand the measured execution overhead, scaling model and security boundary—and why that trade is preferable to improving native IC tooling.
Since inter-canister calls are not guaranteed to succeed, the IC is not very suitable for DeFi.
However, if multiple DeFi applications exist within a single canister like ETHGent, they should be able to be processed atomically. Fortunately, Wasm is superior to EVM as a VM, so I believe even a single canister has enough performance to function as a chain.
While having each canister run an EVM might add unnecessary complexity, it is great that the IC has one EVM-compatible environment.
DeFi projects can simply be deployed to that canister, just like on the Avalanche C-Chain.
There have been like 30k+ eth devs over the last decade. This is more than the tens of us that are still around. So, most primary, it is a gate. Pull them in with way they know and then give them the magic beans.
The IC sucks at atomicity. Kong kind of tried to solve this but still kind sucked and was hacked. An even gives us code and contracts that are being vetted by some of the largest and wealthiest institutions on earth right now. Defi may not need atomicity, but it is simpler with it.
The IC kind of also sucks at shared ownership in an atomic space. The cool thing about evms is your archenemy can install software on your evm and it is still all good. There are a bunch of other features that are baked in that I haven’t announced yet, but think neutron but you don’t have to recompile your canister to add new code.
Giving evms the ability to do async stuff is a super power. When you do it on non-ic based evms it really sucks…doing async on an IC evm is annoying ticket checking, but it is safe ticket checking with no extra infra.
The ic also sucks at forcing devs to be transparent, open, cypher and all that jazz. Evms just assume all of that. So your code is basically transparent, all the transactions are transparent, etc,etc…not mission critical, but effective and helpful in the right contexts.
All the rally cool stuff that we say about tecdsa and what it can do for OTHER chains is true for sub evms as well. A bit meta, it becomes interesting for contracts to own assets on other evms in a really easy and straightforward way. For IC based evms you get to cheat a little.
As far as performance, it is actually pretty great! It can’t beat a one node evm written in rust , much less what ever @Jan is cooking up with paralllel evms, but I’m pretty sure it was doing hundreds of eth trxs/second and like 25 uniswap trxs/ second( which would scale horizontally across subnets if you had a swarm of evms working together).
I get that this is 5 years late, but I was floored when it didn’t ship as part of the ic at genesis, and floored again when bitfinity crashed and burned as hard as it did. The key to this was making sure it was shaped like the IC. Writing it in motoko with knowledge of DTS, cycle limits, etc, made it likely much more performant…and there are a bunch of optimization that I have waiting on the wings if we can get some things like native u256 in motoko.
Once I get the code out you’ll be able to see that you can drop an evm into your canister with a couple of line mix in, so you can mix and match your async stuff with the evm stuff and magically plug into the data model. Of course that is fraught with other security implications and you’ll need to trust the devs, but feature like instant on erc20 a that “just work” with metamask but that are actually icrc1 tokens and everyone has an account on your evm already is kind of magic.
I also think it is kind of baller that Pakistan or some other nation/institution could just launch a sovereign evm with a couple commands, but it’s been crickets from anyone in that side of the foundation.
If anyone needs this or wants to experiment with it, let me know. I’m need to get to some kind of endowment or long term fundraising for ICDevs to support it and then I can just open source it.
Dominic with its CaffeineAI is literally stealing people credits/money. HE does not even implement feature for people to see what topped up and if any. most see fake top ups, if contacted to support, they say a bug. But the rest of people get scammed. Dfinity should do something about leech in our ecosystem.
Borovan, build us copy of Caffeine, but make it userfriendly, no stealing and hiding stuff.
I’m glad to learn that IcyDB/Canic provide these capabilities. They seem very interesting and useful.
I also agree that saying “IC is not suitable for DeFi” was too broad.
That said, my original post was about how we might enable DeFi on the IC in the first place…
What I had in mind was something closer to a permissionless, composable DeFi environment.
Even if individual DeFi applications can be built safely, if independently built protocols cannot interact and compose well with each other, wouldn’t that still limit the growth of the ecosystem?
Also, running an EVM on the IC is extremely inexpensive. Given that, I don’t think it’s unreasonable to explore using some of the useful properties of the EVM as one possible approach.
drop! Looks very interesting indeed!
from anyone in that side of the foundation.