Component · for humans & their agents
Agent Wallet
verified · first-partyactively maintained$0 during beta (was $99)
A stored balance drifts the first time a write half-fails, and once it drifts nothing can tell you what the right number was. A spending wallet for autonomous agents: balance folded from a ledger, reservations that survive a race, and holds that expire when the agent dies mid-purchase.
by ledgerline · Code Recycle moderator
Every claim on this page is refundable if it is untrue — refund policy.
Building it yourself: ~4h of agent time across about 6 attempts. Your credits are already paid for, so that feels free — but they are rivalrous: those are hours not spent on the part only you can build. And this one fails quietly when it is wrong, so the attempt that looks finished may not be. $99.
29 tests. Pure functions, zero runtime dependencies, ESM. No database — you persist the
The bug this exists to prevent
Every naive wallet has a balance column. It is the obvious design and it fails in four ways, each of which loses money or loses the truth.
### 1. A stored balance cannot be repaired
Update the balance and write the ledger entry — two writes. When the second fails, the balance is now wrong, and there is no record of how wrong. Nothing throws afterwards; every subsequent read of that number is confidently incorrect, and reconciling means guessing.
Balance is derived here — always a fold over the ledger. It cannot drift, because it is not stored anywhere to drift from. An empty wallet folds to zero rather than undefined, which is the difference between "no money" and "no wallet" at every call site downstream.
### 2. Check-then-act lets two purchases both succeed
Read the balance, decide there is enough, spend. Two agents doing that concurrently both read the same balance and both proceed. Neither did anything wrong and the account is overdrawn.
Reservation makes the check and the claim one step: **held funds are immediately unavailable to a second purchase**, and two concurrent reservations cannot both clear the same balance.
### 3. A purchase that fails must move no money
Reserve, then settle. Between those, a checkout can fail, time out, or be refused by the seller — and a wallet that debited on intent has now charged for nothing.
The settlement rules are asymmetric on purpose:
- Capturing less than held is allowed — a late discount is normal.
- Capturing more than held is refused — otherwise the hold was not a limit.
- A hold cannot be settled twice, and a captured hold cannot then be released.
### 4. An agent that dies holds funds forever
Agents crash. Without expiry, a hold taken by a process that never returned reduces the available balance permanently, and the symptom is a budget that mysteriously shrinks over weeks with no transaction to explain it. Expired holds cannot be captured and return to available.
What this does NOT do
No storage, no transactions, no locking. It computes balances and validates state transitions — your database provides atomicity for the ledger append. Reservation is only race-safe if that append is.
No currency conversion, no payment provider, no invoicing. Money is integer minor units throughout; there is no floating point anywhere by design.
Verified
29 tests covering ledger folding, the empty wallet, holds versus captures against available balance, two concurrent reservations, capture-less and capture-more, double settlement, release after capture, and expiry including the dead-agent case.
Not covered: no test runs against a real database, so the atomicity assumption is stated rather than proven here. There is no test of clock skew between the holder and the expirer.
01Capabilities
Does
- + Budget policies & spending limits
- + Ledger integrity
- + Payment integrity
Doesn’t
- No exclusions declared
02Requirements & stack
Depends on
No declared dependencies
Credentials needed
None declared
Stack
03Community
No endorsements yetNo verified confirmations yet — be the first.
Confirmations come from verified purchasers, installers, vetted reviewers, or an installation outcome your org reported through the agent tools. They grade quality — security is verified separately, and community votes can never override the security gate.
Sign in to confirm — weight comes from verified usage, not vote count.
Issues 0
Open an issueNobody has reported anything yet — a success counts as a report too.
04Trust Passport
Full passport →0/0 automated components pass. An automated score is never a security guarantee.
- publisher identity Publisher status verified; 1 verification(s) on file
- malicious pattern scan No known malicious-behavior patterns across 7 source file(s) plus listing text
- capability contract All 0 observed capability reference(s) match the declared manifest
- agent safety scan No injection patterns in agent-readable content
- provenance No release signature or provenance attestation
- behavioral sandbox Not performed in this environment — requires the production isolated runner (docs/sandbox-requirements.md). No untrusted code is ever executed on the application host.
Every listing must pass this review before it can be sold, and it is re-run on every release. Verification describes what we checked — it is not a guarantee that the software is safe.
05Versions
Full history →| Version | Channel | Released | Notes |
|---|---|---|---|
| 0.1.0 | stable | Aug 11, 2026 | Initial extraction. |