Q: How is the quantum data generated?
A: ERIS Quantum RNG v3.0.0 is built on a unique, quantum-inspired approach to generating randomness in software. The details are proprietary—sometimes, when you've worked hard for a breakthrough, you have to protect it. What matters is that our results are open for anyone to test, and our randomness stands up to the toughest scrutiny.
Q: What type of noise is generated by Eris raw?
A: It's natively pink noise (no filtering), everything else is white noise.
Q: Does this support PQC?
A: Yes! Eris is innately a quantum process to generate the entropy, which is why she exhibits pink noise too. Yes, in the sense that Eris:null (and full) aims to provide an entropy source of such high quality and unique generation (quantum-native code, resistant to manipulation, 8 DC nodes, etc.) that it would be an ideal foundation for seeding and operating within a PQC environment.
Q: How is the API key secured?
A: API keys are associated with your authenticated account (Email/Password or GitHub) and should be kept confidential. Use the X-API-Key header for programmatic access.
Q: What happens if I exceed my daily quota?
A: Requests beyond your tier's daily limit will receive an error response until the quota resets (typically midnight UTC).
Q: Can I request larger amounts of data?
A: The API is optimized for frequent, smaller requests. For bulk data (>1MB), please contact datorien [at] occybyte [dot] com to arrange a custom data delivery.
Q: Is the free tier sufficient for testing?
A: The free tier provides enough data (256 bytes/day) to test API integration and basic functionality.
Q: What categories is this tech in?
A: Primary Category -> Deep Tech && Secondary Category -> Infrastructure
Q: What is Eris full, and Eris:none?
A: Full is the whitened binary / output. None is the raw output with no whitening.
Q: What's the interesting paradox?
A: ERIS successfully passes the Dieharder with only 1 weak using the raw, 16-million chi-square output for randomness. That same raw (eris:none) binary actually fails the NIST_STS because it expects uniformity with randomness. Which was discovered to be because those tests are fundamentally built on classical assumptions that uniformity equals randomness. When in reality? Randomness is any%. In fact, the better that randomness got with the raw Eris, the chi-square doubled from 800k to 16 million but at the same-time removed two of the original three fails in Dieharder (Eval2 from the Github). It's important to note the NIST STS software itself comes with the following disclaimer: "This software was developed at the National Institute of Standards and Technology by employees of the Federal Government in the course of their official duties. Pursuant to title 17 Section 105 of the United States Code this software is not subject to copyright protection and is in the public domain. The NIST Statistical Test Suite is an experimental system. NIST assumes no responsibility whatsoever for its use by other parties, and makes no guarantees, expressed or implied, about its quality, reliability, or any other characteristic. We would appreciate acknowledgment if the software is used." Therefore, while ERIS output (when appropriately processed) successfully passes the NIST SP 800-22 tests, it is more accurate to state this fact rather than claiming formal "NIST STS compliance," which implies an official validation process that does not exist for this specific test suite.
Q: Where is the Github Repo?
A: https://github.com/thyarcanist/EntropyLattice-Public/tree/main/Evals
Q: What is TRNG mostly useful for, where PRNG falls short?
A: True Random Number Generators (TRNGs) like Eris are crucial in areas where the quality and unpredictability of randomness are critical. This includes high-fidelity simulations (like financial modeling or realistic wargaming), robust AI training, high-stakes security applications, and situations requiring verifiable randomness like lotteries.
Standard Pseudo-Random Number Generators (PRNGs), being deterministic algorithms, can replicate statistical randomness well but inherently lack the ability to model truly emergent phenomena like state collapse, attractor fixation, or genuine learning observed in complex systems. They can reproduce predictable structures but miss the essential spontaneity. In a world increasingly reliant on adaptive systems, relying only on PRNG can be like training in a sterile, predictable environment – it doesn't prepare the system for real-world unpredictability or reveal its behavior under genuine chaos.
Q: Doesn't true, genuine randomness mean no reproducibility?
A: Not in the way that matters for analysis. While consecutive calls to a TRNG like Eris will produce different, unpredictable random sequences, the sequence of bytes returned from any single specific call is fixed. You can capture this output block and use it as a high-entropy "seed" for any process that requires reproducible input. Crucially, this form of reproducibility focuses on consistent behavioral emergence. Using a captured sequence allows you to observe how your system consistently behaves when subjected to that specific, complex, high-entropy input. Reproducibility here doesn't mean determinism in generation, but reliability in observing the outcome of using truly random data. It allows learning about system behaviors.
Q: What about seeds?
A: Eris doesn't rely on a traditional input "seed" like a PRNG. Instead, it generates randomness algorithmically based on quantum-inspired principles. The random data sequence you receive from an API call itself acts as a high-quality, unpredictable "seed" that you can use for your applications or for ensuring reproducibility as explained above. Ultimately, for a generator like Eris, the concept of an input 'seed' is less important than the inherent stability and design of the entropy-generating structure (the functions and logic of the program) itself. The quality comes from the process, not a simple starting number. All seeds are borne from Eris with this; what you are getting is a seed of randomness.
Q: Why should I care?
A: Think of how hard I have to explain why randomness and entropy are important. They also coincide with one another. After a point, randomness becomes less pseudo and more entropic. High entropy is a measurable qualitative for true randomness; not just high-quality. For complex, adaptive systems, the subtle patterns or predictability in PRNG act like noise, obscuring true behavior. True randomness, harnessed correctly, isn't just noise – it's the signal revealing a system's true capabilities and weaknesses under chaos. Once a system is stable enough to handle it, high-entropy randomness teaches.
Q: Are the /api/d20 dice rolls always fresh?
A: Yes. This endpoint uses eris:full (whitened) by default and returns brand-new quantum bytes on every call—so you'll never see the same roll twice unless you explicitly reuse or log the bytes yourself.
Q: But how can randomness have reproducibility?
A: Quantum RNG calls always yield new entropy, so raw rolls aren't repeatable. If you do need to replay exactly the same sequence, simply capture & store the byte block returned by your first API call—and feed that back in later. Or pull one quantum-sourced block up front, then seed a conventional PRNG with it for all subsequent rolls—giving you both true randomness and full replayability.
Q: How can I get repeatable dice rolls for gaming?
A: If you want every dungeon master session to behave identically, fetch 16 bytes once (`/api/eris/invoke?size=16`), store them as your "campaign seed," then derive all your d20 rolls from a standard PRNG seeded with that value.
Q: Why do the statistical properties (e.g., quality score, correlation) in the `/api/quantum/certificate` response sometimes look different from the high scores in published audit reports?
A: The statistical properties shown within a single API certificate response are calculated *only* on the small amount of data requested for that specific certificate. Statistical measures like entropy scores or correlations require large amounts of data (typically many kilobytes or megabytes, like those used in our full audit reports of 1MB, 10MB, or larger datasets) to be reliable and truly representative. You can observe this effect yourself: try fetching certificates with different sizes, for example, 128 bytes, then 1024 bytes (1KB), and then 90000 bytes (90KB). You'll likely see the quality scores and correlation metrics reported in the certificate improve and get closer to the true baseline as the sample size increases. While the certificate is always useful for verifying the integrity of that specific data block via its hash, you should rely on the comprehensive audit reports (linked in documentation/GitHub) to assess the *overall* quality. These large-scale audits consistently show exceptional entropy quality (typically 0.9999862 down to 0.99 bits/bit) and verified unpredictability (correlation typically -0.000 to -0.008). The stats calculated on the small samples within the certificate response can fluctuate significantly due to statistical noise and do not reflect this high level of bulk performance.