A quick update a year later on our Motoko EVM that I’ve posed about previously:
We’ve actually pulled this off. We have the EVM working, and it is passing 99% of the fixtures from GitHub - ethereum/execution-specs: Specification for the Execution Layer. Tracking network upgrades. · GitHub(only the intentionally stack-blowing and recursive tests are failing).
Now I need feedback/direction because the environment has changed quite a bit over the years that this has been under development, and I know the market conditions are miserable right now.
I’d like to get technical feedback on whether a Motoko-based EVM(motoko is an actor-based language specifically designed for consensus-based/blockchain-based systems) with native threshold signing, async scheduling, richer wallet models, and outbound data access exposes a genuinely interesting design space, or whether these are mostly seductive but unnecessary primitives. Basically, should I put any more time into this or not.
We built an EVM in Motoko because we think there is room for chains that feel like Ethereum at the application layer, but expose infrastructure primitives that normal EVM stacks do not get by default.
The value proposition is not “new VM, new language, trust us.” The value proposition is:
keep the EVM surface recognizable;
keep Solidity and Ethereum mental models relevant;
add base-layer primitives that make cross-chain control, wallet design, async workflows, automation, and specialized deployments easier to express.
I’d welcome any pushback on whether these advantages are actually meaningful, and where the design is still ugly.
What This EVM Already Tries To Prove
The current engine work is aiming at real EVM parity:
142 opcodes
18 precompiles
5 transaction types
13 hardforks
88/88 JSON-RPC compatibility tests passing
2,681 Ethereum fixture files passing in the execution-spec style corpus
So the starting point is not “let’s invent a quirky alternative to Ethereum.” The starting point is: how far can we preserve Ethereum semantics while exposing stronger system primitives underneath?
Why I Think A Motoko EVM might be interesting to Etherians
0. Push button, Get a globally distributed 13 or 34 independent node EVM for a few bucks.
1. Cross-chain asset control can be a contract primitive, not just a bridge company product
One of the more interesting capabilities here is threshold ECDSA-based signing infrastructure, which means EVM contracts and wallet surfaces can be designed to natively control accounts or assets on other chains.
No need for:
a multisig run by an ops team,
an external relayer set,
a specialized bridge committee,
or a protocol that is notionally decentralized but still operationally concentrated.
The question we are exploring is whether ETH-like contracts can treat external-chain signing as a native, auditable system capability instead of bolting it on as separate middleware.
If that works cleanly, it changes the design space for:
BTC-oriented EVMs,
cross-chain treasury management,
contract-controlled settlement rails,
wallet-mediated account abstraction,
and regulated asset movement where governance over signing policy matters.
2. Async execution is not an accidental afterthought
Currently, anything async gets pushed into bots, keepers, off-chain workers, cron services, or relayer stacks.
The Motoko environment is interesting because async is a real base primitive. That opens the door to execution models built around:
timers and cron-style scheduling,
pub-sub / listener patterns,
long-lived workflow coordination,
deferred completion patterns,
wallet-routed external calls,
and richer retry / journaled state machines.
This does not mean “async EVM” in the naive sense. EVM execution still needs deterministic boundaries. But it does mean the chain can express more of the lifecycle natively instead of pretending everything important fits inside a single synchronous transaction.
I think the interesting question is whether this lets us move a meaningful amount of off-chain coordination back into the replicated system without breaking the developer mental model.
3. Oracles and external data can become less middleware-heavy
Another advantage is outbound HTTPS access as a first-class system capability. That means decentralized oracle and automation patterns do not always have to start from “which off-chain committee do we trust to fetch and repost data?”
This does not make oracle problems disappear. It does not magically solve data authenticity. But it does change the architecture:
fetching can be part of the system surface,
verification policy can be on-chain,
and protocols can reason about external reads without defaulting to the same relayer patterns every time.
I expect pushback on determinism, replayability, authenticity, and cost modeling here. That is exactly the kind of feedback I want.
4. Wallets can be much richer than session signers
One of the most differentiated surfaces in our evm is the wallet model.
The wallet direction here is not “browser extension, but ours.” It is closer to a per-user execution environment(it is an evm) with:
delegated permissions,
method- and contract-scoped policy,
spend limits,
recovery timelocks,
submission journaling,
authenticated transaction flow,
and routing of external calls through the user’s wallet identity.
From an Ethereum point of view, that means wallets can become programmable security and coordination surfaces instead of being thin wrappers around a keypair.
I think this matters for:
safer retail UX,
team and institutional wallets,
plugin/app-store style wallet extensions,
account abstraction experiments,
and chain-native app composition.
5. Specialized chain deployments become easier to reason about
This architecture can be deployed on independent 13-node or 34-node subnets, with geography-aware placement choices.
That matters less for retail degen UX and more for people thinking about:
institutional chains,
sovereign or jurisdiction-sensitive deployments,
KYC-gated environments,
and chains where infrastructure shape is part of the product, not a hidden backend detail.
Ethereum has always had a tension between credible neutrality and specialized deployments. I am interested in whether this kind of architecture is a good place to explore the latter without pretending it is the former. (The unstated assumption here being that mainnet pinning is a default.)
Open Questions
These are the questions I would most like ETH-native people to react to:
Is native threshold-signing access for contracts actually a big enough primitive to matter, or does it just move the trust boundary around?
Is the async/timer/pub-sub model a real advantage, or does it mostly create a new category of developer foot-guns?
Are deterministic/external-data access patterns worth integrating at the chain level, or is this better left to oracle protocols and middleware?
Does the wallet model meaningfully improve on smart-account / AA direction in Ethereum, or is it just a different packaging of similar ideas?
Which use case is actually most compelling:
open ETH-like chain for scalability,
BTC-oriented chain(BTC as gas/native token),
regulated/KYC chain,
or wallet-centric applications?
- Which parts would make you skeptical immediately?
It has been a long slog to get here, and I’m not sure that the accomplishment meets the moment. We are considering the extent to which we should continue to dedicate time and resources. If any of this is intriguing or interesting to anyone here, please reach out. I know this isn’t as exciting as new zk Proofs or scaling the mainnet directly, but if done correctly, we think there are some really exciting opportunities here for easily bootstrapped app chains and other, potentially more peculiar experiments.
(To the extent that performance is important, the system is currently tracking at 2s-6s finality with 1000/standard TPS and about 13.5 Uniswap v3 swaps/second, supporting up to 400GB of state/EVM)
