I am a beginner in ethereum DApp development and I am testing my Contracts in Remix IDE. My question is that can I restrict only one account to pay for all the transactions happening on my application since I don't want my application users to pay for the transaction fees at all as that would require that each user must have some wallet like MetaMask or Mist installed. Is this approach correct and is this possible ? How can I implement this ?

  • Unfortunately, this is currently not possible. – Jesse Busman Dec 27 '17 at 22:42

As Jesse Busman mentioned in comments, this is not yet possible directly in smart contracts. But you can try to register all the transaction costs and addresses (via events) which payed them so you will refund the list of addresses later.

  • Is it then possible in private ethereum blockchain network to ultimately remove the gas price and gas limit so that miners need not be paid? How can this be achieved ? – Ahsan Jamal Dec 29 '17 at 10:13
  • @AhsanJamal yes, in private chain any transaction will be mined because you own the miner and run it to mine every transaction with no difference in transaction fee. – Roman Frolov Dec 29 '17 at 10:20

It is possible using meta-transactions.

The general idea is as follows:

  1. A user signs a transaction. This, itself, does not require gas and, strictly speaking, does not require metamask or any other "wallet". Your app can attend to it, and also issue public/private keypairs and ETH addresses for your users so that, from a user perspective, "it just works."

  2. Since sending the transaction costs gas, someone will have to do it, and that "someone" will indeed pay for gas. But, importantly, the sender doesn't need to be the signer. The user transmits the signed transaction, offchain (e.g. HTTP(s) POST), to someone else, called the "forwarder" or "bouncer" as Austin calls it in the video. The forwarder could be your server or even a public utility that is willing to do it. They send a transaction with that message as data.

  3. The forwarder/bouncer sends the transaction with gas. The receiving contract needs to be crafted to expect meta-transactions - msg.sender is always the forwarder but it will probably be important to dig into the signed payload to discover who signed the original message using ecrecover.

  4. An optional variation of this process is the forwarder could be compensated with tokens or ETH if the signed transaction is to a contract that pays them for their trouble.

In summary, Alice sends a signed message to Bob. Bob relays Alice's signed message (as an argument) in a transaction from Bob, so Bob pays for gas. The receiver is usually a contract, and it unpacks the signed message, verifies Alice's signature and possibly compensates Bob for delivering it.

There are implementation details that would take a whole blog post to unpack. Suffice it to say this isn't an easy pattern to deploy, but it is doable. This video isn't deeply technical but it can give you a sense of what it could look like or help focus your Google-Fu.


Hope it helps.


It is not a good idea to have you paying for all your users.

This open the door to many possible attacks to your money and your contract, as DoS attack, where someone repeatedly and fastly call your contract again and again and, this way, prevents any regular user to access the service and wastes your money in gas.

This is because in Ethereum anyone who transact have to pay for it: it has to pay for what it moves.

Of course you can refund this gas to the user who make a correct transaction: this is up to you.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.