senddigidollar: integer-vs-decimal amount ambiguity is a 100× footgun

[eps8sap]

Raised this in the oracle Gitter as well — filing here so it's durable and trackable.

While building a third-party integration against the DigiDollar RPCs (an MCP server that lets an AI agent pay in DD), I hit an amount-handling hazard in senddigidollar that I think is worth addressing before mainnet activation.

The behavior

senddigidollar interprets an integer as cents but a decimal as dollars:

senddigidollar 10000 → $100.00
senddigidollar 10000.00 → $10,000.00

Two values that look nearly identical differ by 100×. It is documented in the help text, but it's the kind of thing a wrapper, a JSON serializer, or a port of existing sendtoaddress code can get wrong silently — a JSON encoder that renders 10000.0 as 10000 (or vice-versa) flips the meaning without anyone touching the number.

On testnet that's a harmless bug. After mainnet activation it's a 100× overpayment of a collateral-backed asset.

Suggested mitigations (any one would help)

1. Reject ambiguity: refuse decimal input and require integer cents, or
2. Separate RPCs: senddigidollarcents (integer) and senddigidollarusd (decimal), or
3. Explicit unit parameter: senddigidollar <addr> <amount> <unit: "cents"|"usd">, or
4. At minimum, a prominent warning in the help text and integration docs.

Secondary note on the same RPC

senddigidollar returns an object ({txid, to_address, amount, status, fee_paid, ...}) whereas sendtoaddress returns a bare txid string. Not wrong, but it silently breaks anyone porting DGB code — my confirmation check failed until I traced it. Worth a doc note.

Context

Found while building https://github.com/dgb-tools/dgb-digidollar-mcp (testnet only, v9.26.4). Happy to submit a PR if there's a preferred approach.