Loosing old vote state

[owl352]

Currently, there are aliases in the testnet that were voted on a long time ago, but we can't get the results of this vote, instead we get an empty vote state object.

As example: testnet identity 8eTDkBhpQjHeqgbVeriwLeZr1tCa6yBGw76SckvD1cwc with alias canuseethat1.dash

Expected Behavior

Vote state object with info about vote state

Current Behavior

Empty vote state object

{
  "lockedVoteTally": undefined,
  "contenders": [],
  "abstainingVoteTally": undefined,
  "winner": undefined,
  "skipped": 0
}

proof:

0100f6019bbd47a4b82039c135396f09e51a388b4459d4b271f0bc187a9861593a10c54f0222cfdb6be7e7c4ad2c2dbd79e637d2ae7edc45ef51ef92067e35e9c708e005951001949936dde2d5f028f54769a610fa6e1c47524e994733b2e0a48460846ec492dc024658f3a8aa44e4dbd5aa16f12b4a20545a003df532c8bc0a8abc3dc59b745e93100194dca29a5731f08ede0e1e92a3564ebd16649fe5218b276dc21dc35a813ed69c04017000050201016400250ed3c96efe53c3b56789a8e01d85c3a3b748ac7a863e7f693a35606dd3961a10015c394097237fef137ae4656c80728028ec4e25c015d44c40a55526bd81ccbe07111111010170006e04016300050201017000919da05942b7677655983193887a1e4a263c2df3ee1d0b05a1309b2af4f8f9c202c87eb5cf3e911256d61c101ff883f923dc3837468591754f34189c617f1ceaf010011ffbe3ed6ba1372646c2c26f61517c0d77c0185a5024c8c0ff9e5f4aada766cf11010163006b01daf32cce8abb7ece9b1f2061f25b32e8919c7310bf3649de60c3e0f5dcbb9e130401700024020120e668c659af66aee1e72c186dde7b5b7e0a1d712a09c40d5721f622bf53c531550027de79af62950739722d3cd59078e00da93b63ae1b38131ca6f5a5fbf843ec7910010170009201a141e838b1baddf01639bb21957291c5da641bbde471cd38064a9dad4fc1beb40420e668c659af66aee1e72c186dde7b5b7e0a1d712a09c40d5721f622bf53c53155000a020106646f6d61696e00bf832fe6dec357c2d7c15c2376a973faf56c6df17932ccdb1acd96f9afe5330a100134a7a657df603b73f537089ba777b8cf2055b88c96560c0ea6ff3c5e55b90720110120e668c659af66aee1e72c186dde7b5b7e0a1d712a09c40d5721f622bf53c53155002f0406646f6d61696e000502010101000d391cebd860d6bac61ffc0166d7c573282d49c17a14b95da5f4c2be041b58030106646f6d61696e004f010f883aa00363e4173f418ac35c05f550fe7771b43effad30ecb13b7ce4ef81c7040101000802010464617368005e74e69e986776c59b6a8edd08e3dee2ab3845023f8af036168b3ea703ba00c4100101010053040464617368002b020103663031012302888f5cf5be0c1c0dc63048d5b2a5003362a4a35f12dfa3f3f43de22a854d4a4303a496e28a3e995ddc18f6aaeb4216b8d8d8a2bfc9b53708856349aba97e131d3c9c01046461736800fb024e013576d95bfe81426f7e63899d3001c0b759ef90dcefcb30edf37abb594f7049e102cbcdf365d47020573de2c86c9777a24d03cf6f3a127899cc88b3e83ac2d0cdd310012fdbba2de2ee373b6f743dd4d2a0aea8b4f7ec75e3be5c99e21a4cb23b0d2681025e69dd82717af1b4cec79fa7d637e0da42f306b4bcef91c0c94ceb5ebcddacd2100120648baa1d16eaf997823dd9a0d187d2a63cccd18c87a160e6eca67a1ce7e3e102b7468358b1503b25817d59b721693e1a5c32ff34c3703f38b28aac8be639803d10050463317479268aa50a21672aa9ff5850d201acedba61059edb5280067be39ee4bb7cf6c552050763617031746131195d153566c0217ca5654da5595c4c808eb52c697a87c8e8b6491dce13be704010015adbae06f57727f0a40881912ed42cc89b8e84f538f53e2cfc800ee5adc4894f1111020ac5a7bc058d06bde99289f4674c2786385524150015ab174bb3376fbb12f3bf10013154674a5c996e1c9bb26f8242c5556f95d95518980677081522c43379bdaab111023de1990a6327b5c21177fe7d3162f952c0ec12ed19b913d672942ab31ccc619610010f9912db737d956c124128249e65d1f445836e2335287897e1d821b16cc3d9b31102c034996a1182be6ab9f79d0bce2c8a39cee1add035e4d29fa200ef65d1a649781001fefc484379db6f5a3cb72ceafb6a669d9503c0772ce2d57a4522222110e2e6e011111102347df6cd61078a984175e13cfa31d8438456044f4304dff1501c782c990442171001f86121c1f4d266c110cf3984e9557f46cda173d53563cfc737769b70420ba5111100

