Veridium Network (Rule 30 VDF, PoSW, Binary-Field STARKs)

Hey folks! Just kicking off my journey as a newbie here and wanted to say hi with a little intro. I used to hang around this place back in the day, like late 2010. I was totally hooked on Bitcoin and spent days diving deep into it. Having a solid grasp of the whole system was everything back then. After some time, when CPU mining on Litecoin died down, I sold off my coins and moved on. More recently, I jumped into ETH and a few other coins, but I’ll always remember how incredible it was to be part of something groundbreaking when it all started, especially when not many people understood it. Lately, I've been toying with this idea involving Rule 30 VDFs that just wouldn't leave my mind. Turns out, some really smart folks beat me to the punch with the foundational consensus theory back in 2013: Publicly verifiable proofs of sequential work https://dl.acm.org/doi/10.1145/2422436.2422479 For someone like me, just having the theory isn't enough. My project (still waiting on a name) is gonna need a ton of effort to explain and fully grasp, just like Bitcoin did. This is the spot for that, so I finally decided to join up and share. Oh, and my launch plan needs to pull the hash from the minting of a future Bitcoin block to kick off fairly. So yeah, I'm definitely in the right place! If anyone has suggestions on forums where I could discuss this further, I'd love to hear them. But just in case someone's curious about my idea and the choices I’ve made so far: - 100% fair-launch L1 commodity coin: no premine, allocations, funds, operators, contracts, or foundations - First Mover: Proof of Sequential Work Consensus - Mining

Welcome back. Anyone who was around in 2010 and still has enough wits left to willingly design a new consensus system in 2026 is at least posting in the right asylum.   Joking aside, you're at least starting from an actual mechanism instead of branding first and physics later. The part I'd be careful with is the leap from "the race looks flatter in simulation" to "real-world mining stays flat under adversarial conditions." That gap eats people alive. Schedulers, memory hierarchy, network jitter, implementation quality, tuning, weird hardware asymmetries, and plain old operator competence have a way of sneaking back in through the basement window even when the front door looks sealed.

Thanks for the warm welcome! Even just a little external attention on this is enough to keep me going right now. It means a lot. Your point about these basement windows around me is well taken. Security is hard. Cryptography is extra hard. And, deploying a properly tuned L1 with an ossified protocol and a novel consensus protocol? I'm finding out that it's gonna require making some new friends. It's also true that I don't have everything figured out. For instance, I've only just started considering privacy in the networking layer. I'm no expert, but a Dandelion++ implementation like in Monero seems like the best fit. Another thing I'm still figuring out is the macroeconomics. I want this coin because I want mining to be fun again. But, my research indicates that without a mining race a lot of people won't care. The best answer I have for this is a consumer framing. It goes like this: Right now, buying consumer hardware like cell phones and laptops is a pure cost center the moment you click "Buy" or walk out of the store. What if a miner running passively on that device coulld generate even $5-20 per month reliably? That could reframe every piece of consumer electronics as a productive asset! Let the first device pay for the next and so on. Since my last post, I've made a few changes that address some of those specific asymmetries you mentioned. The major one, is that I just finished the transition to a binary-native ledger format. This aligns the state transition directly with the STARK circuit, making my proof-of-everything (PoE) recursive state updates significantly faster and more memory-efficient. A stateless ledger gives minted blocks the property of being verified on sight. No need to build up the entire state from history to know a block is valid. No catching up. No merkle checkpoints or roll-ups. Instead, every block carries an aggregated STARK proof of the VDF continuity and the ledger transition, the block is its own certificate of validity. The physics ensure that the coins are there and the clock has stayed true since genesis. This makes participation on mobile, NUCs, and other lightweight hardware safer by design. Another big change, is that I've moved the internal hashing layer from Groestl/SHA2 to Vision32b. Vision is arithmetization-friendly for binary fields, so in my Binius-style STARK, proving is now essentially "free". It allows me to embed much higher-resolution "proof-of-trace" checkpoints into the VDF clock without bloating the proof. Another change worth mentioning is that I now have miner auto-calibration for the STARK prover. I'm calling a "Switchover Probe". It's a one-time check that dynamically adjusts the sumcheck crossover points based on the local machine's cache and SIMD width (AVX2/NEON). This ensures that proving throughput remains consistently optimal across heterogeneous hardware. It should help prevent that from becoming a hidden tax on smaller miners. It's a lot of work, but the physics really are starting to feel solid. I'm currently tuning the M/N window ratios to ensure the protocol stays lottery-like even when one peer has a significant hardware advantage. With a little help refining my ideas and calibrating my testnet, this could open doors to some wild places!

