The 2022 Inflation Claim: Claims vs. Evidence

Derolytics' "irrefutable proof" is a string anyone can forge — and even a genuine one describes a transfer the chain would have rejected.

TL;DR Summary

At the center of every inflation accusation is a string. About a hundred characters of base32, prefixed deroproof1..., pasted into an unpatched DERO explorer where it lights up as Verified ✓ for an amount the explorer renders as 184,467,438,537,095.51434 DERO — roughly fourteen million times the entire DERO supply.

That string is the foundation of the Derolytics "DERO Heist" report (opens in a new tab) and its follow-ups — the source of the 2.2-million-DERO figure, the cited evidence for every downstream claim of laundering, theft, and attribution. It is also a payload proof: a wallet-side display object the protocol gives no third party any way to verify. By design. Ring signatures rely on exactly this ambiguity — if outsiders could verify payload proofs, plausible deniability would die with them.

The technique that produced it became possible in May 2024, when a separate wallet-layer randomness-reuse bug (patched in Release 142) gave outside observers their first means of reading inside DERO's encrypted payloads. Pointed back at a transaction mined on October 17, 2022 — accepted by every validating node, indistinguishable on-chain from any other transfer — that technique returned a value, paired it with a payload proof, and announced an inflation.

The chain never said any such thing. The transaction is the same one it has always been: bounded by range proofs that pin every amount to a non-negative range, conserved by balance proofs that bind inputs to outputs, accepted unanimously. What changed in 2024 was the ability to interpret — and a misreading, intentional or otherwise, of what a payload proof is and does. The entire Derolytics narrative rests on that single misreading. Every chart, every accusation, every dollar figure.

Part 1: The Claim and Its Foundation

The report cites this payload proof as cryptographic evidence — readers paste it into an explorer, see Verified, and treat that as confirmation the on-chain transfer was negative (Proof Types; display-layer only, not consensus). As cited:

Payload proof:  deroproof1qyyj0cgu3htmkumr79sgca75vwsx8kx7zkrjg0nfez46w36qyx4kwq9zvfyyskpqvdpcfhkhk4m7y9d77ehyj7yhnnrv9z0tjr9m5fqe2yx9t27dwtdxy4j4r0llll7vcmaxwjcl8jzfq
Date:           October 17, 2022
Block:          1,081,893
TX:             5bbe1b7eecfe3447cb045b1197a07a214b456968eda8a3d5a90f5fae9ce57e55

The technical claim (as stated in public exploit reports) rests on a single assumption — that the payload proof above is cryptographic evidence, and what verifies on an explorer also represents what consensus accepted:

1. The transfer amount was −2,200,000.00181 DERO — −220,000,000,181 atoms when the bech32 is decoded (Part 2).
2. Stored as uint64 (an unsigned 64-bit integer, no negatives), that negative value wraparound displays as ~184 trillion DERO on explorers — roughly 14 million× total supply.
3. Post-2024 deanonymization is cited to name a fresh wallet as the sender — and to read the wraparound as a ~2.2M DERO credit to that sender, not the ~184 trillion figure on screen.
4. Conclusion: consensus failed → ~2.2M DERO minted from nothing.

Each step is load-bearing. The rest of this page evaluates them on three independent grounds — the proof string (Parts 2–3), what consensus enforces (Part 4), and attribution limits (Part 5) — then synthesizes them (Part 6).

Report claims vs. evidence

Part 2: The Explorer Wraparound — What It Actually Proves

Paste the Part 1 payload proof into an unpatched explorer and it displays 184,467,438,537,095.51434 DERO with Verified ✓ — roughly 14 million× total supply on screen. That figure is a display-layer reading of the embedded uint64 as a positive number.

Decode it yourself

The canonical path the callout cites — rpc.NewAddress → args.Value — runs in ~10 lines against any DEROHE checkout:

// go run decode.go — requires a DEROHE checkout.
package main
 
import (
	"fmt"
	"github.com/deroproject/derohe/rpc"
)
 
func main() {
	addr, _ := rpc.NewAddress("deroproof1qyyj0cgu3htmkumr79sgca75vwsx8kx7zkrjg0nfez46w36qyx4kwq9zvfyyskpqvdpcfhkhk4m7y9d77ehyj7yhnnrv9z0tjr9m5fqe2yx9t27dwtdxy4j4r0llll7vcmaxwjcl8jzfq")
	v := addr.Arguments.Value(rpc.RPC_VALUE_TRANSFER, rpc.DataUint64).(uint64)
	fmt.Printf("uint64:  %d\n", v)                                   // 18446743853709551435
	fmt.Printf("signed:  %d atoms\n", int64(v))                      // -220000000181
	fmt.Printf("DERO:    %.5f\n", float64(int64(v))/100_000)         // -2200000.00181
}

On the cited TX with the Part 1 string:

