[ANN] RIGOR — Not More Consensus, but a Different Allocation of Monetary Role

[rigorchain]

[ANN] Rigorchain — Not More Consensus, but a Different Allocation of Monetary Roles

Rigorchain Mainnet Genesis Activation:
2026-10-25 06:00:00 UTC

This pre-launch announcement describes the Rigor protocol design, consensus rules, and planned procedures for independently inspecting and running the software after its public release.

The official source-code repository and mainnet release packages are scheduled to become publicly available at the announced mainnet activation time.

Abstract

Rigorchain is a Proof-of-Work UTXO blockchain with two native consensus assets:

ORU — Operational Resource Unit

RES — Reserve End State

The central structural distinction is simple:

Rigorchain has two native assets, and one of them cannot be mined.

ORU is produced by Proof-of-Work.

RES is produced only inside a transaction that destroys ORU in the same transaction, under an integer inequality evaluated by every full node.

There is:
- no coinbase RES;
- no swap contract;
- no issuer;
- no reverse path from RES back to ORU.

The mainnet launch contains:
- no premine;
- no founder allocation;
- no administrative issuance path.

Rigorchain is experimental blockchain software designed for public inspection and independent verification. The protocol design and selected parameters are described in this announcement and the public-facing project resources. The implementation source code and official mainnet release packages are scheduled for public release at mainnet activation.

This announcement does not guarantee adoption, market value, security under all conditions, or future development outcomes. Users should review the source code and understand the protocol before running software or participating in the network.

1. Why Rigorchain Exists

Many digital monetary systems ask one native asset to serve several functions at once:
- medium of exchange;
- miner incentive;
- network security budget;
- long-term reserve.

This is not a criticism of any existing system. It is a protocol design question.

These functions interact. An asset used for frequent transfer naturally tends toward circulation. An asset treated as a long-term reserve naturally tends toward reduced velocity.

Security is a continuous flow. Hashpower protects prior history, not only the current block. A transaction fee is a one-time payment for inclusion.

Bitcoin chose a unified approach:

One native asset coordinating multiple monetary functions.

That is a coherent and historically significant design decision. Rigorchain does not consider Bitcoin's design principles incorrect.

Rigorchain builds on properties Bitcoin demonstrated:
- Proof-of-Work ordering;
- UTXO ownership;
- independent node verification;
- deterministic consensus rules.

The difference is not the foundation. The difference is the allocation of monetary roles.

Rigorchain explores whether those roles can be separated at the protocol layer while retaining Proof-of-Work, the UTXO model, and deterministic validation.

This is a design-space exploration, not a verdict on any other system.

2. Architecture

Rigorchain's constraint is to separate monetary roles without introducing a parallel accounting system.

One UTXO state space

Rigorchain does not introduce:
- a second ledger;
- an account model;
- an external asset registry.

A coin remains:

Code:

(nValue, scriptPubKey)

identified by:

Code:

(txid, n)

There is no separate ORU database and no separate RES database. Both assets exist within the same UTXO state space.

Script-as-asset

Asset identity belongs to consensus-defined script classification. It does not come from wallet interpretation, explorer metadata, address prefixes, indexer databases, or external registries.

The same bytes produce the same classification on every node.

Identity lives in the script. Legitimacy lives in consensus.

Closed consensus surface

Consensus recognizes a fixed set of transaction templates. Rigorchain does not include:
- a general-purpose virtual machine;
- a contract execution environment;
- arbitrary token interpretation;
- a hidden state layer;
- an external asset registry.

Unknown monetary forms are rejected rather than interpreted. A future asset type would require an explicit consensus change.

Dual-asset conservation

ORU and RES share one UTXO state space but maintain independent conservation rules.

An output carries one asset identity. ORU inputs cannot fund RES outputs, and RES inputs cannot fund ORU outputs. The only exception is the one-way destroy-to-mint path described below.

The two assets are not represented through an external token layer.

Domain-separated Proof-of-Work

Rigorchain separates block identity from Proof-of-Work validity.

Block identity:

Code:

SHA256d(header_80)

Proof-of-Work validity:

Code:

