Hard day at the office — what happened with TRYBE?
Blockchain is a really interesting space, there is no hiding. That’s the point right? So what do you do when you mess something up? Usually you make the traces go away behind your walled garden. Teams of IT professionals and customer service portals make right the wrongs, the person on the phone is happy, and the whole world is none the wiser.
When you mess up on Blockchain everyone gets the opportunity to see what went wrong. They can chose to point and laugh, or they can learn from someone else’s misfortune and make the whole system stronger.
Before I get philosophical about EOS, what actually went wrong?
What happened?
TRYBE provided a unique scheme where users could sign up on their site prior the TRYBE token being deployed. Once the token was deployed the public could Airgrab the token. TRYBE honoured tokens on their site, and provided a bonus for signing up pre-token and airgrabbing as well.
Because users could provide any name they wished they weren’t always valid.
- Lesson learned: When possible for off-chain sites… determine a method of linking true EOS accounts to off-chain identities. If this isn’t possible for some reason, perhaps the user inconvenience is considered too high, exercise higher caution when validating EOS names.
The airdropping utility uses eosjs, the first and most commonly used javascript library for interacting with the EOS blockchain, which was provided by BlockONE. During initial testing 6 weeks ago on a prior airdrop a key configuration flag of broadcast: false was confirmed to prevent transactions from sending.
During testing of the names provided this flag was kept in broadcast: false however somehow, the transactions had apparently been broadcast after all.
UPDATE: It appears that in the current version of eosjs
eos.transaction(...actions)ignores certain configuration settings.
To absolutely force this you need to useeos.transaction(...actions,config)
- Lesson learned: Don’t trust packages to not change or always work the same way when you upgrade them. Even if you are confident the code works, perform local tests to ensure it.
When the erroneous transfers of tokens was identified the process was halted and solutions were evaluated.
How was it resolved?
- Freeze transfers of the token to prevent invalid dropped quantities from moving and becoming unmanageable. This was done rapidly by adding an
eosio_assert(false,"no transfers allowed")to the transfers action. The code was compiled and deployed. - With tokens frozen extra care could be taken. Transfer was futher modified to allow only the airdropper to transfer tokens, and to add an
airdropfixaction that would allow the dropped funds to be returned without changing overall supply. This decision was considered acceptable because up until this point all tokens were advance gifts to close supporters. This would also expose the reversal transactions publicly instead of hiding them (which was an available option). Transparency was always considered the upmost importance in the response. - A snapshot was taken of all participants before and after token values from the drop. Because the time from invalid drop to detection was short, and only affected approximately 120 of the nearly 10,000 accounts that would be dropped to, the risk of tokens gained through other means or having been transferred was acceptably low.
- The invalid tokens were retrieved using the
airdropfixaction. - The correct airdrop distribution was applied granted nearly 10,000 accounts tokens.
- The original smart contract was deployed, removing the transfer freeze and
airdropfixfunctionality.
The TRYBE team did an amazing job communicating with community throughout the process.
What does this teach us?
The simple fact of EOS is that unlike many of the blockchains before it contracts and values are mutable — this means that they can be changed. For those where the primary appeal is that a coin or token is irreversible and forever yours… or forever lost…then there are some ways to do that on EOS, but they won’t be universally adopted.
EOS creates a new space where the actions you take are forever recorded for all to see for as long as blocks are made, but it’s also a place where you can fix your mistakes when they don’t match you intentions.
Many DAPPS, industries, governments may be looking at EOSIO for this very reasons, accountability without inflexibility. The TRYBE token is a utility to fuel a place of knowledge sharing. The tokens had to respect the rules it had laid out to everyone who wants to trust and participate in that community even if it meant temporarily taking away to correct an error.
At the very core EOS requires some trust, which is rewarded with transparency.
What if I don’t want to trust?
This is where the power of DACs becomes important. Decentralizing control of mutable things will become the key to trusting mutability. When the entire community can take part in the decision making process to create something wonderful or fix something that went wrong they are more likely to trust those decisions.
While slower than a lone wolf with all the keys making decisions on the fly or with a small committee it provides a powerful safeguard and statement about the thing you are making together and the confidence in its reliability.
What do you think?
EOS is breaking new ground and events like these should be used to consider the evolution of the technology and the community. Humanity will ever make mistakes and it’s our obligation to learn from them and make things better.
- Should a technology punish our mistakes and prevent us from fixing them? What does this achieve?
- Is too much flexibility and freedom going to erode confidence and slow adoption? Or is the transparent flexibility the missing link to widespread use?
- Is there a middle ground? What does it look like?
The community and technology need to find these answers so it can continue to evolve and become the world changing force we all want to see.