Unpatched (DEROFDN/derohe main (opens in a new tab) — no proof/proof_validation.go) shows it as Verified ✓:

Patched (DEROFDN/derohe community-dev (opens in a new tab), via PR #14 (opens in a new tab) — ValidatePayloadProofAmount) rejects the wraparound before display:

Part 3 shows anyone can forge such proofs for arbitrary amounts.

Part 3: Forge a Fake Proof Yourself

We forged one to show how trivial it is. Below is a fake deroproof… built specifically for this page — accepts on unpatched explorers, shows an amount that never moved on-chain. It took minutes. No wallet, no private keys, no insider access. Everything needed is already public: the Part 1 transaction, its 16 ring slots, and the commitment math.

The point isn't that forgery is theoretically possible — it's that the report's "Verified ✓" evidence is the same kind of object, built the same way.

The trick, in plain English

1. Pick the real transaction everyone is looking at (5bbe1b7eecfe3447cb045b1197a07a214b456968eda8a3d5a90f5fae9ce57e55).
2. Pick one of 16 ring slots (positions 0–15) — each slot has a public address; you choose which slot the fake proof should attach to.
3. Pick any amount you want on screen — including −1 DERO or ~184 trillion DERO wraparound values.
4. Do the math. Each ring slot has a published commitment of the form amount × G + blinder — public on chain. Pick any amount; rearrange to solve for the blinder that fits: blinder = C[slot] − amount × G.
5. Paste the string into an unpatched explorer with the same TX.

If the display math fits → Verified ✓ on an unpatched explorer. Nodes never saw the string; supply didn't change. The circulated report string (Part 1) is exactly one such pasted object.

Three ways to see it for yourself, easiest first — paste ours, ask an agent, or build one from scratch with nothing but public data.

Tier 0 — Paste the one we already made

deroproof1qyvvfxzyfqtjm0lgyf5jncleh6cxmmfahgmekxpyrzhhsz832dv8qq9zvfyyskpqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqxy4j4r0lllllllll8jcq3r0a08

Unpatched (DEROFDN/derohe main (opens in a new tab)):

Patched (DEROFDN/derohe community-dev (opens in a new tab), PR #14 (opens in a new tab)):

Tier 1 — Ask your agent to forge one (no setup)

No Go, no keys, no math. The DERO MCP server ships a dero_forge_demo_proof tool — connect once, then ask in plain language. Two ways in:

• Nothing to install — point an HTTP MCP client (ChatGPT custom connectors, Cursor hosted mode) at https://mcp.derod.org/mcp.
• Run it yourself — npx dero-mcp-server and add it to Claude or Cursor, or to a privacy-first client like OpenCode (opens in a new tab) or Goose (opens in a new tab) running on a local model via Ollama (opens in a new tab). Either way it finds a node automatically: your own if you're running one, a public node otherwise.

Then ask:

"Forge a payload proof for TX 5bbe…e55, ring slot 7, for −5,000,000 DERO."

Back comes a deroproof… string. Paste it into an unpatched explorer — it lights up Verified ✓, rendering your −5M as a ~184-trillion-DERO "mint." The chain never moved a coin. Change the slot, change the amount, go bigger; the "evidence" doesn't care what number you pick — that's the whole point.

Tier 2 — Build one from scratch (no DERO tooling)

No wallet — public inputs, public math, one bech32 string. Nothing here comes from DERO, so a skeptic can re-run the whole thing from public data and trust the result. We're showing the work so it can be reproduced, not taken on faith.

What we chose: ring slot 0, target −1 DERO (= −100,000 atoms). Encoded as the uint64 wraparound 18446744073709451616, the unpatched explorer renders it as a positive number → 184,467,440,737,094.51616 DERO on screen — the −1 we picked never appears (same display-layer reading as Part 2).

The equation (proof/proof.go):

amount × G + blinder  ==  C[slot]

C[0] is public in the TX hex. Rearrange: blinder = C[0] − amount×G. That derived point — not the ring address — plus V (amount) and dummy H, bech32-encoded → demo string above.

Self-check:

proof.Prove(forged, tx_hex, ring, mainnet)
→ err=nil
→ receiver = dero1qyjgfvvf4e7jrna8xg6mmwh77km6q9nfrgdue6q2lczy33almkgy2qq9wzrkp  (slot 0)
→ amount   = 18446744073709451616

Passes → unpatched explorer shows Verified ✓. Nothing on-chain changed.

The circulated report string (Part 1) is the same kind of object.

# Requires a synced mainnet daemon — RPC port 10102 by default.
 
curl -s http://127.0.0.1:10102/json_rpc \
  -H 'Content-Type: application/json' \
  -d '{
    "jsonrpc": "2.0",
    "id": "1",
    "method": "DERO.GetTransaction",
    "params": {
      "txs_hashes": ["5bbe1b7eecfe3447cb045b1197a07a214b456968eda8a3d5a90f5fae9ce57e55"],
      "decode_as_json": true
    }
  }' | jq '.result.txs[0].ring[0] | length'
 
# List all 16 ring addresses (pick any slot 0–15 for forging):
curl -s http://127.0.0.1:10102/json_rpc \
  -H 'Content-Type: application/json' \
  -d '{
    "jsonrpc": "2.0",
    "id": "1",
    "method": "DERO.GetTransaction",
    "params": {
      "txs_hashes": ["5bbe1b7eecfe3447cb045b1197a07a214b456968eda8a3d5a90f5fae9ce57e55"],
      "decode_as_json": true
    }
  }' | jq -r '.result.txs[0].ring[0] | to_entries[] | "\(.key): \(.value)"'
 
