BOLT
Lock beneficiary funds on Arc via Privy policy + World Selfie Check. Public verification included.
Demo
About
BOLT-Beneficiary Only Ledger Transfers BOLT answers a fundamental question: how does a business prove it can't spend customer money? By making it impossible. BOLT locks customer accounts using Privy policies enforced inside a secure enclave. The policy runs before the signing key is reassembled—unauthorized transactions are refused before a signature can ever exist. When a beneficiary claims their money, they prove identity via World Selfie Check, then a key quorum of business owners approves the unlock. The transfer settles as USDC on Arc. Every obligation, balance, and state change is recorded on-chain and indexed by The Graph. Anyone—regulator, auditor, customer—can visit the public page and cryptographically verify the money's location and amount. No trust in the business required. Just math
How it's made
BOLT is built on three load-bearing sponsors working together, each doing irreplaceable work: Privy enforces the core lock. We compile a policy that decodes USDC calldata and constrains transfer._to (not just transaction.to—the latter points to the token contract, not the payee). The policy runs inside Privy's secure enclave before the signing key is reassembled. No unsigned paths, no app-layer overrides. Key quorum signatures are required to widen the policy. Arc is where the money lives. Every obligation, every balance, every settlement is USDC on Arc testnet. The subgraph indexes all events in real-time. World gates access. Beneficiaries prove identity via Selfie Check (IDKit) before claiming. We discovered and worked around a React 19 incompatibility in the widget, switching to the raw IDKit.request() API from @worldcoin/idkit-core with identical results. Technical stack: Next.js 15 frontend + API routes (TypeScript strict), Solidity contract (BoltRegistry) on Arc via Hardhat, Postgres + Drizzle for workflow state, AssemblyScript subgraph for indexing. Device IDs tracked via localStorage to implement repeat-verification skip (FR-8.8). Notable hack: Obligation accrual must record the on-chain ObligationAccrued event before inserting the Postgres row. If you reverse the order, the settlement call later reads a stale Postgres obligationId, tries to settle on-chain, and reverts after the money has already transferred—leaving state inconsistent. We discovered this the hard way and backfilled evidence.