I've been thinking lately how convenient it would be if contracts could accept tokens like DAI for payment of services, but at the moment there doesn't seem to be such a good way. ERC777 seems to improve this as the hooks could be used to trigger some sort of action on the receiving contract end so that the contract is AWARE of the fact it has received a payment. Obviously, it would be nice to be able to pay for things natively in DAI.
Are there any thoughts about creating a standard (maybe an ERC777 operator) to allow for this?
IERC777Recipient allows for, as you’ve mentioned, contracts to react to token transfers. A default operator could also be useful, but since it is the token itself that decides which operators are default, I only see such a thing working for e.g. a crowdsale, or a token’s native system. Regular operators require being authorized, which isn’t too different from being given ERC20 allowance.
Regarding DAI, the ideal scenario would be a migration to ERC777, but I doubt that’ll happen anytime soon. I’m thinking of an interface that requires a setup stage, where allowance is given to the contract, and payments are then processed via transferFrom called from the contract. Ideally we’d do infinite allowance so that this setup was only run once, but we’d have to think through the security implications of that.
For the sake of complicating things unnecessarily:
When you transfer an (ERC20) token there is an event emited. Maybe we could use a network of relayers to watch transfer events, and then for payment, call some function on the receiving contract to register the token.
Oh @Dennison, in the words of Avril Lavigne, why do you have to go and make things so complicated?
In all seriousness, this would require a lot of trust in these external relayers, since events are not accessible inside the EVM. A scheme where you provide proof to a contract that a transaction happenened is possible (by providing all transaction info, the tx hash can be reconstructed by the contract, and an accompanying Merkle proof could be used to verify that a block with hash X was indeed one of the last 256 minted blocks), but this is way hard. It is what libsubmarine uses to penalize people cheating their system though, which I find very interesting.
I think a contract as part of OpenZeppelin for accepting ERC20 as payment (especially stable tokens) would be great.
Whilst new tokens would ideally be developed using a standard that includes approve and call such as ERC777, there are still many existing ERC20 tokens.
