Dogecoin Cannot Check DogeOS’s Proofs Yet: The Date Nobody Gave

DogeOS opened its public testnet on Wednesday, and the pitch is a good one. Dogecoin has spent twelve years being able to do exactly one thing, which is move DOGE from one address to another. DogeOS is an EVM-compatible zero-knowledge rollup that settles to Dogecoin, so the roughly $14.8bn of DOGE that currently sits in wallets doing nothing can be lent, borrowed, traded and gambled with. Developers can build on it today.

Then you read the security section, and you notice it is written in two different tenses.

Today, the network is secured by a permissioned sequencer, a validator set, a trusted execution environment and a committee called the Security Council. Eventually, Dogecoin’s own miners will verify the proofs directly, via a proposed upgrade to Dogecoin Core called OP_CHECKZKP.

Everybody covering the launch reported both halves accurately. Nobody asked the question that sits between them, which is: when? Not rhetorically. As a date. We went and measured how far away it is, and the answer is not a number of months. It is that there is currently no mechanism by which the answer could become a number of months.

TL;DR

• DogeOS launched a public ZK-rollup testnet for Dogecoin on 30 September 2026. Today it is secured by a permissioned sequencer, a validator majority, a TEE signer and a Security Council. It says Dogecoin’s miners will eventually verify its proofs instead.
• That future depends on OP_CHECKZKP, a proposed Dogecoin Core opcode. We measured its status: a GitHub discussion opened 435 days ago with 5 upvotes, no maintainer acceptance, and no activity in 228 days.
• The only implementation in the repository is a draft pull request from an unaffiliated contributor, 94 lines, untouched for 251 days, whose proof verifier is labelled MOCK IMPLEMENTATION and returns true if the proof’s first byte is 0x01.
• Dogecoin’s formal proposal repository contains three documents, all from 2014, all still marked Draft, and its README explicitly excludes innovative work from that track.
• A security claim written in the future tense is not a security claim. It is a forecast about people who have not agreed to anything. Satoshie’s fairness claims are written in the past tense: the proof was verified on-chain before the payout fired.

What actually shipped, stated fairly

DogeOS is not vapour and this is not a hit piece. The testnet is live, it is EVM-compatible, it uses test DOGE for fees, and teams are already building lending, trading and stablecoin products on it. It comes from the MyDoge wallet team, and Timothy Stebbing of the Dogecoin Foundation endorsed it publicly at launch, which is notable given the Foundation disowned Dogechain in 2022.

More to the point, DogeOS has been unusually straight about the current trust model. Asked directly by The Block, chief executive Jordan Jefferson confirmed that Dogecoin does not verify the ZK proofs itself, and that bridge state transitions require valid proofs plus signatures from a majority of the validator set and a TEE signer. That is a clear, checkable sentence. Most rollups bury that paragraph.

The unasked half is the word “eventually”. Every launch like this carries a sentence of the form “and later this will be secured by something much better”. That sentence is doing enormous work. It is the reason a permissioned sequencer reads as a phase rather than a design. And almost nobody checks whether the later thing has a date, a venue, a process, or a single person obliged to deliver it.

We went and measured it

OP_CHECKZKP was proposed on 22 July 2025 by jordanj77, the DogeOS founder, as discussion #3869 in the Dogecoin Core repository. Measured today, 1 October 2026:

• It has been open for 435 days.
• It has 5 upvotes.
• It sits in the discussion category “General”, described in the repository as “Chat about anything and everything here”.
• It has 16 top-level comments and 49 comments including replies. Thirty-four of those come from accounts with no association to the repository at all.
• No answer has been marked. Nothing has happened on it in 228 days.

That reads worse than it is, and the reason matters. One Dogecoin Core maintainer, patricklodder, engaged with it seriously and repeatedly: thirteen substantive replies, on soft-fork mechanics, on whether Rust belongs in consensus code, on trusted setups, on verification cost. This is a maintainer doing the job properly on a proposal he did not ask for.

Which is what makes his verdict load-bearing. On 26 October 2025, 339 days ago, he wrote:

“The implementation that was linked needs a lot of work. I’m not sold on the protocol proposal either yet, but we need to have these discussions anyway, so it’s good to have that.”

And he had already named the condition under which he would oppose it outright:

“Of course we need verification to be performant, and if we end up with a proposed implementation where a single input will take 1000x the cost of an ECDSA sig, then it will not be useful, become highly controversial, and I probably will be on the NO side of that too.”

That is not obstruction. It is a maintainer being clear in public, which is the correct behaviour and considerably better than silence. But it means the live state of the dependency is: the person whose agreement is required has said, on the record, that he is not yet convinced, and nobody has moved it since.

