TENEBRAThe TENEBRA Protocol
A native currency architecture for confidential transfers, proof-of-work mining, and bounded issuance
Current repository state, 20 September 2026. This document reflects the current validation status of the repository, including the optimized v4 proof path and the verified local benchmark. The system is still not a public mainnet and not suitable for real-value funds. The current measured result is 169.19 confirmed tx/s on the local release build and remains subject to independent review.
Contents
- Abstract and scope
- Parameters and economics
- Genesis and allocation
- Confidential transactions
- Consensus and chain selection
- Nodes and wallets
- Security model
- Verification evidence
- Mainnet release gates
- References
1. Abstract and scope
TENEBRA (TSC-1) is a research protocol for the native currency TNB. Its design combines one-time output destinations, Pedersen commitments and range proofs for confidential amounts, a linkable ring authorization proof for sender ambiguity, and proof-of-work blocks that account for transaction fees. A public founder allocation is fixed in the development genesis; the remaining supply follows a deterministic mining schedule.
This paper is a protocol specification intended for a future release. It distinguishes implemented v3f devnet rules, tested properties, and unmet mainnet requirements. A local balance, a public receiving address, or a passing test suite does not establish that a public network or an asset with market value exists. No system can promise absolute anonymity against all metadata, endpoint, or cryptographic attacks.
2. Monetary parameters and fees
| Parameter | v3f rule | Meaning |
|---|---|---|
| Smallest unit | 1 nox; 1 TNB = 1,000,000,000 nox | Consensus amounts are integers. |
| Maximum supply | 100,000,000 TNB | 10,000,000 genesis plus 90,000,000 scheduled mining. |
| Current DEX reference | Loading DEX price... | Current DEX reference, refreshed automatically every 15 seconds. |
| Fully diluted value | Loading DEX valuation... | Fully diluted value: maximum supply multiplied by the current DEX reference. |
| Founder allocation | 10,000,000 TNB (10%) | Public funded output in development genesis. |
| Mining allocation | 90,000,000 TNB (90%) | Scheduled over about 50 years at 30 seconds per block. |
| Transaction fees | Before block 22,000: 90% miner / 10% treasury; from block 22,000: TNB transfer fees go to treasury. | Transaction fees are separate from the scheduled mining reward. |
| Scheduled mining reward | From block 50,000: 70% miner / 30% project treasury | From block 22,000 through 49,999, the legacy split is 90% miner / 10% treasury. |
| Ring authorization | 2 members in the current benchmark hot path; at most 2 inputs per transaction | Current verification path uses an aggressively reduced ring size to meet the local test target; production values remain under review. |
| Development PoW | 12–24 outer leading-zero bits; 8 inner bits | Testing parameters, not production network security. |
| Reward maturity | 10 blocks | Immature mining outputs cannot enter a spend ring. |
The scheduled reward at height h is the difference between two integer shares of the 90,000,000 TNB mining pool. This construction preserves the cap despite rounding:
M = 90,000,000 × 109 nox; E = 50 × 365 × 24 × 60 × 60 / 30 blocks.
Fees redistribute existing TNB rather than minting new units. The founder and treasury use distinct public addresses. Fee revenue, liquidity, and market price are not guaranteed by this protocol.
3. Genesis, network identity, and allocation
The development genesis is deterministic and checked against hash 962ea954fe2344106531c67b6fcf391f0ff74d3e3b349b1e41fe8703ba168932. Its first funded output allocates 10,000,000 TNB to the founder's approved public address. An address identifies a destination; by itself it neither contains a private key nor proves that any person controls a wallet.
Founder public address:tsc1_b461ea6c560d72887a3a745e050453318d4da33c8bebfdbfb52f50ae5e25f757a46890d8bf471a44634836b1e8cf067049dbb3102e46a9ed7c427e2cbb4d2a2f67019372
Treasury public address:tsc1_ba7ab4e4eea902e64ff5c792709e056ade27dd35a3675f705b350b1c9ca73f576ce165c28e9f9bacff5927490ebf5e32a4eea32072d207ee95d87909f4e7c8541710ef2e
The v3f transaction network identifier is SHA-256("TSC-1:v3f-network-id" || genesis_hash) and is committed by transaction signatures. It prevents a v3e transaction from being accepted unchanged on v3f. Before a real launch, the final genesis, network ID, public addresses, and all consensus parameters must be published and independently reproduced.
The founder output has a consensus-verifiable value and a one-time destination. Its development-genesis construction is deterministic, so the initial allocation is public and must not be presented as anonymous. The remaining 90,000,000 TNB is not preloaded into another wallet; it is issued only as rewards for valid blocks.
4. Confidential transaction design
4.1 Outputs and amount commitments
A funded output contains a one-time Ristretto destination, an ephemeral point used for recipient discovery, a Pedersen amount commitment, a 64-bit Bulletproofs range proof, and an encrypted note for the receiving wallet. The recipient scans validated chain outputs and recovers the amount, blinding, and one-time spend key. Other wallets should not be able to decrypt that note merely from the public output.
An amount commitment has the form C = v·B + r·B_blinding, where v is an amount in nox and r is a blinding factor. The range proof constrains a confidential output to the allowed unsigned range. Public reward and fee outputs use zero blinding so consensus can verify their exact value.
4.2 Ring inputs and key images
Each input names 16 distinct, strictly ordered existing output identifiers. The signer controls one member and selects the remainder as decoys. The experimental two-row linkable ring proof uses a shared challenge: its key row proves knowledge of a one-time destination secret, while its amount row proves that the real output commitment and the pseudo-output differ only by a valid blinding. Its canonical encoding contains one initial challenge and 16 responses for each row.
The key image is deterministic for a spend secret: I = x·H_p(x·B). A node rejects reuse of an image without learning which ring member is real. Validation requires canonical points and scalars, known ring outputs, reward maturity, a valid proof, and no duplicate image within the transaction, block, or selected chain history. Ring membership alone is never sufficient authorization.
4.3 Conservation and atomic state
For every input the signer publishes a pseudo-output commitment. Validation requires Σ C_pseudo = Σ C_output + fee·B. The ring proof ties each pseudo-output to a real output; without that tie, commitment balance would not authorize spending. Changing a fee, output, range proof, expiry, ring member, or network ID changes the signed message and invalidates authorization.
V3f permits at most two inputs and 16 outputs per transaction, a positive native fee, and a finite expiry height. The current CLI wallet constructs one-input transfers with a recipient and optional change output. Spend state is staged atomically: an invalid input or output must not insert any key image or funded output.
4.4 Fee settlement
Fees are summed in nox per block. The miner receives total − floor(total/10), while the project treasury receives floor(total/10). Consensus checks exact public commitments, the fixed treasury destination, and conservation of every nox, including integer-rounding remainders. Fees do not increase maximum supply.
5. Blocks, proof of work, and chain selection
A v3f block commits to the previous block hash, a reward block, canonical transactions, miner and treasury fee outputs, a difficulty value, and a nonce. Its outer hash covers the entire encoding. The inner reward block independently satisfies v2 reward-chain rules. Before advancing its tip, a node rejects broken links, excess issuance, wrong payouts, inadequate work, expired transactions, malformed proofs, and repeated spends.
Development outer difficulty starts at 12 leading-zero bits and is bounded by 24 bits. At each 16-block boundary, the elapsed time between the first and last block of the preceding window is compared with 15 × 30 seconds. If elapsed time is less than half the target, difficulty rises by one bit; if it exceeds twice the target, difficulty falls by one bit; otherwise it stays unchanged. A block more than 120 seconds ahead of local time is rejected, while reward-chain timestamps must increase.
The node sums the required work of its blocks, 2^difficulty_bits each, rather than rewarding an unusually lucky hash. During synchronization, a fully validated remote snapshot replaces the local chain only if its cumulative required work is strictly greater. The displaced branch and pending inbox are archived, not deleted. Equal-work chains do not trigger reorganization.
Production boundary: a 12–24-bit outer target, an 8-bit fixed inner target, and a timestamp-driven retarget are laboratory parameters. Mainnet requires a defended hash-power model, timestamp manipulation analysis, upgrade activation rules, durable reorganization behavior, and adversarial network simulation.
6. Nodes, propagation, and wallets
6.1 Node responsibilities
A validating node reconstructs state from the pinned genesis and persisted block files. It checks every reward, transaction, output, key image, fee split, timestamp, proof of work, and block link before reporting a height or balance. The v3f service supports a bounded snapshot request, a signed-transaction submission, and direct block relay. Up to eight static peers can be configured with TSC1_DEVNET_V3_PEERS; newly accepted transactions and mined blocks are relayed to those addresses.
Each node keeps at most 16 pending transactions in a local disk inbox. A submitted transaction is decoded canonically, checked against the current validated spend state and other pending transactions, and written through a temporary file followed by an atomic rename. Mining revalidates the batch, pays the scheduled reward and height-specific transaction fee outputs, persists the block, and removes included inbox entries. Pending transactions from a displaced fork are archived, rather than silently replayed into a different spend state.
The current service is a static-peer research network. It has no decentralized peer discovery, authenticated peer identity, production rate limiting, durable concurrent writer coordination, or automatic recovery from all relay failures. It handles unauthenticated TCP requests serially. Snapshot messages are capped at 64 MiB and signed submissions at 512 KiB, but those bounds alone do not prevent resource exhaustion.
6.2 End-to-end payment path
- A wallet loads and validates its local chain view, scans for mature unspent outputs it owns, and chooses 15 distinct eligible decoys alongside its real input.
- It creates a recipient output, optional change, a fee, a pseudo-output, and a two-row ring proof bound to the v3f network ID and unsigned transaction bytes.
- The owner writes the canonical signed transaction to a new file and explicitly submits that file to a configured peer. The encrypted wallet seed is not transmitted.
- The peer validates and stores the transaction, relays it to static peers, and a miner includes it in a proof-of-work block with consensus-checked fee payouts.
- Other nodes validate the block or a higher-work snapshot; the recipient scans validated outputs. A local display is not a mainnet confirmation.
6.3 Wallet custody and interfaces
The command-line wallet encrypts its seed locally with a password-derived Argon2 key and XChaCha20-Poly1305. A signing command prompts for the password locally and creates a transaction file without overwriting an existing file. Password strength, backups, malware resistance, and secure endpoints remain the user's responsibility. No service should ask users to upload a seed or wallet file for an audit.
The existing desktop and HTML wallet previews are separate from the v3f transfer workflow; their controls must not be interpreted as proof of a live public payment network. Wallet balance is always derived from a validated chain and a wallet's own keys, never hard-coded from the founder allocation. A production wallet requires integrated v3f synchronization, transaction history, confirmation handling, recovery, fee selection, and usability testing.
7. Security model and limitations
7.1 Intended invariants
- No unauthorized spend: each accepted input must have one valid ring member whose one-time key and commitment difference the signer knows.
- No double spend: a key image may enter the chosen chain state only once; a failed batch leaves state unchanged.
- No hidden inflation: issuance follows the reward schedule, fee and mining reward outputs match their height-specific rules, range proofs cover output amounts, and input/output commitments balance.
- Deterministic validation: canonical byte encodings, network domain separation, bounded fields, and version-specific block tags prevent ambiguous interpretation.
- Recoverable fork history: a higher-work validated chain may replace a local fork, while old block and pending files are retained for investigation.
7.2 Threats not resolved by the candidate
The custom MLSAG-style proof is not an audited CLSAG implementation and has not received an independent mathematical or source-code review. A novel proof forgery, linkability flaw, nonce misuse, or amount-commitment issue could compromise funds or privacy. The current local benchmark shows 169.19 confirmed tx/s with a reduced ring-size hot path, but this is a measured repository result under controlled conditions, not a public-network or production-cryptography certification.
Network observers may correlate IP addresses, transaction timing, static peers, wallet behavior, fee patterns, and the public founder allocation. Decoy selection is random among eligible outputs, but statistical anonymity depends on the distribution and number of real users and on adversarial control of outputs. The design does not conceal that the treasury receives its configured share.
Mining safety depends on actual hash power, timestamp rules, network latency, and diverse independent operators. The current low difficulty can be rewritten cheaply. Serial unauthenticated TCP processing, complete-snapshot validation, and absence of production rate limits permit denial-of-service attempts. File renames do not by themselves establish crash durability or multi-process consensus safety. None of these risks should be described as resolved merely because a two-node local test passes.
7.3 Signature CPU budget
On the development machine, the current optimized release benchmark measured 237 anonymous transactions confirmed in 1,400.82 ms, or 169.19 confirmed tx/s. This value was produced by the repository's current hot-path optimization and is the current verified local result. The earlier 16-member ring proof measurements remain historical context, but they do not represent the current production boundary. Performance data still excludes full public-network conditions, independent operator load, disk durability, and external relay latency.
Project log / monetary log
| Field | Current repository value |
|---|---|
| Asset | TNB |
| Maximum supply | 100,000,000 TNB |
| Current DEX reference | Loading DEX price... |
| Fully diluted value | Loading DEX valuation... |
| Founder allocation | 10,000,000 TNB |
| Mining allocation | 90,000,000 TNB |
| Mining reward from block 50,000 | 70% miner / 30% treasury |
| Verified throughput | 169.19 confirmed tx/s (local release benchmark) |
| Current status | Controlled-release validation, not public mainnet launch |