# Raw TX bytes for the Go tab:
curl -s http://127.0.0.1:10102/json_rpc \
  -H 'Content-Type: application/json' \
  -d '{
    "jsonrpc": "2.0",
    "id": "1",
    "method": "DERO.GetTransaction",
    "params": {
      "txs_hashes": ["5bbe1b7eecfe3447cb045b1197a07a214b456968eda8a3d5a90f5fae9ce57e55"]
    }
  }' | jq -r '.result.txs_as_hex[0]' > tx.hex   # full serialized TX (several KB) — do NOT truncate; the Go tab needs all of it
# peek at the start if you like:  head -c 80 tx.hex

Part 4: The Chain's Account at the Exploit Block

The proof asserts consensus accepted a negative-amount transfer — that the protocol minted ~2.2M DERO from nothing. The chain testifies otherwise on two independent counts.

First: range proofs cannot verify a negative-amount transfer, so no validating node could have accepted one. Second: the block where it allegedly happened records a 0.615 DERO reward — scheduled emission, not millions — and one transaction whose range proofs passed cleanly at every validator. Both counts hold.

Negative transfers fail range-proof validation

Could negative transfers pass consensus — separate from the submitted proof string?

No — and the guarantee is cryptographic, not a string-parsing quirk. Every DERO transfer carries a Bulletproof range proof. The protocol packs the transfer amount and the sender's remaining balance into one 128-bit value and proves, in zero knowledge, that it lies in [0, 2^128) — i.e. that both the amount sent and the balance left over are valid non-negative 64-bit numbers (number := btransfer.Add(btransfer, bdiff.Lsh(bdiff, 64)) at cryptography/crypto/proof_generate.go:471).

A "negative" transfer is the uint64 wraparound of a huge value, and it cannot satisfy that proof:

• As the amount — a value near 2^64 exceeds the 64-bit range bound.
• As the consequence — spending more than you hold drives the remaining balance negative, which wraps out of range too.

By the computational soundness of Bulletproofs — under the discrete-log assumption on the bn256 curve, in the random oracle model (Fiat-Shamir) — no prover can construct a proof that verifies for an out-of-range committed value, except with negligible probability bounded by the underlying hardness. Combined with DERO's homomorphic accounting (inputs and outputs are bound to balance exactly), value cannot be created from nothing. Every node runs this verification independently before accepting a block, so a negative-transfer mint is rejected at consensus — not merely discouraged client-side. See Cryptographic Assumptions for the full assumption stack.

Full derivation: Negative Transfer Protection.

That closes the mechanism question. The outcome question is what the chain permanently recorded at topo 1,081,893 — not what a pasted deroproof displays.

Verify supply at the exploit block

The report's conclusion is that ~2.2M DERO was minted from nothing on October 17, 2022 (topoheight 1,081,893). To support that, it would need to show abnormal coin creation at consensus — a multi-million DERO step in the block itself, or a supply audit against something other than the emission schedule. It publishes neither: only a payload proof string and an interpretation of the corresponding transaction (Part 1).

Scheduled emission is deterministic from block height: premine plus block rewards that halve on a fixed schedule (CalcBlockReward in blockchain/transaction_execute.go). That formula estimates expected cumulative supply at any height. DERO.GetInfo reports the same approximation (cmd/derod/rpc/rpc_dero_getinfo.go:81-82: PREMINE + CalcBlockReward(topoheight) × topoheight, then divided by 100,000 to convert atomic units to whole DERO) — scheduled emission in whole DERO, not a UTXO census or balance sum across the ledger.

Exploit block: what the chain records

Independent on-chain checks at topoheight 1,081,893 — query any synced node:

For context, if a +2.2M DERO consensus mint had occurred at this block, expected cumulative supply under the schedule would be ~15,146,618 DERO instead — but detecting that would require an independent supply measure the protocol does not expose via RPC. The report never publishes one.

For this alleged mechanism, the block record is decisive anyway: a negative-transfer mint would require consensus to accept an impossible amount (range proofs). The TX was accepted — under normal protocol rules, with a 0.615 DERO block reward, not millions.