SHA3-256("RGRPOW01" || header_80)

The domain-separation prefix `RGRPOW01` makes the PoW function explicitly protocol-specific.

Mining produces shared chain ordering. Mining does not produce RES.

Protocol monetary roles

Code:

Work
  |
  +--> ORU subsidy
       128 ORU per block

RES demand
  |
  +--> ORU destruction
       (RFC-020)

RES transfers
  |
  +--> Half of the ORU transaction fee destroyed
       (RFC-018)

The miner subsidy is defined by the protocol: 128 ORU per block from height 1 onward. It does not depend on long-term holders transacting, RES activity, or external demand.

The protocol does not create demand for RES. It defines the transformation that converts such demand, if it exists, into destroyed ORU.

3. Chain Mechanics

Consensus: Proof-of-Work, most-work chain

Ledger: UTXO only

PoW validity:

Code:

OpuHash = SHA3-256("RGRPOW01" || header_80)

Block identity:

Code:

SHA256d(header_80)

Difficulty adjustment: ASERT

[th]Parameter[/th][th]Value[/th]
Target spacing	600 seconds
Half-life	43200 seconds
Anchor height	1
Adjacent target adjustment clamp	±12.5%

Signatures: Ed25519

Script: Four closed templates; no general-purpose script VM.

Maturity: 100 confirmations for coinbase ORU and RES mint outputs.

Script templates

Witness v0 / 20-byte program
- ORU
- Address form: `rg1q...`

Witness v1 / 32-byte Ed25519 program
- RES
- Address form: `rg1p...`

Witness v1 in Rigorchain is not Bitcoin Taproot.

HASH160 / `0xbd`
- ORU destruction
- The destruction output never enters the UTXO set.

Zero-value OP_RETURN
- No asset.

Anything outside the supported templates is rejected.

Spends are checked through `VerifyRigorPredicate`.

The following spend paths are not accepted:
- P2PKH;
- P2SH;
- P2WSH;
- Bitcoin Taproot;
- secp256k1 spend paths.

4. ORU and RES

Rigorchain defines two native consensus assets.

ORU — Operational Resource Unit

ORU is the operational asset. It provides:
- transaction fees;
- miner subsidy;
- Proof-of-Work security incentive;
- the source material for RES creation.

ORU is designed for circulation. Its issuance provides a continuous subsidy-based incentive for miners.

Issuance:

Code:

subsidy(0) = 0 ORU
subsidy(h >= 1) = 128 ORU

There is no halving schedule.

ORU has no declared terminal supply cap. `MAX_MONEY = 10^10 ORU` is an arithmetic bound, not a monetary supply cap.

RES — Reserve End State

RES is a separate scarce asset with a deterministic protocol supply boundary and reserve-oriented ownership semantics.

RES cannot be:
- mined;
- received from coinbase;
- issued by governance;
- converted back into ORU.

At genesis:

Code:

S_RES(0) = 0

Every RES unit must originate from an observable ORU destruction event.

Bitcoin uses one native monetary asset. Rigorchain defines two. Whether this separation achieves its intended economic goals remains an open question.

5. Convergence

Convergence is the only protocol path that creates RES.

A user spends ORU into an `OP_CONVERGE` output with amount `B`. That output never enters the UTXO set.

The same transaction may create Witness v1 RES outputs whose amounts sum to `R`.

At confirming height `h`, the consensus predicate is:

For `R > 0`:

Code:

R * (2^25 + h)^2 <= B << 40

For `R = 0`, `B` is unconstrained by the RES mint predicate.

The destruction is explicit. It is not inferred from:

Code:

inputs - outputs - fee

The mint occurs in the same transaction as the destruction. The miner who includes the transaction receives no RES from this mechanism.

The predicate is integer-based. The same `(R, B, h)` produces the same acceptance or rejection result on every conforming full node.

Display form:

Code:

destroy_cost(h) = 1024 * (2^25 + h)^2 / 2^50
ORU per whole RES

At height 0:

Code:

destroy_cost(0) = 1024 ORU

The cost is a protocol requirement, not a market quote.

RES mint restrictions

