INTcoin Technical Whitepaper
Version 1.0 — April 2026
Authors: INTcoin Core Developers
Contact: team@international-coin.org
Abstract
INTcoin is a full-node cryptocurrency implementing NIST-standardised
post-quantum cryptography for transaction signing (ML-DSA-87),
peer-to-peer key exchange (ML-KEM-1024), and address derivation
(SHA3-256). The system uses RandomX ASIC-resistant proof-of-work
for consensus, supports a built-in Lightning Network for layer-2
payments, and provides Tor/I2P anonymous networking.
The architectural foundations — the UTXO transaction model,
proof-of-work consensus, and chain of digital signatures — were
first described by Nakamoto [1] in 2008. INTcoin preserves these
proven designs while replacing the cryptographic primitives with
lattice-based post-quantum alternatives, ensuring long-term
security as quantum computing matures.
This document describes the cryptographic foundations, consensus
mechanism, network protocol, transaction format, wallet
architecture, and institutional custody features.
Table of Contents
Cryptographic PrimitivesTransaction ModelConsensus MechanismNetwork ProtocolWallet ArchitectureLightning NetworkScript SystemStorage LayerPrivacy NetworksInstitutional FeaturesSecurity AnalysisEconomic Parameters
1. Cryptographic Primitives
1.1 Digital Signatures: ML-DSA-87 (Dilithium5)
INTcoin uses ML-DSA-87 (formerly known as CRYSTALS-Dilithium
Level 5) as specified in FIPS 204 for all transaction signatures.
| Parameter | Value |
|---|
| Security level | NIST Level 5 (≥256-bit classical, ≥128-bit quantum) |
| Public key size | 2,592 bytes |
| Secret key size | 4,896 bytes |
| Signature size | 4,627 bytes |
| Underlying problem | Module Learning With Errors (M-LWE) |
| Polynomial ring | R_q = Z_q[X]/(X^256 + 1), q = 8380417 |
| Module rank | k = 8, l = 7 |
Key generation: Deterministic from a 32-byte seed via SHAKE-256.
Unlike ECDSA, the public key cannot be derived from the secret key
alone — both must be stored together in
CKey.
Signature verification: Constant-time. The verifier reconstructs
the commitment from the signature and checks that the challenge hash
matches. No modular inversion or point multiplication is required.
Implementation: Wraps the liboqs 0.15.0 OQS_SIG_ml_dsa_87
implementation (reference C with optional AVX2 acceleration).
1.2 Key Encapsulation: ML-KEM-1024 (Kyber1024)
All peer-to-peer connections use ML-KEM-1024 (formerly
CRYSTALS-Kyber Level 5) as specified in FIPS 203 for key exchange.
| Parameter | Value |
|---|
| Security level | NIST Level 5 |
| Public key size | 1,568 bytes |
| Secret key size | 3,168 bytes |
| Ciphertext size | 1,568 bytes |
| Shared secret size | 32 bytes |
| Underlying problem | Module Learning With Errors (M-LWE) |
The shared secret is used to derive symmetric keys for
FSChaCha20Poly1305 authenticated encryption with forward secrecy
(ephemeral keys per connection).
1.3 Hash Functions
| Use | Algorithm | Output |
|---|
| Block hashing | SHA3-256 | 32 bytes |
| Merkle tree | SHA3-256 | 32 bytes |
| Address derivation | SHA3-256 + RIPEMD-160 → Bech32 | variable |
| HD key derivation | SHAKE-256 | 64 bytes |
| Transaction ID | SHA3-256 of serialised tx | 32 bytes |
| Audit chain | SHA3-256 chaining | 32 bytes |
1.4 Symmetric Encryption
| Use | Algorithm |
|---|
| P2P transport | ChaCha20-Poly1305 (RFC 8439) |
| Wallet encryption | AES-256-CBC + HMAC-SHA256 |
| HSM signer files | AES/ChaCha20-Poly1305 with HKDF-SHA3-256 derived key |
2. Transaction Model
INTcoin uses a UTXO (Unspent Transaction Output) model similar to
the established cryptocurrency design pattern.
2.1 Transaction Structure
CTransaction {
int32_t nVersion; // Currently 1
uint32_t nLockTime; // Block height or Unix timestamp
vector<CTxIn> vin; // Inputs (references to previous outputs)
vector<CTxOut> vout; // Outputs (amounts + locking scripts)
}
2.2 Input Structure
CTxIn {
COutPoint prevout; // hash + index of spent output
CScript scriptSig; // Unlocking script (signature + pubkey)
uint32_t nSequence; // Sequence number (RBF signalling)
}
2.3 Output Structure
CTxOut {
CAmount nValue; // Amount in base units (1 INT = 10,000)
CScript scriptPubKey; // Locking script
}
2.4 Transaction Size
Due to ML-DSA-87's larger signatures (4,627 bytes vs ~72 bytes for
ECDSA), INTcoin transactions are substantially larger:
| Component | ECDSA (typical) | INTcoin (ML-DSA-87) |
|---|
| Public key | 33 bytes | 2,592 bytes |
| Signature | ~72 bytes | 4,627 bytes |
| 1-in-1-out tx | ~226 bytes | ~7,300 bytes |
| Typical tx | ~250 bytes | ~7,500 bytes |
This is a fundamental trade-off: post-quantum security requires
larger key material. The block weight limit (4,000,000 weight units)
and fee market accommodate this difference.
2.5 Signature Hash
Transaction signing uses SignatureHash() which computes:
sighash = SHA3-256(
nVersion || hashPrevouts || hashSequence ||
outpoint || scriptCode || amount ||
nSequence || hashOutputs || nLockTime || nHashType
)
Supported hash types: SIGHASH_ALL, SIGHASH_NONE,
SIGHASH_SINGLE, SIGHASH_ANYONECANPAY.
3. Consensus Mechanism
3.1 Proof of Work: RandomX v2.0
INTcoin uses RandomX as its proof-of-work function. RandomX is
designed to be:
CPU-optimised — uses random program execution, floating-point operations, and branch prediction in ways that GPUs and ASICs
cannot efficiently replicate
ASIC-resistant — the algorithm changes with each block's key block (every 2048 blocks), requiring general-purpose hardware
Memory-hard — requires a 2 GB dataset (or 256 MB in light mode) that must be randomly accessed during hashing
Block validation: The header hash is computed using RandomX with
the key derived from the block at height (currentHeight / 2048) * 2048.
The result must be below the target derived from nBits.
3.2 Difficulty Adjustment: Digishield v3
Difficulty adjusts every block using a modified Digishield algorithm:
Averaging window: 17 blocksTarget spacing: 120 seconds (2 minutes)Max adjustment down: 32% per blockMax adjustment up: 16% per blockThis provides rapid response to hashrate changes while preventing
oscillation attacks.
3.3 Block Structure
CBlockHeader {
int32_t nVersion; // Block version (BIP9 signalling)
uint256 hashPrevBlock; // SHA3-256 of previous block header
uint256 hashMerkleRoot; // SHA3-256 Merkle root of transactions
uint32_t nTime; // Unix timestamp
uint32_t nBits; // Compact target representation
uint32_t nNonce; // Proof-of-work nonce
}
Block hash: SHA3-256(serialised_header) — single hash.
3.4 Consensus Rules
Maximum block weight: 4,000,000 weight unitsCoinbase maturity: 100 blocksMaximum reorg depth: 100 blocks (fork protection)Minimum relay fee: 1 base unit per virtual byteDust limit: 5,000 base units (0.5 INT) for standard scripts; 10,000 base units for large scripts (>100 bytes)
3.5 Monetary Policy
| Parameter | Value |
|---|
| Initial block reward | 105,113,636 INT (1,051,136,360,000 base units) |
| Halving interval | 1,051,200 blocks (~4 years at 2-min blocks) |
| Maximum supply | 221 trillion INT (2.21 × 10^18 base units) |
| Base unit | 1/10,000 of 1 INT |
| Subsidy formula | reward = initialReward >> (height / halvingInterval) |
The maximum supply fits within a signed 64-bit integer
(2.21 × 10^18 < 9.22 × 10^18 = INT64_MAX).
4. Network Protocol
4.1 Transport: V2 Post-Quantum Encrypted
All peer-to-peer connections use the V2 encrypted transport:
Handshake: Initiator generates ephemeral ML-KEM-1024 keypair, sends public key (1,568 bytes). Responder encapsulates a shared
secret and returns the ciphertext (1,568 bytes).
Key derivation: HKDF-SHA3-256 derives session keys from the shared secret for bidirectional ChaCha20-Poly1305.
Message encryption: Every protocol message is AEAD-encrypted with a per-message nonce. Replay protection via sequence counters.
V1 (unencrypted) transport is not supported. All connections are
post-quantum encrypted.
4.2 Protocol Messages
Standard messages follow the established P2P cryptocurrency protocol
pattern: version, verack, addr (ADDRv2/BIP155), inv,
getdata, block, tx, headers, getheaders, ping, pong,
sendheaders, feefilter.
Magic bytes: 0x49 0x4e 0x54 0x01 (mainnet), 0x02 (testnet),
0x03 (signet), 0x04 (regtest).
4.3 Address Types (BIP155 ADDRv2)
| Network | ID | Address length |
|---|
| IPv4 | 1 | 4 bytes |
| IPv6 | 2 | 16 bytes |
| Tor v3 | 4 | 32 bytes |
| I2P | 5 | 32 bytes |
| CJDNS | 6 | 16 bytes |
4.4 Transaction Relay: Erlay (BIP330)
When compiled with Minisketch support, INTcoin uses set
reconciliation for efficient transaction relay. This reduces
bandwidth by ~84% compared to flooding-based relay.
4.5 Compact Blocks
Block relay uses a compact block protocol (BIP152-style) where the
sender transmits short transaction IDs and the receiver reconstructs
from its mempool, requesting only missing transactions.
5. Wallet Architecture
5.1 HD Derivation
INTcoin uses SHA3-256-based hierarchical deterministic key derivation
following the BIP44 path structure:
m / 44' / 2210' / account' / change / index
BIP44 coin type: 2210
Key derivation function:
child_key = SHAKE-256(parent_key || child_index || domain_separator)
Unlike BIP32/secp256k1, child public keys cannot be derived from
parent public keys alone (Dilithium limitation). Both secret and
public keys must be derived together from the parent secret key.
5.2 Extended Keys
Extended keys use ixpub / ixprv encoding (Bech32 with SHA3-256
checksums):
ixpub: ~3,600 characters (contains 2,592-byte public key + chain code + metadata)
ixprv: ~10,300 characters (contains 4,896-byte secret key + 2,592-byte public key + chain code + metadata)
5.3 Address Format
Addresses use Bech32 encoding with network-specific human-readable
parts:
| Network | P2PKH prefix | P2SH prefix | HRP |
|---|
| Mainnet | int1q | int1s | int |
| Testnet | tint1q | tint1s | tint |
| Signet | sint1q | sint1s | sint |
| Regtest | rint1q | rint1s | rint |
5.4 Coin Selection
The wallet implements four coin selection algorithms:
Branch and Bound — exact match with waste minimisationSingle Random Draw — random UTXO selection for privacyCoinGrinder — weight-optimised for fee minimisationKnapsack — heuristic fallback for large UTXO sets5.5 Fee Estimation
Multi-horizon fee estimation tracks confirmation times across
multiple fee rate buckets and provides estimates for target
confirmation windows of 1, 3, 6, 12, and 24 blocks.
6. Lightning Network
INTcoin includes a built-in Lightning Network implementation for
layer-2 instant payments.
6.1 Channel Construction
Commitment transactions use Dilithium5 2-of-2 multisigHTLC (Hash Time-Locked Contract) scripts use OP_CHECKSIG_DILITHIUM with hash preimage reveals
Revocation uses per-commitment keys derived via SHA3-2566.2 Payment Protocol
BOLT-11 invoices with int / tint prefixesBOLT-12 offers for reusable payment codesOnion routing with post-quantum encrypted packet layersKeysend for spontaneous payments without invoices6.3 Channel Monitoring
The chain monitor tracks deadlines for:
HTLC timeout claimsHTLC success claimsCommitment broadcast windowsPenalty (breach) transactionsAnchor spend deadlinesAutomatic sweep broadcasting with fee bumping (CPFP) ensures
time-sensitive outputs are claimed before expiry.
7. Script System
7.1 Opcodes
INTcoin's script system is based on the established stack-based
scripting model with the following post-quantum addition:
OP_CHECKSIG_DILITHIUM — verifies an ML-DSA-87 signature against the top two stack items (signature, public key)
Standard scripts:
# P2PKH (Pay to Public Key Hash)
OP_DUP OP_HASH160 <pubkey_hash> OP_EQUALVERIFY OP_CHECKSIG_DILITHIUMP2SH (Pay to Script Hash)
OP_HASH160 <script_hash> OP_EQUAL
7.2 Signature Verification
The OP_CHECKSIG_DILITHIUM opcode:
Pops the public key (2,592 bytes) and signature (4,627 bytes)Computes the signature hash using SignatureHash()Calls OQS_SIG_ml_dsa_87_verify() with the hash as the messagePushes TRUE or FALSE onto the stackVerification is constant-time and takes ~0.3ms on modern hardware.
8. Storage Layer
8.1 Block Storage
Blocks are stored in flat files (blk00000.dat, blk00001.dat, ...)
with an LevelDB index mapping block hashes to file offsets. Undo data
(rev00000.dat) stores the spent outputs for each block to enable
chain reorganisation.
8.2 UTXO Set
The UTXO set is stored in LevelDB with XOR obfuscation (random key
generated on first run). Each entry maps (txid, output_index) to
(value, script, height, coinbase_flag).
Dirty entry tracking enables efficient cache flushes — only modified
entries are written to disk.
8.3 Block Pruning
Configurable pruning limits disk usage by deleting old block data
files while retaining the UTXO set and block index. The minimum
retention is 288 blocks (~9.6 hours) for reorg safety. Default
prune target in standalone wallet mode: 550 MB.
8.4 Block Filter Index (BIP 157/158)
Compact block filters enable light clients to efficiently determine
if a block contains relevant transactions. The filter index stores
Golomb-coded set (GCS) filters for each block, allowing clients to
download only the blocks that match their wallet scripts.
9. Privacy Networks
9.1 Tor Integration
The node connects to a local Tor daemon via the control port
(default 9051) and can:
Create ephemeral v3 onion services (listenonion=1)Accept inbound connections via persistent onion addresses (
externalip=.onion)
Route outbound connections through a SOCKS5 proxy9.2 I2P Integration
The node opens a SAM 3.1 session to a local I2P router (e.g. i2pd)
and creates a persistent destination for inbound and outbound P2P
connections. The private key is saved to /i2p_private_key
for a stable .b32.i2p address across restarts.
9.3 Network Isolation
-onlynet=onion or -onlynet=i2p restricts all P2P connections
to the specified privacy network, preventing clearnet IP leakage.
10. Institutional Features
When compiled with -DBUILD_INSTITUTIONAL=ON, INTcoin includes an
enterprise custody module:
Tamper-evident audit log — SHA3-256 chained events with persistent chain tip, verifiable via
verifyauditlog RPC
RBAC — role-based access control with persistent users, roles, sessions, and RFC 6238 TOTP MFA
Spending policies — configurable limits with multi-party approval workflow
Address whitelist — pre-approved destinations with cooldown, per-address caps, and AML screening hook
Software-backed external signer — AES/ChaCha20-Poly1305 encrypted Dilithium5 keypair store outside the wallet
See INSTITUTIONAL.md for the full
specification and INSTITUTIONAL_DR.md
for backup and disaster recovery procedures.
11. Security Analysis
11.1 Quantum Resistance
INTcoin's post-quantum security rests on the hardness of the
Module Learning With Errors (M-LWE) problem:
ML-DSA-87: signature unforgeability under chosen-message attack (EU-CMA) in the quantum random oracle model (QROM)
ML-KEM-1024: IND-CCA2 security under adaptive chosen ciphertext attack in the QROM
SHA3-256: collision resistance (128-bit quantum via Grover's algorithm with the birthday bound)
11.2 Classical Security
256-bit classical security for signaturesAES-256 equivalent key strength for symmetric encryptionRandomX provides ~2^32 work per hash evaluation (no shortcuts below brute-force search)
11.3 Fork Protection
Checkpoint validation at hardcoded heightsMaximum reorg depth: 100 blocksEclipse attack resistance via ASMAP-aware peer selection and network diversity requirements
Stale tip detection with automatic peer rotation11.4 Transport Security
All P2P messages are authenticated and encrypted (ChaCha20-Poly1305)Forward secrecy via ephemeral ML-KEM-1024 key exchangeSelf-connection detection (loopback, external IP, nonce matching)Rate limiting and ban scoring for misbehaving peers
12. Economic Parameters
12.1 Supply Schedule
Block reward at height h:
reward(h) = 105,113,636 × 10^4 >> (h / 1,051,200)Total supply:
S = Σ_{k=0}^{∞} reward_k × min(1,051,200, remaining_blocks_in_era_k)
S ≈ 221 × 10^12 INT = 2.21 × 10^18 base units
12.2 Halving Schedule
| Era | Block range | Reward per block | Era supply |
|---|
| 0 | 0 – 1,051,199 | 105,113,636 INT | ~110.5T INT |
| 1 | 1,051,200 – 2,102,399 | 52,556,818 INT | ~55.3T INT |
| 2 | 2,102,400 – 3,153,599 | 26,278,409 INT | ~27.6T INT |
| 3 | 3,153,600 – 4,204,799 | 13,139,204 INT | ~13.8T INT |
| ... | ... | ... | ... |
12.3 Fee Market
Minimum relay fee: 1 base unit per virtual byte (0.0001 INT/vB)Block weight limit: 4,000,000 weight unitsFee estimation: multi-horizon with exponential decayReplace-By-Fee (RBF): opt-in via nSequence < 0xfffffffe
Disclaimer
Cryptocurrency is unregulated and inherently risky. INTcoin is
experimental open-source software provided "as is" without warranty
of any kind. The INTcoin Core Developers accept no liability for
loss of funds, whether through software bugs, user error, market
volatility, regulatory action, cryptographic vulnerability, or
any other cause. This document is a technical specification, not
financial advice, and should not be treated as a solicitation to
purchase or invest in INTcoin.
References
Foundational
Nakamoto, S. (2008). *"Bitcoin: A Peer-to-Peer Electronic Cash System."* — Foundational architecture: UTXO model, proof-of-work consensus, chain of digital signaturesPost-Quantum Cryptography
Ducas, L., Kiltz, E., Lepoint, T., Lyubashevsky, V., Schwabe, P., Seiler, G., Stehlé, D. (2018). *"CRYSTALS-Dilithium: A Lattice-Based Digital Signature Scheme."* IACR Trans. CHES 2018. — Basis for ML-DSA-87 (FIPS 204)Avanzi, R., Bos, J., Ducas, L., Kiltz, E., Lepoint, T., Lyubashevsky, V., Schanck, J.M., Schwabe, P., Seiler, G., Stehlé, D. (2018). *"CRYSTALS-Kyber: A CCA-Secure Module-Lattice-Based KEM."* IACR ePrint 2017/634. — Basis for ML-KEM-1024 (FIPS 203)NIST FIPS 204 (2024). *Module-Lattice-Based Digital Signature Standard (ML-DSA)*NIST FIPS 203 (2024). *Module-Lattice-Based Key-Encapsulation Mechanism Standard (ML-KEM)*NIST FIPS 202 (2015). *SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions*Proof of Work
tevador (2019). *"RandomX: ASIC-resistant proof-of-work algorithm."* — CPU-optimised PoW using random program execution and memory-hard access patternsdeswa (2014). *"Digishield v3."* — Per-block difficulty retargeting with bounded adjustment to prevent oscillation attacksLayer 2
Poon, J., Dryja, T. (2016). *"The Lightning Network: Scalable Off-Chain Instant Payments."* — Payment channel architecture for instant, low-fee transactionsWallet Standards
Palatinus, M., Rusnak, P. (2013). *"BIP 39: Mnemonic code for generating deterministic keys."* — Seed phrase standard for wallet backupBIP 44: Marek Palatinus, Pavol Rusnak. *Multi-Account Hierarchy for Deterministic Wallets*Network Protocols
BIP 141: *Segregated Witness (Consensus layer)*BIP 155: *addrv2 message for network address relay*BIP 157/158: *Client Side Block Filtering*BIP 325: Kalle Alm. *Signet*BIP 330: Gleb Naumenko, Pieter Wuille. *Transaction Announcement Reconciliation (Erlay)*Symmetric Cryptography
RFC 8439: Nir, Y., Langley, A. *ChaCha20 and Poly1305 for IETF Protocols*RFC 6238: M'Raihi, D., Machani, S., Pei, M., Rydell, J. *TOTP: Time-Based One-Time Password Algorithm*
Source code: github.com/INT-devs/intcoin
License: MIT