Update from Parano1d

Sep 16, 2026

Parano1d v2 begins with proof-native contracts

Parano1d v1.1.0 is live. Work on v2 has now begun. The goal for v2 is to make Parano1d programmable without turning it into another general-purpose VM chain. Contract execution must become part of the recursive proof that already carries State validity forward from genesis. Miners prove it once. Nodes verify the proof instead of replaying the computation. The network must continue deleting old transaction bodies and reusing spent State slots. A node joining years later must still be able to verify the present without an archive or trusted checkpoint.

That is what I mean by proof-native contracts.

Before selecting a protocol design, I tested three models inside the actual HistoryStep geometry. The first question was not how expressive they could look on paper. It was whether useful programmability could fit inside Parano1d without making proof construction too slow for the network.

A general interpreter did not fit the B25 block budget. Recursively verifying a complete generic proof for every call was much worse.

One route survived. A bounded State-object model can reuse the authorization and commitment machinery already paid for by every block.

The integrated prototype confirms the basic geometry. It keeps a fixed proof shape as activity changes, fits the complete B25 step inside the current domain, preserves all 255 live authorization positions in B255, and leaves the Tx8x2 body at 323 bytes. Adversarial changes to code, State, context, recipient and authority do not pass.

A fixed relation for variable activity:
Update screenshot The same B25 relation accepts 0, 1, 4 and 16 contract calls without changing its row count or relation digest. Contract activity changes the witness, not the proof shape.

The complete step still fits B25
The full HistoryStep with the contract layer uses 4,188,799 of 4,194,304 rows, leaving 5,505 rows inside the existing domain.

Invalid transitions do not pass
Update screenshot Five adversarial mutations were tested. Invalid code, State, context and effects make the relation unsatisfied. Invalid authority is rejected before proof construction.

This is a feasibility result, not a protocol activation. The ABI, terminal proof, resource policy and updated soundness calculation still have to be completed.