There is no per-block RES mint cap.

RES mint outputs mature after 100 confirmations.

Examples of consensus rejection reasons include:

Code:

bad-txns-res-mint-underpaid
bad-txns-res-mint-no-burn
illegal-res-to-oru-conversion

RES transfer destruction

For transactions spending RES inputs, half of the ORU transaction fee, rounded down, becomes unclaimable:

Code:

floor(fee / 2)

This mechanism is defined in RFC-018.

It excludes pure ORU spends and Convergence transactions themselves.

6. Supply Model

Rigorchain defines:

Code:

RES_MAX_SUPPLY = 2^22 = 4,194,304 RES

This value is derived from protocol constants, not an arbitrary assigned cap.

The closed-form derivation is:

Code:

(S / P0) * H
= (2^7 / 2^10) * 2^25
= 2^22

where:
- `S = 2^7 = 128 ORU` subsidy;
- `P0 = 2^10 = 1024 ORU per RES` at height 0;
- `H = 2^25`.

The full derivation is specified in RFC-020.

RES issuance boundary

The following values represent the `ρ = 100%` boundary condition: every ORU emitted by the protocol is destroyed for RES creation.

These are mathematical upper-bound calculations, not forecasts. The calculation is generated from `tools/res_continuous_price_schedule.py`.

Year	Height	ORU / RES	Cumulative RES	% Ceiling
1	52,594	1,027.21	6,564	0.16%
4	210,379	1,036.88	26,134	0.62%
10	525,949	1,056.35	64,729	1.54%
16	841,518	1,076.01	102,616	2.45%
32	1,683,037	1,129.30	200,331	4.78%
100	5,259,492	1,370.17	568,350	13.55%
638	33,555,558	4,096.14	2,097,187	50.00%

Protocol observations

Two observations follow from this `ρ = 100%` boundary model.

First, under this condition, issuance reaches half of the theoretical RES ceiling at approximately year 638, corresponding to height `2^25`. This is the midpoint of the modeled issuance distribution, not a forecast of actual issuance.

Second, the destroy cost changes gradually during the early years. At height 0, the cost is 1,024 ORU per RES. By year 16, the modeled cost has increased by approximately 5%. The curve is strictly increasing; it is not an early steep ramp.

Supply definitions

Four different quantities must be distinguished.

1. Theoretical maximum

4,194,304 RES, the protocol-defined upper bound derived in this section.

2. Actual minted supply

Actual RES creation depends on voluntary ORU destruction through Convergence. If nobody converges, RES issuance is zero and the chain continues to function normally.

3. The issuance table

The table represents only the `ρ = 100%` maximum-participation boundary. Actual participation below this condition produces less RES.

4. Circulating supply

Circulating supply is the subset of minted RES that exists in spendable UTXOs. Minted supply and circulating supply are not identical quantities.

Protocol boundary

The protocol enforces the RES mint predicate, the absence of a RES-to-ORU conversion path, and the maximum RES supply boundary.

The protocol does not enforce, promise, or predict:
- that anyone destroys ORU;
- that the ceiling is ever approached;
- that a market exists;
- that `ρ` reaches any specific range.

Mathematical scarcity is a protocol property, not a guarantee of an economic outcome.

Open protocol question

RFC-020 records an open question rather than hiding it. RES issuance is intentionally thin during the early years. If a market is too thin to discover a meaningful RES/ORU exchange relationship, demand may not be transmitted into ORU destruction.

The RFC defines the mechanism. It does not define or guarantee a market threshold.

7. Verification Boundary

Rigorchain maintains a Coq consensus kernel model.

The published statement is:

Inside the Coq consensus kernel model, critical consensus invariants have been machine-checked, with explicit extraction and runtime trust boundaries.

The formal model is not claimed to be:
- a proof that the production binary has no bugs;
- a proof of implementation equivalence;
- a replacement for independent review.

The trust boundary is explicit:

Code:

Formal model
!= equivalence with the running implementation
!= proof about the running binary

The project records:

Code:

equivalence_claimed = false

Explorers and websites display public data. Validity is decided by a full node.

8. Genesis and Launch