Hi, everyone. Progress update: Today was a productive mix of coding, generating mermaid charts, and policy planning. I also promoted my whitepaper to v3 to reflect the new binary ledger format. Today's applied research gains: - Identities can now derive up to 256 sub-keys; for multi-core CPU mining - Aggregated STARK proofs now partially working over VDF and ledger state - Binary native ledger now operational with HorizonTree and HorizonTreeWasm for 32-level Merkle - Switchover Probe is now binary native - Identity DDA now targets lease density instead of entry velocity - Throughput DDA now adapts to median VDF steps/s from Micro-Win metadata - Improved Chord scaling by implementing a successor list (depth=128) for churn-resistance - Finished the cross-chain genesis system and tested it under simulation Some new insights and ongoing efforts worth mentioning: - Wolfram's Rule 30 provides the VDF with computational irreducibility as a timekeeping primitive - Flattening the advantage curve converts mining from a tournament into a yield-bearing asset - Calibration of the coin cap and emission schedule is now active research topic - Researching Vision32b-based nullifier verification and ZEXE recursive shielding for encrypted UTXOs I'm really looking forward to earning my chance to start uploading a few things. Advice and questions are welcome.

Progress Update: Today I finally decided on a name for the project. Then, I registered domains and secured accounts on various platforms to ensure future availability. Now, I'm proud to announce: Veridium Network by Anosic Systems As a coinage, Veridium roughly means "green mineral" or "green ore". Why? Green is my favorite color and the connection to so-called "emerald ore" and "mining" is very satisying for this old Minecraft fan. Anosic means "without disease" or "healthy". In this case, the sickness is the perverse incentives created by PoW consensus. With Veridium, Anosic aims to prove that a modernized crypto can be much greener. Anosic Systems will be a research vessel and technical maintainer of the Veridum protocol and ecosystem. I have a few other active research projects (like my eBPF-like principled semantic IR) that this org will also maintain. Once I have a proper landing page the public site will be at: https://anosic.com (coming soon) Veridium Network refers to the permissionless L1 P2P network. Veridium is the name of cryptocurrency minted by participants of the network. A technical portal site with a block explorer, downloads, and various utilities will be at: https://veridium.cc (coming soon) No logo yet, but I did spend a few minutes exploring Unicode for a value symbol to adopt. I found "MATHEMATICAL SCRIPT CAPITAL V" at U+1D4B1 and it looks nicer than all the other V-shaped options I found. So, I'll soon start using in my scripts and in the testnet TUI to help me focus on the values more easily. For example, they would look like this: 𝒱0.01 If anyone has feedback on these names or questions/concerns about these plans it would be greatly appreciated.

