Team introduction:

Inspiration - Magic Question: 'What if it were easy?'

The initial idea was to provide an enterprise solution to make all legacy data stores WORM compliant.

We found out there were many use cases for WORM storage and achieving product/market fit would take lots of customer development. For the sake of the hackathon we asked ourselves a magic question: ‘what if it were easy?’.

This led to an epiphany: if we start with building a robust integration with the API hub Zapier, we would essentially be building a solution to make 2000+ apps WORM compliant.

But it didn’t stop there. We found out that simply pushing data onchain was too one-dimensional. Kyrt was becoming something bigger: an immutable workflow tool, allowing you to listen and write the blockchain as well as initiate micropayments, all through third party app integrations.

Kyrt allows to bridge off- & onchain, #breakdowndatasilos.

What it does

Kyrt is a data platform that allows anyone to integrate Bitcoin into their workflows without using code. This means you can do two things:

a) Create onchain actions like a data push or micropayment that is triggered from 2000+ apps. (example: IF a new invoice is created in Xero Accounting, THEN push the invoice information onchain)

b) Listen to events happening onchain that creates an action in any of the 2000+ apps. (example: IF I receive 10$ on this BSV address, THEN send an email with a PDF attachment using Gmail)

Aside from the API, we built a User Dashboard and SDK allowing our users to view their automations, manage their costs and index their onchain information.

Our vision is to provide custom API integration services allowing enterprises to create immutable enterprise workflows. Immutably store, move and monetize information.

How we built it


Being an entirely remote team, our most important tools were Google Meet and Trello. We held weekly meetings and more if needed. Tasks were distributed according to each team member’s expertise. Using a combination of OKR and agile scrum methods, progress was steady and also easily observable by the entire team.


Initial architecture diagrams

Zapier Integration with publish and micropayment actions Zapier Integration with webhook triggers

On a technical level, a lot of research went into the practical possibilities of our vision. We created diagrams of the architecture integrating with Zapier Actions (publishing to Bitcoin) and Triggers (listening to transactions).

Development of backend & frontend

To get up and running very quickly we decided to use Mernkit as a boilerplate. In hindsight this wasn’t the best technical decision but for hackathon purposes it was adequate. Besides customization of the boilerplate we also set up a TXQ server to deliver our transactions to the miners.

The filtering engine seen in the second diagram was entirely written from scratch. This was partly done in preparation for upping the technical standards of the entire project and also keeping an eye on scalability of our platform. The filtering engine is based on our own boilerplate which we have developed and been using for more than a year now. It’s written in Typescript and includes everything we like as developers: built-in linting, flexible debugging setups, unit tests, CI/CD integration with Gitlab and more. It runs as a separate process and while we’re not there yet, the intention is to allow it to scale massively by spinning up many concurrent workers in combination with RabbitMQ as the internal message broker.


We make heavy use of Gitlab’s CI/CD pipelines. The frontend, backend and filtering engine are automatically deployed when commits on the master branch happen. This saves us immense amounts of time and also makes all changes immediately visible to the rest of the team.

Challenges we ran into

We obviously are a new formed team so we had to get familiar with each other's way of working and skillset. This turned out to be a match made in heaven. :)

Accomplishments that we're proud of

You know you are building a valuable product when you immediately use it yourself. We have integrated Kyrt with Mailchimp and Twitter to send micropayments to new waitlist subscribers and Twitter followers. We are also incentivising the wisdom of the crowd by sending a micropayment to anyone suggesting new Kyrt integrations on Twitter with the hashtag #IntegrateBitcoin. It’s very cool to be able to use Bitcoin so effortlessly in all your daily apps.

Apart from that we are super proud we have been able to deliver something valuable and usable. Kyrt is not a concept, it is a working product that people can use today.

What we learned

Developing a proper marketing strategy around these new concepts is hard. It will take customer research and education to sell our solution. Something positive that we learned is that nothing in our strategy or business vision is being capped by the protocol BSV. The sky's the limit!

What's next for Kyrt

Kyrt's current strategy is actually reverse-engineering customer feedback. Normally you ask your ideal customer what they want - and then you work from there. Kyrt flips that upside down:

We shipped a sandbox that acts as an 'engineered feedback system'. We want to push you - our users - to integrate apps to experience the value of the blockchain. All this feedback will be fed into strategy to make sure we keep building towards a solution that the market needs.

We are eyeing to innovate the WORM storage sector by providing superior security and sharing functionality to the centralised alternatives like AWS Glacier and Azure Immutable Blob or the CD-ROM and USB stick.

Technically speaking, besides obviously wanting to up our code quality from hackathon level to enterprise level, we have a lot more ideas about integrating with enterprise customers.

In the future we want to release SDKs for popular programming languages that will allow developers to easily integrate with Kyrt directly. Whether the customer wants to publish or listen for data on Bitcoin, a good developer experience of integrating an existing system with Bitcoin is something we find very important.

Kyrt also does not want to limit itself to one protocol (HTTP) to interface with Bitcoin. When customer need arises for different protocols such as MQTT (for IoT use cases), Websockets or Kafka, we will be the first to listen and implement these requirements.

Most importantly, Kyrt wants to implement and further explore true data ownership.

Built With

Share this project: