Cash should protect your financial life. Kova is building a private network for a quantum future, with safeguards for your savings and a faster path to usable payments.
01 / The Kova research programmePrivate by default. Independently verifiable.
01The purpose
Financial privacy is part of personal safety.
A public rulebook. A private financial life.
Digital cash should let people pay, receive and save without publishing a permanent map of their finances. Verification should establish that a payment is valid while its private contents remain with the people entitled to see them.
Kova brings that principle together with two further requirements: security that anticipates advances in computing, and spending policies that give people a chance to respond to theft. Privacy, usability and protection belong in the same design.
Research objective
Develop a private cash system in which users can manage their money with confidentiality, security against quantum adversaries and enforceable protection for savings. Kova is being developed from scratch as a custom chain, with its own ledger and consensus architecture, standardized cryptography and attributed open source dependencies. The programme combines compatible merged mining research with stake certified settlement, private contracts and a withdrawal Safe.
01 / Confidentiality02 / Verifiability03 / Control
02The architecture
Privacy at the core. Security throughout.
Protocol design
One coherent system for private ownership, encrypted delivery and independently checked state transitions.
A
Prove the payment. Keep the witness private.
The wallet is designed to construct payment proofs locally. The required relation connects the same hidden notes to ownership, membership, authorization and conservation. Nodes verify the result and reject previously consumed spending rights.
(1)
Ordinary payment conservation. Amounts stay in the private witness. The fee and other verification metadata can remain public.
B
Post quantum security as a system requirement.
The target covers authorization, encryption, commitments, proofs, consensus certificates and recovery together. Kova is evaluating standardized lattice primitives and transparent proof constructions under a common threat model.
01AuthorizationWho may spend
02EncryptionWho may read
03CommitmentsWhat is bound
04ProofsWhat is verified
Versioned cryptography and private migration paths are part of the architecture. Upgrades must preserve ownership and conservation while avoiding public links between old and new notes.
Full post quantum security is a research target. Primitive standards and component tests are inputs to the complete protocol analysis.
Technical note / 01
Foundations
Evaluation baseline
The research separates the mathematical primitive, the private proof relation and the ledger rule. Each needs its own assumptions, canonical encoding and adversarial tests.
01 / Authorization
Module lattice signatures
ML DSA 87 is the current signature evaluation baseline. Its polynomial structure includes the following underlying key relation.
(2)
Here q = 8380417. A is a polynomial matrix and s1, s2 are short secret vectors. The derived t precedes public key rounding. This is an underlying key relation, not the full signature verification algorithm.
ML KEM 1024 is the key establishment baseline. A sender encapsulates to the recipient, who recovers the same shared secret locally.
(3)
A context bound key derivation and authenticated encryption then protect the note payload. Recipient discovery, viewing authority and ciphertext metadata require separate privacy analysis.
Transparent proof research targets a relation that binds ownership, membership, authorization, value and policy to the same private inputs.
(4)
x binds the public statement, w is its hidden witness, S is authenticated state and v selects the rule version. The node separately enforces eligible roots, global consumption and atomic state updates.
Complete hiding integration remains active work.
C
Work records. Stake certifies.
The consensus design combines Equihash proof of work with stake checkpoint certificates. Mining provides the work chain. Eligible stakers vote on valid history, with confidential staking as a design requirement. Regular nodes independently verify the protocol.
(5)
Design quorum rule. We is the fixed eligible epoch weight. Consensus safety also requires the specified voting, lock, data availability and epoch transition rules.
Private proofs and encryption protect transaction contents. Work and stake protect the ordering and commitment of valid state. Their contribution is to enforce the public rules without requiring the private witness to be revealed.
03Shared work
AuxPoW with a versioned boundary.
Adapter architecture
The initial research profile targets Zcash compatible Equihash (200,9). A reusable adapter library separates parent work verification from Kova's private ledger.
Every activated profile must define its parameters, personalization, parent encoding, child commitment, witness limits and work accounting. A matching algorithm name alone does not establish compatible mining jobs.
A library of supported profiles
The registry model permits compatible additions as authenticated profile data when the existing verification rules already cover them. Nodes derive the same active profile set from the protocol's accepted state.
Further Equihash parameter sets or parent networks need explicit bounds and validation. New verification semantics follow the network upgrade process. A plugin cannot independently change the rules accepted by other nodes.
(6)
℘(h) is the active profile set for the authenticated rule context. B is the Kova candidate and W the complete auxiliary witness. Normalized work accounting and activation rules remain specification requirements.
Private proof
Binds hidden ownership, membership, authorization and value.
Work verifier
Checks the supported puzzle, target and full parent commitment witness.
Stake consensus
Commits valid state under the epoch, quorum and locking rules.
The parent witness must cover the relevant transaction and authorizing data commitments. A child target match and acceptance on the parent network are different events. See ZIP 244 for the parent commitment boundary. Pool adoption and live submissions require separate integration tests.
04 / Aegis protocol
Payments move. Mining keeps its cadence.
Later protocol milestone
Aegis aims to provide instant private payments without waiting for the next mined block. A completed stake consensus decision would establish payment finality and eligible onward spending, while miners record the same certified history on their regular block schedule.
The initial chain profile uses checkpoint finality for onward spending. Aegis activation requires a reviewed implementation of confidential quorum, conflict handling and data availability.
Algorithm 1 / Certified transfer
Prove. C constructs a private proof bound to the exact payment.
Validate. Stakers check the proof, eligible state, consumption conflicts, policies and complete payload.
Commit. Consensus completes an ordered state decision under its quorum and locking rules.
Recover and spend. Y verifies the certificate and note, then constructs a new payment to Z against accepted certified state.
Record. Miners include the same ordered certified history in work blocks.
A payment latency budget
(7)
The budget includes local proving, data distribution, consensus and recipient recovery. Latency depends on available voting weight, network conditions and proof resources.
Sequential design model. Actual latency requires end to end measurement.
05Protected savings
A Safe that gives you time to respond.
Chain and wallet design
Keep everyday payments fluid. Give protected savings a deliberate withdrawal policy.
The Kova Safe is designed as a private balance with a chain enforced withdrawal delay. A separate recovery authority can cancel a pending withdrawal and return its value to the predetermined protected Safe.
Withdrawal and recovery are distinct capabilities. Cancellation and completion consume the same pending right, so only one outcome can succeed.
01
Request a withdrawal with a fixed destination.
02
Allow a response window measured in finalized mined history.
03
Complete after the delay, or cancel back to the protected Safe before unlock.
The delay begins from the request's first finalized mined context. Recovery requires the correct authority and action within the policy window. Aegis rounds do not advance this clock.
06Private applications
Cash with private conditions.
Application roadmap
Private smart contracts extend the payment model to escrow, confidential assets and programmable spending policies. Private inputs and committed state must remain connected to the transaction's ownership and value rules.
Applications share the ledger's consumption rules. Ordinary payments also need a defined resource budget, so expensive contract work cannot consume every available payment slot.
Accounting, independent reference implementations, bounded component proofs, and connected native signature and note ownership constraints.
Active implementationII
Private ledger and test network
A practical hiding payment proof, complete ledger rules, work and stake consensus, networking, recovery data and wallet integration.
Next integration stageIII
Protected and programmable cash
Private contracts, confidential staking, the wallet Safe, cryptographic migration and the later Aegis protocol.
Staged research
Note
Kova is in research and development. Component tests and native constraint checks establish their tested scope. A complete private payment network and full system post quantum security remain engineering and review goals.
Protocol mechanics
One witness. One valid state transition.
The architecture connects private ownership to publicly verifiable state. Membership, authorization, consumption and conservation must refer to the same hidden notes throughout the payment.
01 / Bind ownership
Authorize the same hidden note
The spending key and signature must authorize the exact transaction context. A private membership path binds that note to an eligible ledger root, without publishing its input commitment.
02 / Conserve and consume
Keep value private and prevent reuse
The proof constrains input value, output value and fees together. Stable nullifiers identify consumed rights without exposing their originating notes. The node rejects duplicates and previously spent identifiers.
03 / Deliver and apply
Recover notes, then advance state
Output commitments and encrypted payloads are bound to the authorized transition. The recipient recovers the note locally. Nodes apply spent state and new outputs atomically under the active rule version.
Proof verification, eligible roots, canonical encoding, resource limits, policy checks and global conflict handling are joint admission requirements.
What does private by default mean?+
Private payments are the intended normal payment path. Spending notes, input commitments, amounts, keys and authentication paths stay inside the proof witness. Recipient data is encrypted. Public verification still uses commitments, consumption identifiers and other protocol metadata.
Wallet queries, timing, network traffic, fees and application identifiers need separate leakage measurements. Users also need scoped viewing permissions and reliable recovery of encrypted data.
How can a payment be usable before a mined block?+
Aegis is designed around an ordered certified state. A completed stake consensus decision would make an eligible output available under that protocol version. Miners subsequently record the certified sequence in the work chain. A proposal, preliminary lock or first quorum is insufficient.
Availability depends on valid proofs, an eligible quorum, complete payload data and the protocol's safety and recovery rules. Aegis remains a later milestone. The initial onward spending rule is checkpoint finality.
How does security evolve with cryptography?+
Versioned commitments, proof profiles and authenticated activation rules provide boundaries for future changes. Private migration must prove valid ownership and conserve value across versions while protecting links between old and new notes.
Migration needs to be designed before the old protection fails. It cannot erase information already exposed or restore reliable ownership after an underlying authorization scheme is broken.
Primitive evaluation is informed by FIPS 204, FIPS 203 and FIPS 202. The complete protocol requires its own composition and quantum security analysis.
What makes the Safe enforceable?+
The intended policy is enforced by ledger transitions and private proofs. A withdrawal request binds its destination, value and delay. Its origin is the first finalized mined context, and only finalized mined height advances the unlock condition.
Before unlock, recovery can return the pending value to its fixed protected Safe. At or after unlock, authorized completion can release it. Both paths consume the same right. Monitoring, key loss, reorganizations and data availability remain explicit design and test requirements.
