Version 0.1 · 5 November 2026 · Design proposal
Modcoin is proposed as an independent Proof-of-Work Layer 1 with a maximum supply of 42,000,000 MOD, a shared UTXO ledger, two separately accounted 21,000,000 MOD issuance pools, and authenticated peer networking. The design goal is that compromise of either mining engine alone must not be sufficient to rewrite settled transaction history. This is a security objective requiring a formal consensus design and evidence; it is not established by using two source-code lineages or alternating block slots.
Modcoin does not inherit Bitcoin or DigiByte network hashpower, security, user balances, or transaction history. Copying code does not create those properties.
Proposed maximum supply: 42,000,000 MOD, divided into an issuance cap of 21,000,000 MOD for each engine. Every validating node must enforce both caps and their combined limit through consensus state, including subsidy and any future issuance mechanism. Unclaimed or rounded-away rewards should remain unissued rather than be reallocated without an explicit rule.
A candidate subsidy model is 2.5 MOD per engine block, halving every 4,200,000 blocks of that engine. The geometric series has a theoretical maximum of 21,000,000 MOD per engine before integer rounding. This is a candidate parameter, not an adopted rule. The design must define coin precision, rounding, genesis allocation, fees, subsidy validation, and behavior at zero subsidy.
The target average interval is 15 seconds. A proposed strict alternating schedule gives each engine a 30-second target and approximately 120 blocks per hour, for about 240 total blocks per hour. Those are statistical targets. Alternation risks chain-wide stoppage if either engine cannot produce its required block. A fallback rule cannot silently let one compromised engine control settlement; any liveness escape must state what security property is weakened and how users are protected.
| Engine | Issuance cap | Candidate work | Candidate difficulty lineage |
|---|---|---|---|
| Bitcoin-derived | 21,000,000 MOD | SHA-256d | Bitcoin-style retargeting |
| DigiByte-derived | 21,000,000 MOD | SHA-256d, Scrypt, Skein, Qubit, Odocrypt | MultiShield-derived; new-chain validation required |
DigiByte’s candidate algorithm list includes SHA-256d, creating overlap with the Bitcoin-derived engine. The protocol must define algorithm-domain separation, valid engine/algorithm schedules, work normalization, difficulty bounds, and how the same physical hashpower is treated. “Five algorithms” and an adjustment algorithm are separate concepts: MultiShield adjusts difficulty; it is not a mining algorithm.
A single scalar chainwork measure is insufficient unless it has a defined security interpretation across all eligible algorithms and enforces both engines' contribution. A viable specification must define:
The protocol must be modeled against adaptive hashpower, rented mining, algorithm overlap, network partitions, eclipse attacks, time manipulation, and one-engine compromise. “Both engines contribute” must be measured mathematically; counting blocks alone is not proof of security.
Both issuance engines would create native MOD outputs in one ledger. All full nodes must apply identical transaction, script, signature, subsidy, and supply validation rules, irrespective of which engine mined a block. Wallet balances are derived from unspent outputs, not an editable account balance. Native address encoding, script versions, signature algorithms, dust rules, fee policy, mempool behavior, and transaction malleability protections remain to be specified and tested.
PGP Proof of Possession can authenticate that a peer controls a signing key when it signs a fresh challenge. The signed challenge should include nonces from both peers, protocol version, both public-key fingerprints, a connection/session binding, and expiration. The authenticated exchange should run inside a reviewed encrypted transport. Key discovery, revocation, rotation, bootstrap peers, privacy, rate limiting, and anonymous-node policy need documented rules.
Peer authentication does not prove honesty, prevent Sybil identities, validate blocks, or protect a compromised endpoint. Consensus validation remains authoritative.
The proposed Decentralized Exchange Mechanism (DEM) is intended to facilitate non-custodial exchange among supported native assets. A signed order is only an expression of intent; it does not itself lock funds, guarantee atomic execution, validate another chain, or settle trades. DEM needs a fully specified matching/market protocol, escrow or atomic-swap construction, cancellation and timeout paths, fee model, failure recovery, market abuse controls, and independent audits before handling value.
BTC-on-Modcoin or DGB-on-Modcoin would be distinct Modcoin-native representations unless a secure verification and redemption mechanism is implemented. They are not native BTC or DGB merely because of their labels.
$MONEY is a proposed pair of AUD- and USD-denominated digital units intended for use within DEM. The concept contemplates acquiring AUD units with AUD fiat and USD units with USD fiat, trading between them, and using them for DEM markets. No issuer, reserve, fiat gateway, redemption promise, peg, or token contract is currently established by this proposal.
Before launch, the project would need to decide who issues and redeems each unit, the legal claims held by users, reserve custody and reconciliation, insolvency treatment, audit/attestation cadence, payment partners, consumer disclosures, access controls, AML/CTF responsibilities, and whether the instrument and service require authorisations in each market. A “decentralized” label does not settle those questions.
The project aims to make automated attacks more costly and easier to detect through conservative consensus validation, peer authentication, rate/resource controls, signed releases, reproducible builds, independent review, and monitored public infrastructure. AI can increase attack scale and speed, but it does not by itself break sound cryptographic primitives. Practical risks include compromised keys, exploitable implementation bugs, hashpower concentration, social engineering, software supply-chain compromise, denial of service, and unsafe upgrade coordination.
The design objective is: compromising one mining engine should not be sufficient to rewrite confirmed Modcoin transaction history. The phrase “confirmed” must be tied to a precisely specified settlement condition. No security claim should be published as achieved until adversarial analysis and independent audits support it.
Desktop, browser extension, Android, and iOS wallets are planned. Production wallet releases require finalized transaction/address formats, secure key generation and storage, encrypted backup and recovery, safe transaction review/signing, node connectivity, network identity verification, update signing, and incident response. UI mockups or shells are not wallets and must not display fictitious balances or accept real funds.
The initial supplied file was a static landing page. The subsequently supplied v0.2.0 archive contains a Go testnet node, persistent prototype UTXO chain, command-line wallet, local dashboard, and PGP-authenticated TLS peer prototype. It does not integrate Bitcoin Core or DigiByte Core; its DigiByte-derived engine is Scrypt-only, proof targets are fixed and trivial, and its local reorganization lock is not global finality. A v0.3.0 wallet-dashboard source draft adds local send/receive and transaction-history screens but has not been compiled. No mainnet, production wallet, public chain data, DEM settlement, or real-funds use is claimed.