It’s been a full month of pure excitement, inspiring creativity, surprising innovation and a great level of activity. But this Sunday, the deadline was reached for the second edition of the Byteball Use-a-Thon.

On behalf of the entire Byteball team and community, I would like to thank everyone who participated and shared their ideas and entrepreneurship with everyone else. You’re all freaking amazing!

While this is usually where we take a look at a specific feature available on the Byteball platform, we have to skip that for today’s announcement. Instead, it will allow us to introduce you to all the projects and use cases that were entered during the contest period.

Besides a brief description of the proposed use case, there is a short section with some thoughts of the jury members or advice on how to proceed with realization after the Use-a-Thon contest. The jury consist of four veteran Byteball users with very different backgrounds and preferences. This led to interesting debates on use cases, and it is important to stress that apart from deciding on the winners the jury members did not necessarily agree on all the details. As the article is written by @punqtured, so is the “Jury comments” section of each use case.

With that sorted, brace yourself for a lengthy but hopefully super exciting article! Let’s dive right in and take a look at the use cases in the order the contestants joined the contest.

By introducing a Byteball Smart Contract-driven way to buy votes on Steem, the project aims to solve a problem that gets increasingly difficult when done manually. A user would create a Smart Contract and request a specific type of post to be made in return for the vote. It could be specific photographs or articles on specific topics. If the poster doesn’t claim the reward within a certain amount of time, the amount offered on the Smart Contract would be returned to the user making the offer.

While the idea is definitely possible, there seem to be already automated bots and platforms on Steem making this possible. Assessing the feasibility, it would seem that while it’s definitely possible to create such a Bot on Byteball the benefits would be rather small. It would, however, make it possible to show the user creating the post that the money is on the table - or on the Smart Contract. With existing solutions, a user would have to trust the other party to actually make the payment or cast the vote to be rewarded.

Even before the Use-a-Thon was announced, an easy exchange between Bytes and STEEM was needed. Only days after the announcement that Byteball would reward all Steem users who linked their username with a Byteball wallet, @grow-pro and his friend @jackmiller had their solution ready. And even beating the in-wallet exchange bot by providing a fee-less exchange between Bytes and STEEM.

The process requires the two contestants to manually keep track of users wanting to make an exchange, which is great for a start but could quickly become a problem or even introduce errors. The use case is highly relevant, and it is obvious to the jury that these contestants were able to pinpoint a problem they could solve. The endless hours of work this must have required is admirable. While the use case doesn’t introduce new uses for the Byteball platform, we acknowledge the ability to spot the problem and provide the fastest possible solution.

Probably inspired by knowing how valuable contributions to open source projects are, @drsensor introduced the idea of linking Byteball to GitHub. Through the use of a bot and an oracle tapping into the APIs of GitHub, the solution would make it possible for a repository owner to request specific contributions to be made to his project and set specific rewards for them on Smart Contracts. During work on the project, it grew and eventually ended up becoming too large for one man to pull off.

This project uses the core of what the Byteball platform is able to do: eliminate the need for trust between two parties in digital transactions. By elegantly spotting the need for a bot allowing project owners to request specific tasks and an oracle that could provide an unbiased result from the effort of the contributor, this project hits pretty much all the right notes. Most existing platforms either require the contributor to trust the project owner to transfer the reward after he has provided all the work, or introduce an escrow service. The jury believes that this project’s realization would be highly valuable both to project owners as well as contributors, who would potentially be willing to pay a small fee to take advantage of all the benefits. So it is our sincere hope that someone will eventually pick up on the idea and make it happen.

A freelancing platform. Having spotted basically the same potential as @drsensor did, this project’s aim was a bit more open, providing more or less all the features of existing crowdsourcing platforms but removing the need for trust. By implementing a bot that allows requestor and producer to connect, browse specific categories of job offers and see specific payments for each job, the project takes a more holistic view of freelancing platforms than a specific GitHub integration.

Probably without knowing it, the contestant provided a solution that, when storing the rating score of a contributor on the DAG, would allow 3rd party applications to benefit from this project too. The direct engagement between someone offering a job and a stranger providing the work is a brilliant use case for the trustless exchange of value and information on Byteball.

A voting app or website. While there is an existing voting functionality available on the Byteball platform, this use case aims to introduce a new and improved poll or voting platform. One of the key features would be the possibility to generate a password that users wanting to vote have to know. This would allow for private polls to be conducted.

The existing poll feature can definitely be improved on, and there are a few novel ideas that would be a great addition to the Byteball platform. Apart from the basic idea, there weren’t really any details, making it a bit hard to evaluate. We found the idea to generally be good and highly feasible to implement.

