Damus

Recent Notes

Second profile picture

Small but mighty changelog for 0.1.3. Bark now ships an IndexedDB StorageAdaptor—the missing piece for browser-based wallets. Combined with the WASM and gRPC-web support from 0.1.0, you can now build Ark wallets that run entirely in the browser with persistent state.

Bark can now also connect to access-controlled Ark servers via bearer tokens. You know what this means. 😉

Full release notes available at the usual place: second.tech/docs/changelog
Second profile picture
Double changelog today for bark-0.1.0 (you know we’re getting closer to mainnet when the “beta” tag is dropped!). Highlights include event-driven notifications replacing polling, a fee estimation API for all operation types, Tor connectivity, barkd security hardening with auth tokens and CORS, HTLC preimage recovery from on-chain exits, and WASM compilation for browser-based Ark wallets.

Full changelog: second.tech/docs/changelog

Second profile picture
Nice one AJ Towns. Your signet reorg simulations caught a nasty bug lurking in unusually deep reorgs. Thank you for passively torturing our code with edge cases 👍
🚀1
Second profile picture
"This was a genuinely fun build. The Bark integration was way smoother than I expected going in. Being able to accept Lightning payments without running my own node, and having native Ark payments work alongside that, made the whole payment layer surprisingly simple to wire up." - PiHiker, ArkAPI dev

Cool new project for charging for API calls: https://community.second.tech/t/arkapi-a-pay-per-call-api-gateway-with-lightning-and-native-ark-payments-built-on-bark-and-live-on-signet/193/1
1💚1
Second profile picture
We caught a capacity overflow bug in Bark before it ever hit a user—thanks to the fuzz testing @luca0x46 has been running around the clock. A malformed VTXO could have requested an arbitrary vec size during deserialization, triggering a panic. Now it's patched.

Bark's client-server architecture means the server has to gracefully handle anything thrown at it—malformed VTXOs, malicious client requests, unexpected edge cases. Fuzzing helps make sure the server stays up and keeps serving rounds no matter what comes in.

The vec allocation bug is a good example of something easy to miss in review—stable Rust doesn't yet support try_with_capacity, so the bounds check has to be done manually. Our first fuzz target was a straightforward deserialize/serialize pass, and it surfaced the issue immediately.

The fuzzer runs 24/7 now, with minimized corpora pushed to our bark-qa repo alongside test vectors used throughout Bark's development. More targets coming—serialization/deserialization expansions first, then method-level fuzz targets.

Full writeup: https://blog.second.tech/fuzzing-bark-for-server-reliability/

Second profile picture
Bark's Rust API docs are live on docs(dot)rs. `Wallet` is the central entry point—create, sync, inspect VTXOs, pay Lightning invoices, refresh in rounds, exit unilaterally. All from one struct.
Second · 8w
Rust docs: docs.rs/bark-wallet/latest/bark
Second profile picture
It's probably going to be a process of trial and error to find the optimal refresh strategy for users on Ark. Bark lets each wallet dev implement their own VTXO refresh strategy—set when VTXOs should be auto-refreshed based on expiry, size, or exit cost:

Second · 9w
Devs can even open up these settings to users, so that they can customize refresh policy based on their preferences/needs.
Second profile picture
Bark's `Wallet` struct is the single entry point for Ark, Lightning, and on-chain payments. Create one with a mnemonic + sqlite + server URL and you're transacting.

❤️1