Show HN: Making missed workouts cost money with Android T…

Article URL: https://pedrooaugusto.github.io/blog/posts/making-missed-workouts-cost-money-with-smart-contracts/ Comments URL: https://news.ycombinator.com/item?id=47139885 Points: 2 # Comments: 1

Most fitness plans fail for the boring reasons: motivation fades, life happens, and “I’ll do it tomorrow” becomes an everyday excuse. This post is about an experiment I’m running to prevent one specific failure mode: the ability to negotiate with myself. I built FitVow, a small system where I lock real money into a smart contract and, each week, I need to hit my physical activity goals. If I don’t, I pay a fine.

The twist: anyone can trigger enforcement and collect part of the fine as a reward, and the rest goes to a charity wallet (Giveth). I have no control over the enforcement process whatsoever. If I miss my weekly goals, I’m automatically eligible for a fine—no pleading, no explaining, just contract rules. If you want to verify (not trust) the current state of the experiment, the live dashboard is here: fitvow.pedroaugusto.dev.

It reads directly from the blockchain (no backend) and shows the initial stake, week-by-week pass/fail results, and how much has been lost to fines so far. FitVow is not a product. It’s a personal experiment in motivation: seeing if putting real money at risk succeeds where willpower alone usually fails. Think of it as a gym buddy you hand a pile of money to for safekeeping—except he’s allowed to give some of it away every time you skip a workout.

Because anything that depends on my future self being honest and diligent is exactly what I’m trying to avoid. That incentive is also why the penalty is split. If I could enforce my own failure and get 100% of the penalty back, the system becomes theater. Splitting it between the enforcer and charity ensures that even if I try to “cheat” by enforcing my own missed week, I still lose real money to charity.

FitVow-Sync (Android app): A custom Android app I built that integrates with Android Health Connect to read workout sessions recorded by my Samsung Galaxy Watch. It signs weekly activity summaries using a non-exportable, hardware-backed key and publishes them on-chain. Fitness Unbreakable Vow (smart contracts): A set of contracts deployed on Arbitrum (Ethereum L2) that verify the signed activity data, track weekly pass/fail outcomes, and manage the stake by applying fines when a week is missed.

FitVow Dashboard (website): A simple frontend that reads from the blockchain and displays the live state of the experiment (stake, weekly results, and fines paid). It also lets anyone connect a wallet with Metamask and enforce a missed week when enforcement is available. * FitVow-Sync filters Health Connect records to only accept data originating from Samsung Health (the Galaxy Watch companion app).

If the system were just “check a box saying you went to the gym”, it would be pointless. I could click the box while watching Netflix in bed and call it a day. How do you make cheating annoying enough that the path of least resistance is simply doing the workout? A wearable-backed data source Activity data comes from my Galaxy Watch via Samsung Health → Health Connect. A watch produces a bundle of signals (duration, heart-rate patterns, calories/energy estimates, timestamps, etc.) that are much harder to fake convincingly than a manual checkbox.

Could someone fabricate it? Probably. But it’s already a much higher-effort attack than “tap to confirm”. A hardware-backed signing key (Android Keystore / TEE) FitVow-Sync doesn’t just upload raw activity records—it uploads a signed weekly summary. The private key used to sign is non-exportable and lives in Android’s Trusted Execution Environment (TEE). This makes “I’ll just run a script on my laptop and submit fake workouts” not work: the contracts only accept updates that prove they came from the enrolled device.

To make this verifiable, I also publish the key’s Android Key Attestation on-chain, so anyone can independently inspect the attestation chain and key properties [1] [2]. Public, verifiable execution The rules and state live on-chain, and the code is public. That doesn’t magically prevent cheating, but it does make the experiment auditable. If I try to game the system, I’ll be doing it publicly—with a permanent on-chain paper trail.

The goal isn’t “impossible to cheat.” It’s cheating being more effort than the workout. This system only works if the contract can distinguish “data produced by my enrolled phone + app” from “some script submitting whatever it wants” (aka the sandbox environment). The model is simple: trust the wearable data pipeline, and strongly authenticate the publisher. On first install, FitVow-Sync app generates a P-256 private key that is non-exportable and stored inside the Android TEE.

