Transferring A-EUR without ETH

[szerintedmi]

The issue
By default a user must have ETH to execute an A-EUR transfer to cover the transaction gas cost. We consider this as a high friction for the general A-EUR users. Users should be able to spend A-EURs they received (eg. from other users, services or from an exchange in return for fiat) without jumping through the hoops of buying ETH.

Solution proposal
EIP86 in Ethereum will allow contracts to pay the gas costs and it’s planned in the Constantinople Metropolis hard fork but its release date is uncertain.
As an interim solution we could allow trustless services to send in signed transfer transactions from users. This service will submit the transaction to the network, pay the transfer tx gas costs and it will be compensated by the token contract.
The client would be able to set any maximum compensation she is willing to pay in tokens. The service would request max that amount or less, depending on its strategy.

Questions

1. Gas cost incurs in ETH and the gas price is set by the caller. Ideally we should compensate the Service in ETH as their gas costs are in ETH. But the user doesn't have ETH - that's the whole point of this change - so we could

   • a) compensate for gas costs in ETH from an Augmint account - this could be covered from a higher Augmint transfer fee for these type of transfers. But this way Augmint system would take fx risk (as fee in A-EUR and pay out in ETH).
   • b) cover gas costs from user's A-EUR balance - this way the caller Service takes fx risk but they can have multiple competing strategies offered to clients unlike if Augmint would set a rule.
     Proposing option b) but any better solution?

2. The current thinking is to have specific delegated execution fx-s, e.g. delegatedTransfer

• if that's the case then should be the TxDelegator contract separate and if so then should it be changebale? (see PR Delegated txs #89 for current first pass approach)

1. Could this solution somehow used to incentify other services (e.g. merchants) to accept A-EUR? It would require to be able to reverse the fees, i.e. fees paid by beneficiary

Draft Flow

1. Client signs the hash of the tx with her ETH account’s private key. Tx data: token address, from, to, nonce, minGasPrice, max executor fe in A-EUR)
2. Client sends signed txhash + tx data to transaction submitter service
3. Service validates tx signature and checks if user has enough funds to avoid rejected tx and lost gas cost
4. Service forwards tx to A-EUR contract from its own ETH account, adding the submission reward it requests.
5. A-EUR contract validates signature, nonce, gasPrice and submission reward
6. A-EUR contract increments nonce and transfers A-EUR according to client instructions and sends reward to service
7. Service sends confirmation to client

Implementation draft

new functions on AugmintToken contract:

function delegatedTransfer(
    AugmintTokenInterface augmintToken, address from, address to, uint amount, string narrative,
    uint maxExecutorFee, /* client provided max fee for executing the tx */
    bytes32 nonce, /* random nonce generated by client */
    /* ^^^^ end of signed data ^^^^ */
    bytes signature,
    uint requestedExecutorFee /* the executor can decide to request lower fee */
)

and

function delegatedTransferAndNotify(address from, TokenReceiver target, uint amount, uint data,
    uint maxExecutorFeeInToken, /* client provided max fee for executing the tx */
    bytes32 nonce, /* random nonce generated by client */
     /* ^^^^ end of signed data ^^^^ */
    bytes signature,
    uint requestedExecutorFeeInToken /* the executor can decide to request lower fee */
)

NB:

• Nonce is random generated by client to allow concurrency and offline signing
• Signature consist of sigV, sigR, sigS and destructured with inline assembly
• We don't need chanId as it's in sigV and implicitly in augmintToken's address

Alternative generic implementation (scrapped)

A generic contract (TxDelegator ?) would receive any destination contract and transaction in a generic format, such having arbitrary tx calldata signed and passed as an argument to any contract.

E.g. Lock could be done with much less friction, without ETH. I.e. Buy A-EUR for fiat on an exchange, send lock tx immediately. After release the proceedings could be sent back to exchange without ETH again.

TxDelegator would verify the signature, manage the nonces and forward the call to any contract we wish :

destination.call.value(value)(calldata)

The receiving contract would allow the corresponding function(s) (e.g. delegatedTransfer in case of AugmintToken) to be called only by TxDelegator.