I'm proud to announce that today I finalized the STARK field alignment. I got beat up pretty bad on this. I couldn't figure out how to get the trait implementations to play nicely together. In the end, using a specialized witness index, I managed to unify VDF, Identity, Ledger under a single oracle set. This gives Veridium three distinct proof segments bound by a consistent field tower. One final stretch of hard work remains before I can build a Rust/WASM miner client out of the simulator. Mainly, I need to record baselines and implement the Horizon Tree membership proof as a standalone Binius circuit. This won't be trivial, and I am worried that I will blow my 10KB proof budget in the process; but at ~7KB it might still work out. Keeping the sizes low is vital to building Veridium Network such that miners can participate with nothing more than a common smartphone. Also, I moved into a new monorepo under the Anosic Systems banner. There, I developed a new diagnostic chart providing needle scatterplots for the events for each node in the network. This has enabled me to bring the testnet performance to a full recovery under the binary ledger format. In fact, I am seeing a 3x speed-up in average VDF rate (over V8 workers) across all nodes. I also now have a wide array of unit and integrations tests. And, my library of utility scripts for various benchmarks has grown significantly. In the hope that sharing this kind of thing could lead to more people taking an interest in what I'm doing, these are the scripts: Consensus & VDF Research vdf:bench - Benchmark the Rule 30 VDF clock speed (Rule 30 parity) vdf:validate - Validate Rule 30 implementation against reference states vdf:chart:lyapunov - Perform Lyapunov exponent analysis and spectral VDF texture checks audit:degree - Audit Rule 30 non-linearity and bit-mixing degree audit:interpolation - Audit low-degree proximity for Reed-Solomon hegemony - Run the Monte Carlo fairness sweep to simulate block production luck wisdom:probe - Analyze entropy and "wisdom" density in the sequential clock yarn test:starvation - Audit event-loop lag and gossip responsiveness Prover & STARKs prover - Run core Binius STARK prover integration tests prover:build - WASM compiler, primary toolchain for portable prover builds prover:wasm - Validate WASM-compiled prover in the Node.js environment prover:bench - Native prover, peak throughput benchmark (Native AVX2/AVX512) bench:vision:stark - Benchmark the Vision-based STARK prover performance bench:compression - Measure trace compression efficiency for recursive proofs bench:recursion - Recursion bench, measure STARK recursion depth and overhead tax:probe - Tax probe, simulate "Field Tax" penalties for unoptimized witnesses Network & Sybil Resistance sybil - Perform high-concurrency Sybil stress tests on the Chord DHT tollbooth - Run RandomX PoW verification tests for DHT entry gating tollbooth:ring - Ring audit to verify identity-gated gossip constraints ring - Test the Veridium P2P Ring topology and connectivity lease - Test the Proof-of-Trace lease renewal mechanism audit:leaserenewal - Lease audit, for peer ejection and hardened gate enforcement audit:collisions - Collision audit, for detecting Chord ID address space clustering dos:stress - Stress test the node's resilience against RPC/Gossip flooding genesis:set - Orchestrate the initial Genesis validator set genesis:monitor - Monitor the health and propagation of the Genesis block tollbooth:purge:identities - Clear local identity cache for fresh audits It's still slightly premature for me to share my whitepaper or my numeric specs. But I'm happy to explain the trade-offs I've picked and how I've solved various problems if anyone is curious.

Veridium almost came to a full stop today. I thought that recursive STARK aggregation would significantly compress the ledger under TensorPCS. Instead, I saw the payload shoot from 10 KB up to sizes that would never work. I did find a field solution that would reduce it to nearly 20 KB, but this would have required miners to commit gigabytes of RAM to make proofs. It was almost game over. I was tempted to quit for the first time. Instead, I found another way. My research has now pivoted into a new dual-PCS (Polynomial Commitment Scheme) strategy. If it works, this means that the Veridium protocol will utilize two distinct PCS phases in an inductive chain: Phase A: Inner Segments - Work Layer - Target: VDF (Rule 30), Identity (Vision), Ledger (Horizon Tree) - PCS: TensorPCS - Reasoning: Optimized for high-throughput, large-trace "work" circuits - Output: Three internal proofs" (~525 KB total) - RAM Overhead: Minimal (linear to trace) Phase B: Master Verifier - Compression Layer - Target: Recursive Binius circuit that verifies the three TensorPC` proofs - PCS: High-Expansion FRI-Binius - Reasoning: Because Binius verifies Binius with degree-1 XORs, the trace is exceptionally small (2^14 bits per column) - Compression: By using an inv_rate of 256, we compress the proof size to 20 KB. - RAM Overhead: ~16 MB. Because the trace is small, the 256× expansion tax is trivial for consumer hardware/mobile phones. It's already coming together. Test suite is mostly passing again. The Binius-on-Binius verifier circuit exists. I have the witness, allowing me to feed the three segment proofs into the master circuit. I even have a field-compatible FRI-Binius implementation. But, the prover is still leaning on TensorPCS for the master proof. To hit a 20-30 KB target envelope for network transmission and fix the remaining handshake/starvation issues I'll need to hook FRI-Binius into the prover. I hope to do that soon and report back.

