2

I'm developing a "corporate" DApp, therefore the employees don't have any reason to "spend" their ether/gas for interacting with the contract...

Is there any way to enable each transaction to be auto-paid by the contract itself? If not how would you address this problem? I cannot pass ETH to employees, because they might "spend it", and, at the same time, why would they use their own ETH?

Thank you all for any suggestion.

Cheers

3
  • 1
    Let the Dapp pay for it (using a dedicated Ethereum account), and restrict the usage of the Dapp only to employees. – goodvibration Oct 12 '20 at 8:15
  • Thank you for the suggestion, I am keen to understand more about the logic.... how do I achieve what you suggest? will the employees share the same wallet address embedded into the DApp? mmm I am a bit confused... – FiNaR Oct 12 '20 at 9:18
  • 2
    Your dapp will have to restrict access using purely offchain (non-Ethereum) measures. Once a user is granted access (for example, based on username/password login), he or she can perform the desired action on the dapp. The dapp will then execute the corresponding transaction, using a dedicated account which the dapp has access to (i.e., has the private key of). You should preload that account with a sufficient amount of Ether, and perhaps reload it every once in a while. – goodvibration Oct 12 '20 at 9:25
1

At the moment, Ethereum does not support models where the transactions would be paid by someone else.

Some smart contract based wallets like Pillar and Argent has built complex infrastructure to address this problem. The wallet itself is a smart contract that can do the action that user has signed with his or her key. However the transaction ETH gas cost is covered from the hot wallet of the service provider. The provider than bills the user based to the consumed ETH by dollar/other token.

So you can create very complex logic to dance around this limitation. But it sounds like your user case is relatively straightforward and more of an issue of not trusting the organisation employees. I would assume you can retoactively fire the emplyoees who lose their ETH.

3
  • thank you for your suggestion.... I like the idea of having a "hot wallet".... this is not just because "I dont trust employees", but also because some "user of the DApp" will not be my employee , but just external parties.... therefore : 1) they do not have any interest on spending their Ether/Gas 2) I dont have any agreement/contract that if I pre-charge their wallet, they wll not spend for something else... my I know more details on how to design a "hot wallet"? please – FiNaR Oct 12 '20 at 10:04
  • Take an open-source wallet like Pillar and study it how they have done it. – Mikko Ohtamaa Oct 12 '20 at 10:10
  • Another smart contract wallet you could study is Gnosis Safe. – Mikko Ohtamaa Oct 12 '20 at 10:12
0

You could implement some kind of meta-transaction system. Instead of signing directly a transaction, the employees sign a message containing the input parameters of the smart contract method, let's say inputA, inputB, and inputC.

Basis

  • In the frontend ask the user for the inputs.

  • Hash the inputs plus a random parameter : web3.utils.soliditySha3(inputA, inputB, inputC, random);. The random parameter prevents hash collisions if the same user signs twice the same data.

  • Ask the user to sign the hash with them private key.

  • You receive the signature, the user inputs, and the random parameter in your backend and inject them in the contract by signing the transaction with the application private key. The prototype of your solidity function should be something like this :

    function myFunction(uint256 inputA, address inputB, uint256 inputC, uint256 random, address userAddress, bytes32 r, 
    bytes32 s, uint8 v) public;
    
  • Inside the function, hash the parameters and verify the user signature :

    bytes32 hash = keccak256(abi.encodePacked(inputA, inputB, inputC, random));
    require(ecrecover(hash, v, r, s) == userAddress);
    

Requirements to implement such logic

This kind of system has some requirements :

  • That's the application which signs and sends the transaction in the backend on behalf of the user so you need to create an admin account and manage yourself the private key.
  • You pay for the transactions so you need sufficient Ethers to cover the fees.
  • You have to implement some kind of nonce management system to handle multiple concurrent requests.

Further remarks

Note that this system is poorly decentralized as the user does not sign directly the transaction. However, in the worst case, the application could only decide to not broadcast the transaction. There is no way to execute a malicious transaction as all input parameters are pre-signed by the user.

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.