A Byteball Discord bot. Acknowledging that Discord is rapidly growing and that more and more users are becoming aware of Byteball too, it is likely that there would be a need for a Discord bot for Byteball. The features of the bot would allow users to register a wallet with the bot, from which they could then send tips to other users, make payments, pull data from the DAG, present the polls generated in the previous use case and quite a few other useful ideas.

Showing incredible speed in progress and being able to create a working prototype in a matter of days is impressive. Implementing features only a few weeks old also proves an in-depth understanding of the platform. We are absolutely convinced that the Discord bot is an excellent addition that will not only help introduce Byteball to a wider audience but also provide users easy access to features. The possibility to follow the development more or less live on GitHub was a great pleasure as well.

Ask Anything. The idea is to allow users to post a question on their Steem blog. If the question is considered good, the person who asked would receive an answer and an upvote. All answers to the post would then be evaluated and rewarded an amount of Bytes. This way, the user asking a question would earn STEEM while the user providing the best answer would receive Bytes. A Win-Win use case.

Jury comments

We had quite a hard time figuring out how the user asking the question would know whether or not the user providing the best answer had made a public attestation with the Steem attestation bot. Without a public attestation, asker wouldn’t know the address of the best answerer. It seemed somewhat forced to bring Byteball into the use case and it would be far easier for the asker to simply send STEEM to the user with the best answer.

Use case #1

In cases where a person or organisation owns a domain name, and someone else wants to buy it, there is always a need for either great trust between the parties or an escrow service. Particularly when buying domains from so-called domain squatters, the trust can be a big problem. Therefore, an Oracle could be developed to pick up data from root DNS servers to verify if a domain had been transferred to the buyer or not. The buyer would deposit the agreed amount of money to a Smart Contract that would release the funds to the seller when the Oracle posts information to the DAG that the transfer has been completed.

Jury comments

The use case definitely hits the nerve of a very relevant problem. There is a great amount of money being lost because of dishonest people claiming to be owners of domains that they then offer to sell to companies. There will be some technical difficulties since more or less all domain registrants are now anonymized, which makes it hard to devise an Oracle that can be 100% certain that the domain was transferred. There might be technical solutions to that, though, but it would definitely require some more research to figure out a completely bulletproof way that would allow the trustless exchange of funds and domain. We do believe that if a solution is found for this problem, it could potentially be a highly relevant use case that many users would even happily pay a small fee to use.

Use case #2

Creating a Chat Bot that allows users to send SMS messages. The bot could be used by any user to send SMS messages that the bot would then relay through a SMS provider to someone’s mobile number. It would also allow other bots and applications to use the service to send out one-time passwords, verification codes, reminders of won bets or basically anything that they want.

Jury comments

Acknowledging that SMS service is a dated service compared to other modern means of sending messages between two users, it’s obvious that it’s still one of the preferred ways. One of the reasons could be that sending an SMS costs money. This effectively makes it impractical for spam purposes and is therefore often considered more legitimate than, for example, an email or text message on a social media platform. The use case is both highly feasible as well as sustainable as it would potentially generate income when implemented. By open sourcing the code for it, other contributors could build APIs for it or even more advanced features so we find this use case to have a great potential.

Use case #3

The use case title “Paid Surveys/Polls” would lead a reader to believe that this was about creating a service that would allow a simple poll. However, upon further study, it turns out to be a complete market research platform. The use case would require a bot with which users would register, particularly users that had completed the Real Name Attestation. A clothing company wanting to learn whether Portuguese men aged 30-40 prefer black or blue scarfs, would create a poll or research instance with the bot, adding an amount of Bytes to be distributed to the Byteball users meeting the criteria who answered the poll. Today, companies pay huge amount of money to other companies to conduct those type of researches, and methods like Facebook don’t reward the users providing the important data.

Jury comments

With the current number of users, any research that is not aimed specifically at tech-savvy men that understand crypto would probably not receive a sufficient number of answers. However, it does in fact eliminate an entire link in a value chain by the use of the Byteball platform. Furthermore, it allows users to stay anonymous and only prove to the bot that they fit the target group, without revealing their identity at all. This, combined with the possibility to have companies pay directly the users providing the data, is potentially something that could be extremely relevant in the years to come or in other use cases involving direct peer to peer transactions of value and data.

With an impressive determination to realize his use case, @Malos10 set out to prove to his local community that Byteball as a means of payment can be a better alternative than the Venezuelan Bolivar. Through a series of posts throughout the Use-a-Thon, he described his progress and identified the most important barriers to cryptocurrencies becoming widely adopted and used.