The corresponding public key is registered on-chain. From that point on, the contracts only accept updates signed by that key [3]. In other words: the contract doesn’t trust “who sent the transaction”; it trusts “who can produce a valid signature”. To make that claim auditable, I publish the key’s Android Key Attestation on-chain. This gives third parties a way to verify (via Google’s attestation chain) properties about the enrolled key and environment—e.g.

that the key is hardware-backed and tied to an expected app identity/build [4]. This primarily targets the “I’ll just run a modified build or a desktop script” attack. A subtle failure mode in mobile security is silent drift over time: new builds, different signing keys, debug toggles, or “temporary” shortcuts that accidentally become permanent. FitVow treats enrollment of a public key as a one-way door.

The enrolled key/app identity isn’t something I casually swap. If I do rotate it, it’s intentionally expensive, so “upgrading into a cheat” has a real cost. During release, the APK is signed with a one-time, ephemeral signing key, and then the signing keystore is permanently deleted. After that, it’s cryptographically impossible to produce another APK with the same signature [5]. Why it matters: on Android, the app’s signing key is the app’s identity.

If you ship a future APK signed with a different key, Android treats it as a different app. That forces a reinstall, as opposed to an update, and, crucially, destroys the original app’s hardware-backed (TEE) keys. If I want to change behavior, I must pay the full price: reinstall (losing the TEE keys) and use the explicit on-chain key-rotation mechanism. To make releases verifiable, official FitVow-Sync APKs are built by GitHub Actions.

Anyone can inspect the workflow, review the logs, and download the exact artifacts produced by CI. The version currently running on my phone comes from this build: To put those numbers in context (Brazil): my monthly internet bill is R$99 (≈$18), natural gas is R$70 (≈$14), and the monthly national minimum wage is R$1518 (≈$286 💀). So yes — the fines are small, but they’re real enough to matter to me.

…in retrospective, not using stablecoins to keep it simple was not the best idea… Each week has three goals. The oracle records pass/fail for each one, and the vow contract uses that outcome to decide whether enforcement is allowed. If the system only trusts a specific hardware-backed key, then “my phone got stolen” becomes a real operational problem (I’ve had a phone stolen before in São Paulo).

So FitVow has an emergency escape hatch: a one-time key rotation. But it’s intentionally expensive: rotating the enrolled key costs 35% of the current contract balance, and that fee is donated to charity [6]. Permissionless enforcement works because other people have an incentive to call the enforcement function when a week fails. But there’s an edge case: what if nobody interacts with the contract?

To prevent “winning by inactivity”, FitVow also has automatic enforcement powered by Chainlink Automation. The key point is that the Upkeep is owned and configured by the Fitness Unbreakable Vow contract itself — once registered, I (the pledger) can’t pause it, modify it, or disable it. In normal circumstances, humans enforce and get rewarded. Automation only exists as a backstop to make sure the vow can’t be bypassed by simply staying inactive.

Access the Chainlink upkeep page here. Wearable data isn’t perfect. Sensors drift, vendors change behavior, and APIs evolve. For example, after a Samsung firmware update (Jan 22), my watch stopped reading heart rate reliably on my left wrist and keeps locking itself — real-world hardware is messy [7]. Proving “this is the exact APK running on my phone” is hard. Official FitVow-Sync releases are built in public via GitHub Actions, and the APK on my phone comes from that pipeline.

But there isn’t a clean cryptographic way for a random reader to verify my device is running that exact artifact. The best I could do is publish the build logs/artifacts and a screen recording of the installation process on my phone. The oracle boundary is still the boundary. The contracts can only enforce what the android app reports. If the input becomes cheap to forge (or the data source becomes unreliable), the whole system collapses.

There’s also a philosophical limit here: you can’t outsource discipline completely. At best, this is a nudge in the sense of nudge theory—it doesn’t force behavior, it just changes the incentives and reduces the room for “I’ll do it tomorrow” negotiations. I locked real money into a smart contract and wrote a system that penalizes missed workout weeks. Activity data comes from a wearable via Android, results are published on-chain, and enforcement is permissionless: anyone can trigger penalties and collect a reward, while the rest goes to charity.

Summary

This report covers the latest developments in samsung. The information presented highlights key changes and updates that are relevant to those following this topic.

---