2

We are processing user payments with require_recipient code. Someone does eosio.token transfer, passes parameters with memo and gets his token. But since user uses standard eosio.token transfer he can only see its ricardian contract (in Scatter or other popular wallets).

  1. Anyone has any ideas how to show user our ricardian contract (in Scatter for example) in our case?
  2. Where should you even put your ricardian contract for procedures which are called as a result of require_recipient. Right now these procedures are not even part of the abi (and adding them will introduce new security vulnerabilities)
2

UPDATE: The authorization for the system contract to do transfers in behalf of the users through inline actions is automatic because it is configured as a privileged account in the blockchain. For normal contracts to be able to send inline actions to other contracts, you would need the user to specify the eosio.code permission for that contract, thus giving explicit authorization for that contract to do a transfer for them, and allowing them to view and sign the specific terms of your contract and its ricardian text, so this might be what you are looking for. More info here: https://github.com/EOSIO/eos/issues/3847#issuecomment-394805728


I personally think that reacting to require_recipient should be used more for each user automating actions related to their own account in response to certain actions related to it, but not for providing functionality to the users of your smart contract.

For what you want to do I would recommend making a contract with which users will interact directly, sending a transaction to the specific action of your contract, so they can read the ricardian contract that is specific to that action. Then you can use the permission given by the user in the transaction itself to issue the eosio.token::transfer action from your own contract code. You can use SEND_INLINE_ACTION for this purpose, and you can see an example of it happening in the system contract's bidname action: https://github.com/EOSIO/eos/blob/master/contracts/eosio.system/eosio.system.cpp#L107

Here, the user accepts the terms of the bidname action, which include an automated transfer of funds triggered by that inline action call.

This approach is actually more secure, since if a user issues a regular transfer to the contract account, but the contract's code is updated before the transfer gets processed by the network, and the update changes the behavior of the contract upon receiving a transfer (maybe the contract doesn't react to transfers at all anymore) then the user's transaction will still go through and the funds will be transferred with no side-effect or a different one than the user expected. The smart contract's account has no "legal" obligation to do anything in response to the transfer, since no agreement was made between the two parties, so the user has to trust that the code will be there to respond in a certain way to their transfer.

On the other hand, if instead the user signs a transaction agains a specific action of a contract, they are signing those contractual terms specifically, and the contract's account has explicit obligation of abiding to those terms. Also if the contract's code was updated just before the user's transfer is processed, the transaction would fail since the signature would be valid for a previous version of the contract, not the current one.

This and other reasons are why the Block.one team has decided to implemented these important things using inline transactions all around the core functionalities of EOSIO, like when buying/selling RAM, staking and delegating bandwidth, and much more: https://github.com/EOSIO/eos/blob/master/contracts/eosio.system/delegate_bandwidth.cpp

  • This actually was our first implementation. But we found out that ppl are suspicious of contracts which do transfers inline. I really hope that our small focus group was wrong and in time users will get used to the "pattern" from your answer. But for now we went with Require_recipient aproach. If it proves to be non-viable we'll revert to the one you recommended. Thank you! – opcheese Jul 23 '18 at 21:20
  • @opcheese I'm sorry to say that if your focus group was suspicious of contracts that send inline transfer actions, then they won't be able to use EOSIO at all! lol I updated my answer to explain further. If you find it useful please mark the answer as accepted so it can help others as well. – Andres Berrios Jul 24 '18 at 14:44
  • Your answer is definitely useful. This far I know 4 different ways (patterns) of implementing payment but I am still not 100% sure which one is the best for our situation. For now, I really hope to find some answers regarding RC for our pattern. If no better answer becomes available I'll mark yours as a correct one. – opcheese Jul 25 '18 at 15:30

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.