URI - ZIP321 add an amount param in other currencies

Currently URI zip321 only support specifying amount in ZEC. Can we please add 2 extra params to allow supporting different currencies? Open to different naming…

Example
currencyparam=USD
currencyamountparam=10

If the wallet supports currency it would calculate the amount of ZEC using the current exchange rate. If the wallet doesn’t support currencies but “amountparam” is set it would use that as the backup default. Otherwise if it doesn’t support currencies and doesn’t contain the amountparam it wouldn’t default to anything.

I can’t imagine I’m the only one who wants this. Maybe it’s already a feature in some wallets @hanh @NighthawkWallet?

Edit: this would useful for printed QR codes that need to adjust the ZEC amount via exchange rates.

Edit 2: Basically I’m just after a way to auto populate the currency amount which is already available in many wallets.

While we are at it we may as well also include param to default to (or at least ask the wallet to prompt the user) to “include my address in memo”. Open to other names…

myaddressmemoparam=true
1 Like

It could be confusing for the receiver because the tx is in ZEC. The same code will have a variable amount.

That’s the idea.

Use-case
I want to put a printed QR code on the snack/drink fridge at work. Snacks/drinks cost $1 AUD. Currently there is a coin box near the fridge that people put their coins in. All honesty based. I want to add the option to pay for snacks in ZEC without having to put a screen next to the fridge which is not viable in this case.

@hanh thoughts?

If it’s honesty-based, it seems to be a niche use case and they could use an average ZEC value. I suppose they aren’t monitoring payments anyway.

In the regular case, having two prices is a bit confusing. The payee asks for 1 AUD and receives 0.2 ZEC. Is it enough? To determine that, it needs to have the fx rate. Then why not give the price in ZEC in the first place unless it doesn’t have a screen? But if it has the ability to recognize incoming blockchain payments, shouldn’t it include a screen too?

1 Like

In my example above you wouldn’t have 2 prices. Only 1. $1 AUD which would be converted to ZEC within the wallet.

You’d need to include the price in ZEC for legacy wallets that do not support your feature yet.

Even if there was only one price in AUD, my point is that the receiver should be the one who decides the acceptable rate since he’s providing the service/goods.

Or just default to 0 and make the user enter the amount of ZEC?

Even if there was only one price in AUD, my point is that the receiver should be the one who decides the acceptable rate since he’s providing the service/goods.

While true for a honesty system that takes about $2 to $10 a day the cost of deciding the price in ZEC is more then it’s worth. They’d be happy to take any lost cents by providing a service to those they may not have otherwise purchased those goods.


The other example for this is an unmanned roadside pumpkin stall. A driver pulls over and doesn’t have cash but has a Zcash wallet. Pumpkins are $2 AUD. Most people only buy 1 pumpkin so default to $2. They stuck the QR code on the stall a year ago and haven’t had to replace it.

I’m not talking about the honesty system for which a QR code with a fixed price in ZEC works fine IMO.

For other use cases, I think the payee will want to set the price himself.

Isn’t that the same use case? The pumpkin stall does not have an internet connection, therefore it cannot check whether any payment was made. It’s a honesty system too.

2 Likes

Of course. For other use-cases you wouldn’t use this currency parameter. This is only really useful in cases when you want a static QR code.

Fixed price in ZEC? Are you suggesting someone has to change the QR code daily to reflect the new exchange rate?

I mean if they are ok with people “forgetting” to pay, they would be ok with a fixed exchange rate.
Keep it at 1 ZEC = 90 AUD for example.

In a group of people that trust each other to be ethical wouldn’t the payee actually prefer to charge the user at a close to accurate representation of the exchange rate even if it is decide on the payer’s wallet?

When the exchange rate is set by the payer’s wallet an ethical person will always pay and always use the correct exchange rate. When the price in ZEC is fixed an ethical person may sometimes decide on the method of payment based on which is cheaper. So when the ZEC price of the item is fixed in ZEC isn’t the payee worse off? Especially when the exchange rates can swing 20% in a week and there is a chance the QR code won’t be changed in that time frame.

Let me put it another way. I’m going to put a Zcash QR code on the snack/drinks fridge with no amount set and allow the user to type in 1AUD manually. I just thought this would be a really obvious and straight forward way to prevent the user from having to type it in manually.

So if I understand you correctly, you would like to have the QR code suggest a fiat currency & price while letting the payer choose the fx rate?
And the use case is “the payee trusts the payer to do the right thing and would like to make it easier for the payer to pick the right values”.

If yes, it makes sense but in my opinion, the use case is too rare to make it into a standard feature.

Fair enough. Thanks for your help :heart:.