The implementation is a mock, and it is not DogeOS’s

There is exactly one pull request in the entire Dogecoin Core repository that mentions CHECKZKP. It is #3952, opened on 9 December 2025 by a contributor called SukanyaByteSavy, who as far as we can tell has no connection to DogeOS. The DogeOS founder’s account has opened no pull requests against the repository at all.

The pull request is still a draft. It has one commit, 94 added lines across six files, zero comments and zero review comments, and it has not been touched in 251 days.

We read the diff. Here is the complete proof verifier that is meant to let Dogecoin’s miners check a rollup’s execution:

// TODO: Integrate libsnark or halo2 backend here for real ZKP support.

bool VerifyZKP(const std::vector<unsigned char>& proof, const std::vector<unsigned char>& public_inputs)
{
    // MOCK IMPLEMENTATION FOR PROPOSAL
    // Accepts proof if it starts with 0x01.
    // Rejects otherwise.

    if (proof.empty()) {
        return false;
    }

    // Mock specific: Check for magic byte to simulate successful proof
    if (proof[0] == 0x01) {
        return true;
    }

    return false;
}

The accompanying functional test is a pass statement under the comment “For now, just logging that we implemented the test file.” The public_inputs parameter is never read. The opcode case in the script interpreter does not pop its operands off the stack, unlike every comparable opcode in the codebase. And none of the six changed files touch versionbits or chain parameters, which means there is no activation mechanism in the patch at all, soft fork or otherwise.

To be completely fair to its author: it is honestly labelled, it is explicitly a draft, and a mock skeleton is a legitimate way to open a conversation about an opcode’s shape. Nobody is pretending this is finished.

That is precisely the point. Nobody is pretending. And yet a live product’s security roadmap rests on it, and the distance between those two facts has gone unmeasured by everyone who covered the launch. The eventual guarantee is currently 21 lines of C++ that returns true when a byte equals one.

There is no route from here to there

Here is the part that convinced us this post was worth writing, because it is a fact about Dogecoin rather than about DogeOS.

Dogecoin has a formal proposal repository, dogecoin/dips, Dogecoin Improvement Proposals. We looked inside it. It contains three DIPs. They are numbered 0070, 0071 and 0072, they were all written in 2014, they all adapt Bitcoin’s payment protocol BIPs, and the one we read is still marked Status: Draft twelve years later. Ten pull requests have ever been opened against it. The last content push was in October 2023.

And the README rules the track out for this anyway:

“DIPs are only to be used where minor modifications are required to a BIP to make it suitable for Dogecoin. For any innovative work or significant divergence from a Bitcoin standard, documents should be prepared for submission as standards track RFCs.”

There is no such RFC process. There is no repository for it, no index, no template, no queue. So a new consensus opcode is explicitly out of scope for the only formal proposal track that exists, and the alternative it points at is not an artefact you can file anything into. Which is why OP_CHECKZKP is a chat thread. Not because DogeOS filed it lazily, but because a chat thread is where it goes.

Then, even assuming code gets written, reviewed and merged, there is one more gate. As patricklodder put it when a commenter suggested nodes could opt in:

“That’s not how soft-forks work. It will be mandatory for miner-side which is what the softfork mechanism does.”

Miners have to signal. Miners are not employees of anyone in this story. We have written before about what happens when a core team and its mining pools disagree: on Ravencoin, the core team asked the pools to reorganise from a particular point, and the pools simply declined. Asking nicely was the entire mechanism available.

The property that makes it honest is the property that makes it unbankable

In August we praised Bitcoin’s change process for stalling BIP-110 in public at under 3% miner support. The argument was that three properties made it admirable: the rules were written down in advance, refusal was unilateral because not upgrading your node was a vote, and the whole thing was observable from outside without a statement from anyone.

We stand by that. But it cuts both ways, and this is the sharper version of the point.

A change process you can refuse is a change process that can refuse you. The same unilateral refusability that makes open consensus trustworthy is exactly what makes “the miners will eventually verify our proofs” an unbankable promise. If the process could be driven to completion by the party that wants the outcome, it would not be worth having. Its value to you as a Dogecoin holder is precisely that DogeOS cannot make it happen.

So DogeOS is in a genuinely hard position, and not through any fault of its own. It can write the prover. It can run the sequencer. It can pay for audits, ship the bridge, court the developers. Every other item on its roadmap is an engineering task with an owner. This one is a persuasion task, aimed at people it does not employ, through a venue that is a general chat category, with no deadline, no quorum rule and no defined point at which anybody has to say yes or no.