The approach was to first study the Byteball platform thoroughly to learn the benefits and the shortcomings. Armed with this highly technical knowledge, he then set out to talk to merchants and explain it to them in ways they could understand and that allowed them to see the potential benefits. Having successfully convinced a number of merchants to test the use of the platform for a week and by providing customers with free Bytes they could use in the shop, @Malos10 effectively took on the role of a skillful puppeteer orchestrating a complex act of commerce. Paying careful attention to all the parties in the value chain from customer to shop to exchange and back to customer, he successfully pulled off the field test.

In the final week, he returned to the shops to interview the owners about their experience with using Byteball to know where the project could be improved.

Jury comments

The amount of work put into this use case is remarkable. The weekly progress reports were inspiring and engaging and made it easy for everyone to follow the progress. The initiative has the potential to make a significant impact on the way people do commerce and provides a solution to a highly relevant problem in Venezuela. We believe that the project makes a great impression, but at the same time also acknowledge, that the use case - at least in its current state of progress - doesn’t require the Byteball platform to be used. It would be possible with basically any cryptocurrency that people would agree on using instead of fiat currency.

A briefly explained concept of providing a random quiz or competition, where users would sign up with a bot and the bot would then issue a question at random intervals. The first user to provide the correct answer would win a reward.

Jury comments

The idea is beautifully simple and probably would be fairly straightforward to implement. It would help keep Byteball in mind with users and could be a fun and engaging way to spread more knowledge about the platform and all its features to both new and existing users. It could also potentially attract new users hoping to be first to answer the questions and win a prize. It’s a prime example of how simple things can sometimes make a real difference.

Like many other Steemians, the idea for the use case started with the attestation reward program. A lot of Steem users suddenly had Bytes, and providing an easy and safe way for users to exchange their Bytes was seen as an opportunity by many. Having successfully created a manual exchange service for Nigerian Steem users, @drumstix went on to explore if there could be further potential to the benefit of everyone. As with many other other African countries, the purchase of utilities like electricity, water, mobile airtime etc. can be done through API integration with utility providers. By enabling Nigerians to spend bytes to pay for utilities, Byteball could be a safe way to do trustless transactions and eliminate the need to buy vouchers or scratch cards in shops. Another option could be to allow users to earn interest on their Bytes by lending them to others for investments. In short: An online Bytes Bank with a variety of services.

Jury comments

There are definitely possibilities in the African utility market. This potential has already been spotted by a great number of crypto projects. Yet, it would seem there’s definitely room for more, and in the race to become a widely accepted and trusted service provider, it would probably be a matter of being one of the first to actually implement solutions. And this is perhaps where there is a bit lacking with this use case. It’s not obvious how the project would be realized and which obstacles would have to be overcome to be successful. So while there is definitely great potential in that particular market, it would require a very dedicated effort probably by a team of people working on it together.

Being familiar with the Use-a-Thon contest from the first Use-a-Thon held at the Simon Bolivar University in Venezuela, @dialsamai once again provided a possible use case for this second edition. The general idea is to create a strategy game based on the history of Israel from a Christian point of view. The game would award players with Bytes for completing various stages or reading passages of biblical text. The general idea is to incentivize users to obtain more knowledge about history and Christianity while playing the game, earning Bytes and of course, winning the game.

Jury comments

There is probably no doubt that gaming is one of the industries where we will probably see the first actual use cases, and there is quite intensive focus on the rapidly growing gaming industry. Creating a game not only requires a large team of developers, it primarily requires a huge number of digital artists and content creators. Even relying on existing game engines would require quite a large project with a lot of people involved, and it would definitely take quite a long time. It would seem like the aim is for “the Rolls-Royce model” instead of gradually improving on a small-scale game idea. It could even be small existing games like Minesweeper, where Bytes could be introduced as an integrated part of the game.

By the use of the Byteball Wallet, this use case enables users to take part in a class action against Facebook and Google. The action would be for having banned crypto ads on their platforms, effectively causing the market to tumble and depreciate about 300 billion dollars. By allowing Byteball users to prove they own crypto currency, they could join the class action without any legal risks to them personally.

Jury comments

This is one of the more interesting use cases we came across. And while proof of real world identity isn’t needed in this specific case, it could very well be that similar future use cases could benefit from Byteball having built-in identity verification in the wallets. The need to prove that users actually own cryptocurrency is fulfilled by the entry coming from a user’s wallet in this case, and therefore the use case doesn’t particularly give a Byteball user any benefit over other crypto owners.