The 4th Bitcoin SV Hackathon
The 4th Bitcoin SV Hackathon will be taking place entirely online from 14th June to 26th July 2021. Registration is open from 16th May onwards and will remain open until the conclusion of the coding round of the competition on July 26th at 12:00 pm (GMT), when entries for all submissions close.
Theme: Peer-to-peer applications
When we think of Bitcoin's peer-to-peer capabilities and properties, the first thing - and for many, the only thing - that will spring to mind, is payments.
But Bitcoin is so much more than just a payments rail, so let's get creative and demonstrate that to the world!
The theme of the 4th Bitcoin SV Hackathon is 'peer-to-peer applications' - not just payments, but any type of application that involves direct interaction between participants on the Bitcoin network.
Hackathon entrants are tasked with leveraging the recently released SPV Channels service as part of their application to facilitate communication across the network, as well as interacting with the Bitcoin network directly via the Merchant API (mAPI).
For desktop applications, the SPV Channels service offers a simple REST interface, while for mobile applications, mobile client libraries for both Apple and Android devices are available.
Each team or individual entrant will be invited into a group Discord chat via email.
Please note: If you are part of a team, you may also communicate with your team members directly through any medium of your choice.
Things to remember
Whenever your code is in a working state, commit it. You never know when you may encounter a bug that you get stuck on. You can always roll back and submit an earlier working version. Sometimes, too, it can be easier to go back to a known working version and rewrite the code in a different way so as to avoid the bug.
Remember too, that your entry can address a smaller part of a bigger problem. The code component is meant to be a proof of concept. Make your entry as functional as possible, but if you need to, mock-up parts of other process flows - It is acceptable to demonstrate how your solution and its core components work.
We expect participants may have full-time jobs and will spend varying amounts of time on their entries. The 6 week competition period was chosen so that you can fit in time for the Hackathon around work and home obligations. The 6-week competition period does not reflect our expectations about the readiness or degree of completeness of your final submission.
Important: Please ensure you and all your team members have an active Discord for communication with moderators at all times.
$100,000 in prizes
$50,000 USD (paid in Bitcoin SV)
$30,000 USD (paid in Bitcoin SV)
$20,000 USD (paid in Bitcoin SV)
Submitting to this hackathon could earn you:
Who can enter the Hackathon?
Participants can enter the Bitcoin SV Hackathon as an individual, or as part of a team.
However, a participant cannot be part of more than one entry. This means:
- a participant cannot be a member of more than one team.
- a participant cannot be an individual entry and also be part of a team.
- a team cannot submit more than one hack submission.
If you do not have a team but would like to join one, visit the Participants page on Devpost to see other registered users who are also seeking teammates.
Upon completion of your Hackathon work, a link to the following deliverables should be submitted on Devpost:
- Code submission using a GitHub repository named after your team.
- There should be one single Git repository for your submission. If external resorces are required, an install/setup script should be included.
- All submission should include Docker or Vagrant container(s) that the solution runs on.
- Supporting documentation (this may include photographs of whiteboards, diagrams, written notes, a short business case, or any other material you think relevant)
- A 5-minute (or less) video summarizing your entry – e.g. a screencast demonstration of your product and a short introduction to your team, vision, goals, and business proposition.
- A working application and/or website.
Here is a link that explains how the submission process works.
Remember, our judging teams have limited time to review numerous entry submissions. Additionally, keep in mind it can be a challenge for our judges to get your application working, especially if your own development has dependencies installed that you are not aware of. If these are undocumented in your submission materials, it may be difficult to get your application to build without background knowledge of you work or the tech stack you are using.
For this reason, if you will not be running/hosting your entered application/service(s) and require us to run your submission locally, we advise you to dockerize your application in order to make this process easier for the judges. If you only have one image, then a Dockerfile in the repo or hosted publicly on Docker Hub is acceptable (with documentation on running the container). If you have multiple images, then a docker-compose in the repo is also acceptable.
Docker will be helpful in specific cases where we need to run your code, so if your project entails the creation of a library, for example, then Docker is not necessary.
You can learn more about Docker here: https://docs.docker.com/get-started/overview/.
External infrastructure and APIs
Can external infrastructure and APIs be used as part of a submission?
However, if it is deployed and required infrastructure you have written yourself during the Hackathon you will need to submit the commit hash and link to relevant code it is running. You are not allowed as part of your submission to continue working on and improving the deployed version of your external infrastructure which will be relied upon for judging.
How technically impressive is the product? Does it use a particularly inventive technique, or does it use several different components? Does the product have a “wow” factor? How well does the project solve the prescribed problem?
Did the team put thought into the user experience? How well designed is the interface? Is it convincing, intuitive and consistent? Was the overall context of a solution considered? How relevant is the solution itself?
Does the product solve a real problem and have a plausible market? Is there a workable business model that the project fits into? The project need not implement an entire business model.
Does the product work? Did the team achieve what they wanted?