For wallet providers who already support DigiByte and want to add DigiDollar (DD) support.
DigiDollar is a decentralized USD-denominated stablecoin system built natively into DigiByte Core. Each DD is designed to track $1.00 USD through over-collateralized DGB vaults, live oracle pricing, DCA, ERR, and volatility protections. No company controls it — everything runs inside the DigiByte protocol.
There are only 4 operations: Mint, Transfer, Redeem, and regular DGB transactions.
| Feature | Detail |
|---|---|
| Token type | Native UTXO (not a layer-2 token) |
| Address format | DD... (mainnet), TD... (testnet), RD... (regtest) — Base58Check with 2-byte version prefix wrapping a P2TR x-only key |
| Amount unit | USD cents for integration code (10000 = $100.00) |
| Fees | Always paid in DGB (not DD) |
| Minimum fee | 0.1 DGB per DD transaction for transfer builders; mint and redeem builders enforce their own DGB fee floors in src/digidollar/txbuilder.cpp |
| Signing | Schnorr (BIP-340) for DD inputs, ECDSA/Schnorr for DGB fee inputs |
| Wallet type | Descriptor/bech32m HD wallet required for DigiDollar V1 mint/address creation; legacy wallets are unsupported |
| Confirmations | Same as DGB — 15-second blocks |
| Backend | Requires DigiByte Core v9.26.2+ with DigiDollar built in; features remain BIP9-gated until activation |
Your wallet must:
- Run DigiByte Core v9.26.2 or later (with DigiDollar consensus rules)
- Set
digidollar=1indigibyte.conf - Set
txindex=1; startup enforces this on mainnet/testnet DigiDollar chains and on regtest when DD testing is enabled - Wait for BIP9 activation (DigiDollar features are disabled until activation; status is exposed via
getdigidollardeploymentinfo) - Use a descriptor/bech32m HD wallet with private keys enabled. DD mint
requires deriving an HD owner key for the time-lock; encryption is
supported, in which case the wallet must be unlocked with
walletpassphrasebefore private-key DD actions. Legacy BDB wallets and watch-only/private-key-disabled wallets cannot create DD addresses, mint, send, redeem, or sign.
Before activation, getdigidollardeploymentinfo remains available and wallet-local oracle key setup can be prepared with createoraclekey, exportoracleprivkey, and importoracleprivkey. DD address, balance, history, mint, send, redeem, and running-oracle status/operation RPCs are activation-gated.
# digibyte.conf
server=1
digidollar=1
txindex=1 # required for DigiDollar transaction lookupsDigiDollar uses its own address format — standard DGB addresses won't work for DD operations.
| Network | Prefix | Example |
|---|---|---|
| Mainnet | DD |
DD<base58check-taproot-key> |
| Testnet | TD |
TD<base58check-taproot-key> |
| Regtest | RD |
RD<base58check-taproot-key> |
Generate a DD address:
digibyte-cli getdigidollaraddress
# Returns a Base58Check DD/TD/RD address for the current networkList DD addresses in wallet:
digibyte-cli listdigidollaraddresses
# Include generated but still-empty addresses:
digibyte-cli listdigidollaraddresses false 0 trueDD addresses are P2TR (Taproot) under the hood, encoded with a 2-byte Base58Check version prefix (0x52, 0x85 mainnet -> "DD"; 0xb1, 0x29 testnet -> "TD"; 0xa3, 0xa4 regtest -> "RD" — see src/base58.cpp:180-182). They are not Bech32/Bech32m strings even though the underlying output is Taproot. Prefix alone is not validation: use validateddaddress or the current-network Base58Check validator before accepting or sending to an address. Invalid, whitespace-padded, wrong-network, wrong-size, or checksum-invalid input returns isvalid=false and a blank canonical address.
listdigidollaraddresses hides generated zero-balance addresses by default to avoid leaking wallet/keypool size. Pass include_empty=true as the third argument when an operator needs a full generated-address inventory.
DigiDollar balances are tracked separately from DGB balances. The wallet maintains its own DD UTXO set.
Get total DD balance:
digibyte-cli getdigidollarbalance
# Returns: { "confirmed": 50000, "unconfirmed": 0, "total": 50000 }
# (amounts in cents — 50000 = $500.00)Get balance for a specific address:
digibyte-cli getdigidollarbalance "DDaddress..."Key points:
confirmed— DD in confirmed transactionsunconfirmed— DD in unconfirmed but trusted transactions when queried withminconf=0, for examplegetdigidollarbalance "" 0- Default
minconfis 1, so confirmed-only accounting is the default - Users need BOTH a DD balance (to send DD) AND a DGB balance (to pay fees)
Minting locks DGB as collateral and creates new DD tokens.
The 10 canonical lock tiers (defined in src/consensus/digidollar.h:57-68):
| Tier | Lock Period | Collateral Ratio |
|---|---|---|
| 0 | 1 hour (240 blocks) | 1000% (testing/onboarding) |
| 1 | 30 days | 500% |
| 2 | 90 days | 400% |
| 3 | 180 days | 350% |
| 4 | 1 year | 300% |
| 5 | 2 years | 275% |
| 6 | 3 years | 250% |
| 7 | 5 years | 225% |
| 8 | 7 years | 212% |
| 9 | 10 years | 200% |
These tiers are consensus-enforced. Custom (non-canonical) lock durations are rejected by the validator — src/digidollar/validation.cpp checks bad-mint-lock-tier, bad-mint-lock-tier-duration, and bad-mint-lock-period paths so wallets must select a tier 0–9. The OP_RETURN encodes the tier explicitly so it can be cross-checked against the locktime.
Longer lock = lower collateral requirement. The collateral stays in YOUR wallet — you never give up your keys.
- Minimum: $100 (10,000 cents)
- Maximum: $100,000 per transaction (10,000,000 cents)
Step 1: Check the oracle price
digibyte-cli getoracleprice
# Returns current DGB/USD price in micro-USDStep 2: Estimate collateral needed
digibyte-cli calculatecollateralrequirement 10000 180
# 10000 cents ($100), 180 days lock (350% ratio)
# Returns: required DGB amount
# Or use estimatecollateral with tier (both args required):
digibyte-cli estimatecollateral 10000 3
# 10000 cents ($100), tier 3 (180 days)
# Optionally pass a custom DGB price (micro-USD) for what-if calculations:
digibyte-cli estimatecollateral 50000 5 6500Step 3: Mint
digibyte-cli mintdigidollar 10000 3
# Locks DGB collateral, creates $100 DDResponse:
{
"txid": "abc123...",
"dd_minted": 10000,
"dgb_collateral": "55468.12345678",
"lock_tier": 3,
"unlock_height": 1234567,
"collateral_ratio": 350,
"fee_paid": "0.10000000",
"position_id": "abc123..."
}The mint transaction creates:
- Collateral output (P2TR) — Your DGB locked with a CLTV timelock. Uses a NUMS internal key (mathematically unspendable via key-path), ensuring it can only be unlocked via the script-path after the timelock expires.
- DD token output (P2TR) — A 0-satoshi Taproot output representing your DigiDollars. Freely transferable.
- OP_RETURN metadata — Records the DD amount, lock height, and tier for network-wide tracking.
- DGB change — Any leftover DGB returned to your wallet.
Sending DD is straightforward — it works like sending any UTXO.
For automated integrations, pass integer cents without a decimal point. senddigidollar, sendmanydigidollar, and redeemdigidollar also accept decimal-dollar input for CLI compatibility: 5000 means $50.00, but 5000.00 means $5,000.00.
digibyte-cli senddigidollar "DDrecipientAddress..." 5000
# Sends $50.00 worth of DDWith optional comment:
digibyte-cli senddigidollar "DDrecipientAddress..." 5000 "Payment for services"Response:
{
"txid": "def456...",
"to_address": "DDrecipientAddress...",
"amount": 5000,
"status": "success",
"fee_paid": "0.10000000",
"change_amount": 5000
}- Transfers require DD UTXOs (for the value) AND DGB UTXOs (for the miner fee)
- Minimum fee: 0.1 DGB for transfer builders; mint and redeem builders enforce DGB fee floors in their txbuilder paths
- DigiByte uses DGB/kB for fee rates (not DGB/vB). The default DD fee rate is 35,000,000 sat/kB (≈0.35 DGB/kB), which yields ≈0.1 DGB on a typical ~300-vB tx
- Maximum single transfer: $100,000 (10,000,000 cents)
- DD change is automatically returned to your wallet
- Transfers are confirmed-only: a DD UTXO must have at least one confirmation before it can be spent in a subsequent transfer or redeem. Consensus refuses to resolve DD amounts from
MEMPOOL_HEIGHTinputs for transfer/redeem, and the wallet no longer chains unconfirmed DigiDollar outputs (commit0b4959f563). Plan throughput around the 15-second block time, or batch withsendmanydigidollar. - Advanced wallet coin control can pass
selected_inputsmatchinglistdigidollarunspentrows. The deprecatedfee_rateargument on send/redeem RPCs is ignored by the fixed DD fee policy.
Use sendmanydigidollar to fan out DD to many addresses with a single fee:
digibyte-cli -rpcwallet=hot sendmanydigidollar "" '{"DDaddr1...":1500,"DDaddr2...":2500}'
# amounts in centsThis is the DigiDollar analogue of sendmany; the first argument must be the compatibility dummy string "". Like senddigidollar, it requires confirmed DD inputs and pays the fee in DGB. Large batches are limited by standard OP_RETURN relay size because one amount is committed for every DD output plus possible change; split large withdrawal batches and handle the RPC's "Too many DigiDollar recipients" error.
Receiving DD works like receiving DGB — share your DD address and wait for the transaction.
Watch for incoming DD:
digibyte-cli listdigidollartxs 10 0 "" "receive"
# Lists last 10 received DD transactionsResponse includes:
{
"txid": "ghi789...",
"category": "receive",
"amount": 5000,
"address": "DDyourAddress...",
"confirmations": 6,
"blockheight": 12345,
"time": 1770934000
}# All DD transactions (last 20)
digibyte-cli listdigidollartxs 20
# Filter by category
digibyte-cli listdigidollartxs 10 0 "" "mint"
digibyte-cli listdigidollartxs 10 0 "" "send"
digibyte-cli listdigidollartxs 10 0 "" "receive"
digibyte-cli listdigidollartxs 10 0 "" "redeem"
digibyte-cli listdigidollartxs 10 0 "" "redeem_change"
# Filter by address
digibyte-cli listdigidollartxs 10 0 "DDspecificAddress..."Transaction categories:
mint— You minted new DD (locked DGB collateral)send— You sent DD to someonereceive— You received DD from someoneredeem— You redeemed DD back to DGBredeem_change— DD change returned to the wallet during an ERR/full redeem flow
History rows include in_mempool and wallet_state (local, pending, confirmed, conflicted, or abandoned). Send rows are negative amounts; receive rows are positive. count is capped at 1000 and skip must be non-negative.
When you mint DD, you create a collateral position. You can view and manage these:
# List all your positions (filterable by tier / amount / active)
digibyte-cli listdigidollarpositions
# Check if a position can be redeemed
digibyte-cli getredemptioninfo "position_id"listdigidollarpositions reports unlock_height, status, spendable, and can_redeem for each position (with optional filters: [active_only=true] [tier_filter] [min_amount] [count] [skip]); clients should filter on those fields rather than calling a separate "redeemable only" RPC. (The legacy listredeemablepositions symbol exists in src/rpc/digidollar_transactions.cpp but is not registered — that file's command table is never wired into the RPC server.)
Each position tracks:
- DD amount minted
- DGB collateral locked
- Lock tier and unlock height
- Whether it is pending, active, unlocked, pending redeem, or redeemed
DigiDollar position state and DD owner keys are persisted inside the
wallet database as side tables (dd_position, dd_balance, dd_owner_key,
dd_address_key, dd_transaction) loaded by DigiDollarWallet::LoadFromDatabase.
Every standard wallet management
command works with DigiDollar wallets:
| Operation | What survives | Notes |
|---|---|---|
unloadwallet "name" |
All DD records on disk | DD wallet RPCs return -18 RPC_WALLET_NOT_FOUND while no wallet is loaded. |
loadwallet "name" |
Positions, balances, DD owner keys, dd_transactions | After load, listdigidollarpositions and getdigidollarbalance reflect the same on-chain state. |
digibyted stop / start |
Same as above | postInitProcess re-runs ScanForDDUTXOs() to validate vault UTXO state against the active chain. |
rescanblockchain |
Idempotent — no double counting | Triggers a post-rescan call to ScanForDDUTXOs() -> ValidatePositionStates() so any vault that was redeemed off-wallet is correctly marked inactive. |
-reindex=1 |
Same as restart | Wallet replays the chain; confirmed mints remain active until a real redeem/transfer spends the collateral on the active chain. |
backupwallet path / restorewallet new_name path |
Full DD state including owner keys | Restored wallet is loaded under new_name; existing wallet is untouched. |
importdescriptors into a fresh wallet + rescanblockchain |
Reconstructs DD positions from on-chain OP_RETURN metadata after proving ownership of the zero-value DD P2TR output | If the imported descriptors can provide the Taproot spending key, the wallet recovers and indexes that key for redemption. |
# 1. From the original (still-loaded) wallet, export descriptors with private keys
digibyte-cli -rpcwallet=mywallet listdescriptors true > /secure/path/dd_descriptors.json
# 2. On the recovery host, create a blank descriptor wallet and import them
digibyte-cli createwallet "restored" false true "" false true
digibyte-cli -rpcwallet=restored importdescriptors "$(cat /secure/path/dd_descriptors.json | jq '.descriptors')"
# 3. Run a full rescan so DigiDollar positions are reconstructed from the chain
digibyte-cli -rpcwallet=restored rescanblockchain
# 4. Verify
digibyte-cli -rpcwallet=restored listdigidollarpositions
digibyte-cli -rpcwallet=restored getdigidollarbalanceAfter step 4, the restored wallet may immediately redeemdigidollar any
position whose unlock_height has passed. There is no separate "DD owner
key import" step. The rescan reconstructs positions from mint metadata after
wallet ownership of the zero-value DD token output is proven, then recovers the
Taproot spending key from the imported descriptors when available.
If the wallet file is lost but the BIP39 seed / extended private key is
preserved, re-derive the descriptors with your wallet stack's seed-restore
tool, import them with
importdescriptors, and rescanblockchain from genesis. Active and redeemed
DD position state is reconstructed from chain data, and spend keys are cached
only when the imported descriptors can prove ownership of the DD output.
Encrypted wallets must call walletpassphrase before any RPC that derives,
exports, imports, or uses private DD/oracle keys: getdigidollaraddress,
mintdigidollar, senddigidollar, sendmanydigidollar,
redeemdigidollar, createoraclekey, exportoracleprivkey,
importoracleprivkey, and startoracle when it uses a wallet-stored key.
loadwallet and unloadwallet do not require the passphrase. Existing DD
positions remain visible to read-only RPCs while locked, but
listdigidollarpositions reports them as not spendable/not redeemable until
the wallet is unlocked.
DigiDollar V1 mint requires HD-derived owner keys persisted via the
descriptor wallet path. Loading or restoring a BDB legacy wallet that has
DD records is not supported and is not exercised by the V1 test suite.
Operators with legacy wallets must migrate to a descriptor wallet
(migratewallet or fresh export/import) before minting on mainnet.
Redeeming burns DD tokens and unlocks your DGB collateral. The timelock must have expired.
# Redeem a position (must redeem full vault amount)
digibyte-cli redeemdigidollar "position_id" 10000
# position_id = the mint transaction hash
# amount = DD cents to redeem (must match full vault amount)- Normal (system health ≥ 100%): Burn your original DD amount → get 100% of your collateral back
- ERR (system health < 100%): You may need to burn extra DD (up to 125%) to get your full collateral back. This creates buying pressure on DD during crises, helping stabilize the peg.
Critical rule: Collateral cannot be spent through the DD redemption paths before the timelock expires. There are no early liquidations or margin calls, but the collateral remains illiquid until expiry and redemption still requires the normal or ERR-adjusted DD burn.
# System-wide DD stats
digibyte-cli getdigidollarstats
# Returns: total DD supply, total collateral, system health ratio
# Current oracle price
digibyte-cli getoracleprice
# Returns: DGB/USD price, staleness info
# Check activation status
digibyte-cli getdigidollardeploymentinfo
# Returns: BIP9 status, signaling progressIf your wallet parses raw transactions, here's how to identify DD transactions:
Check the transaction version:
(tx.nVersion & 0x0000FFFF) == 0x0770 → It's a DD transaction
Extract the type:
(tx.nVersion & 0xFF000000) >> 24
1 = MINT
2 = TRANSFER
3 = REDEEM
Parse the DD OP_RETURN by transaction type:
- Mint:
OP_RETURN "DD" 1 <dd_amount_cents> <unlock_height> <lock_tier> <owner_xonly_pubkey_32b> - Transfer:
OP_RETURN "DD" 2 <amount1> <amount2> ...; assign amounts to zero-value DD P2TR outputs in output order, including change - Redeem:
OP_RETURN "DD" 3 <dd_change_amount>only when DD change exists; full redemption may have no DD OP_RETURN - All DD amounts are integer cents
DD token outputs have 0-satoshi value with P2TR scripts. The actual DD value is in the OP_RETURN.
Custom opcodes (Tapscript OP_SUCCESSx soft-fork, defined in src/script/script.h:209-220):
| Opcode | Hex | Purpose |
|---|---|---|
OP_DIGIDOLLAR |
0xbb |
Marks DD outputs (Tapscript OP_SUCCESSx slot pre-activation) |
OP_DDVERIFY |
0xbc |
Verify DD conditions (Tapscript OP_SUCCESSx slot pre-activation) |
OP_CHECKPRICE |
0xbd |
Reserved and deterministically disabled; consumes one operand and pushes false |
OP_CHECKCOLLATERAL |
0xbe |
Collateral ratio check |
OP_ORACLE |
0xbf |
Coinbase oracle bundle marker (Tapscript OP_SUCCESSx slot pre-activation) |
Non-DD-aware wallets can safely ignore these — they behave as Tapscript OP_SUCCESSx (BIP-342) until SCRIPT_VERIFY_DIGIDOLLAR is set, which only happens after BIP9 DEPLOYMENT_DIGIDOLLAR is ACTIVE.
OP_CHECKPRICE is reserved and deterministically disabled; mint/redeem validation reads authenticated coinbase oracle bundles and the oracle price cache instead of a script-local price opcode. Oracle P2P messages, including ORACLEHEARTBEAT use IsOracleP2PActive.
Registered in GetWalletRPCCommands() at src/wallet/rpc/wallet.cpp:
| Command | Description |
|---|---|
getdigidollaraddress [label] |
Generate new DD deposit address |
listdigidollaraddresses [include_watchonly] [min_balance] [include_empty] |
List DD addresses; empty generated addresses are hidden unless include_empty=true |
getdigidollarbalance [addr] [minconf] [include_watchonly] |
Get DD balance (confirmed, unconfirmed, total) |
mintdigidollar <cents> <tier> [fee_rate] |
Mint DD by locking DGB collateral; amount is integer cents |
senddigidollar <addr> <amount> [comment] [fee_rate_ignored] [selected_inputs] |
Send DD to a DD address; integer means cents, decimal means dollars |
sendmanydigidollar "" <amounts_obj> [comment] [selected_inputs] |
Send DD to multiple DD addresses in one tx |
listdigidollartxs [count] [skip] [addr] [category] |
List DD transaction history; categories include mint, send, receive, redeem, redeem_change |
listdigidollarunspent [minconf] [maxconf] [addresses] [include_unsafe] |
List DD UTXOs with spendable and safe flags |
listdigidollarutxos [minconf] [maxconf] [addresses] [include_unsafe] |
Alias for DD UTXO listing |
listdigidollarpositions [active_only] [tier_filter] [min_amount] [count] [skip] |
List collateral positions |
getredemptioninfo <position_id> [amount] |
Check redemption status; optional amount must equal the full vault amount |
redeemdigidollar <position_id> <amount> [redemption_address] [fee_rate_ignored] |
Redeem DD -> unlock DGB collateral; integer means cents, decimal means dollars |
validateddaddress <address> |
Validate a DD address |
createoraclekey <oracle_id> |
Wallet-scoped oracle key generation |
exportoracleprivkey <oracle_id> |
Export a wallet-stored oracle private key for backup/migration |
importoracleprivkey <oracle_id> <private_key_hex> [replace] |
Import a wallet-stored oracle private key for recovery/migration |
startoracle <oracle_id> [private_key_hex] |
Start local oracle from a wallet-stored or supplied key |
Registered in RegisterDigiDollarRPCCommands() at src/rpc/digidollar.cpp:
| Command | Description |
|---|---|
getdigidollardeploymentinfo |
BIP9 activation status, signaling progress |
getdigidollarstats |
Network-wide DD supply and health |
getdcamultiplier |
Current Dynamic Collateral Adjustment multiplier |
getoracleprice |
Current DGB/USD oracle price (from MuSig2 consensus) |
getalloracleprices |
Per-oracle price view (debug/status) |
getoraclesigners [blocks] |
Recent on-chain MuSig2 oracle-bundle signer IDs and metadata |
getprotectionstatus |
DCA / ERR / volatility protection state |
getoracles [active_only] [blocks] |
Oracle roster and local/remote status |
listoracle |
Local oracle status |
stoporacle <oracle_id> |
Stop a local oracle |
getoraclepubkey <oracle_id> |
Local oracle public key/status; wallet RPC paths can show the stored key before startoracle |
calculatecollateralrequirement <cents> <lock_days> [oracle_price_micro_usd] |
Calculate needed collateral by lock days (NOT tier) |
estimatecollateral <cents> <tier> [oracle_price_micro_usd] |
Estimate collateral; both cents and tier are required |
importdigidollaraddress <address> [label] [rescan] [p2sh] |
Validate a DD address and return the V1 unsupported/no-op warning; it does not import, mutate wallet state, or rescan |
setmockoracleprice <micro_usd> |
Regtest-only mock oracle price setter |
getmockoracleprice |
Regtest-only mock oracle price reader |
simulatepricevolatility <percent_change> |
Regtest-only volatility simulation |
enablemockoracle <enabled> |
Regtest-only mock oracle toggle |
DigiByte Core ships a DD lifecycle tab plus Qt widgets/dialogs/helpers: digidollartab, digidollaroverviewwidget, digidollarsendwidget, digidollarreceivewidget, digidollarmintwidget, digidollarredeemwidget, digidollarpositionswidget, digidollartransactionswidget, digidollarcoincontroldialog, digidollarreceiverequest, ddaddressbookpage, and digidollar_qt_translate. DigiDollarTab exposes the tabs $DD Overview, Send $DD, Receive $DD, Mint $DD, Redeem $DD, $DD Vault, and $DD Transactions, with an activation overlay until BIP9 activates. The Qt mint flow derives an HD owner key and persists it before broadcasting (commit 1e95478b7e), so an HD wallet with private keys enabled is required. See REPO_MAP_DIGIDOLLAR.md (Qt GUI section) for individual widget responsibilities.
The Qt mint widget broadcasts the assembled mint transaction directly through node().broadcastTransaction rather than through the mintdigidollar RPC. As a result the Wave 6 RPC pre-check that translates Emergency Redemption Ratio (ERR) state into a friendly RPC error does not run on the Qt code path: the widget's owner-key derivation, two-step confirmation dialogs, and HD wallet flow are all driven before broadcast, and the consensus reject reason (minting-blocked-during-err, bad-tx-no-musig2-quote, volatility-freeze, bad-mint-lock-tier-duration, bad-oracle-price, bad-mint-collateral) reaches the user only when mempool refuses the transaction.
In v9.26.2 (DD-FA-FUNC-032), the mint widget routes the broadcast reason through qt/digidollar_qt_translate.h::TranslateMintRejectReasonForUser before display. Known DD/oracle reject tokens are rewritten with a plain-English explanation and a remediation hint (e.g. minting-blocked-during-err is shown as "DigiDollar minting is paused because the system is in Emergency Redemption Ratio (ERR) recovery mode."). Unknown reasons pass through unchanged so operators retain forensic detail. The translator is unit-tested by src/test/digidollar_qt_translate_tests.cpp and is buildable without enabling Qt.
For wallet integrators that bypass the Qt widget and submit raw mint transactions via sendrawtransaction, the canonical consensus reject tokens above are stable and may be matched directly by RPC consumers; see src/digidollar/validation.cpp (ValidateDigiDollarTransaction) for the authoritative list.
The current public testnet in this source tree is testnet26. DigiDollar activation is BIP9-gated at/after block 600 once 140 of 200 blocks signal; verify live status with getdigidollardeploymentinfo.
- Download the latest DigiByte Core v9.26.2 build from this branch
- Configure for testnet:
testnet=1 [test] digidollar=1 txindex=1 addnode=oracle1.digibyte.io:12033 server=1 rpcuser=yourusername rpcpassword=yourpassword
- Launch:
digibyted -testnet -daemon - Get testnet DGB from the dev chat: https://app.gitter.im/#/room/#digidollar:gitter.im
- Start minting, sending, and receiving DD!
| Parameter | Value |
|---|---|
| Testnet name | testnet26 |
| P2P Port | 12033 (set in src/kernel/chainparams.cpp) |
| DD Address Prefix | TD |
| Oracle Consensus | 35 active slots, 7 signatures required |
| Exchange Sources | Binance, CoinGecko, KuCoin, Gate.io, HTX, Crypto.com (6 active feeders, see src/oracle/exchange.cpp:1092-1097) |
| Outlier filter | Median-distance: a price is dropped when its distance from the median exceeds outlier_threshold × median (MultiExchangeAggregator::FilterOutliers at src/oracle/exchange.cpp:1225) |
| Activation | BIP9 bit 23, min activation height 600; check getdigidollardeploymentinfo for current status |
Mainnet activation is BIP9-gated on bit 23 (src/kernel/chainparams.cpp:177-180): signaling starts 2026-06-01 (nStartTime=1780272000), times out 2027-06-01 (nTimeout=1811808000), uses a 40,320-block confirmation window with a 70% threshold (28,224 blocks), and the minimum activation height is 23,627,520. Use getdigidollardeploymentinfo on the target release and network as the runtime source of truth for status, window size, threshold, timeout, and minimum activation height.
Join the developer chat: https://app.gitter.im/#/room/#digidollar:gitter.im
Track testnet activation: https://digibyte.io/testnet/activation
💎 DigiDollar — the first truly decentralized stablecoin on a UTXO blockchain.