In addition TxDelegator could be able to compensate in any ERC20 tokens by adding an ERC20 token contract address as parameter to the call

Questions:

• how could TxDelegator access the "from" in data passed against signer?
• How executorFee would be deducted and what loopholes would it create?

[phraktle]

Few thoughts on first read:

Terminology: I would call this concept "delegated transfer" (vs OnBehalf).

Question: would you still want to collect the usual A€ token transfer fees?

EIP86: have you considered how the economic model should work once EIP86 is implemented?

Not sure about the parameters...

• minGasPrice - why minimum? when would a higher price be used?
• requestedTransferOnBehalfFee - why request a fee? could we just let the caller keep all remainder from the max fee?
• how would the max fee work with the gasLimit? gasLimit * gasPrice implies an ETH price, but the fee is in AEUR.

You may want to consider a delegated analog of the current transferAndCall function as well.

[szerintedmi]

Terminology: I would call this concept "delegated transfer" (vs OnBehalf).

good call, updating the post. If we go with specific then it's better. For generic (see later) how about delegatedTx ?

Question: would you still want to collect the usual A€ token transfer fees?

My initial thought is yes, collect transfer fees too. These are two separate costs: one is sending in the tx one is Augmint system costs. The fee could be indicated in the same transfer fee field or (TBD) have a new field or just emit events from the delegatedTxVerifier (?) contract.
What you think?

EIP86: have you considered how the economic model should work once EIP86 is implemented?

Not really. First thought (without knowing too much about final EIP86 details): Economics and challenges are the same: someone else must pay the gas cost in ETH but the user only has A-EUR. Technically the service might not be required anymore, that could be taken over by an Augmint contract. The challenge of covering an ever changing ETH costs with A-EUR is still there it's just will need to be solved by the contract. It could just calculate A-EUR cost from published ETH/EUR rates and from current gasPrice. Source of ETH is still a question, i.e. each tx would give more system exposure to ETH/EUR rates.

Not sure about the parameters...

minGasPrice - why minimum? when would a higher price be used?

It would be the service's discretion what gasPrice to actually use. E.g. user sends in tx but gasPrice has increased and/or ETH/A-EUR rate changed . The offered fee still covers the gas cost so it still worth send in with higher gasPrice. If it's a fixed price then the service wouldn't have this flexibility.

requestedTransferOnBehalfFee - why request a fee? could we just let the caller keep all remainder from the max fee?

Same idea as for gasPrice. The service could decide to charge less than the max if gasPrice and/or ETH/EUR rate allows. Or it could be their biz model (e.g. it's a merchant service and they could offer to cover the tx fee). Actually we should consider the calling service being able to cover Augmint fees as well, will put some thinking in it :)

how would the max fee work with the gasLimit? gasLimit * gasPrice implies an ETH price, but the fee is in AEUR.

This is the idea is that the client app and the calling service would calculate the transaction cost in A-EUR on the fly based on actual ETH/EUR and gasPrice. It would be the client's calculation and decision how much are they willing to pay (and what gasPrice they request for that fee). Service then could decide if it worth submitting tx on client's behalf for that fee (and with the minGasPrice)
This complexity could fairly well hidden on the client side (e.g. service could just publish current fee & gasPrice conditions they accept transactions, client side it would be only a single A-EUR amount displayed for approval. obviously this needs more UX thinking but different client and service approaches could co-exist.

You may want to consider a delegated analog of the current transferAndCall function as well.

Agree. this is where it gets complicated (and that's what I meant by generic verifier and delegator).

I'm going to elaborate / iterate on the proposal based on the above and on our discord discussions :)

[szerintedmi]

implemented in PR #89

[elekm]

multiple costs are annoying in the user point of view.
The best would to deduct from users a-eur ballance just in case when system detects that there is no eth ballance for tx fee...
setting gas prices is only for pro users. Try to avoid gas price question to be decided. It should be automatically added (if there is any ballance) or deducted in case the vallet is empty. Extras click for pro users to set gas price is OK.
That was the user point of view...