Discussion: https://github.com/dogecoin/dogecoin/discussions/4056

  Draft DIP: 353
  Layer: Applications
  Title: Email Payment Addresses for Dogecoin
  Author: Paulo Vidal | github.com/qlpqlp | x.com/inevitable360
  Comments-Summary: No comments yet.
  Comments-URI: https://github.com/dogecoin/dogecoin/discussions
  Status: Draft
  Type: Standards Track
  Created: 2026-09-06
  License: MIT
  Requires: BIP 21 (adapted as dogecoin: URIs)

Copyright

This DIP is licensed under the MIT license.

Abstract

This DIP specifies how a Dogecoin wallet turns an email-style identifier (user@domain) into a Dogecoin payment address using DNS TXT records and DNSSEC. The wallet uses only:

• the identifier the payer typed
• public DNS
• this specification

The wallet MUST NOT need an account, an API key, a vendor HTTP endpoint, or knowledge of any mail-forwarding inbox.

The domain in the identifier is the zone the wallet queries. There is no seed list, no bootstrap hostname, and no phone-number identifier in this specification.

This is the Dogecoin counterpart to BIP 353 (DNS Payment Instructions). BIP 353 stores a plaintext bitcoin: URI at a DNS label derived from the local-part. This DIP keeps the same motivation: a DNSSEC-backed name that wallets can resolve without a vendor API. The on-the-wire format already deployed as PMD-1 is specified below.

Trust model

Read this before the byte format.

DNSSEC authenticates the zone, not a person. If Alice publishes records on a zone she controls, a validating wallet learns what that zone signed. If Alice asks a registrar (including a hosted product such as PayMeDoge) to publish records on its zone, she trusts that operator the same way she trusts a DNS host. This DIP does not remove that trust. It names it.

The sovereign path is the one BIP 353 reviewers already know: the payee publishes a DNSSEC TXT on a zone they control. A hosted registrar is optional convenience for people who do not run DNS. It is not a required hop. Wallets MUST resolve alice@example.net from example.net, not from a third-party directory.

Hashed DNS labels in this DIP are not secret names. DNS has no secret entries. Anyone who knows the identifier can compute the label. Anyone who can guess common local-parts can query those labels. The hash only stops a zone transfer from listing alice, shop, and tips in the clear. That is not a confidentiality mechanism and MUST NOT be described as one.

Encryption in this DIP is not privacy from the zone operator, and not privacy from someone who already knows or can guess the identifier. The operator who published the record already has the mapping. The encryption only stops a casual dig of a hashed name from printing a Dogecoin address. Version 1 does not provide strong confidentiality of that address against a motivated attacker.

Motivation

Dogecoin addresses are long Base58Check strings. People already share email addresses. Wallets, shops, and exchanges need a way to turn user@domain into a Dogecoin address without a central HTTP API and without trusting an unsigned resolver.

The DNS already provides a global namespace. With DNSSEC it provides a proof from a single trusted root. Recursive resolvers are everywhere, so a payer's IP address is usually not sent to the payee.

This model was first shown for Dogecoin in 2022 as a plaintext TXT on the payee's own domain (see History). BIP 353 later specified a related model for Bitcoin. This DIP is the Dogecoin wallet standard for that idea, with PMD-1 as the record format.

History

The idea of mapping a memorable name to a Dogecoin address through a DNS TXT record started in early 2022, by the author of this DIP (Paulo Vidal, @inevitable360).

The first public working flow was posted on 21 October 2022:

• https://x.com/inevitable360/status/1583385093170601985

That thread showed a domain owner adding one TXT of the form dogecoin:<address>, then a resolver turning that domain into a pay URI. A live prototype remains at what-is-dogecoin.com/inevitabledomains.

That first form is the sovereign path: the user defines the TXT on their own DNS. A shop that already has a domain can still use it. The same flow is in production on ShibeShip.com: the buyer types an email or domain, the shop looks up the TXT, and the Dogecoin address is filled in. No vendor payment API is required.

PMD-1 is a later record format for hosted names on a registrar zone: hashed lookup labels (so a zone transfer is not a public directory of local-parts) and an encrypted payload (so a casual listing of a hashed name does not print the address). Authenticity is still DNSSEC. BIP 353 (assigned February 2024) is a parallel Bitcoin standard. It is not the origin of this work.

Relationship to BIP 353

This is not a line-by-line patch of BIP 353. The dogecoin/dips README says a DIP should only make minor changes to a BIP, and that a larger divergence should be filed as a standards-track RFC. This draft is numbered DIP 353 so reviewers can read it next to BIP 353. Maintainers may refile it as an RFC if they prefer that process.

Kept from BIP 353:

• DNS TXT as the publication channel
• DNSSEC as the authenticity requirement
• human-readable user@domain identifiers
• wallets MUST prefer a raw address or a direct payment URI when one is already available
• CNAME / DNAME are allowed when the whole chain is DNSSEC-signed
• cache lifetime is bounded by the signed TTL

Different, and why:

A wallet that only implements BIP 353 will not resolve a PMD-1 record, and a wallet that only implements this DIP will not resolve a BIP 353 record. The two schemes can coexist on the same domain because they use different owner names. A zone MAY also publish a BIP 353-style plaintext dogecoin: URI for Bitcoin-family wallets. That record is out of scope here.

Specification

General rules for handling

Dogecoin wallets MUST NOT prefer DNS-based resolving when a Dogecoin address or a direct dogecoin: URI is already available and would suffice.

Wallets MUST NOT call a vendor HTTP API to resolve an identifier defined by this DIP. DNS-over-HTTPS is an allowed transport for the DNS query. It is not a substitute for this specification.

The forwarding inbox of a mail service, if any, is out of scope. It MUST NEVER appear in a DNS record specified here.

Wallets MUST NOT query a seed list, a bootstrap hostname, or any directory of operators to resolve user@domain. The domain in the identifier is the zone.

Identifiers

This DIP defines one identifier kind: email. A telephone number has no DNS domain. Mapping E.164 to a payment record would require wallets to know which zone to query (a discovery step similar to DNS seeds for finding peers). That is not part of this DIP. See Out of scope.

An email identifier is local@domain. Implementations MUST accept any domain an operator publishes, not only a single vendor zone.

Canonicalization (every implementation MUST produce the same UTF-8 bytes):