Hi everyone, I'm back with results from the dual-PCS compression work. The Veridium gossip certificate has been stabilized at 20.70 KB. The core breakthrough was decoupling the security parameters of the gossip layer from the underlying proof system. By parameterizing the FRI query phase, the Master Verifier now uses a 256x expansion factor with 12 queries, tuned to a 96-bit security margin -- appropriate for ephemeral network propagation. The two-layer architecture: 1. Work Layer - TensorPCS arithmetizes the Rule 30 VDF and Horizon Tree transitions into committed polynomials 2. Compression Layer - FRI-Binius wraps those commitments into a single opening proof, collapsing 3.5 MB of witness data into a 20 KB certificate What a peer verifies when they receive this certificate: 1. VDF Continuity - That the sequential work for the current interval was performed (Rule 30 steps) 2. Identity Gating - That the miner held a valid sub-key 3. Ledger Integrity - That the included transactions correctly transition the state root On succinctness: The 20.70 KB size is achieved through adaptive FRI parameterization, not a fixed circuit constraint. This means the gossip budget and settlement budget can be tuned independently as the network's security requirements are better known. Comparison to Mina: Mina's 22 KB proof (via the Pickles SNARK system) achieves constant size through recursive elliptic curve arithmetic over the Pasta curves, which requires a trusted setup. Veridium's certificate is transparent and post-quantum resistant with no trusted setup and binary field arithmetic throughout. The tradeoff is that FRI proof size is polylogarithmic rather than strictly constant, though at this scale the practical difference is negligible for gossip purposes. Next, I plan to push towards chain-depth recursive verification. The basic roadmap for this includes: - Move all internal Merkle trees to Vision-native arithmetization. This should yield a ~90% gate reduction in the verifier circuit - Arithmetize the FRI-fold and sumcheck logic directly as Binius constraints - Wrap the previous block’s certificate as a witness into the current proof The goal is to provide a "verified on sight" guarantee for the entire chain history. This could push the gossip payload up into the 35–60 KB range, but that would still be a modest price for the ability to verify the entire chain depth in milliseconds.

it won't work, it's impossible to compete with powerful hardware

