The Dogecoin ZK Upgrade (OP_CHECKZKP), Explained

OP_CHECKZKP is a proposed Dogecoin opcode that would let Dogecoin verify zero-knowledge proofs directly in its consensus rules. It has not been merged. It was submitted by DogeOS in July 2025, exists as an open GitHub discussion, and has drawn substantive technical objections from Dogecoin Core maintainers. There is no implementation timeline.

That matters beyond Dogecoin's protocol politics, because it is the piece that would let a Dogecoin rollup settle trustlessly back to Dogecoin. Without it, any "Dogecoin Layer 2" is relying on something other than Dogecoin for its security.

What OP_CHECKZKP would let Dogecoin do

Dogecoin's script language can check a signature and move coins. It cannot evaluate a mathematical proof that some computation was performed correctly somewhere else. OP_CHECKZKP would add exactly that one capability — nothing more.

A zero-knowledge proof is a small piece of data that demonstrates a large computation was carried out correctly, without requiring anyone to redo it. If Dogecoin could check such proofs, a separate chain could process thousands of transactions off-chain, compress the result into one proof, and have Dogecoin confirm its validity. Dogecoin stays simple and cheap; the applications live elsewhere but inherit Dogecoin's security.

DogeOS's announcement framed the target applications as DOGE-backed lending markets, decentralized exchanges, verifiable multiplayer games, NFT and identity platforms, and zk-rollups supporting thousands of transactions per second.

The proposal is deliberately narrow. It takes a soft-fork path using OP_NOP10, which older nodes ignore, preserving backward compatibility. It introduces no virtual machine and no general programmability to Dogecoin itself. The design intent is a single primitive, not a platform.

The technical design

Two proof modes are specified.

Mode 0 is Groth16 over the BLS12-381 curve. The stack layout takes eight proof elements, two 32-byte public inputs, and six 80-byte verifying-key chunks.

Mode 1 is reserved for PLONK with Halo2/KZG over BN256, using variable-length proof and verifying-key blobs reassembled from 80-byte chunks, capped at 4,096 bytes for a proof, 8,192 for a verifying key, and 64 public inputs.

The mode selector is the forward-compatibility mechanism: new proof systems can be added later without another consensus change to the opcode itself.

Why DogeOS wants it

DogeOS is building a zkEVM application layer whose documentation describes an end state where "the Dogecoin blockchain verifies that every transaction on DogeOS is valid," with transaction data published to Ethereum for availability.

The verification half of that sentence requires OP_CHECKZKP. Dogecoin cannot check a proof today, so DogeOS cannot today settle to Dogecoin in the way its own documentation describes. The proposal is not a nice-to-have adjacent to DogeOS's roadmap — it is the load-bearing assumption underneath it.

Tim Stebbing, a director of the Dogecoin Foundation, endorsed the direction: "Dogecoin gaining the ability to integrate with ZK L2s is the kind of interoperability we need to build ecosystem utility, allowing the L1 to focus on being the fastest, best, most fun blockchain and means of exchange for all humanity."

Foundation support is not Core approval, and the two should not be conflated.

The objections

The discussion is substantive rather than dismissive. Four distinct concerns have been raised.

Verification cost and denial-of-service. Every node must verify every proof in every block, so a cheap-to-create, expensive-to-verify operation is an attack vector. The proposal's own estimate is "on the order of a couple milliseconds per proof (roughly 2-10ms depending on optimization and hardware)," with a more pessimistic figure of "~10-20ms total" for Groth16 given BLS12-381 pairings at 4–8ms each. The discussion works through the implication directly: "At 20ms each, 1000 proofs would take 20 seconds to verify... problematic given 60s block interval." The proposed mitigation is a hard cap — "at most one OP_CHECKZKP per script and a maximum of 5 such transactions per block."

Rust in consensus-critical code. A contributor identified as cf objected: "As much as I love rust, I think adding a rust crate to the dogecoin codebase for the sole purpose of verifying one of the proposed modes is not a good idea (CPP port?)." Maintainer Patrick Lodder agreed on maintainability grounds: "We're not a big enough repo to have multi-language on essential components... adding rust on the most important part of the codebase... is asking for trouble." This is an argument about who can audit the code, which for a consensus change is the argument that usually decides things.

Quantum resistance. A participant, Pimax1, raised it squarely: "Mode 0 is Groth16 on BLS12-381. That's not post-quantum and a sufficiently capable QC (Shor-style discrete log attacks) would undermine ECC assumptions and could enable forged proofs." Lodder acknowledged the concern without treating it as urgent — "The clock is ticking... No need for panic. I can factor 15 too, in my head, instantly. That is not as awesome as the marketing departments make it sound" — and pointed to BIP-360 and Script Restoration as longer-term directions.

Trusted setup. Groth16 conventionally requires a trusted setup ceremony, a recurring objection to that proof system. Lodder noted it is not inherent to the category: "Not every ZKP solution needs a trusted setup... ZCash got rid of theirs something like 4-5 years ago."

Lodder's overall position, and the line to quote if you quote one: "The implementation that was linked needs a lot of work. I'm not sold on the protocol proposal either yet." He has also described intent to stand up "an uncheckpointed testnet, with more robust parametrization" as a venue for evaluating soft-fork ideas collaboratively.

Read that as engaged skepticism, not rejection. A maintainer proposing a test environment is describing a path. But a path with no dates on it is not a roadmap.

What DogeOS can ship without it

This section is inference, clearly labeled. DogeOS has not published a fallback design.

A rollup can operate without L1 proof verification — most do. Transactions execute off-chain, data availability is handled elsewhere (DogeOS's documentation already points at Ethereum for this), and the bridge is secured by something other than Dogecoin: a multisig, a validator committee, or an economically bonded operator set. That is a working system, and it is how essentially every chain calling itself a Dogecoin Layer 2 operates today.

What it is not is trustless with respect to Dogecoin. Users would be trusting DogeOS's operators rather than Dogecoin's proof-of-work. That is a materially weaker guarantee, and it is the specific thing OP_CHECKZKP would fix.

The practical consequence for anyone evaluating DogeOS: if a mainnet launches while this proposal is still unmerged, the first question to ask is what secures the bridge instead. See our DogeOS bridge guide for what is and is not documented today.

Status tracker

Inference, labeled: seven months of inactivity on a consensus proposal is not unusual for Dogecoin, which changes slowly by design and by culture. It is also not a sign of momentum. The realistic next signal is either a revised implementation addressing the language and DoS objections, or the appearance of the test network Lodder described. Neither has a date.

We update this table whenever the discussion moves.

What changes at mainnet

• If OP_CHECKZKP is merged and activated, DogeOS could become the first rollup genuinely settling to Dogecoin, and every "Dogecoin Layer 2" claim becomes checkable against a real standard.
• If DogeOS launches a mainnet first, the bridge's actual trust model becomes the question that matters, and this page becomes the reference for what it is not relying on.
• If the proposal is formally rejected, expect either a revised proposal or a different settlement design. Watch for what replaces it, not for silence.

Background in What is DogeOS?. For how this compares to Dogecoin's other EVM option, see DogeOS vs Dogechain.

TrustSwap is not affiliated with DogeOS, MyDoge or the Dogecoin Foundation. DogeOS has not announced a token; any asset trading under the DogeOS name is unaffiliated with the project.