The scheduled Rigorchain Mainnet Genesis activation time is:

Code:

2026-10-25 06:00:00 UTC

This is the announced public launch time. The Genesis timestamp identifies the chain's configured time; it should not be confused with a separate wall-clock consensus rule unless explicitly implemented as one.

Genesis parameters

[th]Parameter[/th][th]Value[/th]
Genesis hash	`e2ce92cfef740f92e8cc84a8541d8e760c776c668afd9b61740b3a4315241468`
Merkle root	`9d3fbd207af927fc8e2c57e975d8d5845913bf059d956592e8a0bcf38b3515dd`
Genesis nTime	`1792908000` (2026-10-25 06:00:00 UTC)
Genesis nBits	`0x1d008000`
Genesis nonce	`0`
Genesis message	`Selection not computation. Convergence defines state. Naming is consensus.`
Message magic	`ce f1 db fa`
P2P / RPC ports	`8760 / 8761` (RPC intended for localhost use)
Address HRP	`rg`

The Genesis block is the chain identity anchor. Genesis itself is not a mined Proof-of-Work block. Its nonce remains zero. `nBits` defines the starting difficulty for height 1.

Distribution facts

Genesis subsidy: 0 ORU.

The Genesis coinbase is not added to the UTXO set.

From height 1 onward:
- subsidy: 128 ORU per block;
- no halving;
- no early bonus;
- no premine;
- no founder allocation;
- no administrative issuance;
- no other ORU issuance path.

RES starts at:

Code:

S_RES(0) = 0

Coinbase cannot mint RES. The first subsidy-bearing block is height 1 and is produced through public Proof-of-Work after the announced launch.

A node reporting a different block-0 hash is not on this Rigorchain Mainnet. Do not reuse a data directory initialized for a different genesis.

Early Network Synchronization and Confirmations

During initial network operation, nodes may take time to discover peers and synchronize. Miners should verify that their node is connected to the intended Rigorchain Mainnet, is following the expected chain, and has the appropriate synchronization status before mining.

As with any Proof-of-Work blockchain, temporary chain reorganizations can occur when competing valid branches are observed. This statement is a general property of Proof-of-Work networks; it is not a prediction that a particular Rigorchain block height will reorganize.

Users should wait for an appropriate number of confirmations before treating transactions as final. The appropriate confirmation depth depends on the transaction's value, the network's observed condition, and the user's risk tolerance.

9. Mining

Coinbase pays ORU only. Proof-of-Work does not create RES.

Public participation in this release is solo mining against your own node.

Mining flow

Code:

getblocktemplate
       |
       v
copy canonical coinbase bytes
       |
       v
SHA3-256("RGRPOW01" || header_80)
       |
       v
submitblock

The node assembles the coinbase. The miner uses the canonical coinbase transaction supplied by the node:

Code:

default_coinbase_tx

`getwork` is not a supported mining path.

Stratum is refused as a solo-mining URL.

The reference CPU miner uses the algorithm identifier:

Code:

-a rgrpow01

No GPU or ASIC implementation is published with this release.

Mining requirements

The payout address must be a Mainnet ORU address:

Code:

rg1q...

Do not use a RES address:

Code:

rg1p...

Do not use a testnet address such as:

Code:

trg1q...

Genesis, synchronization, and template availability

Mining should begin only after the official mainnet software and release instructions become available and the miner has verified the intended chain identity and synchronization status.

Reference miner example

The following example illustrates the planned command-line interface for the official reference miner after its release:

Code:

rigor-miner -a rgrpow01
  -o http://127.0.0.1:8761
  -u <rpcuser>
  -p <rpcpassword>
  --coinbase-addr=rg1q...
  -t <threads>

Replace the placeholders with your own RPC credentials, Mainnet ORU address, and thread count. Keep RPC bound to localhost and protect the credentials.

The official miner binaries and source code are scheduled for public release at mainnet activation. The command above is an advance reference, not a statement that the software is currently available for download.

10. Running a Node

Node parameters

[th]Service[/th][th]Value[/th]
DNS seed	`seed.rigorchain.com`
P2P	`8760`
RPC	`8761` (localhost use)

