Research method and evidence labels
This method makes each conclusion traceable to its source, version and scope, so readers can distinguish a project statement from a reproducible source fact.
Who publishes this research?
SynergyX Research is the institutional byline already used by this site. It is affiliated with the SYNX project. These pages explain that project and the cryptography around it; the byline does not represent an independent laboratory or a named external auditor.
This reference set uses AI-assisted drafting, source extraction and scripted checks to organize evidence and make calculations repeatable. Those processes do not establish independent review or replace release-specific validation. The method below describes work supported by the published records.
How sources are selected
- Cryptographic definitions: the controlling publication is preferred, such as FIPS 203 or FIPS 205. A standard’s algorithm name and role are kept separate from product claims.
- SYNX statements: the whitepaper, FAQ and other first-party pages establish what the project says. They are attributed as project statements, not treated as external corroboration.
- Upstream values: an exact repository revision identifies the reference configuration. A source check records its date; it does not imply continuous monitoring.
- Original analysis: a table or calculation states its inputs, operation and limits. An editorial comparison is labeled as a comparison, not a measurement.
The article source register connects citations to the reference set. The protocol-claim ledger records the narrower SYNX claims and their verification status.
Evidence labels
| Label | What supports it | What it does not establish |
|---|---|---|
| Project statement | An identified, dated first-party source. | Independent confirmation, deployed behavior or certification. |
| Published standard | The named standard and its publication or revision. | That a particular wallet, library or network conforms to it. |
| Pinned reference data | Values in exact upstream files at a fixed revision. | A product benchmark, a serialized transaction size or a release audit. |
| Source-derived calculation | Disclosed inputs and reproducible arithmetic. | Runtime behavior, compressed storage or an unstated real-world result. |
| Not independently verified here | The evidence record does not establish the claimed implementation or review result. | That the claim is false or that the implementation fails. |
How the SPHINCS+ size comparison was calculated
The comparison uses the upstream README and SHAKE-specific headers for 128s and 128f at revision 7ec789ace6874d875f4bb84cb61b81155398167e, checked 21 September 2026.
- The reproduction script retrieves the pinned files and checks their recorded SHA-256 digests and byte lengths.
- It parses the README rows and matches six configuration parameters against the corresponding SHAKE headers.
- It compares the published raw signature sizes: 17,088 − 7,856 = 9,232 bytes. Relative to 128f, 9,232 ÷ 17,088 × 100 = 54.03%, rounded to two decimals.
- It records the same 32-byte public-key and 64-byte secret-key sizes for both configurations.
Inputs, digests, assertions and results · Python reproduction script. The calculation parses public text and performs arithmetic. It does not compile or run the signing code, execute SYNX binaries, measure speed or explain the project’s historical parameter choice.
Scope limits
A source can support an algorithm’s purpose without supporting a product’s security. A roadmap can support a statement about a plan without supporting completion. Similarly, an attack model, a hardware demonstration and a network outcome require separate evidence. These distinctions are kept visible in article answers and tables.
This method reports no new SYNX latency, hashrate or other laboratory benchmark. It also does not establish a completed independent audit. The audit-status entry identifies the project’s stated plan and the evidence limit.
Dates and corrections
The date on this page marks the source check for this edition. Initial record: . No later correction entry is recorded here in this edition. The site’s editorial policy identifies its existing correction route and publication policy.
A useful correction identifies the affected URL and passage, the replacement fact and its public source. A changed source, a calculation error and newly supplied release evidence are different updates; none should be represented merely by changing a date.
For the actual findings and their links, return to the research library or the protocol-claim ledger.