Possible Solution

Steps to Reproduce (for bugs)

1. Call getContestedResourceVoteState via dapi with this parametrs

{
  "oneofKind": "v0",
  "v0": {
    "contractId": "e668c659af66aee1e72c186dde7b5b7e0a1d712a09c40d5721f622bf53c53155",
    "documentTypeName": "domain",
    "indexName": "parentNameAndLabel",
    "indexValues": [
      "120464617368",
      "120c63616e757365657468617431"
    ],
    "resultType": 2,
    "allowIncludeLockedAndAbstainingVoteTally": true,
    "prove": true
  }
}

All binary data converted to hex

Context

How has this issue affected you? Platform-Explorer returns error on aliases which vote state loosed

Your Environment

• "dash-platform-sdk": "1.5.0-dev.7"
• node v22

[thephez]

When I look for that identity on platform explorer, it says not found. Is this maybe an identity that was created before one of the testnet resets and it doesn't exist anymore? I lost some identities/names that way.
Edit: oh, the identity is returned by the SDK so I guess that's not it.

[owl352]

On PE identity not found because api trying to fetch all aliases for identity and then throws error instead identity info response

[pshenmic]

After v4.0 upgrade (protocol 12) we noticed some of the identities data aren't shown - most of the fields are nulled, however we can see all associated transactions properly. After an investigation we found that some DPNS names were failing to request vote state info for previously working names, Error: Vote state not found are now returned. The backend simply fails to request some specific names for the identity and that makes the query fail.

