Search projects, hackathons, sponsors and tech

    ← All projects

    Heirloom

    Non-custodial HBAR inheritance: an allowance, not a deposit, released by the chain itself.

    Demo

    About

    Every crypto inheritance product today is a vault: you hand your savings to a contract and hope it gives them back later. Heirloom does the opposite. The owner grants our contract a native HBAR allowance (HIP-906) from their own wallet. No money moves. They keep spending normally. The allowance lies dormant until the switch fires, and then a single HTS cryptoTransfer with isApproval=true moves the HBAR directly from the owner's account to the beneficiary's. Our contract's balance never changes. This is only possible on Hedera: Ethereum has no allowance mechanism for its native asset. There is also no server, keeper, or cron job. The vault schedules calls to itself with HIP-1215 scheduled contract calls. It wakes up, checks whether the owner is alive, and reschedules. The interval tightens as the deadline approaches (30 days, then 7, then 1), so the system watches harder the closer it gets to acting. Liveness is detected passively. Every transaction the owner signs costs a fee, so any activity lowers their balance, and only the key holder can cause a decrease. The heartbeat sees that and resets the timer. The owner never has to open our app. A one-tap "I am alive" covers the rest. Before releasing, the vault re-checks liveness one last time and reads the allowance live from the ledger; if the owner has been active, it resets instead of releasing. It fails toward not releasing. The beneficiary needs no setup and need not know the vault exists. The factory indexes vaults by beneficiary, so connecting a wallet is enough to find one. The owner can revoke at the ledger level at any time by setting the allowance to zero, with no cooperation from our contract. This is running on Hedera Testnet. We watched a scheduled self-call release 100 HBAR from the owner's account to the beneficiary's, three times, with nobody clicking anything. The vault's balance only ever moved by its own heartbeat fees.

    How it's made

    Contracts are Solidity 0.8.24 with Foundry, tested against mocked Hedera system contracts etched at 0x167 (HTS), 0x16a (HAS) and 0x16b (HSS), 63 unit tests plus fuzzing on the timer maths. Three Hedera primitives do the real work: HIP-906 HBAR allowances (the owner calls hbarApprove on the Hedera Account Service; the vault reads hbarAllowance live, never cached), HIP-206 atomic cryptoTransfer with isApproval=true to spend that allowance, and HIP-1215 generalized scheduled contract calls for the vault to schedule its own heartbeat(). The scheduler never reverts: failures are emitted, and a permissionless poke() restarts a dead chain. The frontend is Next.js 16, Tailwind 4, wagmi and viem, with MetaMask over the Hedera JSON-RPC relay. The activity log is built entirely from mirror-node event queries; no subgraph. Deploy and lifecycle scripts are TypeScript with viem and the Hedera SDK. We spent the first hours on verification spikes before writing production code, and they earned their keep. Two findings overturned our plan. First, inside the Hedera EVM every value (msg.value, address.balance, call{value}) is already tinybars; the relay presents weibars. Our spec assumed weibars in the contract and would have released 10^10 times too little. The contract now does zero unit conversion. Second, a scheduleCall costs about 1.5M gas, so our planned 400k heartbeat budget would have killed the chain on its first link, and each heartbeat costs about 1.75 HBAR, which we surface as runway in the dashboard. Hacky bits worth admitting: liveness by balance decrease is a heuristic, and we saw it bite us in a good way. Calling release() from the owner's own wallet aborted the release, because paying the fee proved the owner alive. Only a non-owner can trigger a release now. We also drained the fee reserve exactly at the finish line in one test run (INSUFFICIENT_PAYER_BALANCE on the final scheduled call), which is why the reserve is refundable, runway is shown, and anyone can restart the chain. And MetaMask refuses to send calldata to one of its own accounts, so the allowance grant goes through the Account Service system contract instead of the HIP-906 own-address redirect. Nothing is faked: the demo runs on testnet with compressed timings (3-minute timeout, 15/10/5-second heartbeats) using the same code path as production. Two things to adjust before submitting: swap the project name if you've picked a different one, and if the form asks for team or partner technologies separately, the partner technology is Hedera (HIP-906, HIP-206, HIP-1215, the JSON-RPC relay, and the mirror node).