Decentralised News · Editorial by Heath Muchena · Evidence reviewed 12 November 2026 · Edition 1.0
What Matters
Quantum randomness concerns how unpredictable input is produced. It does not automatically change a wallet’s signature algorithm, protect its host or prove a shipped integration. NIST’s entropy certificates identify particular implementations and parameters. DN’s calculator connects an entered entropy rate to a BIP39 sizing budget, while keeping device validation, secure conditioning and post-quantum signature resistance separate.
DN Evidence Block
- Source review
- 12 November 2026.
- Primary evidence
- NIST entropy-source certificate E63 and its public-use document; SP 800-90B, SP 800-90C and statistical-testing guidance; the BIP39 specification.
- DN original
- DN Wallet Entropy Budget v1.0.0, a local parameter calculator and versioned scenario record.
- Established facts
- Published parameters and mnemonic-format relationships can be checked. End-to-end wallet security requires additional evidence.
- Not performed
- No device teardown, random-stream collection, entropy assessment, wallet certification, adoption survey or quantum-attack benchmark.
Read the complete chain behind a quantum claim
A wallet buyer may encounter several promises in one sentence: quantum-generated randomness, a certified component, a longer recovery phrase and protection against future quantum attacks. Those promises concern different stages. Combining them does not make the evidence for one stage apply to all the others.
DN’s thesis is that randomness should be reviewed as a chain: physical source, sampling, health tests, conditioning or random-bit-generator construction, application integration, secret handling and eventual signature scheme. A break in one stage is not repaired merely by adding a prestigious component elsewhere.
This is also why a commercial partnership is insufficient evidence of deployment. A useful production claim identifies the shipped model, hardware revision, relevant firmware, configured entropy path and behaviour when that path fails. Without those details, an analyst can describe an announcement but cannot count a verified wallet integration.
A real entropy certificate provides a narrower, stronger claim
NIST entropy certificate E63 identifies IDQ Quantis IID QRNG, lists specific chip versions and records SP 800-90B validation. The current entry gives 1.75 bits of entropy per two-bit sample and marks reuse as restricted to the vendor. These are certificate-level facts, not a certification of every product that mentions the supplier. [1]
The associated public-use document describes the chip as a component within a host security device. It places responsibility for protecting the chip, driver and connecting paths within that host’s security boundary. A diagram showing a quantum source is therefore the start of the integration review, not its end. [2]
For procurement, record the exact certificate and implementation rather than writing merely “NIST certified.” Ask which part of the shipped system matches the listed implementation and which parts need separate evidence. If the answer identifies only a component, preserve that scope in the assessment.
Claim versus data
| Claim | Evidence that matters | What remains unresolved |
|---|---|---|
| A source uses quantum effects. | Physical design and the identified implementation. | Sampling, integration, secret handling and final wallet behaviour. |
| An entropy certificate exists. | Certificate number, covered versions, operating conditions and assessed parameters. | Whether the deployed configuration matches its scope. |
| The output passed statistical tests. | Test design, sample and results. | Cryptographic suitability and implementation security. |
| The mnemonic has 24 words. | The format and original randomness supplied to it. | Whether the underlying secret was generated securely. |
| The wallet is quantum-resistant. | Signature construction, implementation and chain support. | Migration, recovery and any remaining classical dependencies. |
Source validation and random-bit generation are connected, not identical
SP 800-90B addresses entropy sources, their assessment and health testing. It requires startup and continuous health tests, with error signalling and handling requirements. Those tests concern operating failures; they are not a promise that a component can never degrade or that every downstream application handles an alarm correctly. [3]
SP 800-90C, finalised in September 2025, specifies constructions that connect entropy sources with deterministic random-bit-generator mechanisms. It provides a separate framework for the generator built around the source. Reading only the source label skips that construction question. [4]
For a wallet integration, the practical questions are concrete. Which interface supplies key-generation input? What happens before the first usable output? Can the application distinguish a failed source from a temporary delay? If a fallback exists, is its behaviour documented? Has the same configuration been exercised in the shipped firmware?
A failure report does not need to expose private randomness. It can identify the tested version, injected failure condition, expected control response and observed outcome. Publishing secret material to prove the presence of a random source would undermine the purpose of the review.
Why a statistical pass is not a security verdict
NIST’s statistical-test guidance explicitly says that a collection of statistical tests cannot certify a generator’s suitability for a cryptographic application or replace cryptanalysis. The publication’s page also records a decision to revise it, so it should not be presented as a newly issued wallet certification standard. [5]
A simple thought experiment shows the distinction. A stored sequence may look irregular to a test while being fully known to someone who possesses a copy. Appearance and secrecy are different properties. Likewise, a sound source can feed an application that logs its output or reuses a compromised state.
The review should therefore connect tests to a threat model and a particular implementation. Asking whether a graph looks random is weaker than asking what an attacker can know, change or recover in the deployed system.
BIP39 separates entropy, checksum and the derived seed
BIP39 maps 128, 160, 192, 224 or 256 input-entropy bits to 12, 15, 18, 21 or 24 words. Its checksum contributes 4 through 8 additional bits, respectively. The specification separately derives a 512-bit binary seed from the mnemonic and optional passphrase. Those are different quantities. [6]
A deterministic checksum does not introduce new independent randomness. Nor does a longer derived output, by itself, make an uncertain input more unpredictable. The practical purpose of the budget is to keep those lengths visible so that a marketing comparison cannot silently substitute one for another.
The calculator is an analysis aid for the stated format. It does not generate a mnemonic, validate a real phrase or recommend building a new wallet around BIP39. Never enter a recovery phrase, passphrase, private key or random bytes into it.
A reproducible sizing example, not a device benchmark
Take the certificate’s published parameter of 1.75 bits per two-bit sample as the rate credited in a hypothetical budget. A 256-bit input target requires rounding 256 ÷ 1.75 upward: 147 samples. Their logical sample length is 294 bits, and the credited input budget is 257.25 bits.
With 146 samples, the same model credits 255.50 bits, which falls below its 256-bit target. This does not prove that the physical output contains exactly that amount of entropy. It shows what the chosen crediting assumption can substantiate in a sizing calculation.
If the selected output stage is only 128 bits long, the model limits the credited output budget to 128 even when the input credit is larger. If that stage is 256 bits long, the default example reaches a 256-bit accounting budget. Neither result establishes that a real conditioner achieves that entropy or that an implementation satisfies NIST’s construction requirements.
The sample count is not a device-read instruction. Driver interfaces, batching, restart requirements, conditioning rules and implementation overhead are outside the calculation. A production design needs those details; a spreadsheet-style budget cannot replace them.
Use the DN Wallet Entropy Budget
Enter the sample width, credited entropy per sample, sample count, output length and target mnemonic length. The rate must not exceed the sample width. Record whether the rate comes from a certificate parameter or an unverified assumption, and retain a non-sensitive reference.
DN Wallet Entropy Budget v1.0.0
Conditional parameter sizing only; no random bits, entropy measurement, conditioner validation, shipped-wallet proof or signature-resistance assessment.
Use non-sensitive aliases and references. This instrument makes no network requests and writes no browser storage. The downloaded JSON contains your inputs. Do not enter account credentials, wallet secrets or confidential documents. Defaults are illustrative scenarios.
Enter or review the example assumptions, then calculate. No measurement or live data has been loaded.
The result shows the target format, logical raw length, credited input budget, output-length-limited budget and minimum samples under the entered rate. It also records the selected signature-family label without treating that label as verified. Reaching the arithmetic target is not a security score.
Quantum randomness does not replace signature migration
NIST’s post-quantum overview describes the need for algorithms designed to resist attacks by sufficiently capable quantum computers, including digital-signature use cases. That question concerns the mathematics and implementation of the cryptographic operation, not simply the physical process used to choose initial random input. [7]
Changing the source of a private key leaves the signing algorithm unchanged unless the system also changes that algorithm. A reviewer should therefore maintain two separate findings: the evidence for key-generation randomness and the evidence for the signature scheme’s threat resistance. A strong finding on one cannot be copied into the other.
For the size consequences of different signatures, use DN’s post-quantum signature byte budget. For long-lived encrypted records, use the confidentiality inventory. Neither tool is an entropy-source assessment, and this article does not duplicate their migration or record-retention questions.
What a useful wallet evidence packet contains
Begin with a device and software identifier precise enough to distinguish the tested configuration from a marketing family. Attach the relevant entropy document and a diagram of the implemented input path. Describe the operating conditions and how the consuming application learns about failures.
Then separate evidence that a source exists from evidence that key generation uses it. A procurement statement might establish the component. A reviewed integration or a controlled test might address the active path. Neither automatically establishes that secrets remain protected throughout display, backup, signing and recovery.
The public-use document’s host-boundary requirements make that distinction especially relevant to the E63 example. [2] DN’s wearable-wallet signing and recovery review examines those later user-facing boundaries in a different device context.
Decision table
| Finding | Appropriate conclusion |
|---|---|
| A certificate matches the component but the integration is unspecified. | Record the component evidence; keep the wallet-level claim unresolved. |
| The entered entropy rate exceeds the sample width. | Reject the inconsistent input. |
| The sizing budget falls below the target. | The entered crediting assumptions do not support that target. |
| The budget reaches the target. | Continue implementation and security review; do not award a security rating. |
| The signature scheme is unknown. | Do not infer post-quantum resistance from the randomness source. |
| Only a partnership announcement exists. | Do not count it as a verified shipped deployment. |
Methodology and limits
The source review is dated 12 November 2026. The original QRNG adoption-tracker premise remains held because this research does not establish a measured wallet-installation population. The new contribution is parameter interpretation and an explicit sizing model.
The model multiplies sample count by the entered per-sample credit, limits that budget by the selected output length and compares it with the format’s input target. Such crediting assumes an applicable independence model or an appropriately assessed entropy rate. Correlations or a mismatched operating environment can invalidate that assumption.
Arithmetic uses fixed-point precision for rates up to four decimal places. An entered zero rate produces no finite sample requirement for the positive target. The record identifies all assumptions and never reports a measured entropy value, a validated conditioner, a generated secret or a certified wallet.
Frequently asked questions
Is quantum randomness the same as post-quantum cryptography?
No. The first concerns a source of random input. The second concerns cryptographic constructions intended to resist a different class of computational attack.
Does certificate E63 certify a wallet?
The certificate identifies an entropy-source implementation and specified versions. A wallet claim needs evidence connecting its actual configuration to the relevant component and integration requirements.
Does a 24-word phrase prove 256 bits of secure randomness?
Its format has that input-entropy capacity. The words alone do not establish how the original input was produced or protected.
Can I generate a seed with this instrument?
No. It performs arithmetic only. It requests no secret material and produces no random bits, private keys or recovery phrases.
Why does the example use 1.75 rather than another vendor figure?
It uses the parameter displayed in the reviewed certificate entry. Other figures can describe different analyses or conditions; preserve the exact source of any rate used in a comparison.
Corrections and changelog
Send the affected statement, implementation identifier and public primary reference to press@decentralised.news. Never include recovery material or sampled secrets. Version 1.0.0, 12 November 2026: initial certificate review and conditional entropy-budget model. Changes to certificate scope, public-use requirements or relevant specifications require editorial review.
Primary sources
- NIST: entropy certificate E63.
- E63 public-use document: implementation and host boundaries.
- NIST SP 800-90B: entropy sources and health testing.
- NIST SP 800-90C: random-bit-generator constructions.
- NIST SP 800-22: scope and limits of statistical testing.
- BIP39: mnemonic and binary-seed specification.
- NIST: post-quantum cryptography overview.
Published schema and illustrative record
The schema documents this instrument’s JSON format. The example below contains constructed illustrative inputs and outputs; it is not a provider measurement, verified case or live dataset. The instrument above creates a separate record from the inputs you choose. These resources do not establish an API or an automatic monitoring service.
JSON Schema — dn.wallet-entropy-budget.v1
Schema version 1.0.0. The schema identifier is a versioned reference, not an asserted network endpoint.
{
"$schema": "https://json-schema.org/draft/2020-12/schema",
"$id": "urn:dn:wallet-entropy-budget:v1",
"title": "DN Wallet Entropy Budget record v1",
"type": "object",
"additionalProperties": false,
"required": [
"schemaId",
"schemaVersion",
"instrument",
"recordType",
"createdAt",
"sourceReviewDate",
"inputs",
"outputs",
"assumptions",
"limits"
],
"properties": {
"schemaId": {
"const": "dn.wallet-entropy-budget.v1"
},
"schemaVersion": {
"const": "1.0.0"
},
"instrument": {
"const": "DN Wallet Entropy Budget"
},
"recordType": {
"const": "reader_entered_scenario"
},
"createdAt": {
"type": "string",
"format": "date-time",
"pattern": "^\\d{4}-\\d{2}-\\d{2}T\\d{2}:\\d{2}:\\d{2}\\.\\d{3}Z$"
},
"sourceReviewDate": {
"const": "2026-11-12"
},
"inputs": {
"type": "object",
"additionalProperties": false,
"required": [
"alias",
"sampleBits",
"entropyPerSample",
"sampleCount",
"outputBits",
"mnemonicWords",
"rateBasis",
"sourceRef",
"signatureFamily"
],
"properties": {
"alias": {
"type": "string",
"maxLength": 120,
"minLength": 1
},
"sampleBits": {
"type": "integer",
"minimum": 1,
"maximum": 64
},
"entropyPerSample": {
"type": "string",
"pattern": "^(0|[1-9]\\d*)(\\.\\d{1,4})?$",
"maxLength": 24
},
"sampleCount": {
"type": "integer",
"minimum": 0,
"maximum": 1000000000
},
"outputBits": {
"type": "integer",
"minimum": 1,
"maximum": 1000000000
},
"mnemonicWords": {
"type": "integer",
"enum": [
12,
15,
18,
21,
24
]
},
"rateBasis": {
"type": "string",
"enum": [
"certificate_parameter",
"unverified_assumption",
"unknown"
]
},
"sourceRef": {
"type": "string",
"maxLength": 240
},
"signatureFamily": {
"type": "string",
"enum": [
"classical",
"post_quantum",
"hybrid",
"unknown"
]
}
}
},
"outputs": {
"type": "object",
"additionalProperties": false,
"required": [
"logicalRawSampleBits",
"creditedInputBits",
"outputLengthLimitedBudgetBits",
"mnemonicInputTargetBits",
"mnemonicChecksumBits",
"mnemonicEncodedBits",
"derivedBinarySeedBits",
"minimumSamplesUnderRate",
"sizingStatus",
"targetReachedUnderAssumptions",
"signatureResistanceAssessment"
],
"properties": {
"logicalRawSampleBits": {
"type": "integer",
"minimum": 0
},
"creditedInputBits": {
"type": "string",
"pattern": "^(0|[1-9]\\d*)(\\.\\d+)?$",
"maxLength": 70
},
"outputLengthLimitedBudgetBits": {
"type": "string",
"pattern": "^(0|[1-9]\\d*)(\\.\\d+)?$",
"maxLength": 70
},
"mnemonicInputTargetBits": {
"enum": [
128,
160,
192,
224,
256
]
},
"mnemonicChecksumBits": {
"enum": [
4,
5,
6,
7,
8
]
},
"mnemonicEncodedBits": {
"enum": [
132,
165,
198,
231,
264
]
},
"derivedBinarySeedBits": {
"const": 512
},
"minimumSamplesUnderRate": {
"type": [
"integer",
"null"
],
"minimum": 0
},
"sizingStatus": {
"enum": [
"no_positive_rate",
"output_length_below_target",
"input_budget_below_target",
"budget_reaches_target_conditionally"
]
},
"targetReachedUnderAssumptions": {
"type": "boolean"
},
"signatureResistanceAssessment": {
"const": "not_assessed"
}
}
},
"assumptions": {
"type": "array",
"minItems": 4,
"maxItems": 6,
"items": {
"type": "string"
}
},
"limits": {
"type": "object",
"additionalProperties": false,
"required": [
"randomBitsGenerated",
"secretsRequested",
"entropyMeasured",
"sourceReferenceVerified",
"walletCertified",
"conditionerValidated",
"signatureResistanceVerified"
],
"properties": {
"randomBitsGenerated": {
"const": false
},
"secretsRequested": {
"const": false
},
"entropyMeasured": {
"const": false
},
"sourceReferenceVerified": {
"const": false
},
"walletCertified": {
"const": false
},
"conditionerValidated": {
"const": false
},
"signatureResistanceVerified": {
"const": false
}
}
}
}
}Illustrative example JSON record
This fixed example is published for inspection and integration testing. Its record timestamp is not an evidence-verification timestamp.
{
"schemaId": "dn.wallet-entropy-budget.v1",
"schemaVersion": "1.0.0",
"instrument": "DN Wallet Entropy Budget",
"recordType": "reader_entered_scenario",
"createdAt": "2026-11-12T12:00:00.000Z",
"sourceReviewDate": "2026-11-12",
"inputs": {
"alias": "E63-parameter-sizing-example",
"sampleBits": 2,
"entropyPerSample": "1.75",
"sampleCount": 147,
"outputBits": 256,
"mnemonicWords": 24,
"rateBasis": "certificate_parameter",
"sourceRef": "NIST E63, reviewed 12 Nov 2026; parameter example only",
"signatureFamily": "unknown"
},
"outputs": {
"logicalRawSampleBits": 294,
"creditedInputBits": "257.25",
"outputLengthLimitedBudgetBits": "256",
"mnemonicInputTargetBits": 256,
"mnemonicChecksumBits": 8,
"mnemonicEncodedBits": 264,
"derivedBinarySeedBits": 512,
"minimumSamplesUnderRate": 147,
"sizingStatus": "budget_reaches_target_conditionally",
"targetReachedUnderAssumptions": true,
"signatureResistanceAssessment": "not_assessed"
},
"assumptions": [
"Sample credits require an applicable independence model or appropriately assessed entropy rate.",
"The output-length limit is budget accounting, not an entropy proof for a real conditioner.",
"BIP39 checksum and derived-seed lengths are format properties, not extra independent randomness.",
"Minimum sample count is a sizing result, not a production device-read instruction."
],
"limits": {
"randomBitsGenerated": false,
"secretsRequested": false,
"entropyMeasured": false,
"sourceReferenceVerified": false,
"walletCertified": false,
"conditionerValidated": false,
"signatureResistanceVerified": false
}
}
