Is DigiDollar's $1 minimum output intentional and permanent? (agent / machine payments)

[eps8sap]

Also raised in the oracle Gitter — posting here for a durable answer, and because I filed a related RPC issue at #424.

Building an agent-payments integration on DigiDollar, I ran into these in src/consensus/digidollar.h:

CAmount minMintAmount = 10000; // $100 minimum mint
CAmount minOutputAmount = 100; // $1 minimum output

minOutputAmount is enforced in consensus validation (digidollar/validation.cpp:826), so a sub-$1 DD output is invalid to the network, not merely refused by the wallet.

Why I'm asking

The emerging AI-agent payment standards (x402, AP2) settle fractions of a cent per API call, and today that's almost all USDC-on-Base — an asset with an issuer-level blacklist, on an L2 with a single sequencer. DigiDollar is the obvious decentralized alternative: collateral-backed, no freeze function, PoW settlement. But the $1 floor rules out per-call metering.

I've routed sub-dollar cases to raw DGB in my tools (no floor there), but that loses the stable pricing that makes DD attractive for machine payments in the first place.

The question

1. Is the $1 output floor dust / UTXO-bloat protection, or does it serve the collateral accounting in a way I'm not seeing?
2. I notice minMintAmountActivationHeight exists, which suggests these params were designed to be adjustable at a block height. Is there appetite to revisit the floor later?
3. Or is DigiDollar deliberately scoped to ≥$1 settlement, with DGB carrying the micro tier?

Any of these is a fine answer — I mainly want to document it accurately in the tools I'm publishing rather than guess.

Context: https://github.com/dgb-tools (testnet only)

[Shen]

In my opinion you are on the right way. There are two separate limits:

• minMintAmount = 10000 means a new vault must mint at least $100.
• minOutputAmount = 100 means every newly created DigiDollar token output must contain at least $1.

The important distinction is that only minMintAmount has an activation-height mechanism. minMintAmountActivationHeight switches the mint floor from one cent to the configured $100 minimum at the designated height.
minOutputAmount has no corresponding activation-height field. ValidateOutputAmount() applies it unconditionally to DD token outputs, and transfer validation rejects any output below it. Therefore it is not currently a configurable policy or wallet preference—it is a consensus rule.
The apparent design rationale is indeed spam/dust and UTXO-set protection. DigiDollar token outputs are zero-DGB Taproot outputs carrying value in the DD accounting layer, so the normal DGB dust economics do not naturally express their economic value. The design documentation explicitly discusses minimum DD outputs as protection against creating large numbers of tiny stablecoin UTXOs and uses $1 as the higher anti-spam option.

So the accurate current framing is:

• DGB: native microtransactions and sub-dollar payments.
• DigiDollar: native on-chain stable-value settlement with outputs of at least $1.
• DigiDollar below $1: possible only through application-layer aggregation or prepaid balances, not as an individual on-chain DD output.

For example, an AI service could accept a $10 DD deposit and decrement an internal balance by a few cents per API call, periodically settling on-chain. But a fresh $0.03 DD output for every HTTP request is invalid under current consensus.
One additional integration detail: checking that an invoice is at least $1 is necessary, but not always sufficient. DD change must also be either zero or at least $1. If a wallet spends a $1.50 DD UTXO to pay a $1 invoice, it cannot create a $0.50 change output. The wallet’s coin selection therefore needs an exact-payment combination or at least $1 of valid change.
Could the floor be changed later? Technically yes, but not by simply changing a runtime setting. Because it is a consensus rule without its own activation-height gate, reducing it would require a coordinated consensus upgrade and explicit activation logic so old and new nodes do not disagree about block validity.

In my opinion for documentation today, treating DD as ≥ $1 on-chain settlement and DGB as the micro-payment tier is currently the correct statement.

[eps8sap]

Thank you — this is exactly the clarity I was hoping for. The distinction that minOutputAmount has no activation-height gate (and is therefore consensus-permanent short of a coordinated upgrade) settles how integrators should plan.

The change-output rule is the detail I hadn't fully appreciated: zero-or-≥$1 change means coin selection needs an exact-payment combination or ≥$1 of valid change — every wallet and integration will hit this, so I'll make it prominent in the integration docs I offered in #426.

And your closing framing matches what we've built: DGB for micro, DD for ≥$1 settlement, sub-dollar DD handled as application-layer balances settled periodically on-chain. I'll treat that as the documented guidance going forward.