New Keyguard handling service fees

Discussion Project Ideas
#1

Lets imagine I run a service: X. And my service is that I transfer funds from one person to another. I act as a proxy by collecting the correct funds from person A and send them to person B. For this service I charge 1% flat fee. So if A send 100 NIM to B, person B would receive 99 NIM and I 1 NIM.

In a centralized construction, service X would provide person A a deposit address. Once received, my service sends 99 NIM to person B and I keep the fee.

The power of the next Keyguard is that you keep control of your own funds and don’t let them get managed by a third party. How will the new Keyguard handle such an use case like this? Will it be flexible enough.

#2

The problem with your example is the service is irrelevant. It’s just a layer on top of what can already be done with the keyguard. Why wouldn’t A send 100 NIM to B, with person B receiving 1 NIM (and maybe A getting charged 100.001 NIM if fees are ever a serious thing) through the keyguard or any other wallet.

I see the power of the next keyguard to be that payments can be made easier, and with messages attached. This allows for centralized accounting and logic on the recipients end to take whatever fees it chooses to once you withdraw your money from the centralized service, among many many other things.

I think being able to have a website (that the user doesn’t have to necessarily trust or care to trust) request the user do most actions with the key that could be done if that website had the key itself, and then having the user approve the action (choosing whether to trust the website at the time of the request based on the amount, message, website, etc) will provide developers the chance to do some impressive things.

1 Like
#3

The Keyguard is just a kind of API that lets you sign transactions on third party pages without them learning your private key.
It cannot enforce fees for other services, just like nobody could enforce these fees if you sign a transaction from A to B manually.

Of course, if X is a centralised service, for sure it can simply take its fee while the payment is routed through the service.
In a decentralised service, that’s not so easy (and not an issue of the Keyguard :wink: ).

If we added multiple recipient support for transactions in Nimiq, paying a fee to X and sending funds to B could be made more convenient, as the user would need to sign a single transaction.
It could always be circumvented manually though.

1 Like
#4

Multiple recipient support sounds really cool! I was actually curious about whether we could see Batched Transactions in some way in the future (each tx itself would still be a standard single recipient tx, but each with it’s own value and message)? I didn’t want to bring it up yet as personally I want the basic tx + signature version of the Keyguard ASAP (absolutely so excited for what even the first form will do for the ecosystem), but I think if we could send a batch of TXs for the user to review and approve / reject as a whole* a lot could be done with Nimiq. Far more than just requesting the user send 2 txs so a fee can be taken in a somewhat decentralized way, I think the potential for advanced centralized logic (but all initiated/related to on chain txs that the user fully controls) in applications would be possible.

* - If one wants to send a batch of txs with the user approving / rejecting certain ones, I would expect that dev to use the standard request process on tx at a time, I see Batched Txs more for something where the multiple txs must be sent or none get sent as logic on the requester’s side depends on the multiple txs.

Even something as simple as (just an example) Nimiq Webtip allowing the website to specify multiple addresses and percentages for each developer of the site, and you clicking the “Tip” button in Nimiq Webtip requesting you approve the batch of txs (maybe you Tip 5 NIM which get’s split into 3 txs of 2 ⬣, 2.5 ⬣, and 0.5 ⬣ to the 3 devs). This example is also perfect to show why batched txs would need to be approved / rejected as a whole batch, and not treated as a group of txs grouped for UX convenience but accepted/rejected on a per tx basis. It’d be important that the batch be treated as needing only one approval / rejection as you wouldn’t want the user only approving a donation to 2 of the 3 devs that the site has in it’s JSON file, etc…

image
An example of what I’m talking about. The ? would be clicked on to see what the data of the TX is (since I assume 90% of the time [at least early on in our ecosystem’s lifetime] you’ll only care to check that your money isn’t being stolen by an extra Tx in the batch rather than whether the data being sent is accurate), and the Amount would probably need to be in both ⬣ and ☾ or use decimal places but I just threw this picture together in paint, and didn’t put a ton of thought into the UI needed.

1 Like
#5

Ideally, it is not only a UI thing, but also an actual transaction type on the blockchain.
That can then be used to ensure that either all of the individual parts are executed or none.

I didn’t want to bring it up yet as personally I want the basic tx + signature version of the Keyguard ASAP

Indeed, this would certainly not be part of the initial version of the Keyguard.

1 Like