It might work. That's why I'm here. Hopefully, you're here to do more than make proclamations of doom. That said, your opinion is the natural reaction for anyone who understands how most cryptocurrencies and their underlying forms of consensus work. Veridium works differently. On Information Sharing I haven't fully explained how Veridium is different. I will do that. But, the system is currently under rapid research and development. For instance, FRI-Binius is far more challenging than I anticipated; and I never anticipated needing it in the first place. As of today, it is operating under simulation with full-chain verification and fixed-size blockchain gossip payload of 39.79 KB at 128-bit security and 25 queries and 10 rounds of FRI folding. It still needs hardening of the VDF, Identity, and Ledger segments. After these arithmetizations, there might be so many gates in the verification that I've blown the 100ms budget I'm targeting. I have ideas for dealing with this, but using less queries and getting less network security could be the only good options. Once the parameters are more stable, I'll start publishing research and explaining the various components in detail. That said, I know that sharing some of this information now is the only way to invite feedback and encourage understanding. For this reason, I'm including some explanations below that I've been working on. They are low in technical detail but they do at least partially explain what Veridium is and why it might just work. Veridium Physics are Optimized for Prosumer Mining Veridium plays with most of the same physics as past cryptocurrencies. It even uses PoW (via RandomX) for identity cost. However, outside of Veridium, the idea of a Rule 30 VDF has never been publicly theorized. Consequently, computational irreducibility has never been productionized as a clock oracle. The mechanisms that the Veridium protocol builds around this new time-keeping primitive are what creates the fairness characteristics that would otherwise be impossible. Mining Hardware Becomes a Yield Instrument PoW mining is a zero-sum tournament. You win more by outspending your competitors on hardware and energy. This means: Time, energy, and opportunity are destroyed racing to the frontier- The rational actor is always the *biggest* player- Small holders are eventually squeezed out With a flattened advantage curve under PoSW, Veridium converts mining from a tournament into a yield-bearing asset. The miner is no longer weaponizing their hardware to gain an edge in an arms race. Instead, the miner is incentivized to increase their yield by investing in low-cost high-core hardware because the economics are much closer to a bond with hardware collateral. Self-Funding Hardware Acquisition Loop The key economic unlock of PoSW is: **Revenue ≥ Cost of next hardware unit** Once that's true, rational behavior flips. Instead of purchasing hardware to dominate, a miner will make purchases to either replicate or extend mining capacity through modularity. Each mining node becomes: A cash flow engine, not a competitive weaponSomething you hold, not something you race withAn asset class with a natural reinvestment rate This is very different from mining with PoW. Veridium makes hardware ownership somewhat like owning farmland. Even if your neighbor has much better farmland, yours is still productive. Safe Harbor as a Protocol Guarantee By ensuring that no single actor can price you out of earning, the protocol dramatically changes the macroeconomics: Lowers the discount rate applied to future mining rewardsMakes long time-preference behavior rationalAttracts patient capital, not speculative sprint capital The network stops selecting for the richest/fastest participants and starts selecting for the most persistent. Broad Distribution of Supply Issuance With a hardware advantage of only ~6 points and diluted across 10,000 units, the marginally-equipped miner remains viable indefinitely. This has a number of secondary effects: Newly issued coins distribute more broadlyNo single entity accumulates enough to threaten the networkThe coin's **Gini coefficient at issuance** stays healthier over time Launch Implications Typical PoW "Arms Race" Launch Early advantage creates a gold rush signal that does the following: Quickly pulls in capitalCreates urgency to join earlyBootstraps the networkVolatile but rapid price discovery In typical crypto launches, unfairness is either overt or implied in the marketing, because the asymmetry is the true incentive. Veridium's "Flattened" Launch By removing the hardware advantage, we remove most of the gold rush signal. Now the adoption curve looks more like: A slow burn, rational actors accumulate when they're readyNo urgency premium, so no urgency-driven demand spikeThe asset gets valued on yield fundamentals rather than speculative positioning Note: A recent draft of the Veridium Network emission schedule introduces a steeper issuance curve during the first 10 years of mining; out of a 400-year emission schedule. This 10-year period would be intended to increase early speculative interest in in order to help bootstrap the network.

