Need a crash course on Bitcoin layers?
→ READ OUR FREE GUIDE
Need a crash course on Bitcoin layers?
→ READ OUR FREE GUIDE
Need a crash course on Bitcoin layers?
→ READ OUR FREE GUIDE
Need a crash course on Bitcoin layers?
→ READ OUR FREE GUIDE
Need a crash course on Bitcoin layers?
→ READ OUR FREE GUIDE

Recapping Hiro’s Internal 2022 Hackathon

Two of our company values are we find a way and we engineer moonshots, and in the last week of July, we found a way to manifest new moonshots outside of the scope of our everyday work in our second annual Hiro Hackathon.

Type
Recap
Topic(s)
Events
Hiro
Published
August 11, 2022
Author(s)
Sr Engineering Manager
We engineer moonshots.
Contents

Hiro is a small and mighty team—we are now just over 50 people—and in many ways, a hackathon embodies our spirit. I am constantly amazed by the ingenuity and hard work put in by the Hiro team, and the Hiro Hackathon took that creativity and perseverance to the next level. In just a week, we hacked together some amazing things that can bring real value to Hiro and often to the broader Stacks community too.

Just like last year’s hackathon, we halted work for 3 days to let our team build the coolest ideas they could think up. Here’s how it worked.

  • Monday: Pitch day. After days (or weeks) of deliberation, anyone with a hackathon idea was able to pitch their idea to the entire company, recruiting other team members to help hack the project to fruition.
  • Tuesday-Thursday: Let the hacking sprint begin!
  • Friday: Demo day. Each team presented their final product, and the entire company voted on the winner.
In total, 18 Hiros participated in 11 different projects. The competition was steep, and so we offered the rewards to match.
  • First place: A shiny new Apple Watch for each member of the winning team.
  • Second place: A pair of Stacks- and Bitcoin-branded Ray Ban sunglasses.
  • Participation award: Stacks Co-Founder and Hiro Chairman Muneeb Ali can often be seen around the office wearing a beloved pair of slippers. Now, our hacker Hiros can hack in comfort too with a pair of their own.

Ready to see what we built?

Clear Waters: A Clarity Smart Contracts Game

A video game that teaches you Clarity

Learning a new programming language can be hard. Taking first place in the hackathon was a project designed to make learning Clarity a bit easier.

Led by a cross-departmental group of Hiros including engineering, marketing, and product, they created Clear Waters, a game that you can install as a VS Code Extension. In the game, you have to help Toshi on his treasure hunt as he looks for treasure on a deserted island. 

A level of the game where a pirate navigates a sandy island

In order to help Toshi navigate the island, players have to actually write Clarity to advance him on the treasure hunt, and the game teaches you the basics of Clarity as you go.

The lessons get increasingly complex and cover everything from simple functions to data variables. The game is built on a hidden Clarity smart contract, and a front end reads the contract to move the character in the game. The game won our hearts, and maybe one day soon children all over the world will learn Clarity through Clear Waters. Game of the year.

Watch the Clear Waters team give a demo of the game:

BTC/STX Utility Service

Coming in 2nd place, 4 Hiros on the infrastructure and documentation team built a STX/BTC utility service. The service is a group of different API endpoints that are valuable for querying information on how STX relates to BTC and vice versa. 

A series of endpoints from the API

These new endpoints include, but are not limited to:

  • Address: if you give the endpoint a STX address, it converts it to a BTC address and vice versa. You usually do this via Stacks.js, but you have to code it (and that’s hard). This makes the process much easier.
  • Balances: if you give the endpoint a STX or BTC address, you can see the corresponding balance for both STX and BTC.
  • Miner-participant: give a STX block, then you get the different BTC transactions that participated in mining that block. You can see the transactions, the STX transaction that committed the transaction, and the BTC address for the participants.

This service also has some nice additions for Clarity query helpers. For example, if you want to issue a read only smart contract call, you have to do it via POST and call the node directly. It’s slow, doesn’t let you do caching, and the responses are all encoded in Clarity values.

With this endpoint, you can just use JSONs, which makes the response much more readable. The endpoint also allows for caching, offering a much faster runtime. Usually contract calls take 2 seconds to complete. With this change, it now only takes 500 milliseconds, and even less on multiple calls. This endpoint will be popular for apps that query contracts a lot.

