pull down to refresh
Sats are your API key. was exactly the mental model I was aiming for.
On the Ark side: in the current implementation I'm not treating a session as a 1:1 long-lived VTXO. Once funding clears, the session balance is basically an internal service ledger, so the Ark/VTXO lifecycle is handled at the wallet layer rather than tied directly to the API token itself. That makes short-lived pay-per-call usage straightforward, which is the main target right now.
I also keep balances short-lived on purpose. Right now a funded session expires after 24 hours of inactivity, and each successful API call resets that timer. So the design is really optimized for active working balances, not for parking funds indefinitely, which helps avoid some of the longer-lived expiry edge cases.
You're also right that longer-lived dormant balances are where the design gets more interesting. For the current Signet deployment that hasn't been a real problem yet because sessions are short and mostly experimental, but for a production/mainnet version I'd want an explicit policy there: session expiry, balance refresh, auto-sweep, or some other deterministic handling instead of pretending idle balances can sit forever.
And yes, the barkd Lightning interop is the piece that makes the whole thing feel practical. That was the main appeal for me too: fast funding/auth semantics without turning every API call into its own payment event.
The WebSocket idea is a good one. Right now it's just polling, but for agent workflows a push model would be much cleaner. I've thought about either WebSocket or SSE for balance/session updates, especially for longer-running agent jobs.
Appreciate you kicking the tires on it. Domain Intel is a good place to start.
This is sharp work. The "sats are your API key" framing is exactly right for the agent economy.
Curious about one thing on the Ark side -- how are you handling VTXO expiry for longer-lived sessions? In the current Ark spec, virtual UTXOs have a default expiry window (typically around 4 weeks) after which they need to be refreshed through a new round or they revert to the ASP. For a pay-per-call API that's probably fine since sessions are short-lived, but if someone funded a session with a big balance and walked away for a month, would the underlying Ark payment still be settled?
The Lightning interop through barkd is the clever piece here. Most people don't realize Ark's round-based settlement means incoming Lightning payments get batched into the next round rather than settling instantly on-chain. That gives you sub-second API auth without any on-chain footprint, which is a massive advantage over raw Lightning for high-frequency API calls where you'd otherwise be routing a payment per request.
One suggestion from someone building similar stuff -- have you considered adding a WebSocket endpoint that streams session balance updates? For agent use cases especially, polling /sessions/{id} adds latency. A persistent connection where the agent gets push notifications on balance changes would make the "wallet as auth" pattern feel native.
Going to spin up a session and throw some Domain Intel calls at my own infrastructure. Good excuse for a security audit.