The Lucky Contract — ERC-777
The ERC-777 token contract promises to extend the functionality of the ERC token legacy even more…
Background
The ERC-777 token comes from the original EIP(Ethereum Improvement Proposal) — https://eips.ethereum.org/EIPS/eip-777 written by Jacques Dafflon, Jordi Baylina, and Thomas Shababi. The 777 in the name really don’t mean anything other than that was the current index of the github issues at the time. You can’t deny, though, it is a number that has gambling prone developers everywhere turning their heads. The original impetus of this proposal was to provide transactions with substantially less friction than the current ERC-20 spec. If you have worked in the space long enough, you know that transactions between individuals who maintain their own keys and wallets are easy. You also know that once you deviate from this simple use case, things get exponentially harder.
How ERC-777 will stop the hurting
Here are some common things that I have experienced when working with Ethereum and how the ERC-777 spec can help.
Third-Party Spending — operators
ERC-20
In a classic ERC-20 scenario, if I wanted to approve a third-party account or smart contract to spend tokens from my account I would need two transactions to execute a single transfer. I would need to call the approve method to approve the spender and amount they are authorized to spend AND the smart contract or address would need to execute the transaction. The issue isn’t so much that I have to approve the account, but more that I have to give it a spending limit and make sure that it is always sufficient for my transactions.
ERC-777
The ERC-777 spec hopes to solve the third party spending issue by introducing the concept of operators . Operators are a well known concept in services architecture as they are accounts that are given specific permission to perform specific tasks. In the case of an ERC-777 token, the operators come in two types — a regularoperator and a default operator . A regular operatoris an address which is allowed to send and burn tokens on behalf of another address. A default operator is an address that is allowed to send and burn tokens on behalf of all the token holders.
Gas Spending Solution
A common issue when working with wallets on an exchange or dApps is paying for the gas for a transaction. A user doesn’t want or necessarily care which block their transaction comes in on as long as it’s reasonably fast. Using an `operator` could allow you as a dApp or exchange owner to manage the gas costs to preserve the user experience rather than relying on the customer.
Ownership vs. Spending
One of the great things about the ERC20 spec is that so many tokens are compatible with it. This gives it a great ecosystem for development and user adoption. When you have an ethereum wallet, however, each address constitutes an account with a unique public/private key and if you have thousands of users on an exchange, how can you provide settlement when you don’t have the private key of that user’s funds? An operator would be a good use case for this as it doesn’t really constitute ownership but will allow you to transfer funds for the settlement of trades. It should be noted that an address may add/remove an operator at any time — so this is a tricky thing so remember…
Where the Magic happens — The ERC-820 Contract
The use of the operator is ultimately enabled by another contract, the ERC-820. This contract acts as a universal and ownerless registry where any account/address can check to see if the destination that they are attempting to send their tokens to can receive/manage those types of tokens. This seems to be an evolution of the ERC-223 spec, which is meant to help prevent users from sending tokens to an incompatible smart contract. Under a normal ERC-20 use case, the sender would have to send an approve transaction before they could send any of their PokerCointokens to the SureThing smart contract. In this case, the PokerCoin token(ERC-777) developers can simply register their token with a gaming industry PokerRegistry contract(ERC-820) and state that it is compatible with the PokerCoin contract(Betting Smart Contract). Any attempts to send PokerCoin to another contract that has not registered with the ERC-820 contract will fail.
The eip is here if you would like to read in detail and an example with tests by the eip author is here! Run the tests as follows
git clone git@github.com:jbaylina/ERC820.git && npm i
cd ERC820 && truffle testHooks
Another promise of the ERC-777 spec is that of hooks . They remain a little mysterious to me, but essentially they will allow the developer to implement blocks of code to be executed pre/post transaction to do things like send notifications through an event, require additional input, block addresses, or other process related items.
Summary
The combination of an operator and the ERC-820 means that we know where we are allowed to send our tokens and who we have delegated to spend our tokens. As a user of our imaginary poker dApp, I feel secure that I have set the contract address of PokerCoin as my operator and the only destination I am allowed to send these tokens to is the PokerCoin contract per the developer’s registration on the PokerRegistry ERC-820 smart contract.
The full eip is here and an implementing example project is here. Take a look at the tests and run them by running the following.
git clone git@github.com:jacquesd/ERC777.git && npm i
cd ERC777 && truffle test
