The Lucky Contract — ERC-777
The ERC-777 token contract promises to extend the functionality of the ERC token legacy even more…
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
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.
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 regular
operator 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.
git clone email@example.com:jbaylina/ERC820.git && npm i
cd ERC820 && truffle test
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.
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.
git clone firstname.lastname@example.org:jacquesd/ERC777.git && npm i
cd ERC777 && truffle test