My last post mentioned the need to harden the VDF, Identity, and Ledger arithmetizations. I specifically expressed my concern that gate count inflation could destroy the 100ms verifier budget and/or blow up the blockchain payload. Twenty days later, I'm here to report on my progress. Those concerns were well justified. As a result, these last few weeks have been absolutely brutal. I've been riding an endless rollercoaster of applied cryptographic engineering; and it's far from over. Here's what happened: Bit-Slicing Fail Hardening the VDF meant shifting the architecture to a bit-slicing regime. I spent days migrating the entire kernel to bit-sliced arithmetization. The spatial logic worked perfectly, but the single-segment proof size exploded to 104 KB. Every single bit required its own commitment, destroying the sub-64KB budget. Packed Geometry Pivot To save the budgets without sacrificing security, I pivoted to a packed field geometry. This meant overhauling the N-API bridge and the kernel to collapse 512 individual bit-oracles into four 128-bit packed words. It was a massive architectural risk, but it worked! This brought the proof size back down to ~41 KB and kept the verifier fast. Soundness Crisis & Security Regression While the geometry was now sensible and the budgets were satisfied, soundness was still lacking. The biggest obstacle was not being able to effectively reason about the algebraic traces and polynomials. They were too large and the tests were taking too long for rapid iteration. It was painfully clear that with a log_inv_rate of 4 (16x eval domain expansion) I was probably never going to figure it out. That's when I decided to make a tactical retreat to a log_inv_rate of 1 (2x expansion). This configuration also reduced the security floor to a mere 25 bits. Projection Oracles With the new geometry stabilized, I pushed onward toward projection oracles and vertical arithmetization. This architecture enables transparent unpacking for those 128-bit words inside the circuit without paying the field tax during the commitment phase. It also compressed the massive 1800-column oracle manifest down to a sleek 209-variable manifest, pushing proof sizes down to an incredible 9.7 KB. Continuity Constraints Under this vertical geometry, the prover began failing with an elusive evalcheck error. Also, the verifier was now rejecting the consistency of the shifted challenger state columns. I spent days tearing apart the recursive prover, assuming the constraints were failing. In the end, the bug was buried deep in the verifier's internal Binius reductions. Eventually, I fixed the issue, implemented a live challenger continuity constraint to cryptographically bind the final state, and finally achieved rigorous structural mathematical consistency. Ledger Block With the math consistent, prover stabilized, and all 88 tests and 10 audits passing, I wrote the very first blockchain completeness audit; optimistically expecting it to work. It didn't. This is the one audit that proves Veridium is undeniably real. Undeterred, I scoured the code to inventory all of the remaining technical debt and then identified three load-bearing stubs: A mock algebraic proxy for the Merkle path (not true Vision-32b)A static zero-seeded challenger traceA simplified query indexer Today, I conquered all three. Current Status The hardest part is over. Veridium is now mathematically sound and boasts a bit-sliced, recursive STARK over a Rule 30 VDF and UTXO carrying blockchain payload. However, security is still sitting at just 25 bits. The road ahead requires dialing the log_inv_rate back up to 4 in order to restore the security floor. The grind goes on. But at least the math is finally on my side. Changing The World With a little help, Veridium could change the world. It really could. All it has to do is make something profoundly useful possible that truly never was. Bitcoin and Ethereum both did it. But by comparison, every other cryptocurrency since has either been boring and/or derivative. Consider privacy. Veridium is privacy-first; shielded just like Monero. So who cares? I care. Mainstream people won't. At the end of the day, mainstream people only care about things like comfort and overpaying. To change the world, an L1 has to deliver an obvious and undeniable reason for mainstream people to actually care. Veridium will have a boatload of technical achievements worth boasting about. It will be the only L1 for payments that offers all of these at the same time: the energy efficiency of Chia-adjacent physics-based consensusthe stable blockchain payload and verified-on-sight (zero confirmations) properties of Mina Protocoldefault anonymity with optional Starknet-inspired viewing keys for regulator and auditor compliance Cool right? Wrong! Snoozeville. The mainstream doesn't care about any of that. Not in the least. This is what can be said about world-changing cryptocurrencies: Bitcoin proved that energy can generate currency.Ethereum proved that smart contracts can work.Veridium will prove that sustainable fair home mining is possible. When Veridium delivers the mainstream will not ignore it. Everyone will find out because it enables a new economic choice for everyone with capable (AVX-512/NEON) hardware. Call for Small Donations I'm under-employed right now and working on this in my spare time. Food and gas are the resources I need most. I'm going to continue regardless; that's just how I am. If you're interested in this project and would like to help speed things along, please send a small donation to my address below and then either reply or PM me to let me know if you wish. Bitcoin: bc1qee6dey9v05v2unw9jwywpgqht9q2x9w885gk8d

