42,000,000 MOD cap
Proposed maximum issuance, divided into a 21,000,000 MOD Bitcoin-derived pool and a 21,000,000 MOD DigiByte-derived pool.
Proposed monetary ruleA proposed independent Proof-of-Work network with a 42 million MOD maximum supply, split into two independently accounted issuance pools. Consensus, finality, and production software remain under development.
This portal separates proposed protocol parameters from implemented network facts. No live chain values are fabricated.
Proposed maximum issuance, divided into a 21,000,000 MOD Bitcoin-derived pool and a 21,000,000 MOD DigiByte-derived pool.
Proposed monetary ruleProposed shared chain with independently accounted mining engines. The precise block-selection, chainwork, and settlement rules are not finalized.
Consensus not production-readyPGP proof-of-possession is the design goal for peer identity. Authentication does not prove that a peer is honest or secure the chain by itself.
Protocol specification requiredThe executable is the supplied v0.2.0 experimental testnet. The v0.3.0 GUI update is uncompiled source. All downloads exclude existing wallet and node identity data.
v0.2.0 executable and launcher package. Requires Gpg4win. Uses an unencrypted test wallet and experimental consensus.
Baseline v0.2.0 source and the v0.3.0 wallet GUI source draft. A matching v0.3.0 binary has not been built.
Website, whitepaper, core source draft, extension UI scaffold, and mobile readiness notes. APK and iOS binaries are unavailable.
The design paper states what is intended, what remains undecided, and what must be demonstrated before mainnet.
Dual PoW issuance, shared UTXO ledger, peer authentication, DEM, proposed $MONEY model, threat model, and launch gates.
Design paper · draftAlgorithm set, schedule assumptions, difficulty requirements, and the unresolved fork-choice/finality model.
Protocol notesNon-custodial exchange goals and a proposed AUD/USD-denominated asset. Neither trading nor fiat conversion is live.
Product specificationSearch by block height, transaction ID, or MOD address once a public explorer backend is available.
Unavailable: no public mainnet endpoint.
Unavailable: no public mainnet endpoint.
Unavailable: no consensus-verified supply index.
Planned chain-tip view showing the active tip, cumulative validated work, competing branches, and settlement status.
| Branch | Height | Work status | Source |
|---|---|---|---|
| Modcoin mainnet | Not launched | Not available | No verified feed |
| Modcoin testnet | Not connected | Not available | Local development only |
A public node directory requires authenticated node announcements, freshness checks, and a privacy-aware API.
No Modcoin nodes are listed because no public network directory has been provisioned.
Planned: each node presents a unique key and proves possession through a fresh challenge bound to an encrypted session. Key rotation and revocation rules remain to be specified.
A candidate design uses alternating engine slots with an overall target interval of 15 seconds. These are design targets, not observed performance.
| Engine | Pool cap | Candidate PoW | Schedule assumption | Status |
|---|---|---|---|---|
| Bitcoin-derived | 21,000,000 MOD | SHA-256d | One slot every 30 seconds (~120/hour) | Not integrated |
| DigiByte-derived | 21,000,000 MOD | SHA-256d, Scrypt, Skein, Qubit, Odocrypt (proposed set) | One slot every 30 seconds (~120/hour) | Not integrated |
Bitcoin-style retargeting and DigiByte MultiShield-derived logic are candidate inputs only. Neither is integrated or validated for a shared dual-engine chain.
Live hashrate, pool directory, and pool software upgrades appear here only after public nodes report verifiable measurements.
Candidate schedule: 2.5 MOD starting reward per engine block, halving every 4,200,000 blocks per engine. This sums to a theoretical 21 million per engine before rounding and is not approved consensus code.
The goal is a non-custodial market for assets native to the Modcoin ecosystem. An interface or signed order message alone is not settlement.
MOD, proposed BTC-on-Modcoin and DGB-on-Modcoin representations, and the proposed $MONEY units. Wrapped or represented assets require explicit collateral, redemption, and failure rules.
Requires on-chain contracts or compatible transaction scripts, timeout/refund paths, independent verification, and reviewed implementations. Not implemented.
No live markets, deposits, fiat rails, order book, or matching engine are available. Do not send funds to this site.
A design proposal for AUD- and USD-denominated digital units intended for use inside DEM.
Potentially buy AUD $MONEY with AUD and USD $MONEY with USD through approved fiat rails; trade them on DEM against MOD, BTC-on-Modcoin, DGB-on-Modcoin, or between the AUD/USD units.
Named issuer, legal classification, licensing analysis, safeguarding and redemption terms, reserve attestations, banking/payment partners, AML/CTF controls, consumer disclosures, and a tested settlement design.
The supplied v0.2.0 testnet has a CLI wallet and a local status dashboard. A v0.3.0 wallet GUI source draft adds send, receive, and history screens, but has not been compiled. Production wallets still need secure key storage, finalized formats, and an audited signing flow.
v0.2.0 CLI wallet is present. The v0.3.0 dashboard update is source-only and uncompiled; the existing wallet key is unencrypted testnet Ed25519.
UI scaffold only. It is not connected to the node, and its wallet actions remain disabled.
No APK or App Store build is available. Mobile builds require production key management, node API, store signing, and review.
Modcoin is proposed as its own Proof-of-Work chain with native MOD and a shared UTXO ledger. This does not automatically make assets on other chains compatible.
Direct compatibility with BNB, ETH, SOL, or other non-PoW tokens is not part of this proposal. Any future interoperability would need a separately specified trust model and security review; a bridge is not implied by DEM.