The project may appear on a new deployment in the coming months, and hopefully you can play with these new endpoints soon. You can check out the code on GitHub here.

Watch a demo of the STX/BTC Utility Service:

Native STX Multisig Wallet CLI

Coming in 3rd place is an improved native multisig wallet for Stacks. Multisignature wallets are controlled by multiple keys (for example, a 2 of 3 wallet means 2 keys must sign a transaction from the group of 3 keys in order for the transaction to be approved). In fact, like Bitcoin, the Stacks blockchain has native support for these multisig wallets, and you don’t need a smart contract to implement this type of wallet.

However, today the native multisig wallet is painful to use. Each transfer requires 2 large Bitcoin transactions, and those can fail (requiring new Bitcoin transactions). The functionality of those wallets is also limited: they can only handle transfers and stacking. No PoX delegation, no NFTs, etc.

About 10% of the total supply of STX is stored on these kinds of wallets. A lot of STX could benefit from something nicer!

A web page showing the various fields for the signing tool

With this project, a Hiro engineer built a one page web script that users can interact with locally to perform multisig tasks with Ledger as well as a CLI. It introduces a new wire format for sharing partially signed transactions between parties in the multisig wallet, and the project works with the current Ledger app! Check out the code on GitHub here.

Watch a demo of the project here:

Arbitrum Validator in Clarity

Arbitrum is cool

Blockchains have bandwidth limits. But what if there were lots of blockchains that can interact with each other to solve that problem? That is the core insight behind L2 blockchains, but the problem with L2 is that trust isn’t automatic.

L1 miners aren’t punished if L2 miners misbehave. Optimistic rollups solves that problem and lets users punish L2 miners when they misbehave. Arbitrum is an optimistic rollups protocol that already offers an EVM compiler. Arbitrum defines a virtual machine semantics for running code, and if we can implement this VM in Clarity, then the Stacks chain can verify fraud proofs for L2s.

The contract code
A Glimpse of the AVM Contract

For the hackathon, one Hiro engineer implemented a proof-of-concept virtual machine for Arbitrum in a Clarity smart contract, and that simple implementation was able to pass two tests:

  1. A one line program that tests whether the virtual machine stops when it finishes running instructions and that the program emits the print event expected
  2. A more complex program that tests whether the virtual machine can handle a conditional jump with recursion.

This simple proof-of-concept shows that Arbitrum’s virtual machine semantics can be implemented in a Clarity smart contract, paving the way to enable the Stacks L1 blockchain to verify fraud proofs for Arbitrum L2s 🤯.

If you’re curious to learn more, you can check out the code on GitHub here.

User Profile Page for the Stacks Explorer

The Stacks Explorer is now one year old, and in that time NFTs have exploded in popularity. We needed a way to show NFTs on the Stacks Explorer, so we shoe-horned a “holdings” section to the page for STX addresses—but it’s far from perfect. It doesn’t even display the NFT themselves.

The address page on the Stacks Explorer
How NFTs Appear on the Explorer Today

For the Hackathon, one Hiro team, including members of the UserX team, legal, and engineering, decided to revamp how NFTs are integrated with the Explorer. NFTs are more than images; for many people, they are also a core part of identity. Introducing: profile pages for the Explorer.

A new profile page on the Explorer
The New and Improved Profile Page

Users can log in with their wallet to the Stacks Explorer, add an NFT as a profile picture, and follow other users. This revamped Explorer page pulls in NFT and FT metadata to show the images associated with those assets, and the new page also allows people to easily look at an address’s history of transactions (applying new filters to those transactions), looking through their token balances, and more.

This isn’t just a design file; the team hacked this profile page together in a live environment. This project rethinks what the Explorer experience should be and incorporates a new community focus that doesn’t exist on the Explorer today.

Rod Protocol

A Lightning <> Stacks integration

For this project, one Hiro wanted to explore the question of what can be done between Lightning and Stacks? He decided to address the issue of Lightning onboarding. The challenge with Lightning onboarding is around receiving a payment. In order to do so, you have to open a channel and spend money (bad) or convince a counterparty to open a channel for you (by sending the counterparty some BTC, which is also bad).

Today, there is a list of counterparties you can reach out to, but there is no incentive structure properly aligned with the work. Enter Rod protocol.

An overview of the protocol architecture

