Hive Fest 2026 Workshops - Real Hive client. On a battery 🔋🐝

# Hive Fest 2026 Workshops - Real Hive client. On a battery 🔋🐝 Hello again, dear Hive community! 👋 Remember when I said I was learning some new stuff and "might drop something soon"? Well... this is not Rust 🦀 and it is not Solidity 👾. This time I went **deeper**. Like, *hardware* deeper 🪛  Some of you might have already seen it live - we showed this device during our workshops at this year's HiveFest 26! 🍻 ## 🤏 What is it? It's a Hive blockchain client written in C++, running on the [Seeed Studio XIAO ESP32C6](https://wiki.seeedstudio.com/xiao_esp32c6_getting_started/) - a board smaller than your thumb (21 × 17.5 mm!). It builds and signs transactions **on-device**, using a private key stored on the chip, then broadcasts them straight to the Hive mainnet. No PC. No phone. No backend server. Here's what we're working with: | Spec | Value | | --- | --- | | CPU | RISC-V @ 160 MHz | | RAM | 512 KB | | Flash | 4 MB | | Connectivity | WiFi 6 📶 | | Size | 21 × 17.5 mm | Yes, 512 **KB**. Not MB, not GB. Kilobytes. Your browser tab is probably eating a few hundred times more than that right now 😅  [Here](https://explore.openhive.network/@guest4test) you can explore transacations made during the live demo at HiveFest Workshops! ## 🔁 How does it work? The whole lifecycle is dead simple: 1. **Wake** ⏰ - the BIG RED BUTTON wakes the chip up 2. **WiFi 6** 📶 - connect and talk to `api.hive.blog` 3. **Build** 🏗️ - fetch the reference block and build the transaction 4. **Sign** ✍️ - secp256k1 signature using the on-chip key 5. **Broadcast** 📡 - send it to the network... and go back to deep sleep 😴 And that "go back to sleep" part is the real magic here. ## 🔋 One year on a single battery?! Yup. Let's do the math (I promise it's short): * Active mode: **~100 mA** * Deep sleep: **~15 µA** (micro! 🔬) * Scenario: **10 transactions per day, ~10 s awake each** Awake time per day: 10 × 10 s = 100 s → 100 mA × 100 s ≈ **2.78 mAh / day** Sleep time per day: ~86 300 s × 0.015 mA ≈ **0.36 mAh / day** Total: ≈ **3.14 mAh / day** (hey, π! 🥧) On a single **1200 mAh** cell that gives us 1200 / 3.14 ≈ **382 days** 🤯 > Power consumption values are based on the [Seeed Studio wiki](https://wiki.seeedstudio.com). Real life (WiFi quality, API node response time, battery self-discharge, cold winter nights in Poland 🥶) will of course bite off a piece of that, but the order of magnitude stands! ## 🔐 Crypto on a diet For all the heavy cryptographic lifting (secp256k1, SHA-256, RIPEMD-160 & friends) I used the battle-tested [Trezor crypto library](https://github.com/trezor/trezor-firmware/tree/main/crypto) - written in plain C, tiny, and designed exactly for devices like this one. If it's good enough for hardware wallets, it's good enough for my little bee 🐝 The protocol part, however, was a different story. Serialization, transaction layout, the signing digest - I had to rewrite all of it **byte by byte** by hand 🥲, because the C++ Hive Protocol core simply doesn't fit into 512 KB of RAM together with WiFi and everything else. And that's actually one of the most important lessons from this project: we really need a **separate, lightweight C layer** for the basic Hive protocol functions (serialization, digests, signing). One small, portable core that can be reused everywhere - from microcontrollers, through native apps, up to wax itself (for size optimization) - instead of everyone reimplementing the same bytes over and over again (and making the same mistakes... more on that below 👇). @small.minion what do you think? ## 🐛 The bug hunt (a.k.a. "AI blamed wax for its magic compiled WASM code") Okay, now for my favorite part. Grab some popcorn 🍿 The first version of the firmware generated **bad signatures**. Every broadcast was rejected by the node - the signature was mathematically valid, but it recovered a public key that had absolutely nothing to do with my account 🙃 So I did what every modern developer does - I asked AI for help 🤖 The LLM spent **a few hours** on this. It wrote Python scripts using [beem](https://github.com/holgern/beem), compared outputs, generated hypotheses, reproduced my signatures with beem... and couldn't reproduce them with [wax](https://gitlab.syncad.com/hive/wax). The verdict? Delivered with full confidence: > *"The wax library appears to be bugged - it produces different signatures than beem for the same input."* Wait... what? 🤨 I've been working on wax for a long time now. I know how it's built, I know the C++ Hive Protocol core it runs on, and I know how many tests it goes through. So instead of trusting the verdict, I opened [Transaction Inspector](https://tx.openhive.network) and did a good old byte-by-byte analysis of my serialized transaction 🔍 It took **5 minutes**. ### 🕵️ So what was it? Quick reminder on how Hive signing works: the signature is created over the digest of `chain_id` + the serialized transaction **without** the signatures. Something like this: ``` beeab0de00000000... <- chain id (yes, "bee ab0de" 🐝) xxxx <- ref_block_num xxxxxxxx <- ref_block_prefix xxxxxxxx <- expiration 01 ... <- operations 00 <- extensions 00 <- signatures (empty array) <-- 🚨 THIS ONE! ``` Yup. **One single zero byte.** I appended an empty signatures array to the buffer being signed, where it simply should not be. The signed payload was 1 byte longer than the one the node was verifying, so the digests didn't match, and the recovered key was garbage 🗑️ ### 🤔 But why did beem "confirm" it? And here's the actual lesson. **beem reproduced my signatures** because it happily lets you sign whatever buffer you give it - including a malformed one. So from the AI's perspective, "beem agrees with the device" = "the device is correct". **wax couldn't reproduce them** because wax does not allow generating signatures over such malformed data. It builds the signing digest from a properly defined transaction using the same C++ protocol code as `hived`, so you simply *can't* produce that broken signature with it. The AI took this safety feature and labeled it a bug 🤦 So it wasn't wax being broken. It was wax doing **exactly** its job. ## 💡 Takeaways This is, in my opinion, a primary example of two things: 1. **Why wax is so badly needed** 🛡️ - a library that shares the protocol core with the blockchain itself and doesn't let you shoot yourself in the foot is worth more than a dozen libraries that "just work" until they silently don't. 2. **Why we still need the watchful eye of core developers** 👁️ - AI is a great tool, I use it every day, but hours of confident LLM output lost against 5 minutes of someone who actually knows how a Hive transaction looks inside. Don't blindly stare at whatever the model spits out. Check the bytes. Always check the bytes. ## 🚀 What's next? The client works, signs, broadcasts and sleeps like a baby 👶. If you have ideas for what a tiny, battery-powered Hive device could do - drop them in the comments! I'm genuinely curious what you'll come up with 🤩 Thebeedev, @mtyszczak out \*drops ~~mic~~ microcontroller\* 🎤  --- Images from private archive