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.
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.