Anakun@anakun
No. A based rollup sequences transactions through L1 proposers and posts execution results back to L1 with fraud proofs or validity proofs. OPNet does neither.
There's no sequencer, no fraud proof window, no validity proof submitted on-chain. OPNet nodes independently reexecute every transaction from the raw L1 data.
There's no "posting results back" because every node derives the same state by running the same deterministic execution on the same Bitcoin transactions. It's closer to "everyone runs the same computation and agrees on the result" than any rollup model.
The consensus isn't about who sequences or who proposes. It's about epoch mining, where miners do SHA1 PoW on top of Bitcoin PoW to commit the checksum root that fingerprints the entire state.
Now, SHA1 miners do not post the result onchain.
They submit their mined solution to opnet nodes that are willing to accept their solutions. Similar to bitcoin core where you submit your solution to your bitcoin core node so it can broadcast it.
Now, epoch data must appear onchain somehow right. When you do an opnet transaction, you include something called an epoch solution and optionally (enabled by default), you add about 64 bytes of extra data submitting the proof of a valid epoch solution your node knows about. This gives you a gas discount on your execution.
Even if you are not the one who mined the epoch, you contributed to the network acting as a "relay". Miners don't "inscribe" or "submit to bitcoin". That would be a waste of block space.
The key distinction: rollups (based or not) have a prover/verifier split. Someone executes and posts proofs, everyone else verifies those proofs.
OPNet has no prover/verifier split. Every node executes independently. The checksum root is how nodes confirm they all arrived at the same state.
Now to the checksum root question. Yes, a forged checksum is mathematically bound to a forged state. That's exactly why the system works. The checksum root is a cryptographic fingerprint of the entire execution state. If you produce a different checksum, every other node that independently executed the same L1 transactions will have a different one. The forgery is immediately detectable.
You can't make a fraudulent state produce the same checksum as the honest state because execution is deterministic. Same inputs, same execution, same checksum. Different execution, different checksum. There is no way to find a collision. If you somehow manage to find a collision.. well, nice, you found a sha256 collision!
There are no trust assumptions here. It's cryptographic determinism. Same inputs produce same outputs. No trust required, just math.
One more thing on ordering, and this is where MEV resistance comes in. OPNet doesn't blindly process transactions in whatever order Bitcoin miners included them in the block. Miners can reorder transactions however they want for their own profit, that's the classic MEV problem. OPNet eliminates this by rebuilding the transaction order deterministically after the block arrives.
Here's how it works:
OPNet nodes take all the transactions from a Bitcoin block and build a dependency graph. If transaction B spends an output from transaction A, then A must execute before B. That's the hard constraint. Within that constraint, transactions are sorted by priority fee, highest fee first. This is deterministic because every node sees the same fees.
But.. what if two transactions have the exact same priority fee and no dependency relationship?
They get tie broken by a deterministic hash comparison on their computed indexing hashes. It's a raw byte-level comparison, so the ordering is always the same regardless of which node computes it. Two transactions can never have the same hash (that would be the same transaction), so there's always a definitive order.
The result is... every OPNet node independently arrives at the exact same execution order without any central sequencer, without any miner influence on contract execution ordering, and without any privileged actor deciding who goes first.
The ordering is a pure function of the transaction data itself. Bitcoin miners can order transactions however they want in the block, it doesn't matter, OPNet will reorder them the same way every time.
That's why it's MEV resistant. Miners can't profit from reordering contract execution because OPNet throws away their ordering and rebuilds it deterministically.
Now, I would like to explain you how opnet epoch rewards work:
The epoch miner mines a SHA1 solution off-chain and submits it to OPNet nodes. The nodes store valid solutions. Now here's where it gets clever.
When a regular user makes an OPNet transaction, the user asks their node for the current valid epoch solution. The node hands it over, and the user's wallet builds the transaction itself, including a reward output that pays BTC to a timelocked address derived from the epoch miner's public key.
The user doesn't choose who to pay, it's determined by whoever mined the valid epoch solution. If the user tries to pay the wrong miner or constructs the reward output incorrectly, the transaction is instantly invalid. Every node on the network rejects it. There's no wiggle room.
Now what if the user is connected to a malicious node that tries to game the system?
Doesn't matter.
The user's wallet independently validates the epoch solution using cryptographic signatures and block header proofs. If the node tries to lie about who the miner is or attempts to extract more money from the user, the client catches it before signing.
A bad node can't cheat you because your own wallet verifies everything locally.
The timelocked address uses CheckSequenceVerify with a 75-block lock. Only the miner who owns the corresponding private key can spend that BTC, and only after 75 blocks have passed. That's roughly 12.5 hours. No multisig. No custodian. No bridge. No middleman. Just a Bitcoin script that says "only this key, only after this many blocks."
So the user gets a gas discount for carrying the epoch proof, the miner gets paid trustlessly in BTC locked to their own key, and a malicious node can't game either side. The whole thing happens inside the normal transaction flow. No extra steps, no separate reward transaction, no trusted intermediary.
Now you might ask urself.. Wtf is CSV, why the fuck does opnet use CSV everywhere, I see this everywhere in the doc, csv, csv, wtf why....??
OPNet uses CSV timelocks everywhere for one reason.
Transaction pinning.
Here's the problem without CSV:
On Bitcoin, once a transaction is broadcast, anyone who received an output from it can try to spend that output immediately.
In a system like OPNet where contract execution can partially revert (the BTC transfer goes through on L1 even if the contract logic fails), this creates attack vectors.
Someone could receive BTC from a swap, immediately spend it to themselves at a higher fee, and pin the original transaction so it can't be replaced or rolled back. They got the BTC, the contract reverted, and the other side got nothing.
CSV closes this completely. Every recipient address in OPNet is timelocked. You can't spend the output for X blocks after it confirms.
This means you can't pin a transaction by racing to spend its outputs. The outputs are frozen. By the time the timelock expires, the epoch is buried, the state is final, and there's nothing left to attack.
It's like putting a mandatory cooling-off period on every payment. You received BTC from a swap? Cool, you can't touch it for a while. That window gives the network time to finalize everything. Once the lock expires, the money is yours and the state is settled. No disputes, no races, no pinning.
The miner rewards use a 75 block CSV lock. Swap outputs use CSV locks. It's the same principle applied everywhere: freeze the output long enough for finality to kick in, then release. Simple, effective, and it uses a Bitcoin opcode that has existed since 2016. No new features needed.
There's one more layer of protection on epoch rewards. Miners don't get paid for the current epoch. The reward output in your transaction actually pays the miner from 3 epochs ago.
Why? Reorgs.
Bitcoin blocks can get reorganized. A block you thought was confirmed can get replaced by a competing block. If we paid the miner for the current epoch immediately, and then a reorg happened, the epoch solution could change, the miner could change, but the BTC already went to the wrong person. That's unrecoverable, transaction invalid.
How do you fix this?
You do that by delaying the reward by 3 epochs, the system waits until the epoch is buried deep enough that a reorg is practically impossible. By the time the reward pays out, that epoch's solution is settled history. The miner who actually did the work gets paid, not whoever temporarily had a solution during a chain reorganization and your transaction is always safe.
So it's a double safety net. The CSV timelock prevents the miner from spending the reward too early, and the 3 epoch delay prevents paying the wrong miner entirely. Belt and suspenders.
Now, one thing people do not understand about OPNet.
Partial Reverts.
This is one of the most important things to understand about OPNet. On Ethereum, if a smart contract call reverts, nothing happens. The whole transaction rolls back like it never existed.
OPNet can't work that way because OPNet transactions are real Bitcoin transactions. Once a Bitcoin transaction is in a block, the BTC moved.
Period.
L1 doesn't care if your contract logic failed. The sats are gone.
So on OPNet, if a contract execution reverts, the Bitcoin transfer still goes through but the contract state rolls back. The BTC moved, the smart contract pretends nothing happened. This is a partial revert.
This sounds dangerous, and it is if you don't design around it. That's exactly why reservation system are extremly important for everything that touch Bitcoin and why CSV timelocks exist. This is why Nativeswap work.
About miner censorship..
We already covered how CSV prevents transaction pinning. But there's another attack it blocks: miner censorship of dependent transactions.
Say you're doing a swap on NativeSwap. The flow is two transactions: first you reserve (lock in the price and commit), then you execute (send the BTC and complete the swap).
Without CSV, a malicious miner could see your reservation, then deliberately exclude it from their block while including your execution transaction. Your execution runs, tries to reference a reservation that doesn't exist onchain yet, and fails.
The contract reverts, but remember, partial reverts.
Your BTC still moved. You sent BTC, got nothing back, and the miner pockets the difference.
CSV prevents this because the outputs from the reservation are timelocked. The execution transaction can't even be valid until the reservation's CSV lock period passes.
A miner can't skip ahead to the execution without the reservation being confirmed first, because the execution spends a timelocked output that doesn't unlock until X blocks after the reservation confirms.
This is what you see on motoswap the "reorg protection". Clever design.
The ordering is enforced by Bitcoin script itself, not by trusting miners to be honest.
So CSV does three things at once:
1. Prevents transaction pinning
2. Prevents miner censorship of dependent transactions
3. Gives the network time to reach finality.
One opcode, three attack vectors closed. All of this is already possible on Bitcoin. We didn't reinvent anything.
Nobody did anything like this because the UX is extremly hard to make simple. We did it.
One last thing I would like to cover here is, Quantum Resistance. Thats a hot topic on X.
Every other Bitcoin protocol relies solely on elliptic curve cryptography for identity. Your Bitcoin address, your Taproot key, that's all ECDSA/Schnorr.
If quantum computers break elliptic curves, every address on Bitcoin is exposed.
OPNet doesn't wait for that to happen. Every OPNet user has two keys: their Bitcoin Taproot key (the classical one) and an MLDSA key (the quantum-resistant one).
MLDSA is a lattice-based signature scheme that quantum computers can't break. It's not theoretical, it's a NIST standardized post-quantum algorithm.
Your OPNet identity is your MLDSA key. When you interact with contracts, when you claim tokens, when the network maps who you are, it uses MLDSA. Your Bitcoin key proves you own a UTXO on L1. Your MLDSA key proves who you are on OPNet. Two separate systems, two separate security assumptions. But.. OPNet always require your schnorr identity. Dual key system. So even if one is compromised, both have to be compromised for it to even matter.
So even if quantum computers eventually crack elliptic curves, your OPNet identity and contract state are still protected. The Bitcoin layer would have its own problems at that point, but OPNet's identity layer is already built for a post-quantum world.
This isn't a future upgrade or a roadmap item. It's live. Every wallet, every transaction, every contract interaction already uses MLDSA alongside classical Bitcoin cryptography. Day one design decision, not an afterthought.
OPNet will never have to deal with an upgrade that will introduce some sort of centralisation via zk proof to "fix" the quantum problem similar to other blockchains.
And... The clever part is that OPNet doesn't add a second full signature to every transaction.
Until the MLDSA signature is consensus enabled (forced), you do not have to include a MLDSA signature on your transactions, only when you expose your identity onchain, all transparently.
The MLDSA key is registered once (when you first interact with the network) and from that point on, the mapping between your Taproot key and your MLDSA key is part of the consensus state. Nodes already know the association. You don't re-prove it every time.
So there's no bloat. You're not stuffing a 3309 byte lattice signature into every single transaction. The Bitcoin signature handles the L1 validity (is this a real Bitcoin tx with valid inputs?), and the MLDSA identity is resolved at the execution layer from state that nodes already have.
Every other blockchain that wants to go post-quantum will have to either hard fork to replace their entire signature scheme (breaking every existing address) or bolt on a second signature layer that doubles transaction size. OPNet sidesteps both problems because it was designed with two key systems from the start.
The L1 signature stays small, the post-quantum identity lives in the execution layer, and neither one bloats the other.
Anyways this was my 10 minute rundown of OPNet to you. There'r a lot of things I didnt explain here.
So what is OPNet?
It's not a rollup.
It's not a sidechain.
It's not a metaprotocol stuffing data into OP_RETURN.
It's a deterministic execution layer that runs on Bitcoin as it exists today. No soft fork. No hard fork. No new opcodes. No separate chain. No separate token.
Every OPNet transaction is a Bitcoin transaction.
Every node independently executes the same transactions and arrives at the same state. The checksum root proves they all agree, and that proof rides inside normal user transactions, not as extra data dumped on-chain.
OPNet is not one thing.
It's a system of interlocking parts where every piece exists because removing it breaks something.
Take out CSV and miners can censor your reservations and steal your BTC.
Take out the deterministic reordering and miners extract MEV.
Take out the 3 epoch reward delay and reorgs pay the wrong miner.
Take out the dual key system and you're left with the same quantum migration nightmare every other blockchain will eventually face.
Take out the reservation system and partial reverts let attackers exploit user swapping.
Nothing here is optional. Nothing is decoration. Every mechanism closes a specific attack vector, and they all depend on each other.
None of this required changing Bitcoin. All of it uses Bitcoin opcodes and primitives that have existed for years. The hard part was never "can it be done." The hard part was designing the UX so that all of this complexity is invisible to the user. You click swap, the rest happens.
OPNet couldn't use existing Bitcoin tooling because Bitcoin has no standard. Most of the libraries available were written years ago, are poorly documented, and carry false assumptions.
There's no spec to follow, no reference implementation that handles edge cases properly, no agreed-upon way to do anything beyond basic transactions.
The foundations simply weren't there.
OPNet had to redesign the entire stack from scratch, this is why it took a while.
OPNet have its own libraries, its own wallet, its own SDK, its own transaction builder.
Not because of ego, but because nothing that existed was reliable enough to trust with deterministic contract execution and real money on top of it.
That's OPNet.
OPNet is a community of builders who refused to leave Bitcoin for easier chains.
OPNet is smart contracts without abandoning the strongest settlement layer ever created.
OPNet is the belief that Bitcoin can do more without becoming something else.
OPNet is years of engineering so that you can click one button and never think about any of this.
We didn't fork Bitcoin. We worked with it.
