An Experimental EVM-Compatible Smart Contract Chain Built on Nimiq
DISCLAIMER: I’m one of the five Community Council members who decide on
proposal funding. I will therefore be excluded from all Council discussions and
decisions about this proposal, and I will not attempt to influence any other
member’s decision.
The Vision
What if developers could build programmable applications around NIM using
Solidity, MetaMask, and the Ethereum tools they already know, without requiring
changes to Nimiq’s consensus protocol?
Nimiq-Anchored EVM Chain explores exactly this possibility. It is an experimental
smart contract chain built on top of the Nimiq blockchain. Users submit requests,
nodes exchange coordination messages, and accepted results are recorded through
normal Nimiq transactions. The chain’s ordered history therefore lives on Nimiq.
The smart contract chain is operated by its own set of nodes, separate from
Nimiq’s validators. These nodes validate requests, execute EVM code, maintain
contract state, compare results, and jointly sign accepted outcomes. Nimiq
secures the underlying transactions; the project’s nodes are responsible for
validating the smart contract execution. A new project node can reconstruct
the contract state by replaying the recorded history.
This is not only an idea. A working research prototype already executes EVM
bytecode, communicates with MetaMask, coordinates multiple nodes, and creates
jointly signed Nimiq transactions. The purpose of this proposal is to develop
that prototype into a reproducible public Testnet that the Nimiq community can
try, inspect, and evaluate.
This proposal is for a public Testnet prototype, not a production or Mainnet
launch. Security audits, complete Ethereum compatibility, operator governance,
and a Mainnet security model are explicitly outside this funding phase.
1. Project Description
The opportunity
Nimiq is easy to use for payments, but it does not currently offer the general
smart contract environment that many Web3 developers expect. This limits
applications that need programmable rules, shared state, escrow logic, tokens,
marketplaces, memberships, games, or other contract-controlled behavior.
The
Nimiq Mini Apps Competition
has already shown how creative the community can be. Many of these applications
try to work around the same missing capability: programmable, shared state on
Nimiq. Apps that need this functionality still have to depend on centralized
backends or external smart contract networks. A Nimiq-anchored execution layer
could therefore benefit a large part of the Mini Apps ecosystem by allowing more
application logic to remain verifiable through Nimiq.
Ethereum’s execution environment has a large developer ecosystem. Solidity,
MetaMask, standard JSON-RPC methods, contract libraries, and development tools
are already familiar to many developers. Supporting these interfaces can make it
much easier for them to build experiments connected to Nimiq instead of learning
an entirely new contract platform.
This also aligns with Nimiq’s wider direction. Team Nimiq has publicly named
interoperability with Ethereum and other EVM chains
as a future initiative. While an Ethereum bridge is not part of this proposal,
an EVM inside the Nimiq ecosystem could later provide useful building blocks for
inter-chain swaps, bridges, and representations of bridged NIM on EVM networks
like Ethereum.
The main audience is:
- Nimiq developers who need programmable application logic.
- Solidity developers interested in building with NIM.
- Community projects that currently require a trusted central server for
application state. - Researchers interested in Nimiq as a data, coordination, and settlement layer.
What has already been built
My open-source development of
NTMP laid the foundation for this
chain and its communication through Nimiq transactions.
I have already invested several weeks in a prototype that I built in my free
time. It currently contains early versions of:
- A TypeScript EVM interpreter with contract code, storage, calls, revert
behavior, and a browser debugger. - Ethereum-style JSON-RPC and initial MetaMask integration.
- Deterministic transaction rounds and fee-based mempool selection.
- Multi-node MuSig coordination and final transaction creation.
- State replay from transactions recorded on Nimiq.
- Experimental handling of NIM deposits, withdrawals, and native Nimiq transfers
triggered by contract execution.
These components are not finished or audited, but they reduce the risk that this
proposal is only a theoretical idea.
Early community interest
I shared an early prototype update in the Nimiq
Telegram community. It received 17 reactions, which is unusually strong
engagement in that group. This is an early but clear signal that community
members are excited about bringing EVM capabilities to Nimiq.
How it works in simple terms
The easiest way to understand the system is to view Nimiq as a public notebook
and payment rail: it orders messages and makes the accepted history visible to
everyone.
- A user sends a smart contract request as one or more normal Nimiq
transactions to a defined inbox address. - Independent nodes read the same requests from Nimiq.
- At fixed block-based intervals, every node applies the same deterministic fee
auction and ordering rules. Higher-paying valid requests are prioritized, and
replace-by-fee allows a sender to replace a pending request that uses the
same nonce. This should make every honest node select the same requests while
making large-scale spam expensive. - Every node executes the selected requests in its local EVM and calculates a
checksum, or digital fingerprint, of the resulting transactions and state
changes. - Nodes publish their agreement through Nimiq transactions. Nodes that agree on
the result use MuSig to create one joint signature. - Once the required signing threshold is reached, the accepted result is
written from the project’s multisig address to a dedicated Nimiq blockchain
address. - A new node can download this ordered history and replay it to reconstruct the
same smart contract state.
Node-to-node coordination also uses Nimiq transactions. The prototype does not
introduce a separate peer-to-peer network. A node therefore does not need an
inbound port forwarding setup for an additional network and can run behind a
normal home internet connection. Because the implementation uses TypeScript,
WebAssembly, and the Nimiq Web Client, it can in principle even run inside a
browser. Long-running operators should still use a stable service rather than a
browser tab.
The Testnet includes an internal invocation fee in addition to the normal Nimiq
network fee paid for the underlying transactions. The fee auction is required to
prioritize limited processing capacity and protect the mempool against cheap
spam. Fee levels and operator rewards remain experimental during this phase;
their final economic model is future work.
What this system trusts
This is important: the project does not inherit all of its execution
security directly from Nimiq validators.
Nimiq provides transaction inclusion, ordering, availability, and settlement.
Correct smart contract execution depends on a separate set of project node
operators. The prototype accepts a result when more than 50% of the configured
operators sign it. A dishonest majority could approve an incorrect result, while
too many offline nodes or lost keys could halt the system.
For that reason, I describe this as an experimental Nimiq-anchored execution
layer, not yet as a fully trustless Ethereum rollup. There are no validity
proofs or fraud proofs in the current design. The long-term goal is to improve
the system through further development, testing, governance work, and
independent security reviews until a production design can be responsibly
considered. This Testnet phase is the first step, not the final product.
2. Project Goal and Benefit to Nimiq
The goal of this proposal is a reproducible public Testnet where at least three
separately running nodes can agree on, execute, and finalize EVM contract
requests through Nimiq. Unless the Council or community prefers another
arrangement, I will voluntarily host and operate this initial public Testnet.
If successful, the project can benefit Nimiq in several ways:
-
More utility for NIM: NIM can be used in programmable applications instead
of only direct transfers. -
A lower barrier for developers: Solidity, MetaMask, and Ethereum JSON-RPC
give developers familiar entry points. -
More activity on Nimiq: Requests, coordination messages, signatures, and
finalized outcomes all create Nimiq transactions and network fees. -
No Nimiq consensus change: The experiment can be developed and tested
without modifying Nimiq’s base protocol. -
Less reliance on centralized backends: Some community applications could
move rules and replayable state away from a single trusted server. -
Reusable open-source research: Even if parts of the architecture must
change, the EVM, tooling, tests, protocol findings, and documented limitations
remain useful to the community.
Success in this phase does not mean that every Ethereum application will work.
It means the core concept is demonstrated clearly enough for the community and
security specialists to decide whether a production-focused second phase is
justified.
3. Scope
Included in this proposal
- Deterministic fee-based request ordering, nonce handling, replace-by-fee, spam
protection, and round processing. - Multi-node agreement and MuSig finalization on Nimiq Testnet.
- Deployment and calling of a useful subset of EVM smart contracts.
- Contract storage, internal calls, return data, and revert behavior.
- Small test pages that create invocations through Nimiq Hub.
- Basic Ethereum JSON-RPC and MetaMask interaction in the final phase.
- A limited Testnet mechanism for depositing and withdrawing NIM.
- Automated tests, adversarial test cases, and reproducible demonstrations.
- A public information and documentation website with explanations, diagrams,
tools, and specifications based on the implementation that was proven to work. - Public source code, installation documentation, Docker packaging, and a public
Testnet deployment.
Not included in this proposal
- Mainnet deployment or production custody of funds.
- A claim of complete EVM or Ethereum protocol compatibility.
- A professional security audit or penetration test.
- Validity proofs, fraud proofs, or decentralized sequencer technology.
- Final governance, operator admission/removal, key recovery, or slashing rules.
- A production block explorer, polished wallet, or professional UI design.
These are possible follow-up projects only after the Testnet results are
reviewed.
4. Timeline and Milestones
Development starts on the day this proposal is accepted. The estimated duration
is six months. This is research-driven development: implementation comes
first, while formal specifications and documentation are written after the
working design has stabilized.
Each milestone ends with a public progress update in the Nimiq Forum. Noteworthy
results will also receive a detailed post on nimiq.top, shared through Twitter / X and the
Nimiq Telegram community.
| Milestone | Schedule | Verifiable deliverables |
|---|---|---|
| 1. First multi-node proof of concept | Month 1 | The project’s own source code is published on GitHub under an OSI-approved license as part of this first milestone. Three separately running nodes agree on a shared genesis configuration and jointly finalize the first result to the Nimiq blockchain address. The result is demonstrated with public Nimiq Testnet transaction links and automated tests for state replay and MuSig signing. |
| 2. First end-to-end smart contract invocations | Months 2-3 | Deploy and call an example Solidity contract with persistent storage, return values, revert behavior, and internal calls. Small test pages use Nimiq Hub to create the required Nimiq transactions. The flow includes a proof-of-concept mempool plus Testnet NIM deposits and withdrawals. |
| 3. Fee-auction mempool and public Testnet | Months 4-5 | Block-based rounds, deterministic fee ordering, sender nonces, replace-by-fee, checksum agreement, ordered batch execution, and multi-node finalization. A test tool submits invalid payloads, duplicate nonces, competing fee levels, missing-signer scenarios, and spam-like input. All honest nodes must select the same highest-paying valid batch and result checksum. Unless another arrangement is preferred, I launch and host a public Testnet with at least three nodes. |
| 4. Developer access, website, and documentation | Month 6 | A public website explains the project with plain-language guides, architecture diagrams, current security assumptions, protocol specifications derived from the working implementation, Testnet status, and useful inspection or invocation tools. The release includes basic JSON-RPC and MetaMask support, an updated release of the project’s source code on GitHub under an OSI-approved license, Docker packaging, Deno setup instructions, node/operator documentation, transaction evidence, and a final public demo. |
If a milestone requires a material change in scope, I will explain it publicly
and request Council approval before treating the changed work as complete.
5. Terms of Completion
The proposal is complete only when all four milestones have been delivered and
independently reproducible instructions are public.
The final demonstration must show:
- At least three separately running nodes reading the same Nimiq Testnet
history. - A Solidity contract deployed and called through a small test page using Nimiq
Hub. - The nodes selecting the same ordered request batch and producing the same
result checksum. - The required nodes jointly signing and recording the accepted result through
Nimiq. - A fresh node reconstructing the same contract state from the recorded
history. - A capped Testnet deposit and withdrawal of NIM.
- Competing requests demonstrate deterministic fee ordering and replace-by-fee,
with every honest node selecting the same valid batch. - The public website, implementation-based specifications, node documentation,
test tools, and basic MetaMask integration are available.
Completion means a documented research prototype suitable for public testing. It
does not certify production security or Mainnet readiness.
6. Fundamental Risks
Ordinary bugs and failed transactions on Testnet are expected. Finding their
cause, fixing them, and repeating the test is one of the main purposes of this
proposal. The important risks are the larger problems that could prevent this
concept from ever becoming a safe production system:
-
The concept may not work well enough. Deterministic mempool coordination
or EVM complexity may make the design too slow, too expensive, or too fragile.
There is no honest way to remove this risk before building and operating the
Testnet. -
A software exploit could corrupt or drain the execution layer. A flaw in
the EVM, bridge accounting, mempool, state replay, or multisig process could
halt the chain, create an invalid state, or authorize withdrawals that drain
its Nimiq addresses. A professional audit and several further test phases
would be mandatory before Mainnet funds should ever be accepted. -
The operator majority is a trust assumption. A compromised or dishonest
majority could approve an invalid state or withdrawal. Majority assumptions
are common in blockchain systems: Bitcoin depends on honest majority
hashpower, while Nimiq depends on its consensus and stake distribution. The
important difference is that this prototype begins with a much smaller,
predefined operator set, so trust is more concentrated. A later production
design would need to reduce that concentration. -
Lost operator keys could permanently kill the chain. If enough operators
lose their private keys or disappear, the signing threshold can no longer be
reached. The chain would stop and funds could remain permanently locked. One
possible recovery design is to include two Team Nimiq key pairs in the genesis
configuration. Each key would have one ordinary vote, just like another
participant, but fewer rights than a node key: it could vote on replacing
unavailable operators, but it could not execute invocations, sign regular
execution-layer transactions, or participate in normal chain operation. The
two Team Nimiq votes would not control a decision on their own, but could help
the remaining operators restore a signing majority. The exact voting and
recovery process is future work and must be designed before Mainnet.
The software is expected to process public blockchain data and should not
require personal user data. Debug output and public reports will avoid
publishing unnecessary personal or secret information. Private keys will never
be committed to the repository or included in public logs.
7. Public Communication
- A Nimiq Forum progress update after every milestone.
- At least three detailed development posts on
nimiq.top/blog documenting major results. - Links to each detailed blog post shared through the project’s X account,
Telegram, and other relevant Nimiq community channels. - Public source code, issue tracking, and reproducible setup instructions.
- A final video or live demonstration plus a report describing achievements,
failures, remaining risks, and recommended next steps.
Critical security issues will be handled through responsible disclosure before
technical details are published.
8. Funding Request and Justification
I am requesting USD 24,000 equivalent in NIM as a fixed project budget up
front for the six-month scope described above.
I originally started this project in my free time because the technical challenge
caught my interest and because I want to make Nimiq significantly more useful.
The working prototype and all development completed before this proposal are my
unfunded contribution. This request is not intended to reimburse that earlier
work.
The problem is the scale of what the prototype has become. This is no longer a
small experiment that can realistically be finished through occasional spare
hours. It combines protocol design, an EVM implementation, deterministic
multi-node coordination, a spam-resistant fee-auction mempool, cryptographic
signing, Nimiq integration, developer tooling, testing, documentation, and
operation of a public Testnet.
I currently work full-time and also run a paid self-employed side business. In
addition, I maintain other free projects for the Nimiq ecosystem, including the
nim.re Explorer. These existing commitments leave too
little uninterrupted time to move a project of this size toward a reliable
public release within a reasonable period.
The purpose of this funding is therefore to allow me to suspend my paid
self-employed work for the six-month project period and dedicate the time that
this frees entirely to this project. The grant turns irregular spare-time
development into a focused and accountable development effort with the concrete
milestones and public results defined above.
This focus is especially important because the protocol is intended to handle
real funds in a possible future production version. A security mistake could
eventually affect money belonging to many people. Software with that
responsibility cannot be developed responsibly by rushing features into a few
remaining hours at the end of a working week. It requires sustained
concentration, adversarial testing, repeated multi-node testing, and time to
investigate unexpected behavior instead of working around it.
The project combines several specialist areas that are normally separate:
distributed systems, cryptographic signing, virtual-machine implementation,
blockchain integration, and Ethereum-compatible developer tooling. Much of the
work is not a visible feature. It is the testing and hardening required to prove
that independent nodes reach the same result, reject malformed input, recover
their state from Nimiq, and fail safely when participants disappear or disagree.
The budget primarily represents applicant compensation for this freed
development time. It also includes the comparatively small costs of hosting and
operating the public Testnet, packaging releases, maintaining the project
website, and publishing progress reports. It does not include professional
design, paid promotion, or an external security audit. If the Testnet justifies
a production phase, audit and penetration-testing costs would be proposed
separately with external quotations.
9. Legal and Ethical Compliance
The project is open-source infrastructure research. It will not be presented as
financial advice, an investment product, guaranteed income, gambling, or a
promise of returns. The funded phase will not operate a Mainnet custody service
or invite users to deposit valuable assets.
I will disclose material conflicts, sponsorships, security incidents, and
changes to the project’s risk profile.
Applicant Attestation
- My project and requested funding comply with the Community Council guidelines
(legal, gambling, financial advice, sanctions, fraud). - I will not use funds for prohibited purposes.
- I will disclose conflicts, sponsorships, and material risks.
- I accept milestone reporting and the possibility of payout suspension for
non-compliance. - I am not from a sanctioned country or a sanctioned individual.
10. Supporting Links
- Early community update: Telegram: View @Nimiq
-
Technical protocol / NTMP documentation:
https://nimiq-top.gitbook.io/nimiq-top/ntmp - Development blog: The Blog. - NIMIQ.TOP
-
Council proposal guidelines:
Nimiq Community Council – Proposal guidelines -
Council legal and ethical framework:
Nimiq Community Council Legal & Ethical Guideline Framework
I am genuinely excited about the opportunity to continue developing Nimiq-Anchored EVM Chain!
The idea still fascinates and motivates me as much as it did when I started the
project. It would be a shame to leave it unfinished, not because I have lost
faith in it, but because it has grown too large to move forward responsibly in
the limited time I have left outside my existing commitments. This funding would
give me the focused time needed to keep building and discover how far the idea
can go.
– Mike