Single Receiver mode

[ligi]

Our current trade-off is to make it as easy as possible for the user (single wallet interaction) - with the drawback it is more hassle fr the operator as we have one address per order. Especially when wanting to accept DAI you end up with 2 wallet touchpoints.
But other events that e.g. use the plugin from the market after #158 might want to choose a different trade-off.
As you have 2 touchpoints when doing single receiver mode I would select 1. sign text or typed data 2. transaction on chain
Maybe only for DAI transfers. I would prefer not to walk the token approval route. With ETH you can just add it to the tx-data. Still to be considered in this scenario: refunds

[rahul-kothari]

Upon discussion, the main trade-off, pros/cons are:

• Users will only be able to pay with checkout.web3modal.com (we have no way to otherwise ensure users sign a tx)
• We need to update checkout.web3modal.com to notify the user to sign the tx
• Vendors don't need to spend time consolidating all the orders as now all orders come to the same wallet.

We will also keep the original option and let the vendor admin decide!

[ligi]

Was reflecting on this a bit more:

From the operator side this would be the preferred mode as the whole complication of managing and consolidating multiple keys would vanish.
The only downside we saw is that it limits the payment options ( as @rahul-kothari wrote: Users will only be able to pay with checkout.web3modal.com (we have no way to otherwise ensure users sign a tx) and we have the extra step of singing a message.
Maybe we can mitigate this by doing it "optimistically" and only let a subset of users sign a message where this subset could be 0.
The plugin would then first get the users address in the flow (easy with web3modal) and then write it in the database to correlate this address with the order - then expect a payment from this address.
This could be attacked though. E.g. by someone knowing that someone else will buy a ticket with a certain address. The idea with the optimistic approach is that we mitigate this by only letting users sign in case of an attack. And maybe by having this in place no one would attack in the first place so no one has to have this ugly UX of 2 wallet interactions.
And the limited payment options we might also be able to mitigate - e.g. uniswap could be done by monitoring the contract and then proving with the source address for the swap. With exchanges maybe we can ask them to send a certain amount to prove the address. But maybe it is also a feature to not allow use-cases where users do not control the key.

[ligi]

Another option could be that we use eth_signTransaction and use the tx signature as a signature that the user owns the address. For this it is important we get the trransaction before the mempool does. Also there are problems with replacement-transactions.

[mikulas-mrva]

@ligi just making a note of something we discussed on an earlier call -- we could use the signed transaction as a proof of wallet ownership even if the transaction gets cancelled later on?

The outstanding question is how to pair multiple tickets arriving from a single wallet in case some of the payments are cancelled or sped up and the nonces of arriving transactions don't match the nonces of the signed trannsaction that the backend stores?