With this protocol, when you want to receive a payment, you send BTC to a counterparty on Lightning, and in exchange you get wrapped tokens (rBTC). These tokens are liquid on Stacks. Users can trade them for STX, do some lending, or participate in DeFi.

This enables users to effectively open a “checking account” on Lightning with any rBTC that the user leaves as is. Then they convert any rBTC to other assets (or deposit that rBTC on a lending protocol) for their “savings account” on Stacks.

This could lead to larger pools on Lightning (more liquidity: good for both Lightning and counterparties earning fees). The counterparty on Rod protocol still earns fees like any Lightning channel, but in this case, those fees can go towards a rewards pool to further incentivize users. Users are similarly incentivized to participate in Rod protocol because their assets aren’t locked in a Lightning channel. Instead, they can earn yield on rBTC on Stacks or trade for other assets.

With this protocol, funds are easy to unlock. Since Stacks forks with Bitcoin, funds can be unwrapped in 1 block. During the hackathon, rBTC were successfully minted and burned on devnet (!), bringing two different Bitcoin layers, Lightning and Stacks, closer together.

Helm Hiros

Deploying the Stacks API is difficult. There are thousands of lines of code for a single deployment of the Stacks API. We manage multiple deployments, and so manage tens of thousands of lines of code. That’s hard!

Two Hiro infrastructure engineers decided to say enough is enough and built a solution for this problem during the hackathon using Helm, a package manager for Kubernetes. 

The GitHub repo

Helm greatly simplifies the deployment process for the Stacks API by organizing Kubernetes packages into “charts.” Inside of a chart, you have a repository with a values file and different templates, and the templates pull values from the values file.

If you want to deploy the Helm chart, all you have to do is override values from the defaults found in the values file (though you can even deploy as is for a functional basic setup).

Installing Helm

With a single command, helm install, we can now deploy a new instance of the API that is split into a reader and write deployment, a Stacks blockchain node that writes to the API, and a Postgres database. All with a single command.

As if that wasn’t good enough, DNS also automatically sets up with a new deployment through this Helm framework too. Check out the code on GitHub here.

The Best of the Rest

Buy Now Pay Later With STX

One Hiro wrote a white paper for the hackathon detailing a buy now, pay later service for Stacks. Buy now, pay later services (such as Klarna, Affirm, and After Pay) have been proven to increase sales by allowing users to pay off a purchase in monthly installments instead of all at once. This white paper details how such a payment model could be adapted for Stacks and in particular explores how lending pools could make buy now, pay later services more accessible to both lenders and borrowers.

HiroStory

4 Hiros believe in the power of storytelling and came together to create HiroStory, a website that has an interactive timeline telling the story of Hiro. The website is designed as a tool to help onboard new employees and show how the company evolved from OneName to Blockstack to Hiro over the course of 8 years. Users can click around to different dates and learn about funding rounds, product launches, and more. Check out the page for yourself!

Hiro’s Hallowed Hall

The people team at Hiro is organized. We have an entire employee handbook detailing our company policies and everything else employees may need to know, including an employee directory where you can find a list of everyone at the company and how to reach them.

The one thing the directory lacked was personality. Until now. 3 Hiros came together to create a new employee profile template that shows off each individual’s personality and gives them the opportunity to share their favorite music, foods, travel destinations, and more.

6x faster blocks with one weird trick

One of Hiro’s engineers turned his gaze towards the throughput problem: a blockchain can only handle so many transactions per second—how can we increase that metric and create a higher throughput for the Stacks blockchain?

During the hackathon, this engineer made an interesting discovery: for every 14 seconds spent processing transactions, we spend 86 seconds deciding which transaction to process next. Greg found a time-saving opportunity that sped up Stacks blocks 6X.

Conclusion

Hiros built all of that in just 3 days of hacking. These ideas will help drive our roadmap, and our job now is to incorporate them into our products. In fact, this is already happening with the Stacks Explorer, as we are adding BTC information and fungible token metadata this week.

I can’t wait to see what the Hiro team comes up with next year when the Hackathon will undoubtedly return for the 3rd year in a row. If hacking with us sounds fun, check out our careers page. We’re hiring!

Product updates & dev resources straight to your inbox
Your Email is in an invalid format
Checkbox is required.
Thanks for
subscribing.
Oops! Something went wrong while submitting the form.
View Careers
Copy link
Mailbox
Hiro news & product updates straight to your inbox
Only relevant communications. We promise we won’t spam.

Related stories