Currency choice dictates the "rate of pay" in Web Monetization

The streaming feel of Web Monetization shouldn’t depend on which currency you hold, but it does at present. If a wallet is locked to two decimal places (assetScale=2), the value of the currency dictates the frequency of the payments.

Compare three users paying the same “real” value per hour:

• At USD $0.60/hour, to send the next $0.01 (and fire a monetiation event), the Web Monetization agent waits 60 seconds ¹. This is a slideshow, not a stream.
• At MXN 10/hour, the monetization event fires every 3.6 seconds, which feels more like a stream.
• At INR ₹50/hour, a monetization event can be fired every 0.72 seconds. Now that’s a stream!

In the MXN scenario, the publisher gets monetization events 16 times more frequently (in the INR scenario, it’s 83 times more frequently). The vibe feels alive: the publisher is getting money, and the user is getting more and more content in return - imagine a video buffering based on these micropayments.

We shouldn’t have to switch to a different currency to get a higher frame rate for our payments. The streaming logic should be independent of the unit.

Under the current assetScale=2 limitation, a smooth payment stream experience is an accidental byproduct of having a weaker currency. This reinforces why a higher assetScale of 3 or 4 is a must - it decouples (somewhat) the frequency of the payment from the value of the currency’s base unit.

Footnotes

1. This is where that 60s comes from:

   $\frac{0.01\mathrm{USD}}{\left(\frac{0.60\mathrm{U}\mathrm{S}\mathrm{D}/\mathrm{h}}{3600\mathrm{s}/\mathrm{h}}\right)}=60\mathrm{s}$

   ↩