I'm feeling too exhausted and overworked to post updates lately. That said, I write this one tonight. I hope someone out there enjoys reading it. I'm entirely convinced that Veridium will have more firsts to boast than any blockchain since Bitcoin; so who knows, maybe someday these reports will actually matter to someone else besides me. Veridium is now undergoing an architectural pivot that marks one of the most significant changes in the protocol's short history. In recent weeks, the project has moved through several iterations as real-world constraints exposed the strengths and weaknesses in the design. What began as a search for smaller proofs and better network efficiency has led me to conclude that deep changes to the core proving and hashing choices are necessary. Weeks ago, in the dual-PCS era announced previously in this thread, one proving system (TensorPCS) was used to generate proofs while a second proving system (FRI-Binius) wrapped and compressed them into a smaller package suitable for network propagation. While this approach achieved impressive compression, it also introduced substantial complexity. With one proof system effectively verifying another, maintaining confidence in correctness across both layers became increasingly difficult. Debugging was just too hard and proving was too time-consuming. Then, I moved away from dual-PCS and standardized on a single TensorPCS-based architecture. Removing the recursive wrapper layer exposed a different problem: proof sizes grew far beyond the intended blockchain payload budget. Slowly, and painstakingly, it became increasingly clear that the inflated proofs were a consequence of the underlying design. The current pivot addresses this limitation by removing TensorPCS entirely and adopting FRI-Binius as the native proving system. Instead of acting as an external compression wrapper around another proof system, FRI-Binius now operates directly at the base layer. This eliminates the need for layered proof composition while producing proof sizes expected to fit comfortably within the targeted budget for the blockchain payload. The hashing architecture has undergone a similar reassessment. Earlier development cycles retired Grøstl in favor of Vision. I initially adopted Vision because it appeared to be a strong fit when evaluated through the lens of traditional proof-system design. As the implementation matured, however, Vision's column width requirements (a consequence of prime field bias) became a major source of pressure on circuit geometry and proof efficiency. The new design returns to Grøstl, but not in the role it occupied previously. This time, instead of serving as a defense-in-depth security fallback, it is now arithmetized directly into the binary-field circuit used by the proving system. This alignment allows the protocol to verify hash operations using far narrower circuits and reduces the blockchain payload overhead while satisfying the relevant geometry limits. To me, this pivot isn't a reversal. Some components that seemed optimal in theory proved awkward in practice. Others were solid choices, but required adaptation before they could take full advantage of the underlying mathematics of recursive binary-field STARKs. FRI-Binius and Grøstl are now being re-deployed as native components rather than auxiliary layers. The result should be a simpler architecture that removes the proof-size floor introduced by TensorPCS and avoids the circuit-width issues that emerged under Vision.