# Requires a synced mainnet daemon — RPC port 10102 by default.
# See: /basics/running-a-node
 
# 1) Exploit block header — independent on-chain facts (reward, txcount)
curl -s http://127.0.0.1:10102/json_rpc \
  -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":"1","method":"DERO.GetBlockHeaderByTopoHeight","params":{"topoheight":1081893}}' \
  | jq '.result.block_header | {topoheight, hash, timestamp, reward, txcount}'
 
# 2) Flagged TX exists in chain — accepted tx means range proofs passed
curl -s http://127.0.0.1:10102/json_rpc \
  -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":"1","method":"DERO.GetTransaction","params":{"txs_hashes":["5bbe1b7eecfe3447cb045b1197a07a214b456968eda8a3d5a90f5fae9ce57e55"]}}' \
  | jq '.result.txs[0] | {in_pool, version}'
 
# 3) Optional — GetInfo reports scheduled emission (same formula as Python tab)
curl -s http://127.0.0.1:10102/json_rpc \
  -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":"1","method":"DERO.GetInfo"}' \
  | jq '{topoheight, total_supply, height}'

Part 5: What Deanonymization Can and Cannot Establish

Parts 2–4 closed the mint question. The report leans on one further capability — deanonymization — to name a beneficiary and trace funds. Applied honestly to this transaction, it does not support the inflation claim. It undercuts it.

The ~2.2M is not a deanonymization result. It is the circulated proof string — a forgeable display object (Part 3) whose embedded uint64 reads as −2,200,000.00181 only if you take a wraparound as negative. The report sources the figure there itself: "use the proof string on the official explorer to confirm."

A faithful deanonymization reads the chain — and the chain was constrained in advance. Deanonymizing recovers the value actually committed in the transaction, not a pasted string. Whatever that value is, the range proof already pinned what it can be (Part 4): the sender provably held the amount and the balances conserved. A committed transfer that wraps either way — the on-screen ~184 trillion DERO or the report's signed −2.2M read as a credit — is impossible: the first exceeds the 64-bit range bound, and the second requires the sender's remaining balance to go negative, which the range proof also forbids (Part 4). So a faithful deanonymization of this transaction recovers an ordinary transfer of coins that already existed — not a mint.

The payload structure backs this up: in both pre-fix and post-fix wallet code (walletapi/transaction_build.go), the only address-bound byte serialized into the payload is the receiver index (witness_index[1]) — the sender is never written into the payload in either era. What Release 142 changed was the key derivation, from the global blinding scalar r to a per-payload ephemeral scalar an outside observer can't reconstruct. A faithful read of either era's payload surfaces a receiver index and the committed value — exactly what a deanonymization can return, and nothing more.

Attribution to a named individual is the report's own conceded allegation, resting on timing, access, and behavior — not cryptography. The laundering graph inherits that dependency: with no minted 2.2M, there is nothing to launder.

Part 6: The Keystone Collapses

Every downstream claim in the public exploit narrative — dollar figures, laundering graphs, "stolen funds," attribution arguments, the framing of a multi-year cover-up — is built on one load-bearing artifact: the payload proof pasted above, presented as cryptographic confirmation that the protocol minted 2.2M DERO from nothing.

That artifact fails on four independent grounds — in the order established above:

1. It is only a display object. Part 3 — a payload proof is user-supplied; anyone can build a Verified ✓ one for any amount and any ring slot.
2. The mechanism is impossible. Part 4 — a negative/wraparound transfer cannot produce a verifying range proof, so no node would accept it at the protocol layer.
3. No consensus mint recorded. Part 4 — block reward was 0.615 DERO, not millions; the cited TX was accepted (range proofs passed). GetInfo reports scheduled emission, not a UTXO census — it cannot detect a surreptitious mint by itself. The report never publishes a supply delta against any independent measure.
4. Deanonymization refutes the mint, it doesn't support it. Part 5 — the ~2.2M is the forgeable proof string, not a deanonymization output. A faithful deanonymization reads the value committed on-chain, which the range proof guarantees was held and conserved — an ordinary transfer. Attribution to a person is the report's own conceded allegation.

The display-layer bug that made this confusion possible was real. It is being remediated — DEROFDN/derohe community-dev (opens in a new tab) (PR #14 (opens in a new tab)), HOLOGRAM (opens in a new tab), and patched explorers now reject proofs like this one; main and other unpatched explorers may still show Verified. That is a display-layer problem worth fixing. It is not evidence that the chain minted coins; the range proofs do not permit it.

The artifact at the center of every accusation is a display object anyone can forge. The chain neither records the event the report describes nor permits the mechanism it alleges. Every downstream claim — laundering, attribution, dollar figures — requires that artifact to function as cryptographic evidence. It does not.

Related Pages