RIVER
A Shielded Transaction Protocol Anchored to Hive
Jan Thomasewsky
Protocol Whitepaper — September 2026
Abstract
River is a shielded transaction protocol that separates public verification from public financial visibility. Users hold value as private notes, spend those notes by producing zero-knowledge proofs, and publish only the cryptographic objects required for the network to verify state transitions.
Hive provides River with an ordered, public and reconstructible history from which a new node can recover the accepted state without trusting another node's database.
Public HBD and HIVE may enter the system as shielded liabilities represented by RHBD and RHIVE and later return to their public forms through authenticated withdrawals.
River defines explicit assumptions for zero-knowledge parameters, validator quorum, custody, Hive availability and wallet key security.
This paper specifies the intended protocol model and trust boundaries rather than implementation milestones or development logs.
1. Introduction
Transparent ledgers solve verification by making economic activity easy to inspect. That property is useful for consensus, but it also exposes relationships that do not need to be public: who controls which funds, which outputs were spent, how much value moved, and how activity clusters over time.
River starts from the opposite requirement: a node should be able to verify that a transaction is valid without learning the private facts that made it valid.
River therefore divides the system into two layers.
The shielded ledger carries private ownership and transfers. The public history carries commitments to that private state and enough evidence to verify every accepted transition.
Hive is used as the canonical publication layer for that history. A local database may accelerate synchronization, but it is not the authority from which River derives truth.
The protocol is designed around four principles:
- Private ownership and transfers should not require a public account graph.
- Any full River node should be able to verify the same accepted state from canonical history.
- A public asset entering River must correspond to a clearly accounted River-side liability.
- No single database, broadcaster, validator or hot key should be sufficient to redefine state or unilaterally extract bridge funds.
2. System Model
A River wallet creates and receives shielded notes and retains the private keys and note secrets required to spend them.
River Nodes verify transactions and maintain shielded state. Validators additionally participate in block finality.
River Blocks order valid state transitions.
Hive stores the canonical public history from which nodes can reconstruct those transitions.
A threshold-controlled custody system holds public HBD and HIVE corresponding to outstanding RHBD and RHIVE liabilities.
Figure 1 — High-level River architecture
River Nodes verify proofs and state, River Blocks order valid transitions, and Hive provides canonical publication.
The state of River at height h can be viewed abstractly as a commitment tree C_h, a set of spent nullifiers N_h, asset-liability state A_h, and the consensus metadata needed to identify the accepted block.
A node does not need the plaintext of every private note to verify this state; it needs the public commitments, nullifiers, proofs, roots and block ordering that define valid transitions.
S_h = (C_h, N_h, A_h, consensus_h)
3. Shielded Notes and Commitments
3.1 Notes
Value inside River is represented by private notes rather than ordinary public account balances.
Conceptually, a note contains an asset identifier, a value, a recipient ownership key and fresh randomness.
The exact encoding is an implementation detail, but the note plaintext is not intended to appear in public River history.
note = (
asset,
value,
recipient_key,
rho,
randomness
)
3.2 Commitments
A commitment is a public cryptographic representation of a private note.
It lets the network commit to the existence of a note without publishing its plaintext.
Commitments are inserted into the River commitment tree. The resulting Merkle root becomes a compact public commitment to the set and order of shielded outputs known at that point in the chain.
cm = Commit(note)
Seeing a commitment does not, by itself, reveal the note owner, value or recipient.
The privacy requirement is that the commitment be computationally hiding while still binding the prover to a well-defined note.
3.3 Nullifiers
A shielded note must be spendable only once.
River therefore derives a one-time nullifier from private note data and the spender's secret authority.
The nullifier becomes public when the note is spent. Nodes reject a transaction if any of its nullifiers already exist in the spent-nullifier set.
nf = Nullify(
secret_authority,
note_secret
)
A correctly designed nullifier proves uniqueness of the spend without revealing which public commitment it came from.
Observers can see that a particular nullifier has appeared, but they should not be able to link it to its originating commitment or recover the spender from the nullifier alone.
4. Shielded State Transitions
A River transaction consumes one or more private notes and creates one or more new notes.
The public transaction does not need to reveal the consumed commitments, note plaintexts, owners, recipients or private amounts.
Instead, the spender produces a zero-knowledge proof that the hidden witness satisfies the River transaction rules.
Figure 2 — Public verification of a shielded state transition
4.1 Public Transaction Object
A public River transaction can be represented conceptually as:
tx_public = (
anchor_root,
nullifiers[],
commitments[],
ciphertexts[],
proof
)
The public object exposes the anchor root used by the proof, the nullifiers required for double-spend prevention, newly created commitments, encrypted recipient notes and the zero-knowledge proof.
The witness that satisfies the proof remains private.
4.2 Groth16 Proof
River uses Groth16 to prove, without exposing the witness, that each spent note exists under the referenced Merkle root, the spender has the required authority, each nullifier is derived correctly, every output commitment is well-formed, and the transaction preserves value according to the permitted asset rules.
For an ordinary private transfer, the circuit enforces that hidden input value equals hidden output value plus any explicitly permitted fee or public value.
sum(private inputs)
=
sum(private outputs)
+
permitted public value
Encrypted notes accompany new commitments so intended recipients can discover and decrypt outputs addressed to them.
Other observers may retain the ciphertext, but should not be able to recover the note plaintext without the appropriate viewing or spending material.
4.3 Trusted Setup
Groth16 requires circuit-specific public parameters generated from a trusted setup.
A production River circuit therefore uses parameters created through a public multi-party computation ceremony.
The soundness assumption is that at least one ceremony participant behaved honestly and permanently destroyed its secret contribution, so that no participant or coalition can reconstruct the complete toxic waste.
The proving key and verifying key are public protocol material and may be distributed freely.
Compromise of the ordinary proving key does not by itself reveal transaction witnesses or permit invalid proofs.
Recovery of the toxic waste associated with the setup is different: it could permit forged proofs and would invalidate the supply-integrity assumptions of the affected circuit.
Such an event requires parameter and circuit rotation and an explicit protocol recovery process; proofs accepted only under compromised parameters cannot be treated as cryptographically sound.
5. Canonical Publication on Hive
River uses Hive as the canonical publication and reconstruction layer.
Hive does not execute River privacy rules; it provides a public, ordered and eventually irreversible location for River protocol objects.
A River publication is identified by a fixed protocol domain tag and a versioned envelope containing the River network identifier, protocol version, object type, object identifier, integrity hash and, when necessary, fragmentation metadata.
5.1 River Publication Envelope
Conceptually, every River object published to Hive carries the following identifying fields:
river_object = (
"RIVER",
network_id,
version,
object_type,
object_id,
fragment_index,
fragment_count,
object_hash,
payload
)
The fixed RIVER domain tag distinguishes protocol data from unrelated Hive content.
The network identifier prevents test and production histories from being mixed.
The object type distinguishes blocks, consensus certificates, validator-set updates, withdrawal settlements and other canonical records.
The object hash commits to the complete serialized River object, not merely to an individual fragment.
5.2 Fragmentation
If a serialized River object exceeds the payload capacity of a single Hive operation, it is split into numbered fragments.
Every fragment carries the same object identifier, fragment count and full-object hash, plus its own fragment index.
A node accepts the object only after all required fragments are present, their indexes are unique and complete, reassembly is deterministic, and the hash of the reconstructed object equals object_hash.
Partial or inconsistent fragment sets do not define canonical River state.
5.3 Irreversibility and Reconstruction
A River object is considered canonically published only when every fragment required to reconstruct it has been included in Hive history and the Hive blocks containing those fragments are irreversible under Hive consensus.
Operationally, the publication becomes irreversible when the last required fragment is at or below Hive's last irreversible block and all earlier fragments satisfy the same condition.
Canonical ordering is derived from Hive block order and operation position, while River block validity remains subject to River's own proof and consensus rules.
A new node can therefore begin with no trusted River database.
It reads River-tagged history from Hive in canonical order, reconstructs complete objects, verifies finality certificates and proofs, rejects reused nullifiers, recomputes commitment and state roots, and derives the same local state.
SQLite or any other local store is a cache of derived state, not a source of consensus truth.
Canonical reconstruction
Hive history
|
v
Reconstruct objects
|
v
Verify River finality
|
v
Verify proofs and roots
|
v
Rebuild S_h
6. Asset Representation and Bridge
River can represent public Hive assets as shielded River liabilities.
RHBD denotes HBD liability inside River, and RHIVE denotes HIVE liability inside River.
They are not independent assets in this model: each unit outstanding inside River corresponds to an obligation backed by the associated public asset under the bridge custody rules.
Figure 3 — Conceptual public-to-shielded asset lifecycle
Public deposit → Shielded liability → Private ownership change → Public payout.
6.1 Deposit
A deposit begins with a public transfer of HBD or HIVE to the designated River vault.
After the transfer is irreversible under the deposit finality policy, River may create a shielded note of the corresponding RHBD or RHIVE value.
The mint must be bound to a unique deposit event so the same public deposit cannot create liability twice.
6.2 Private Transfer
Once inside River, ownership may change through shielded state transitions without changing total outstanding bridge liability.
A private transfer consumes existing River notes and creates new notes of equal permitted value.
6.3 Withdrawal
A withdrawal proves authorization to consume River-side liability and specifies the exact public settlement required on Hive.
The River-side spend must become canonical before the payout can be authorized.
A unique withdrawal identifier and settlement record prevent replay or duplicate payout.
The public settlement necessarily exposes its destination and public amount on Hive; River privacy applies to the internal ownership history that led to the withdrawal, not to data required by the public settlement chain.
6.4 Custody and Solvency
Bridge custody is a separate security domain from transaction privacy.
River requires threshold-controlled custody: no individual broadcaster, individual validator, or single hot signing key has unilateral authority to transfer assets from the vault.
A broadcaster may transport an already-authorized payout, but it cannot independently choose or modify the asset, amount, destination or withdrawal identifier.
Custody authorization must be bound to a finalized River withdrawal certificate.
The custody signer set may differ from the consensus validator set.
Treating the two roles as separate security domains reduces the risk that compromise of one operational role automatically compromises both consensus and reserves.
Whatever custody design is used, the bridge must preserve the following monetary invariant:
FUNDAMENTAL RIVER SOLVENCY RULE
Vaulted Public Assets ≥ Outstanding River Liabilities
HBD_vault >= RHBD_outstanding
HIVE_vault >= RHIVE_outstanding
Protocol fees, if any, must be accounted for explicitly and must not make the outstanding shielded liability exceed the public assets backing it.
7. Consensus and Finality
River Nodes may verify transactions independently, but canonical state requires agreement on one ordered block history.
River therefore uses a validator quorum to finalize block proposals.
A block hash commits to the previous block hash, ordered transactions, state root, commitment root, nullifier root, network identifier, chain identifier, protocol version and validator-set epoch.
Validators sign the exact block hash they accept.
Figure 4 — Quorum finality flow
7.1 Parameterized Validator Set
River is not defined as a five-validator protocol.
At each validator epoch e, consensus is parameterized by a validator set V_e of size N and a finality threshold q.
A quorum certificate is valid only when at least q authorized validators from the active epoch have signed the same block commitment.
N and q may evolve between epochs without changing the shielded transaction model.
FINAL(block, e)
iff
valid_signatures(
block_hash,
V_e
) >= q_e
The threshold must be chosen so that any two valid quorums intersect in more validators than the deployment assumes can be Byzantine.
A reference configuration may use N = 5 and q = 4, but those values are configuration parameters rather than permanent protocol constants.
7.2 Failure and Liveness
If fewer than q validators approve a proposal, the block does not finalize.
The network may continue attempting a later round or proposal, but it must prefer loss of liveness over inventing finality.
Under a 4-of-5 configuration, three approvals are insufficient: the state remains unfinalized until a valid quorum certificate exists.
7.3 Conflicting Finality and Equivocation
A validator that signs two incompatible blocks for the same consensus height and round equivocates.
If two incompatible blocks both obtain valid finality certificates, the quorum-safety assumption has been violated and the conflicting signatures constitute cryptographic evidence of that failure.
Nodes must not resolve such a conflict by local arrival order or by trusting a preferred peer; they halt advancement at the conflicting height and require an explicit recovery or governance procedure.
Changing any committed block field changes the block hash and invalidates signatures over the previous version.
The safety of finality therefore reduces to signature authenticity, validator-set correctness and the quorum-intersection assumption for the active epoch.
7.4 Validator-Set Changes
Validator membership changes occur through a canonical validator-set update finalized by the currently authorized set.
The update commits to the next epoch identifier, validator public keys, N, q and an activation height.
It becomes effective only at that deterministic future height after the update itself is canonical.
This prevents nodes from selecting validator sets from local configuration or peer preference.
This remains a federated consensus model. It should not be confused with permissionless proof-of-work or proof-of-stake; its security depends on the validator governance and fault assumptions explicitly adopted by the network.
8. Withdrawal Certificates
The entity that broadcasts a public payout must not be able to invent a withdrawal.
River therefore represents withdrawal authorization as a canonical certificate approved under the same finality rules as accepted River state.
A withdrawal certificate binds the exact request to the River state from which it was authorized.
A certificate can commit to:
- The withdrawal request and request block.
- The request state root and consuming nullifier or burn.
- A unique withdrawal identifier.
- The exact settlement parameters, including asset, amount and public destination.
- Network, chain, validator epoch and protocol version.
- The quorum signatures or finality certificate authorizing settlement.
Once the public payout has been executed, a separate canonical settlement record binds the withdrawal identifier to the resulting Hive transaction ID and records that the withdrawal has been settled.
The transaction ID is therefore evidence of execution, not a prerequisite for authorization.
The broadcaster is therefore an execution role, not an authority role.
Custody signers release funds only for a certificate that is finalized, structurally valid and whose withdrawal identifier has not already been settled.
The authorization they sign must bind the same asset, amount, destination and withdrawal identifier as the River certificate, making mutation or replay detectable and invalid.
9. Privacy Properties
River privacy is strongest inside the shielded pool.
For a valid private transfer, an observer should be able to verify that the transition is legal while remaining unable to determine the plaintext note values, private sender, private recipient, or which prior commitment corresponds to a published nullifier.
Public visibility vs. private information
| Publicly observable | Intended to remain hidden |
|---|---|
| Commitments | Note plaintext |
| Nullifiers | Origin commitment of a spend |
| Zero-knowledge proofs | Private witness used by the proof |
| Merkle / state roots | Private ownership graph |
| Encrypted note ciphertexts | Recipient note contents |
| Block order and timestamps | Internal sender / recipient identities |
| Public deposits and withdrawals | Private transfers between entry and exit |
This does not imply perfect anonymity.
Timing, block ordering, transaction frequency, wallet network traffic and the public bridge boundary can create correlation opportunities.
A user who deposits a distinctive public amount and withdraws a similar amount shortly afterward may reduce the effective anonymity gained from the shielded pool even though no River commitment, nullifier or proof directly reveals the link.
Bridge-level privacy can be improved by batching, delayed settlement, relaying, avoiding unique amounts and increasing the number of users sharing the same shielded pool.
These techniques complement the cryptographic privacy model; they do not replace it.
10. Trust Assumptions
River does not require users or observers to trust a local River database for canonical ledger history, but it does depend on explicit assumptions at several independent layers:
ZK proving system
Groth16 soundness and the integrity of the production parameter ceremony.
Validator quorum
Enough validator keys and operators remain within the stated fault model to preserve safety and liveness.
Bridge custody
The threshold custody policy and signer set prevent unilateral or unauthorized release of reserves.
Hive availability and irreversibility
Nodes can obtain the River-tagged canonical history and determine which Hive publications are irreversible.
Wallet security
Users protect spending keys, note secrets and any viewing material according to their privacy requirements.
Implementation correctness
Wallet, node, circuits, consensus and settlement software correctly enforce the protocol rules.
Violation of different assumptions produces different failure modes.
Validator failure can affect safety or liveness; custody compromise can affect backing assets; wallet-key compromise affects the corresponding user; loss of Hive availability can prevent reconstruction or progress; and compromise of Groth16 toxic waste can undermine proof soundness and therefore shielded supply integrity.
11. Security Model
River composes several security mechanisms rather than relying on a single defense.
Commitments bind hidden notes to public state.
Nullifiers prevent double spends without exposing the spent note.
Zero-knowledge proofs enforce private transaction rules.
Merkle and state roots commit nodes to accepted ledger state.
Consensus signatures bind validators to an exact block and epoch.
Hive provides canonical publication from which independent nodes can reconstruct that state.
Threshold custody and withdrawal certificates protect the public assets backing River liabilities.
The principal security boundaries are therefore:
Cryptographic soundness: Invalid private transitions must not produce valid proofs.
Supply integrity: The shielded liability supply must remain consistent with valid mint, transfer and burn rules.
Wallet security: Loss or theft of private spending material can compromise user funds.
Consensus security: The validator quorum must remain within its stated Byzantine and key-compromise assumptions.
Custody security: No single operational key or role may unilaterally move bridge reserves.
Solvency: Vaulted public assets must remain greater than or equal to outstanding River liabilities.
Canonical-history availability: Nodes must be able to obtain and verify River history published to Hive.
Metadata resistance: Protocol privacy does not erase timing, network-layer or public bridge metadata.
No one mechanism makes River unhackable or absolutely anonymous.
The security of the complete system is the composition of its cryptography, ceremony integrity, software implementation, validator operations, custody architecture, wallet behavior and the public chains with which it interacts.
12. Conclusion
River is designed to make public verification compatible with private value transfer.
The shielded ledger replaces a public transaction graph with commitments, nullifiers, encrypted notes and zero-knowledge proofs.
Hive provides the ordered public record from which River state can be independently reconstructed.
RHBD and RHIVE connect that shielded state to public HBD and HIVE under an explicit solvency rule and threshold settlement model.
Parameterized validator quorums define finality without making five validators a permanent protocol constraint, while canonical validator-set transitions provide a path for the federation to evolve.
The result is a protocol in which observers can verify that the rules were followed without requiring the public to learn the private economic relationships that satisfied those rules:
Private value, public verification.
References
[1] J. Groth, "On the Size of Pairing-based Non-interactive Arguments," EUROCRYPT, 2016.
[2] R. C. Merkle, "A Digital Signature Based on a Conventional Encryption Function," CRYPTO, 1987.
RIVER — A Shielded Transaction Protocol Anchored to Hive
Jan Thomasewsky · September 2026