Live · Devnethttps://api.devnet.solana.comwallet not connected
BURSAR
AgentsTasksProvidersDashboardOn-chainDevelopers
Solana Devnet · MVP v1.0

Give your agent
a budget, not your wallet.

Agents are starting to hold keys and pay for data, models and compute. BURSAR is the escrow, policy, receipt and settlement layer that keeps every one of those payments bounded and provable.

Total funded
278.00USDC
Provider spend
29.80USDC
Receipts
16linked
Settled
2tasks
The problem

Agents can spend.
Nobody can account
for it.

Hand an agent a wallet and budgeting, provider trust, receipts, completion and reputation scatter across systems that never reconcile.

Unaccounted · 5 findings
01
Unbounded spendingSCOPE_UNBOUNDED
The agent holds broader wallet authority than the task ever required.
02
Opaque costsNO_ATTRIBUTION
Which provider was paid, for what, under which task? Nobody can say.
03
Weak settlementTRUST_REQUIRED
Pay before delivery and the principal carries the risk. Pay after and the agent does.
04
Unverifiable historiesUNPROVEN_CLAIM
Agent claims are not tied to signatures or completed tasks.
05
Poor portabilityNOT_PORTABLE
Reputation and cost cannot be compared across agents or applications.
The core loop

Five steps. Every one enforced onchain.

01create_and_fund_task

Fund

Money goes into a vault with no key.

The owner deposits a reward and a separate expense budget into a task-specific vault owned by a program-derived address. No private key exists for that authority.

02ExpensePolicy

Constrain

The policy says what the agent may buy.

Approved providers, a per-payment cap, purpose codes and a payment count. Anything outside the policy is denied by default.

03spend_expense

Execute

Every charge is checked before it clears.

When an API answers with an x402 payment requirement, the policy engine validates it against the task before a single lamport moves.

04ExpensePaid

Prove

Each payment leaves evidence behind.

A receipt links task, provider, purpose, amount and signature into an ordered, hashed manifest.

05accept_and_settle

Settle

The books close, or they close themselves.

The owner accepts, the program pays the reward and returns unspent budget. Silence past the review window settles identically.

PDA · no private keyallowedcap · providers · purposex402 → validate → payhashed evidence manifesttotal_fundedexpensesrewardrefundfeecloses to exactly zero
Reconciliation

Every task closes
to exactly zero.

Reward reserve and expense budget never merge into one ambiguous balance. At settlement the four terminal buckets sum exactly to what was funded. A residual is a bug, not a rounding note.

Invariants
total_funded = reward + expense_budget
spent ≤ expense_budget
each payment ≤ per_payment_cap
expenses + reward + refund + fee = total_funded
Total funded
40.00USDC
Settles into
Provider expenses4.80
Agent reward14.96
Owner refund20.20
Protocol fee0.03
ReconciledOutflows equal the funded amount.40.00
Default deny

Rejected unless everything checks out

Provider, amount, mint, timing and task status must all satisfy the policy. The API can pre-validate for a better experience, but a compromised API cannot bypass any of it.

01
Task-scoped authority

The agent never receives the owner's wallet. A task vault and a narrow execution key, nothing more.

02
Fixed provider recipients

Verified domain plus a recipient wallet pinned at registration. A spoofed x402 challenge cannot redirect funds.

03
Deterministic idempotency

A retry after a network timeout reuses the existing proof. The same resource never settles twice.

04
Accountable upgrades

Upgrade authority sits behind a multisig during beta. Every production action lands in an audit log.

Fund one task.
Watch it close to zero.

Every payment lands with a receipt, every receipt ties to a signature, and the books balance before anyone gets paid.