We first hinted at opening NIM to other networks in Beyond the Crypto Label, where we shared that we no longer regard isolation as a virtue. After exploring the options, the Nimiq technical roadmap proposal set the direction: interoperability with EVM networks as a first step. We are building a way for NIM to be used on those networks, and to come back.
The first version of the bridge is already in implementation and testing, and questions from the community have shown interest in knowing more about it. So why not start from the beginning: what a blockchain bridge is, the principles behind it, and the problems it aims to solve. The Nimiq bridge's technical details will come in a second post.
Two networks that cannot see each other
A blockchain is a network closed by nature. Every computer running the Nimiq network agrees on what happened on the Nimiq blockchain, and every computer running Ethereum agrees on what happened on the Ethereum blockchain. Neither can look into the other. A contract on Ethereum has no way to know that you sent NIM somewhere, and the Nimiq network has no way to know that a token on Ethereum was destroyed.
A bridge is the piece of software that carries a fact from one world into the other, in a form the other world can check and verify. From the user's perspective, it looks simple: NIM goes in on one side, and a token worth exactly that NIM comes out on the other side, where it can be used in places NIM couldn't be used before. Later, the token can go back in, and the same NIM would come out. That is what interoperability means in practice: two networks that cannot see each other, acting on each other's facts.
A good analogy is a cloakroom. You hand over your coat, you get a ticket, and the ticket is worth exactly one coat. You can hand the ticket to someone else, and whoever holds it can collect the coat. The bridge works the same way, with two differences that matter: the cloakroom is a contract rather than a person, and anyone can check that there are never more tickets than coats.
In Nimiq's bridge, the coat is NIM, locked in a bridge contract on the Nimiq network. The ticket is NIM on the EVM network, a token that represents NIM 1:1. Moving NIM across is called lock and mint. Bringing it back is called burn and release.
Every NIM on Polygon has exactly one NIM locked on the Nimiq network behind it.
What it opens up for NIM
Today, NIM lives on the Nimiq network and nowhere else. The Nimiq network is built for fast, cheap, and self-custodial payments. But a large part of what people do with crypto happens on "general-purpose blockchains" like Ethereum, and almost all of it only speaks one token format, ERC-20. Without a bridge, NIM cannot take part.
Before bridges, there was no way to take a token to another network. If you held NIM and wanted to use something on Ethereum, you sold the NIM, bought the token you needed, and withdrew it to the other network. That meant handing your funds to a company, paying fees twice, going through its sign-up process, and taking the price risk of two trades, all to end up holding a different asset than the one you started with. Coming back meant doing it all again in reverse. A bridge replaces that chain of steps with one: the token you already hold stays yours, locked on its own network, and a representation of it appears on the other network, where it can be used as if it were native. When you are done, you hand the representation back, and the original is yours again. The representation of NIM on another network takes that network’s name: NIM on Polygon, NIM on Ethereum, and so on.
With NIM on an EVM network, a NIM holder can:
- Swap NIM for stablecoins and back. The bridge enables this on decentralized exchanges such as Uniswap and Curve, where liquidity is pooled, and no intermediary is needed.
- Use NIM in applications not supported by the Nimiq blockchain, such as lending, liquid staking, and aggregators that find the best swap route.
- Pay with NIM through services that settle in ERC-20 tokens and connect to real-world payment rails.
- Hold NIM in wallets and hardware wallets that support ERC-20 tokens but do not support Nimiq natively.
None of this requires Nimiq to change what it is. The network stays a payments chain. The bridge gives NIM a second place to be useful and a way back. It opens NIM and the Nimiq network to the world.
Why we are building one
Nimiq exists to empower individuals with open and independent money. For years, that meant making NIM fast, cheap, and easy to hold. The next step is letting NIM go where its users want to use it, without giving up any of its fundamental properties. A bridge is how a payments network joins the wider economy on its own terms.
There are many ways to build a bridge, and the simplest ones are services that hold users' funds on one side and issue tokens on the other. They work, and they are fast to build, but they ask users to trust an operator with their money, which is the one thing Nimiq has never asked. So the team set a requirement first and chose a design second: no party, including Nimiq, may ever be able to move locked NIM.
The bridge on EVM networks
The bridge connects Nimiq to EVM networks, aka networks that share Ethereum's design and its ERC-20 token standard. One bridge design works on all of them. We will start with Polygon, which the Nimiq Wallet already uses for USDC and USDT. Each connection is its own bridge with its own token, and more EVM networks will follow.
A breakdown of the bridge components
Every bridge executes four operations:
- Takes the funds in
- Records what happened in a form the other network can trust
- Carries that record across
- Lets the funds out on the other side
In Nimiq's bridge, those operations belong to three components:
Bridge contracts, one on each network. On Nimiq, the bridge contract holds locked NIM and releases it. On the EVM network, the bridge contract is the token itself: it mints NIM on the EVM network when NIM has been locked, and burns it when a holder wants their NIM back. Contracts are code that runs the same way for everyone; nobody operates them.
Oracle contracts, one on each network. This is how each network learns about the other. An oracle is a small contract that stores hashes of what happened on the opposite network: a hash is a short piece of data that summarizes a whole batch of transactions, and from which any single transaction can be proven. The Nimiq oracle holds hashes of the EVM network. The EVM oracle holds hashes of Nimiq.
The relayer is off-chain. Contracts cannot reach outside their own network, so a service watches both networks, computes the hashes, and writes them into the oracles. An operator runs that service. Writing to an oracle is the only action in the whole system that requires permission, and only the operator has it.
The round trip
Moving NIM out of the Nimiq network:
- Lock. You send NIM to the bridge contract on Nimiq, with your EVM address attached. Once a macro block seals the transaction, it is final and cannot be reverted.
- Attest. The relayer writes the hash of that batch of Nimiq transactions into the EVM oracle.
- Prove and mint. You present a proof to the EVM bridge contract that your transaction is in the batch. The contract checks it against the oracle and mints NIM to your address on the EVM network. This step is yours: it needs your signature, and nobody can do it in your place.
Bringing NIM back into the Nimiq network:
- Burn. You burn your NIM on the EVM network and point to the Nimiq address that should receive the NIM.
- Attest. After enough blocks have been built on top of the burn for it to count as settled, the relayer writes the hash of the batch into the Nimiq oracle.
- Prove and release. You sign a release with the proof that your burn is in the batch, and the Nimiq bridge contract checks it against the oracle and releases the NIM to you. The fee comes out of the released amount, so you need no NIM beforehand.
The two directions wait for different signs of finality, because the two networks finish transactions differently. On Nimiq, a transaction is final once a macro block has sealed it. On an EVM network, the bridge waits for several blocks on top instead, a margin the operator sets. Everything else about the two directions is the same: lock or burn, attest, prove, release.
Where the trust is
The honest way to describe any bridge is to say who you have to trust, for what you have to trust them, and what happens if they fail. For Nimiq's bridge, the answers are short.
One trusted role. Almost everything in the system is authorized by proof rather than by permission. Locking NIM is an ordinary transaction. Minting NIM on the EVM network needs a valid proof of a final lock. Burning it needs only the tokens. Releasing NIM needs a valid proof of a burn. Reading the oracles, checking the numbers, even deploying a new bridge: all open to anyone. The one exception is writing hashes into the oracles, which only the operator can do. That is the full trust assumption.
Non-custodial. The operator can never touch the funds. The Nimiq bridge contract has no withdrawal function, and no owner who can move its balance; the only way NIM leaves it is against a valid burn proof. Oracle ownership gives no access to locked NIM, no power to burn or move anyone’s NIM on the EVM network, and no way to block a transfer whose proof is already valid.
1:1 backing. Every NIM in circulation on the EVM network corresponds to NIM held in a bridge contract, because minting requires proof of a lock and release requires proof of a burn. Each transfer can be completed exactly once.
Nobody can refuse you, and nobody can act on your behalf. The receiving account completes minting and release, with its own signature and a proof built from public data. The operator cannot decline a transfer or approve some but not others, and nobody, including the operator, can redeem one without your key.
If the operator fails? Two failures are possible:
- If the operator stops, nothing is lost or stolen. Transfers stop completing on their own, because the hashes they need stop arriving, until the relayer runs again.
- If the operator lies by writing a hash that does not match what actually happened, the contracts cannot tell. They check who wrote the entry, not whether it reflects reality on the other network. That is the risk the design accepts, and it accepts it for a reason: every hash is computed from data that is already public on both networks, so anyone can recompute what each entry should contain and compare. A false entry does not match anything in the public record and is identifiable as soon as someone looks. The design chooses detection over prevention, in exchange for a system where nothing else needs trust.
The two numbers worth watching are the ones the cloakroom analogy suggests: NIM in circulation on the EVM network should never exceed NIM locked, and NIM released should never exceed NIM burned on the EVM network. Both can be checked by anyone, from public data, at any time.
A sneak peek at Nimiq’s design
After brainstorming possible designs for the Nimiq bridge, we settled on one that requires new contract types on the Nimiq network, a protocol upgrade to ship them, and an operator for one task.
The Nimiq side gets two new contract types: a bridge contract that holds locked NIM and releases it, and an oracle contract that stores attested state from the other network. The EVM side mirrors them, with the bridge contract doubling as the EVM version of the NIM token. Between the two sits a relayer that only carries those attestations across: it never interprets them, never holds funds, and never completes a transfer. Each network verifies every transfer, and the receiving account completes each transfer with its own signature; nobody else can redeem it. Coming back costs no NIM up front, because the fee is taken from the NIM being released. Nothing in the design names a specific EVM network, and the first integration is Polygon.
What comes next
The bridge needs two new contract types on the Nimiq network, which means it ships as part of an upgrade rather than as an app you can install. When it is close to launch, a second blog post will cover the mechanism in detail: how the hashes and proofs are built, how the two networks' finality rules are handled, and how to verify the bridge independently. Until then, this blog post sets the foundation. One trusted role, no custody, 1:1 backing, and a round trip anyone can complete.
Thank you for all the support. We are excited about the next phase of Nimiq, and we imagine you are too!
Pura Vida,
Nimiq