Do not expose RPC publicly.

Verify the chain

After the official node software becomes available, check the reported network:

Code:

rigor-cli getblockchaininfo

Expected:

Code:

chain = main

Check the Genesis hash:

Code:

rigor-cli getblockhash 0

Expected:

Code:

e2ce92cfef740f92e8cc84a8541d8e760c776c668afd9b61740b3a4315241468

A different block-0 hash represents a different chain.

Configuration paths

Windows:

Code:

%APPDATA%\\RIGOR\\rigor.conf

Linux:

Code:

~/.rigor/rigor.conf

For mining-specific instructions, consult the official mainnet miner documentation when the source repository becomes public.

11. Official Resources, Source, and Release

Official project resources

Website:
https://www.rigorchain.com/

Explorer:
https://explorer.rigorchain.com/

RES supply and issuance information:
https://explorer.rigorchain.com/res.html

These public resources provide an introduction to the project and allow visitors to inspect the information displayed by the explorer. The explorer is an observational tool, not a consensus authority.

Source repository and mainnet release

Repository:
https://github.com/rigorchain/rigorchain

Mainnet release:
https://github.com/rigorchain/rigorchain/releases/tag/v0.2-mainnet

The official source-code repository and mainnet release packages are scheduled to become publicly available at:

Code:

2026-10-25 06:00:00 UTC

Before that time, the repository is not being announced as publicly available source code, and the release page should not be interpreted as confirmation that downloadable packages are already available.

At mainnet activation, consult the official repository and release page for the actual publication status, supported platform packages, build instructions, and checksums.

Release verification

When the release packages are available, the release page will identify the supported platform packages and their checksums.

If the release includes `SHA256SUMS.txt`, verify the files from the directory containing the downloaded checksum file:

Code:

sha256sum -c SHA256SUMS.txt

Do not run a binary if its checksum does not match the published checksum.

Build from source

After the official source repository becomes publicly available, consult its build documentation for the applicable dependencies and platform-specific instructions.

The basic source-build sequence is expected to follow this form:

Code:

cd core
./autogen.sh
./configure
make

This is a reference sequence for use after source publication. It does not imply that the repository is publicly accessible before the announced release time.

Technical references

The following project documents and source files are intended to provide additional technical detail when the official repository becomes publicly accessible:
- `docs/architecture/RIGOR_ARCHITECTURE_PAPER.md`
- `docs/protocol/RFC-020.md`
- `docs/protocol/RFC-018.md`
- `core/src/consensus/res_issuance.h`
- `core/src/kernel/chainparams.cpp`

12. Disclaimer

Rigorchain is experimental blockchain software intended for public inspection and independent verification. Its source code and official mainnet release packages are scheduled to be published at the announced mainnet activation time.

The protocol defines deterministic consensus rules. However, it does not guarantee:
- adoption;
- market value;
- liquidity;
- future development;
- resistance against all possible attacks.

The protocol separates monetary roles at the consensus level. Whether this architecture achieves its intended goals is an open question that can only be evaluated through long-term operation, independent review, and practical network usage.

Users should verify the source code and understand the protocol before running software or participating.

Final Note

Rigorchain begins with a simple observation:

A monetary protocol does not necessarily need every economic function to exist inside one native asset.

The protocol explores what happens when security incentives and long-term scarcity are separated:

Code:

Security incentive
        |
        v
       ORU

Long-term scarcity
        |
        v
       RES

while maintaining:

Code:

Proof-of-Work
+ UTXO ownership
+ deterministic consensus

The result is not a claim of completion. It is a published experiment in protocol architecture.

The protocol design and selected mainnet parameters are presented here for advance public discussion. The official implementation source code and mainnet release packages are scheduled to become publicly available at the announced mainnet activation time.

The remaining evaluation belongs to time, independent review, and actual network operation.

Rigorchain Mainnet

Genesis activation: 2026-10-25 06:00:00 UTC

Repository:
https://github.com/rigorchain/rigorchain

Website:
https://www.rigorchain.com/

Explorer:
https://explorer.rigorchain.com/