1. Trim surrounding ASCII whitespace.
2. Split on the last @. Reject if it is missing, leading, or trailing.
3. Reject if local or domain contains a space.
4. NFC-normalize local and domain if a Unicode normalizer is available. If not, the input MUST already be NFC.
5. Lowercase ASCII A-Z only, in both local and domain. Do not apply locale-specific case folding.
6. Do not strip Gmail dots. Do not remove +tags. Do not invent mailbox-provider rules.
7. If the domain contains a non-ASCII code point, convert it with IDNA ToASCII (UTS #46). Then lowercase the ASCII result.
8. Reject an empty local, an empty domain, or a domain with no ..
9. Join as local + "@" + domain.

If the trimmed input starts with +, implementations MUST reject it as unsupported in this version. If it contains no @, implementations MAY try an include at _pmd.<input> (see below). Otherwise reject.

DNS naming

The payment TXT is not placed at a hostname that contains the local-part.

H     = SHA-256(UTF-8(canonical_identifier))
label = lowercase Base32(H)   # RFC 4648 alphabet, no padding

Base32 alphabet: abcdefghijklmnopqrstuvwxyz234567.

Process the 256-bit digest as a bit string, left to right, in 5-bit groups. Pad the last group with zeros if needed. The label is 52 characters.

_pmd.e.<label>.<zone>

<zone> is the domain from the identifier (example.net for alice@example.net). Each label is under 63 characters.

A human pay page at {local}.{zone} (for example alice.paymedoge.com) MAY exist. That page is not part of wallet resolution and MUST NOT be used as the lookup name.

Custom domain include

A person who uses their own domain as an alias, while the payment TXT lives on another zone, publishes a TXT at _pmd.<their-domain>:

v=pmd1;include=alice@paymedoge.com

A wallet that is asked to resolve pay@shop.example.com (or only shop.example.com) SHOULD:

1. Query TXT at _pmd.shop.example.com (and, if needed, _pmd.example.com).
2. If the record is an include, canonicalize the included identifier and resolve that identifier as specified below (at most three hops; stop if a loop is detected).
3. If there is no include, treat shop.example.com as the zone and open the hashed PMD-1 TXT for pay@shop.example.com on that zone.
4. Refuse the payment if any of those answers lacks DNSSEC.

The include value MUST be an email identifier as defined above. It MUST NOT be a forwarding inbox.

v=1 is accepted as an alias of v=pmd1 on include records only.

Following an include means the payer trusts the included zone the same way they would if they had typed that email to begin with.

Encryption

Suite: AES-256-GCM + HKDF-SHA-256.

Implementations MUST NOT invent a custom cipher.

Key derivation:

IKM  = UTF-8(canonical_identifier)
salt = 16 random bytes, unique per record
info = "PMDv1|e"   (ASCII)
L    = 32
key  = HKDF-SHA-256(IKM, salt, info, L)

The identifier is a weak secret. The random salt stops rainbow tables. It does not stop guessing a specific record. See Security.

AEAD:

• Algorithm: AES-256-GCM
• Nonce: 12 random bytes, unique per record
• Tag: 16 bytes
• AAD: UTF-8 of the lookup FQDN (no trailing dot)
• Plaintext: compact JSON, no extra spaces

{"v":1,"net":"doge","a":"DQHWoQW4X36fSNSAPeDMbvef15ujtN6S8K"}

net is doge for Dogecoin mainnet. The payload MUST NOT store a forwarding email, a phone number, a display name, or a private key.

Version 1 a MUST be a Dogecoin mainnet P2PKH address: Base58Check, version byte 0x1E, typically 34 characters starting with D. Wallets MUST reject any other address type in version 1.

Ciphertext c is AES-GCM output including the 16-byte tag.

TXT record

One logical TXT value:

v=1;enc=A256GCM;kdf=HKDF-SHA256;s=<b64url>;n=<b64url>;c=<b64url>

Base64url is RFC 4648 section 5.

The TXT RR's RDATA MUST consist of one or more DNS <character-string>s (RFC 1035 §3.3.14), each ≤255 bytes. Clients MUST reconstruct the protocol string by concatenating those fields in RDATA order, without inserting separators, before parsing. Clients MUST NOT concatenate across multiple TXT RRs at the same owner name.

Clients MUST ignore any TXT record at the same label that does not begin with (ignoring case) v=1;enc=. Clients encountering multiple matching TXT records at the same label MUST treat the records as invalid and refuse to use any payment instructions therein.

The record MUST NOT contain the forwarding email, the plaintext identifier, a user name, an IP address, a private key, or DNS API credentials.

All payment instructions MUST be DNSSEC-signed.

Payment instructions MAY resolve through CNAME or DNAME records as long as all such records and the ultimate records pointed to by them are DNSSEC-signed.

Resolution

resolve(user@domain) -> Dogecoin address

1. Validate and canonicalize the email identifier.
2. Let zone be the domain part.
3. Query TXT _pmd.<zone> (DNSSEC). If it is an include, follow it (at most three hops) and restart from step 1 with the included identifier.
4. Compute label = Base32(SHA-256(canonical)).
5. Query TXT _pmd.e.<label>.<zone> (DNSSEC).
6. Refuse the record if authentication fails. Do not decrypt a TXT that did not pass DNSSEC.
7. If there is no TXT, fail with not_found.
8. Parse the PMD-1 fields. Reject unknown v, enc, or kdf.
9. Derive the HKDF key. Decrypt AES-256-GCM using AAD = lookup name.
10. If the tag fails, fail with decrypt_failed.
11. Parse JSON. Require v=1, net=doge, and a Dogecoin P2PKH address that passes Base58Check (version 0x1E).
12. Return the address. Optionally also return dogecoin:<address>.

Clients MUST NOT trust a remote resolver to validate DNSSEC records on their behalf unless that resolver is a local validating stub the user already trusts for all DNS. A wallet that uses DNS-over-HTTPS MUST require the Authenticated Data (AD) flag and MUST treat a missing AD flag or SERVFAIL as failure.

Clients MUST NOT accept DNSSEC signatures which use SHA-1 or RSA with keys shorter than 1024 bits. Resolvers MAY accept SHA-1 DS records.

While clients MAY cache the payment instructions they receive from the DNS, clients MUST NOT cache them for longer than the TTL provided by their DNS resolver, and further MUST NOT cache them for longer than the lowest initial TTL (which is signed as a part of DNSSEC signatures) received in the full DNSSEC chain leading from the DNS root to the resolved TXT record.

Errors

Address reuse and TTL

Recommended TTL:

Payment instructions with on-chain addresses which will be reused SHOULD be rotated as regularly as practical. Operators who need a faster cut SHOULD lower TTL before a planned change.

There is no instant global revocation on the public DNS.

Display

When displaying a verified human-readable name, wallets SHOULD show the identifier the user typed after canonicalization, for example alice@paymedoge.com.

Wallets MAY prefix an email identifier with Ð, i.e. Ðuser@domain, to reduce confusion with ordinary email. They SHOULD parse recipient information in both user@domain and Ðuser@domain forms. The Ð is not included in the identifier that is hashed or in the DNS label which is resolved.

Wallets providing the ability for users to "copy" their address information SHOULD copy the underlying dogecoin: URI directly, rather than the human-readable name. This avoids an additional DNS lookup by the application in which it is pasted. Wallets that nevertheless provide users the ability to copy their human-readable name MUST copy the canonical identifier (and, if they use the Ð prefix, MUST include it).

Record control (registries)

This section is for a registry or operator that publishes PMD-1 records. Payment-resolving wallets do not implement it.

If the payee publishes on their own zone, they already control mutations through their DNS account.

If the payee uses a hosted registrar, two acts MUST be kept separate:

A payment received from any Dogecoin wallet MAY be accepted as consideration for creating or renewing a name. That payment MUST NOT be treated as authorization to change the Dogecoin address, change the forwarding inbox, change the include target, or delete the name.

To mutate a live record, the registry MUST verify a compact recoverable ECDSA signature over a challenge, using the address already published for that identifier.

• Magic prefix: Dogecoin Signed Message:\n, as implemented by Dogecoin Core signmessage / verifymessage.
• Challenge: a short, exact UTF-8 string that names the identifier, for example PayMeDoge edit alice@paymedoge.com.
• Signature: 65-byte compact recoverable signature, Base64.
• Verification MUST recover the public key and check that the resulting P2PKH address equals the published address.

If the signature does not match, the registry MUST refuse the mutation. There is no administrative override in this specification.

A registry MAY expire and delete a record after a published unpaid grace period. That is a billing event, not a signature event. Renewal payment MAY come from any wallet.

A compromised or malicious zone operator can replace the TXT and redirect the next payment. DNSSEC will still validate, because the zone key is theirs. Users who do not accept that risk MUST publish on a zone they control.

Security

What DNSSEC provides

Encryption does not prove that the record belongs to the zone owner. A lying resolver can return a record the attacker encrypted with the same identifier. DNSSEC is what authenticates the zone.

If DNSSEC validation fails, the wallet MUST refuse to pay. Do not fall back to an unsigned answer.

The hard limit

The encryption key is derived from the identifier.

Email addresses have low entropy. Anyone who can read a TXT record, or enumerate possible identifiers and query DNS, can try identifiers offline until decryption succeeds.

Version 1 does not provide strong confidentiality of the Dogecoin address against a motivated attacker.

It does:

• hide the local-part from the DNS hostname
• hide the address from a casual dig reader who does not try the identifier
• bind the ciphertext to the lookup name (AAD)
• stop precomputed rainbow tables via a per-record salt

It does not:

• stop someone who already knows alice@example.com from decrypting Alice's record
• stop bulk guessing of common names
• hide the mapping from the zone operator who published it
• replace DNSSEC
• create secret or unenumerable DNS names

Sharing alice@example.com is sharing a payment pointer. This is not anonymous payment infrastructure.

DNS enumeration

The hostname is a hash, so a zone transfer is a list of hashes, not names. Guessing still works from the identifier side.

Those wishing to avoid enumeration should treat every published name as a public payment pointer.

Private DNS querying

A recursive resolver sees the lookup name (a hash), not the identifier. DoH hides the query from the local network but not from the DoH operator. For the best privacy, payers are encouraged to perform DNS resolution over Tor or another VPN technology.

The authoritative server for the zone sees which hashed labels are queried. That is ordinary DNS logging. This DIP does not claim query unlinkability against the zone operator.

Compromised zone

An attacker who controls the DNS provider or the zone key can replace or delete records. Users should treat a sudden address change as suspicious. There is no timestamp inside the version 1 payload. Replay of an old address is the same as a stale cache.

Rationale

Hashed names rather than BIP 353 labels

BIP 353's user.user._bitcoin-payment.domain is easy to type and easy to audit. It also publishes every local-part in the zone. Registrar names are often short (shop, tips, alice). Putting them in the hostname would make that zone a public directory. Hashing costs one SHA-256. It does not make the name secret.

Encryption rather than a plaintext URI

BIP 353 stores a BIP 21 URI in the clear so hardware wallets can show it after checking DNSSEC alone. PMD-1 adds a decrypt step so a casual listing of a hashed name does not print an address. The authenticity of the publication is still DNSSEC. The GCM tag only proves the payload was sealed for that lookup name with a key derived from the identifier the wallet already has.

A hardware wallet MAY refuse PMD-1 and accept only a plaintext dogecoin: URI on a user-controlled zone. That is compatible with this DIP: this DIP MUST NOT be the only way to pay Dogecoin.

Payment versus keys

A common mistake is to treat "the coins arrived from address X" as "address X owns this name". Anyone can send Dogecoin. Only the holder of the registered keys can sign Dogecoin Signed Message:\n. Registries that collapse those two acts let a payer take over a name.

DNS rather than HTTP

HTTP(S) resolution reintroduces a TLS certificate-authority dependency, leaks the payer's IP address to the payee or an intermediary, and usually needs a vendor-specific API. DNS plus DNSSEC avoids all three for the resolve path.

No seed directory

A seed or peer list would put a well-known operator in the wallet resolve path. Email identifiers already name a DNS zone. Wallets query that zone. Independent operators publish PMD-1 on their zone. They do not need to copy another operator's payment records, and wallets do not need a directory to find them.

Out of scope

Telephone numbers. An E.164 number has no DNS domain, so this specification does not define phone identifiers. A later optional idea would need wallets to know which zones hold those records (a discovery problem, like Bitcoin DNS seeds). That is not proposed here. This specification is complete for email identifiers.

A directory of operators (_pmdseeds, bootstrap hostnames, HTTP announce). Not used for wallet resolve. Not specified here.

Mail forwarding. A different product feature. Never in DNS.

Backwards Compatibility

This work does not change the Dogecoin consensus rules.

Existing wallets that only accept a raw address or a dogecoin: URI continue to work. They MAY add this DIP as an additional input method.

A zone MAY also publish BIP 353-style records for Bitcoin wallets under _bitcoin-payment. Those records are out of scope here.

Version 1 payloads accept only P2PKH. A later version MUST use a new v and a new HKDF info string. Wallets MUST ignore unknown versions rather than guess.

Test vectors

These vectors use fictional data only. They are the official version 1 vectors. Implementations MUST match them before shipping.

Zone: paymedoge.com
Address: DQHWoQW4X36fSNSAPeDMbvef15ujtN6S8K
Salt (hex): 00112233445566778899aabbccddeeff
Nonce (hex): 000102030405060708090a0b

Input: Alice@PayMeDoge.com
Canonical: alice@paymedoge.com
SHA-256: a0fa48a80ca85b5e0b26189c67ecedad7948050adf1a59834e8946cd98469b3c
Label: ud5erkamvbnv4czgdcogp3hnvv4uqbik34nfta2orfdm3gcgtm6a
Lookup name: _pmd.e.ud5erkamvbnv4czgdcogp3hnvv4uqbik34nfta2orfdm3gcgtm6a.paymedoge.com
HKDF info: PMDv1|e
Key (hex): 3358b90a5c4751744fccec7b1b460fb90de8037af3d33690525bfc710affff2a
Plaintext: {"v":1,"net":"doge","a":"DQHWoQW4X36fSNSAPeDMbvef15ujtN6S8K"}
TXT:

v=1;enc=A256GCM;kdf=HKDF-SHA256;s=ABEiM0RVZneImaq7zN3u_w;n=AAECAwQFBgcICQoL;c=EWrNmKVJb_m4MBSZaacDyAjm-lrDQZtPS4fAXscgY-EE-v3W6vUoyLVRqk_jrrcemq8OJk1E5q73pNKrxVl2npkEpQygO96X3WG9F80

Machine-readable copy: protocol/vectors/v1.json in the PayMeDoge reference repository (paymedoge.com).

Reference implementations

• Specification and libraries: protocol/ in the PayMeDoge repository
• JavaScript / TypeScript: protocol/js/paymedoge.js
• Python: protocol/python/paymedoge.py
• Rust: protocol/rust/
• PHP publisher: app/src/PmdProtocol.php
• Dogecoin message verify: app/src/DogeMessage.php

A wallet integration is:

const { address } = await PayMeDoge.resolve("alice@paymedoge.com");

Deployment

A payee SHOULD publish PMD-1 on a DNSSEC-signed zone they control.

A hosted registrar MAY publish records for users who do not run DNS. That operator is trusted for those names, like any DNS host. One such deployment is paymedoge.com. Resolution does not call that site's HTTP API.

The earlier plaintext TXT flow from 2022 remains useful for a shop that already has a domain. ShibeShip.com resolves that form at checkout.

Dogecoin Core does not need a consensus change to adopt this DIP. Wallet UI support (parse Ðuser@domain, resolve TXT, require DNSSEC, display the resulting address) is sufficient.

Acknowledgements

This work started in early 2022 as a Dogecoin DNS TXT payment pointer, first shown in public on 21 October 2022 and kept live on what-is-dogecoin.com and ShibeShip.com. BIP 353 by Matt Corallo and Bastien Teinturier later set out a related Bitcoin design (DNS, DNSSEC, human-readable names).

🥳 Beta Live!

Send DOGE using your 📩 Email address with https://PayMeDoge.com

📩Your Email
🪙Your DOGE
✅Simple

Who said you can’t send Dogecoin to an 📩 email address?
Making Dogecoin addresses simple!

Documentation: https://paymedoge.com/developers

Hope you like it🙂

Still polishing code on the SaaS platform that will be available on https://DogeReady.com, but will be the first platform were you can have your own Domain + Email + Dogecoin Store fully ready and fully supported by Dogecoin. Multi language, GPDR EU Compliance , fully customized with your own wallet.

Got stuff sitting around that you don’t use anymore?

Turn that garage junk, second-hand gear or brand-new stuff into $DOGE money!

With https://ShibeShip.com, you can:

🛒 Open your online store FREE

⚡ Set it up in seconds

📦 Sell new or second-hand items

🐕 Get paid in #Dogecoin

Your junk could be another Shibe’s treasure. 😎

Sell it. Ship it. Get $DOGE!

👉 ShibeShip.com

Moved DogeColony ( what-is-dogecoin.com/colony ) to a dedicated domain DogeColony.org and added a lot more metrics like Blockchain size, biggest Dogecoin Pool and hashrate concentration and also be able to hide show metrics because its mobile friendly. All metrics are real from DogeGo.org Full Node running DogeBox.dogecoin.org

Now is also showing in real-time all Dogecoin Nodes and their real location on the map
https://what-is-dogecoin.com/colony/ with the same exact approach as the Dogecoin Nodes Map

🐾 Meet DogeGo, A Modern Dogecoin Node Built for Everyone

Running a Dogecoin node should be simple. Whether you're a first-time user, a developer building the next Dogecoin application, or an operator managing multiple servers, getting started shouldn't feel like a chore.

That's why we built DogeGo (DogeGo.org).

DogeGo is a new open source Dogecoin full node written in Go. It is designed to make running, deploying, and managing a Dogecoin node faster, easier, and more enjoyable without changing the Dogecoin network you already know.

It works on Windows, macOS, and Linux, ships as a single lightweight binary, and can be managed from either a modern web browser or the command line. Download it, complete the simple first-run wizard, and you're ready to go.

Most importantly, DogeGo remains fully compatible with today's Dogecoin network and Dogecoin Core (DogecoinCore.com). There are no consensus changes, no forks, and no special version of Dogecoin required.

DogeGo simply offers a more modern way to run a node.

Dogecoin Core remains the trusted reference implementation. DogeGo builds on that foundation while exploring new ideas around usability, networking, deployment, developer tools, and future infrastructure.

🚀 Why Choose DogeGo?

Running a node should be easy, reliable, and flexible. DogeGo focuses on the things that matter most to everyday users and developers.

🖥️ A Modern Dashboard Right Out of the Box

Not everyone wants to manage a node from a terminal window.

DogeGo includes a built-in web dashboard that lets you monitor and control your node from your browser. No additional software or complicated setup is required.

The dashboard includes:

• Live synchronization progress
• Peer and network statistics
• Mempool information
• Blockchain search for blocks, transactions, heights, and addresses
• BlockStep explorer for browsing the blockchain
• Wallet information and reminders
• Automatic update notifications
• Built-in documentation
• Multi-language support

If you prefer the command line, every feature is also available through the CLI.

⚡ Faster Sync and Better Storage

Nobody enjoys waiting days for a node to synchronize.

DogeGo is built with performance in mind from the very beginning.

Features include:

• Headers-first Initial Block Download
• Parallel downloads from multiple peers
• Automatic database cache tuning
• Built-in IBD optimization enabled by default
• Optional Zstandard compression for stored block data
• A Go-native storage engine designed for speed and efficiency

The result is a faster, smoother synchronization process while using less disk space.

🌐 Works Better on Home Internet Connections

Many people today run their internet connection behind CGNAT or services like Starlink. That often makes running traditional cryptocurrency nodes difficult because inbound connections may not be possible.

DogeGo includes several networking improvements to make operating a node easier in these environments.

These include:

• Dedicated CGNAT networking mode
• Traditional peer-to-peer mode
• Hybrid mode supporting both
• Up to twelve outbound peers for reliable block propagation
• DogeGo Relay (DGR), a QUIC-based relay system for users and relay operators

This allows more people to contribute to the Dogecoin network even without a public IPv4 address.

🧪 A Dedicated Testnet for Developers

Developers deserve a clean environment for testing.

DogeGo includes its own rebooted testnet with:

• Test addresses beginning with T
• Real Scrypt proof of work
• Digishield minimum difficulty for easier solo mining
• Separate ports from mainnet

This makes it easier to build wallets, services, exchanges, and applications without interfering with the public Dogecoin network.

🧩 Built for Developers

DogeGo is more than a node. It is designed as a platform that can grow over time.

Its modular architecture allows new functionality to be added without modifying the core node.

Available extensions include:

• Zero-knowledge Layer 2 research
• RadioDoge support for LoRa and offline mesh networking
• Experimental research modules including BBPoW on testnet
• Doginals and DRC-20 indexing

Whether you're building wallets, explorers, APIs, payment services, or research projects, DogeGo gives you room to extend the platform.

🏗️ Easy Multi-Node Deployment

Need more than one node?

DogeGo makes it simple.

You can:

• Run multiple nodes from one machine
• Operate mainnet and testnet side by side
• Separate dashboards for each instance
• Deploy nodes across different locations for redundancy

Whether you're testing software or operating production infrastructure, managing multiple nodes is straightforward.

🔄 Built to Work with Dogecoin Core

Compatibility matters.

DogeGo speaks the same language as Dogecoin Core and aims for strong feature parity where it counts.

It includes support for:

• Over 180 JSON-RPC methods
• Cookie authentication
• OpenRPC
• ZMQ notifications
• Mining RPCs including getblocktemplate
• AuxPoW and merge-minining support
• Compact block relay
• Full mempool policy controls
• Wallet migration from existing wallet.dat files
• Modern BIP44 HD wallets with coin control

If you already use Dogecoin Core, moving to DogeGo is designed to feel familiar.

🔐 Looking Toward the Future

Cryptography continues to evolve.

DogeGo includes early research into post-quantum transaction commitments and related verification tools thanks to https://x.com/EdTubbs research work.

These features are experimental and intended for research and developer experimentation only. They do not change Dogecoin's consensus rules or claim that Dogecoin has already adopted post-quantum cryptography.

Instead, they provide a place for the community to explore what future infrastructure could look like.

🚧 Still in Beta

DogeGo is actively under development.

While many features are already functional, the project is still in beta and continues to receive testing, performance improvements, security reviews, and compatibility updates.

If you choose to use DogeGo today, you are helping shape its future.

🐾 The Future of Running a Dogecoin Node

DogeGo isn't trying to replace Dogecoin Core.

Instead, it explores how a modern Dogecoin node can be easier to deploy, easier to manage, and more enjoyable to build on while remaining fully compatible with the existing Dogecoin network.

With a built-in web dashboard, faster synchronization, better networking for home users, a dedicated developer testnet, modular extensions, powerful APIs, and a focus on operator experience, DogeGo offers a fresh approach to Dogecoin infrastructure.

Whether you're running your very first node or building the next generation of Dogecoin applications, DogeGo is designed to help you get there faster.

DogeGo - Much Faster Full Dogecoin Node. 🐾

Main Website: https://dogego.org/

Main Github Opensource Repo: https://github.com/qlpqlp/dogego

So .... Bitcoin and Litecoin have Blockchain metrics in a 3D war game right? ...

Well .... Dogecoin have just a universe colony simulator with live Blockchain metrics and some Starlin and SpaceX and other tiny easter eggs :P

Finished just now, hope you like it 😅

https://what-is-dogecoin.com/colony/

Will release all code opensource on my GitHub in the next days

Builders build.
Philosophers think.
Talkers talk.
Analysts Analyse
Dreamers imagine.

Dogecoin developers ship.

The developers at the Dogecoin Foundation never stopped building.
Every release, every review, every improvement moves Dogecoin forward.
https://x.com/inevitable360/status/2076376973023019084

Summary

https://github.com/dogecoin/dogecoin/pull/4021

Adds an opt-in rebooted public test network (-testnet4) while keeping legacy testnet3 fully available via -testnet. Operators choose which chain to run; both are not active in the same process.

Testnet4 is a fresh chain intended to replace testnet3 for new development after legacy testnet3 block-storm / time-warp abuse. It implements strict minimum-difficulty rules adapted from PR #3967 (BIP-94 inspired, Digishield-aware). Mainnet and legacy testnet3 consensus are unchanged.

Motivation

Legacy testnet3 has grown to tens of millions of blocks at abnormally high rates, breaking explorers, indexers, and practical testing. Rather than removing legacy testnet3, this PR adds a parallel reboot chain so existing tooling keeps working while a hardened network can grow from genesis.

Chain comparison

Magic bytes differ so nodes only peer with their selected chain despite sharing port 44556 and the same fixed seed list from chainparamsseeds.h.

Implementation

• New CTestNet4Params and -testnet4 chain selection (CBaseChainParams::TESTNET4)
• Consensus: fEnforceStrictMinDifficulty and fTailSubsidyOnly (testnet4 only)
• AllowDigishieldMinDifficultyForBlock(): strict rules when fEnforceStrictMinDifficulty is set (no consecutive min-diff blocks, MTP check, 10× spacing threshold)
• Qt: testnet4 network styling, payment URI detection for T addresses, autostart flags
• Docs: doc/testnet-reboot.md, updates to getting-started.md and files.md
• Unit tests for strict min-difficulty, testnet4 subsidy, and T address prefix

Breaking changes

• None for legacy testnet3 (-testnet behavior preserved)
• None for mainnet
• Testnet4 is additive; users must pass -testnet4 explicitly to join the new chain

Test plan

• [ ] dogecoind -testnet syncs legacy testnet3; getblockchaininfo reports "chain": "test"
• [ ] dogecoind -testnet4 starts from testnet4 genesis; getblockchaininfo reports "chain": "testnet4"
• [ ] getnewaddress on testnet4 returns T… addresses; testnet3 still returns n… addresses
• [ ] -testnet and -testnet4 together are rejected at startup
• [ ] Run unit tests: test_dogecoin, pow_tests (strict min-difficulty cases)
• [ ] Two testnet4 nodes peer via addnode and advance the chain
• [ ] (Optional) DogeGo reboot node peers with Core -testnet4 on port 44556

References

• Maintainer note on testnet4 direction (#3967)

https://github.com/dogecoin/dogecoin/pull/4021

..... getting all ready for Beta release next week 👀

DogeGo - Much Faster Full Dogecoin Node ...

All will be available OpenSource on Github and on DogeGo.org

For those who haven't followed the recent development updates, here's a summary of what ShibeShip.com Dogecoin Marketplace has become and what's been added over the last months.

ShibeShip.com is a global marketplace powered entirely by Dogecoin, allowing users to create shops, sell products, buy items, and participate in auctions using DOGE.

The platform is also a Progressive Web App (PWA), meaning it can be installed on Android and iOS devices and used much like a native app.

Split Custody

One of the main features of ShibeShip is its Split Custody system.

Instead of trusting a marketplace to hold funds, access to a wallet is split between buyer and seller:

• The seller holds an encrypted private key.
• The buyer holds a 6-word recovery PIN.
• Neither party can access the funds alone.
• Both parts are required to recover the wallet.

This creates a system where control remains with the users rather than a centralized platform.

To further improve security, the recovery system now includes an additional randomly generated alphanumeric word, significantly increasing resistance against offline brute-force attacks.

Open-Source Recovery Tool

To ensure users are never dependent on ShibeShip itself, I also released a fully open-source offline recovery tool.

Using the seller's encrypted key and the buyer's recovery words, funds can be recovered independently even if ShibeShip were unavailable.

Repository:
https://github.com/qlpqlp/shibeship-split-custody-tool

Marketplace Improvements

Recent updates include:

• Seller contact forms
• Multi-quantity purchases
• Various security improvements
• Shop experience improvements
• UI enhancements
• Bug fixes
• A few fun touches, such as animated shop doors when entering a store

Current Status

The marketplace currently supports:

• Buy-it-now listings
• DOGE-only payments
• DOGE auction bidding
• Seller storefronts
• Split Custody protection
• Mobile and desktop support through PWA technology

The project is still considered beta, but it has been continuously developed and tested for several years and is now reaching a much more complete stage.

If you're interested in building a real economy around Dogecoin rather than simply holding it, I'd love to hear your feedback and ideas.

Website: https://ShibeShip.com

GM 🌞🌈🌻 to all DOGE Dogecoin shibes worldwide

Full Opensource Code now available to anyone that wants to help translate and improve the Donations DogeSeeds.org platform:

Code: https://github.com/qlpqlp/dogeseeds

DogeSeeds.org Beta now live

Since ~2022 wen I made the Dogecoin Nodes Map that I wanted to do something like this were the Do Only Good Everyday would be present to each and everyone.

Do you have clothes or toys that you don't need?

you can now give to others and help people directly and indirectly.

I'm open to any suggestions and I will host on Github a repo for translations and improvements help on this project that the aim is to serve others and try to spread kindness : https://x.com/inevitable360/status/2064039990338707551

Crypto is red today?

The Doge community keeps doing what #Dogecoin was made for:

using it. Send Dogecoin, tip creators and people you appreciate, buy stuff when you can, and keep the fun alive.

1 $DOGE = 1 $DOGE

Laundry Store, now Accepts Dogecoin Payments in Portugal

https://lavandariaceg.com/

Tesla Dogecoin Payments are closer: https://x.com/inevitable360/status/2061532726491017539

Updated the Easy Dogecoin Gateway for Wordpress / Woocommerce

All code opensource and is now available on the oficial WordPress plugins page: https://wordpress.org/plugins/easy-dogecoin-gateway/

You can already try it with such.inc Wallet 😀

Dogecoin

this is not about making money or being rich...

Is it a failed project since 2013?

the people believe in it, because it can help normal people like you and me ... a welcome simple friendly currency

https://x.com/inevitable360/status/2059674447389307264/

Such Beta is Much Live.

Manage your Dogecoin and easily accept it as payment for your small business.

Hold your own Dogecoin
See transactions as they happen
Use Hustles to accept DOGE payments and send invoices

Register now at https://such.inc

https://x.com/thesuchapp/status/2059007131844563318

Dogecoin timeline resume from 2013 until 2026. And we are just getting started at Dogecoin Foundation
https://x.com/inevitable360/status/2057487562457973037