Internally, on Platform Explorer, all dash names (aliases) are indexed and put in the database. Once user opens up an Identity, API get all associated names with the user, and requests vote state info for each one to obtain current dash name status (because we should also show pending names, we can't query names straight from DAPI).

After a new protocol upgrade (12), V4.0, we started to see some identities are now failing to request name data, although it is definitely registered and legit. It first happened to my test identity, but not we've got report from the second person got into this.

[QuantumExplorer]

Thanks for the detailed report — I dug into this, and it has nothing to do with the v4.0 (protocol 12) upgrade. The v12 migration only builds the shielded-pool trees and sanitizes contract schemas; it doesn't touch vote state at all. The data for these names has actually been gone since September 2024 — most likely Platform Explorer only recently started querying vote state for these older aliases, which is when it was noticed.

What normally happens when a contest ends: to save storage space, Drive deletes the votes, contenders, contender documents, and per-identity vote references once a vote poll concludes — but it deliberately keeps a compact record (winner, final tallies, finalization block) under the contested resource, and getContestedResourceVoteState serves finished contests from that record. So old votes are supposed to still return the winner and final tallies.

Why these specific names return an empty state: early testnet (v1.x, protocol 1) had a bug that left corrupted references in the vote-poll end-date tree. We shipped two one-off, testnet-only cleanup passes to fix it — one at the protocol 1→2 upgrade (Aug 2024) and one at the epoch 1434→1435 boundary (Sept 2024, #2134). Those passes swept every contest still in the end-date queue and removed the entire contested-resource subtree, including the stored record. Any name whose contest was active during those windows has no trace left in state.

You can see this in the proof you posted: it's a valid absence proof — the neighboring keys c1ty and cap1ta1 bracket exactly where canuseethat1 would sort. The tree provably does not contain that name, so the empty vote state object is the correct response to the query.

This never affected mainnet — both cleanups were gated to testnet only. At the time we decided not to revert testnet to preserve these records, so the data is unrecoverable there. The recommended handling on the Platform Explorer side is to treat a provably-absent vote state as "no record available" for that alias rather than failing the whole identity response.

Given the platform is behaving correctly here and the missing testnet data can't be restored, can we close this issue?

[owl352]

Yes, this is probably true, but the problem is that the platform explorer has been requesting voting data via dapi since the days when dpns first appeared. We have known this problem for a long time, but before that it affected literally single aliases. Since the last update, the number of such aliases has increased dramatically. Due to the lack of any actions, we had to start processing such "broken" votes, as you suggested, because a very large part of the identity with names started to give an error. Also, in favor of an error in the platform code, I can give a more correct example that does not fit into your theory. This alias was created by me half a year ago, but it is still not available and the contested page gives an error, because there is formally voting in the system, but there is no data about it.

{
    "alias": "bebra.dash",
    "status": "unknown",
    "contested": true,
    "timestamp": "2026-03-17T15:07:37.770Z",
    "txHash": "8C331F3966FE6542D935E9E9F690FB15CC1F4466726728034FE8E97B8EB73B67"
}

https://testnet.platform-explorer.com/contestedResource/WyJkYXNoIiwiYmVicmEiXQ==

[QuantumExplorer]

@pshenmic asked (on Slack) how this identity could be affected by the 2024 cleanups if it was registered in March 2026 — a fair challenge, and it made me re-verify everything against chain state. Correction below; the 2024-cleanup explanation I gave for this specific name was wrong, but so is the March 2026 date. Here is what the chain actually says.

The on-chain timeline (verifiable by anyone):

• Identity 8eTDkBhpQjHeqgbVeriwLeZr1tCa6yBGw76SckvD1cwc was created in tx 0FC9CA6A… at block 8643, 2024-09-11.
• The winning canuseethat1.dash domain document (3UaTg5QPBFpULT64fvvb8Xyg24oMsPyGFTWn6E8aKCqc) was created in tx C27208CC… at block 32759, 2024-10-10, and it is live in the DPNS tree today, owned by that identity — so the contest concluded and the award itself worked.
• The two testnet cleanups I described ran at the protocol 1→2 upgrade and at the epoch 1434→1435 boundary, whose first block was 2024-09-16 — both before this contest existed. So they are not the cause here; that part of my previous comment was wrong.

Full forensic diff of current testnet state. I enumerated every domain document under dash (2,439) and every contested-resource entry still in the votes tree (818), then diffed them. Exactly four names have an awarded document but no vote record:

name	contested	owner
canuseethat1	2024-10-10	8eTDk…
canus1e	2024-10-12	8eTDk…
canus1	2024-10-12	8eTDk…
p1ease1et1tbe	2024-10-12	8eTDk…

All four belong to the same identity and were contested in a two-day window in October 2024. (One caveat: contests that ended Locked leave no document, so a locked contest that lost its record would be invisible to this method — if another affected name ended locked, it would be an additional victim from presumably the same window.)

Everything else is intact: contests that ended in the very same height band (0w1352-testnet @38025, a01 @36236, abc @38825, 101 @43774) still return full records with winner and tallies, as do contests from every era since — protocol 2 through 13.

Why this is not a v4.0 / protocol 12 issue:

• No protocol upgrade migration (v4 through v13) touches vote state at all; the only code that ever deletes a finished contest's record is the testnet cleanup path, which last ran 2024-09-16.
• Records written before, during, and after these four contests are all still readable today. The damage is surgically confined to Oct 10–12, 2024.
• What was happening in that exact window: v1.4.x had a state-consistency bug where vote deletion batches were applied outside the block transaction (fixed in fix(drive): apply batch is not using transaction in remove_all_votes_given_by_identities #2309), which — combined with a Tenderdash partial-commit bug — is known to have corrupted state on mainnet in those same weeks. These four contests were live/ending on testnet right then. That is the most plausible origin; the precise mechanism can't be reconstructed from current state alone.
• My guess is Platform Explorer first noticed at v4.0 because that's when it started issuing these per-alias vote-state queries (or re-indexed). If you have a logged successful vote-state response for one of these four names from after October 2024, please share it — that would point to a later deletion event and I'd want to chase it.

Mainnet is confirmed unaffected — I ran the identical diff against mainnet: 3,545 domain documents, 711 contested-resource entries, zero missing records. Both testnet cleanups were gated to testnet only, and at the time we decided not to revert testnet state, so these four records are unrecoverable there.

Bottom line: Drive is answering correctly — the proof in the OP is a valid absence proof (the neighbors c1ty and cap1ta1 bracket where canuseethat1 would sort). The recommended handling stands: treat a provably-absent vote state as "no record available" for that alias rather than failing the whole identity response. Given the scope (4 testnet names from an October 2024 incident, unrecoverable, mainnet clean), can we close this issue?

[QuantumExplorer]

Closing this issue, as there isn't anything to fix.