Recent work on Veridium has not changed character. It continues to be brutally difficult, with problems having subtle causes that are hard to diagnose. Here is the short version of the recent progress: Switching from Binius v0 (stale fork) to Binius v0 (HEAD), and currently at 53 tests, all passingAdopting some Binius M3 primitives this timeEmbracing formal verificationGrowing coverage of the circuits using KaniPlans for implementing Z3 and a hash-adapted fork of DecreeMany new probes, audits, and diagnostics Current status: Ready to start on the recursion assembly now. This will compose all of the working recursion segments into a single multi-segment block with fully wired data-level integration residuals and assembly-dependent gates. Disclaimer: Deep Veridium Lore Ahead This rest of this post has three goals: 1. Provide a clear picture of the recent difficulties that Veridium has encountered and the solutions that were found. 2. Explain how Veridium rests upon Binius as a substrate, without which it could never have been built. 3. Justify the particular version of Binius in use (v0) versus alternatives like the newer and actively maintained Binius64. Troubles with Multipoint-Opening Veridium recently reached a point where proving the Merkle membership in-circuit FRI verifier was among the final remaining tasks. The system must prove that the coset symbols the circuit folded are the same ones that were actually committed. Without it, a malicious prover could fold any internally-consistent fake coset and the circuit would accept it. For soundness, this is effectively the core of Veridium's proof system. The linkage mechanism required a multiset equality argument to prove that the set {(query, round, M-coset)} from the fold side equals {(query, round, bind)} from the Merkle/Grøstl side. However, because these lived on different rows with no copy/permutation primitive available, this required some form of grand-product or running-product check. Why Binius Before I explain the various failed approaches, it's important to consider what the Binius library is and why it is the foundation of Veridium's design. Binius is the arithmetization substrate that everything else in Veridium sits on top of: the constraint system, the polynomial commitment scheme, the FRI protocol, the field tower. Choosing it was a foundational decision. The people who built Binius were well-credentialed professionals. Irreducible assembled a serious team of cryptographers and systems engineers, funded at a level that reflected the significance of their research agenda. The math that they produced, particularly the binary tower field construction and the packed multilinear approach, is genuinely novel work. There are other libraries for ZK and STARKs, but Binius is still years ahead of them. While I am devoted to understanding zero-knowledge proofs, much of the math and cryptography are still beyond me. As a proof system built by a world-class group of researchers, Binius is a strong foundation to build upon. Three Failed Approaches I tried three different approaches in my efforts to bring multipoint-opening to Veridium. I failed each time, but the pattern told me everything that the circuits couldn't. Approach #1: The Helper Polynomial The idea was to use Binius' included msetcheck and prodcheck features to commit a helper polynomial f' and open it. The product-tree structure forced f' to accumulate five distinct evaluation points, and greedy_evalcheck simply cannot collapse a committed polynomial opened at multiple points into a single same-query PCS claim. That was the wall I was up against; though I still hadn't realized it. Beyond the evaluation problem, the payload cost alone was fatal: supplying the roughly 2,200 trace evaluations needed to cover the batched commitment produced a proof in the 500-600 KB range, way beyond the current blockchain payload budget. Even if the evaluation collapse had worked, the approach just wasn't viable. Approach #2: Isolating the Tuples Then, I thought that perhaps the problem was that the linkage tuples were entangled with the rest of the trace. The second approach moved them into their own dedicated committed batch, on the theory that a narrower, isolated batch would be easier for greedy_evalcheck to handle. It was not. A dedicated batch still commits and opens f', and f' still accumulates the same five evaluation points from the product-tree structure. The same wall was there waiting for me, and so was the payload explosion. Isolating the tuples changed nothing about the underlying mechanics. Approach #3: The Running-Product Column This was the most promising of the three and, for a little while, it looked like it might actually work. This Plonk-style approach meant replacing the separate f' commitment entirely with a single running-product column z living directly in the trace. Because z was riding the main trace commitment, it opened at the main point rather than accruing its own separate openings. The cost dropped to something manageable, and the Fiat-Shamir malleability analysis confirmed the approach was sound as long as the challenges were sampled after the trace was committed. The prove-side wiring went in with RunningProductComposition, the two-round commit structure, a z_next shift, the composite batched into the main zerocheck, and the post-greedy split to open z into the new proof fields. Then, I hit the wall again. The z column was referenced in two ways: directly, and through the z_next logical-right-by-one shift. Each reference landed at a different evaluation point, giving greedy_evalcheck two distinct points to reduce for the round-2 z batch. The main trace batch had an identical direct-plus-shift structure and collapsed successfully, but the fresh round-2 z batch did not. Analysis: Hitting the Multi-Point Committed Polynomial Evaluation Wall Three constructions, three different shapes, and each one ran into the same error. The prodcheck's f' hit it at five points. The isolated tuple batch hit it at five points. The running-product column hit it at two points. The number of points changed but the failure mode didn't. I was now left with only one possible conclusion: the root cause was structural. So, I went looking for answers and it didn't take too long to find out that I had made a major mistake in the early days of Veridium. Tempted by a feature I wanted, I built upon an older fork of Binius without checking how old it was. I now realize it lacked many of the features and decouplings of the latest version. A simple error in judgement had baked insurmountable flaws into the project from the start. The stale fork featured a greedy_evalcheck that was built around the assumption that every committed polynomial could always be reduced to a single same-query PCS claim. The reduction path to handle multiple evaluation points per committed polynomial was simply never finished or exercised. The prodcheck and msetcheck code existed, but the greedy opening path was never hardened for it in practice. Every construction I attempted that needed to open a committed polynomial at multiple points would eventually reach the same incompatible assertion and fail. Solution: Replace the Substrate The wall I kept hitting wasn't just another hard problem waiting to be solved. It was a fundamental property of the substrate I was building on, and the substrate needed to change. By pivoting to an official copy of the latest Binius v0, I was able to resolve both the evaluation problem and the linkage architecture at the same time, and not through patches but through a fundamentally different design. The first major structural difference is the separation of zerocheck and sumcheck into independent protocols. In the old fork, these were coupled, and the evalcheck machinery had to collapse each committed batch down to a single same-query point before it could proceed. Now, greedy_evalcheck returns a flat list of Eval