Barkd is what you run when you want to enable bitcoin payments server-side. It's our reference daemon wallet: a single binary that runs alongside your other services and exposes a REST API for sending and receiving Ark, Lightning, and on-chain payments. It's best for exchanges, payment
Ark users are always in control of their bitcoin. They can perform an emergency exit to get back on-chain whenever they need to. But Bark is a client-server system, and users depend on the server to make payments and refresh their VTXOs before expiry. Careful engineering, rigorous code review, and
hArk (hash-lock Ark), first described in a Delving Bitcoin post, and shipped in v0.1.0-beta.6 is an update to our implementation of the Ark protocol that fundamentally changes how rounds are constructed. Forfeits are now dependent on hash-locks instead of connectors, and are signed after the round'
We've redesigned how Bark wallets receive updates from the Ark server. The new unified mailbox gives developers a single, efficient feed for all wallet notifications—Lightning payments, Ark payments, and refreshes—instead of requiring separate queries for each address. This simplifies app integrations and scales to high transaction
We're funding a year-long grant for Beulah Evanjalin to implement nested MuSig in libsecp256k1-zkp. This is a joint effort between Beulah, Second, and Vora, with Jesse Posner providing weekly mentorship throughout the project. Nested MuSig is a key dependency for us improving the security of Ark server funds,