The tense test

Here is the general rule, and it is portable well beyond Dogecoin.

Read the sentence describing your protection. Check the tense. If it is future, it is not a security property, it is a forecast about a third party.

“The coordinator verified the VRF proof on-chain before the payout fired” is a claim about an event that either happened or did not, and a stranger can check it without anyone’s cooperation. “Dogecoin’s miners will verify our proofs” is a claim about a social outcome, in a venue with no clock, dependent on parties who have made no commitment.

Both sentences can appear in the same security section. Only one of them is checkable, and it is never the one doing the reassuring.

This is adjacent to something we covered in September about what a testnet cannot test, but it is a different failure. There the issue was that mechanisms secured by cost do not transfer onto a testnet, because the security parameter has been set to zero. Here the mechanism is not weakened, it is simply a different mechanism from the one described, and the switchover is contingent on strangers agreeing.

And “eventually” has a base rate. We pulled the numbers from DeFiLlama this morning rather than taking them from the coverage. Dogechain, which launched in 2022 with a comparable pitch and took $4.6m of deposits in days, currently holds $270.92 in tracked DeFi. Shibarium, which followed in 2023, holds $140,508, down from a peak around $6.4m. Neither of those is an indictment of DogeOS, which has better backing, a better technical plan and the Foundation’s blessing. They are just what the distribution looks like for promises of this shape.

What Satoshie claims, and in which tense

Every fairness claim we make about a Satoshie draw is about something that has already happened by the time you can check it.

The contract is deployed on Base. ticketsMinted is readable state before you buy, so your odds are arithmetic over a public number rather than a disclosure we chose to make. The stake is escrowed in the contract at entry. The Chainlink VRF coordinator verifies the randomness proof on-chain before the callback is allowed to execute, which means a draw cannot resolve on a number nobody checked. Resolution and payout happen in one transaction. There is no admin key over a draw in flight.

Not one clause in that paragraph requires a future soft fork, a committee vote, a miner signal or a roadmap item. Everything in it is in the past tense from the moment a draw settles, and a stranger can confirm all of it from the chain without our cooperation and without our permission.

That is not a boast about superior engineering. It is a narrower claim than it sounds: we are not relying on anyone’s future good behaviour because we built something small enough not to need it.

Honest limits

One: our liveness claim is future-tense, and we know it. Base runs a single sequencer operated by Coinbase, and the decentralisation of that sequencer is an item on somebody else’s roadmap, which is structurally the same kind of promise we have spent this post taking apart. The distinction we will defend is narrow and specific: no Satoshie fairness claim depends on a future change by a third party, but our availability does. If Base stops, entries, VRF requests, callbacks and payouts all stop. That is a real dependency and we are not going to describe it as a phase.

Two: we have never had to ask strangers for permission, so we have never been refused. DogeOS is attempting something structurally harder than anything we have attempted. Changing consensus rules in software you do not maintain, for a chain you do not control, is a far more ambitious act than deploying a contract to a chain that already does what you need. A project that has never had to persuade anyone does not get to feel superior about never having been turned down.

Three: we shipped a testnet once too, and we wrote in the future tense when we did. Satoshie announced a testnet and a testnet block explorer in 2023, and our posts from that period are full of things that were going to happen. The gap between a working testnet and a running mainnet is where most of this industry dies, and we were on the wrong side of it for a while. Pointing at someone else’s unannounced mainnet date requires owning that.

Three questions worth asking before you deposit anything

1. Which tense is the security claim in, and who has to act for the future-tense part to happen? Name the party. If you cannot name one, there isn’t one.
2. If that party says no, or simply never says anything, what is the fallback trust model? It is almost always the arrangement you are using today, so read that one as if it were permanent.
3. Is the temporary arrangement described as temporary anywhere that binds anybody? A blog post is not a commitment. A deadline nobody set cannot be missed.

DogeOS deserves credit for saying out loud that Dogecoin does not check its proofs today. That is more disclosure than most rollups manage, and more than any crypto casino has ever offered about its random number generator. But disclosure converts an unknown trust assumption into a known one. It does not convert a known one into a dated one.

Until somebody in the Dogecoin repository says yes, and miners signal, the eventual guarantee is a permissioned sequencer, a validator majority, a TEE signer, a Security Council, and a draft pull request that approves any proof beginning with the byte 0x01.

That is a perfectly honest arrangement. It is just not the one in the headline.

Satoshie runs provably fair raffles and coinflips on Base, using Chainlink VRF for randomness. Every draw is verifiable on-chain, in the past tense, by anyone. See how it works.

📷 Photo by Indira Tjokorda on Unsplash