First agent-payments integration on DigiDollar (testnet) — MCP + x402

[eps8sap]

First agent-payments integration on DigiDollar (testnet) — MCP + x402

The DigiDollar whitepaper and the v5.0 implementation spec live in these discussions, so this is where the people building the protocol already are. I've been building a small open-source toolset that lets AI agents pay and query on DigiByte, all on testnet26, and wanted to put it in front of you.

Full write-up with the story behind it: https://medium.com/@sapidseoblog/i-asked-claude-about-digibytes-digidollar-supply-ed064140a29f

What works end-to-end right now

• An MCP server that lets an AI agent pay in DigiDollar (senddigidollar), USD-denominated, with spend caps enforced outside the model and DD-address validation. The agent never holds keys — allowance, not custody.
• A merchant library (HTTP 402 → verify against your own node → deliver). Full loop proven: an agent paid $1.00 in DigiDollar to a service and got the content; an unpaid claim was refused. On-chain receipt: testnet26 tx 5530f782aca62cbb840c64b820a72076cfa72be6df892d9580541bda8937946a.
• A read-only chain-data MCP so an agent can answer "what's the DigiDollar supply / oracle status / price" from the live chain instead of stale training data.
• A testnet faucet so nobody has to ask around for coins.

All under https://github.com/dgb-tools — MIT, testnet-only.

Two findings I filed while building

Cross-linking for visibility:

• senddigidollar: integer-vs-decimal amount ambiguity is a 100× footgun #424 — senddigidollar reads an integer as cents but a decimal as dollars (10000 = $100, 10000.00 = $10,000). A 100× ambiguity worth hardening before mainnet.
• Is DigiDollar's $1 minimum output intentional and permanent? (agent / machine payments) #425 (discussion) — is the $1 minOutputAmount floor intentional/permanent? It's a consensus rule, so sub-$1 DD outputs are invalid network-wide — which rules out the sub-cent per-call pricing the agent-payment standards (x402/AP2) are built around. I've routed those to raw DGB, but wanted to understand the intent.

Where I'd love help

The merchant side — if you know the DD transaction internals, come poke holes in it.

I'm an oracle operator (slot 29), not a core dev — so if any of this overlaps with work already underway, point me at it and I'll get out of the way.

[JaredTate]

Thank you for taking the time to work on this! This could be very helpful for DigiDollar ecosystem growth. Let me take a deeper dive.

[eps8sap]

Its the least I can do. Thank you for your dedication and persistence!

[eps8sap]

Following up with the rest of the notes from the same integration pass (all against v9.26.4 on testnet26, all reproducible — happy to file any of these as issues instead if that's more useful):

importdigidollaraddress exists but is disabled.
It appears in help, but calling it returns success: false with "DigiDollar watch-only import is explicitly unsupported in this build; no wallet state was changed." Integrators find it in help, build around it, then discover it's stubbed. Suggestion: either drop it from help until supported, or note the status + intended timeline in the help text itself. (Related: addr() descriptors and getaddressinfo reject TD addresses outright, so there's currently no wallet-level watch-only path for DD at all — knowing whether that's permanent or pending would help several designs.)

The TD address encoding is undocumented (and I'd like to help fix that).
Building non-wallet tooling, I needed the TD codec and reverse-engineered it from on-chain data: testnet TD addresses are base58check with a 2-byte version prefix (0xb129) over the 32-byte taproot x-only pubkey, standard double-SHA256 checksum — i.e., a re-encoding of the same witness program that getrawtransaction renders as a dgbt1p… bech32m address in the vout. That vout-renders-as-taproot behavior is itself a confusion point for explorer and wallet integrators ("where did my TD address go?"). Offer: I'm happy to contribute a short docs PR specifying the DD address encoding (testnet + mainnet version bytes from chainparams, the vout rendering behavior, and the OP_RETURN 0x4444 amounts record) so the next integrator doesn't need to reverse-engineer it.

senddigidollar returns an object; sendtoaddress returns a bare txid string.
The object is richer and honestly better — but code that wraps both DGB and DD sends uniformly will break on the shape difference. Worth one prominent line in the docs; integrators coming from Bitcoin-family conventions will assume string.

validateddaddress requires a wallet context.
Calling it without -rpcwallet returns error -19 ("wallet file not specified") even though address validation is conceptually node-level — validateaddress doesn't need a wallet. Minor, but it surprises anyone building thin validation services.

None of this is criticism — the DD RPC surface is more complete than I expected to find (the dedicated UTXO/balance/position calls made the payment tooling straightforward, and the separate DD address type makes asset confusion structurally impossible, which is a genuinely good design choice). Just the notes from a first serious integration pass, offered while things are still easy to adjust.

Michael Emery
Oracle slot 29 · github.com/dgb-tools · testnet faucet: 154.12.247.176:8080