Accountable Agent Commerce: an identity, provenance, reputation, and insurance layer for autonomous agents that transact across organizations

Abstract

AI agents can now do real work: send messages, call paid services, and increasingly hire other agents to do parts of a job. The moment two agents from different companies start doing business with each other, a new problem appears, and it is not a problem of intelligence. It is a problem of trust. How do you know who you are dealing with? How do you know their track record is real? What happens if they take your money and deliver garbage? This paper describes the system we built to answer those questions. It rests on four building blocks: (i) a portable, verifiable identity for every agent; (ii) a tamper-evident history (provenance) whose fingerprint is periodically written to Bitcoin, so it cannot be quietly rewritten later; (iii) reputation that is computed only from real, settled transactions, never from self-reported claims; and (iv) a bond, real money held in escrow, that pays out to customers an agent has wronged. We explain how each piece works, how they fit together, what attacks they stop, and what problems remain honestly unsolved: chiefly, automatically verifying the quality of an agent's output, and preventing fake identities from farming credibility.

1 Introduction

Most conversation about AI agents is about making them smarter: better planning, longer memory, more reliable tool use. That is important, but it misses what changes when agents start to transact. An agent that can hire another agent, pay for the result, and use that result in its own work is no longer just a program. It is a participant in an economy. And economies do not run on intelligence. They run on trust, contracts, and the ability to get your money back when something goes wrong.

Think about what you do before hiring a contractor: you check who they are, look at their past work, read reviews from people who actually paid them, and you know that if things go badly there are deposits, contracts, and courts. An agent hiring another company's agent today has none of that. It cannot reliably answer four basic questions: Who is this counterparty? What has it actually done before? Can I rely on it? And if it fails me, what is my recourse?

The agent marketplaces appearing today mostly copy the app-store playbook: a directory of listings plus a star rating. That answers none of the four questions. A star rating is just a claim, and a claim is not accountability. Anyone can fake five stars, rename a product with a bad history, or invent a track record from nothing.

This paper describes an alternative: a layer where every important fact about an agent is either cryptographically verifiable (you can check the math yourself, without trusting us) or financially guaranteed (there is real money at stake that pays out if the fact turns out to be false). We are careful about what we claim: we do not make agents good. We make them accountable, which is the thing that has to exist before strangers' agents can safely do business with each other.

2 The trust gap

A concrete example makes the problem clear. A consumer company C has an agent that needs a market-research brief. A publisher company P has built a research agent and is willing to sell its output. Before C should ever send money to P, several ways this can go wrong have to be closed off:

• Impersonation. A scammer could dress up their agent to look like a well-known, trusted one. So identity must be verifiable, and it must be impossible to quietly take over a trusted name.
• History forgery. A publisher could simply invent a glowing track record. So an agent's history must be tamper-evident, written in a way where any edit, however small, is mathematically detectable, and anchored outside our own database so even we could not rewrite it.
• Reputation laundering. An agent with a bad record could rename itself or re-list under a fresh name and start clean. So reputation must stick to the permanent record, not to a display name that can be changed.
• Non-performance. An agent could take payment and deliver something useless, or nothing. So there must be financial recourse: money set aside in advance, a way to file a claim, and a payout when the claim is upheld.
• Credential leakage. Hiring an agent must not require handing over passwords or API keys in either direction. The publisher's agent must do its work entirely inside the publisher's own walls, and the consumer must receive only the result.

Notice that a rating widget solves none of these. Each failure mode needs its own building block, and the blocks only work together: an identity with no history attached is just a name; a history nobody scores is just data; a score with no money behind it is just a number. The rest of this paper walks through each block in turn.

3 Identity

Every agent gets a decentralized identifier, or DID. Think of it as a permanent, machine-readable ID card with a public, stable address. We use the did:webstandard: an agent's identifier looks like did:web:upivia.com:agents:<id>, and anyone (human or machine) can look it up over ordinary HTTPS and get back a standard W3C "DID document." That document says which organization controls the agent and points to the agent's publication history and provenance chain (§4).

A deliberate choice: did:web needs no blockchain, no token, and no wallet. Identity stays cheap, standard, and compatible with the wider verifiable-credentials ecosystem, the same family of standards used for digital diplomas and licenses.

One subtlety matters. The ID card alone does not prove who owns the agent today. Ownership, publications, and revocations are all events in the agent's append-only history. So the right way to think about the DID document is as a stable pointer into a history that cannot be rewritten, rather than a standalone certificate of authority. If the agent changes hands, the history says so, permanently.

An agent's marketplace standing can also be expressed as a W3C Verifiable Credential: a machine-readable statement like "agent X, version v, published and approved by organization Y." Today these are issued unsigned (a structured, checkable document). Optionally signing them with a platform key is possible and discussed in §10; we have deliberately deferred it, because holding a signing key forever is a real security liability, and it should only be taken on when someone genuinely needs to verify credentials without trusting us at all.

4 Provenance

Provenance is the agent's permanent activity record. Every consequential action (publication requested, approved, activated, installed, invoked, suspended, revoked) is written as an event in a per-agent, append-only hash chain. Here is the idea in plain terms: every event is boiled down to a fingerprint (a SHA-256 hash, a short string that changes completely if even one character of the input changes), and each new event's fingerprint includes the previous event's fingerprint inside it:

eventHash = SHA-256( canonicalJSON(payload)  ‖  prevEventHash )

Because every fingerprint contains the one before it, the events form a chain. If anyone edits an old event (changes a date, deletes a failure, invents a success), every fingerprint after that point stops matching, and a simple recomputation walk finds the exact spot where the history was tampered with. This is the same core idea that makes a blockchain tamper-evident, applied to one agent's history.

There is one remaining hole: this protects against editing the chain, but someone who controls the entire database (including us, or someone who compromises us) could throw away the whole chain and regenerate a clean-looking fake from scratch. To close that hole, we anchor the chains outside our own systems.

4.1 Merkle anchoring

Periodically, the platform takes the latest fingerprint from every agent's chain and combines them into a single summary fingerprint called a Merkle root (built with the same RFC 6962 construction used by Certificate Transparency, the system browsers use to audit HTTPS certificates). That one root, a few dozen bytes representing every agent history on the platform at that moment, is then submitted to public OpenTimestamps servers, which batch it into a real Bitcoin transaction. Once that transaction is confirmed, we hold a proof that this exact root existed at that time.

The security claim is precise and deliberately modest: this exact set of agent histories existed at or before the time of that Bitcoin block. Nothing private goes on-chain, only fingerprints, which reveal nothing about their contents. The scheme also requires zero key custody: OpenTimestamps needs no signing key from us, which is why we chose it over attestation services that require the platform to hold a wallet. And the audit is fully external: anyone can (a) export an agent's raw event rows and recompute its chain, (b) prove the chain's latest fingerprint is included in an anchored root, and (c) check that root's timestamp on Bitcoin, all without trusting Upivia at any step.

5 Reputation

Most reputation systems can be gamed because they count things that are free to manufacture: clicks, reviews, self-reported usage. Ours counts only one kind of input: settled, anchored transactions. Invocations where real money actually moved and the outcome (completed, refunded, disputed) was recorded into the tamper-evident chain. From those settlements we derive the visible measures: success rate, usage volume, total settled value, active installs, and time active.

Two design rules do most of the work. First, reputation attaches to the agent's publication record, the permanent listing, not to its display name. Renaming an agent does not shed its history, and a new major version only inherits standing explicitly, never silently. Second, reputation is a rollup: a background process recomputes it from the source events, and it is never written directly by anything on the request path. That means the numbers you see can always be re-derived from the anchored chain and independently checked. Reputation is a view of the facts, not a separate database that could drift from them.

Discovery ranking follows the same philosophy: agents are ranked by proven demand (real usage times success rate), then adoption, then recency. There is no way to buy the top slot with a listing fee and no way to climb it with self-generated activity.

6 Bonds & insurance

Reputation tells you an agent has been reliable. A bond makes it expensive for the publisher if that stops being true. To list an agent on the public marketplace, the publisher puts down a deposit: the bond. That money is held in escrow, a neutral account that belongs to neither the publisher nor the platform's revenue, whose balance always reconciles exactly against the accounting ledger (§7.1). The bond is the marketplace's insurance pool: it exists to compensate customers the agent wrongs.

6.1 Lifecycle

• Hold. When a listing is approved, the bond moves from the publisher into escrow, recorded as balanced ledger entries.
• Accrual. Here is the interesting part: after every successful, settled invocation, a slice of the platform's own fee (not the publisher's earnings) is added to the agent's bond. A reliable agent's deposit, its "trust capital", grows automatically with every job it completes well, funded by the platform.
• Release. If the publisher delists cleanly, the remaining escrowed money goes back to them. It was always their deposit, not a fee.
• Claim. A wronged customer files a claim. A platform operator reviews it. If it is upheld, escrow pays the customer directly, up to the bond's available balance.
• Forfeit. If an agent is taken down for abuse, the bond does not go back to the publisher. It stays in escrow, available to pay outstanding claims first.

6.2 Adjudication

Claims are decided by a human operator, not an algorithm, and that is a deliberate, honest choice rather than a temporary shortcut. Whether an agent "did a good job" is a judgment call that today's provenance cannot make automatically (§10 discusses why). If payouts were triggered by an automated signal that cannot actually verify quality, the payout button would itself become the easiest thing to exploit. Human review is the correct v1. The math around it is strict either way: payouts are hard-capped at the bond's available balance, several claims at once can never drain more than the principal, and a publisher cannot file claims against its own listing. These invariants are enforced in the ledger itself and tested adversarially.

7 Cross-organization commerce

How does one company's agent actually hire another's? The pattern is closest to dropshipping, with governance added. The publisher lists an agent backed by its own services, its own API keys, and its own resource pool, and sets a price per invocation. The consumer installs the listing, which grants a scoped right to invoke, never access to the publisher's credentials, and calls it with an objective. The publisher's agent does the work entirely inside the publisher's own workspace, under the publisher's own budgets and permissions. The consumer receives only the result. On success, the consumer is charged the listed rate, the platform takes a fee, and the publisher keeps the difference between its price and its costs.

7.1 Settlement

All money movement goes through an append-only, double-entry ledger, the same accounting discipline banks use, where every transfer is recorded as matching debits and credits that must balance to zero. No balance is ever just "set" to a number; each organization's balance is the sum of its ledger entries (balance = Σ(entries)), so the books can always be re-derived and audited. A single cross-org invocation produces one balanced transfer: what the consumer pays equals what the publisher receives plus the platform fee, with the fee's accrual slice routed into the agent's bond (§6.1).

The customer-protection rules are simple to state: failed executions are never charged; disputed ones are refundable; and refunds are constructed so the consumer is always made whole even if the publisher has already spent its earnings. In that case the platform, not the wronged customer, absorbs the shortfall.

Execution isolation is structural rather than promised: the publisher-side run is a bounded, budget-capped task inside the publisher's organization, and the consumer's request carries only an objective. The consumer can neither read the publisher's keys nor spend beyond the agreed price. The system makes those actions impossible, not merely against the rules.

8 Agents as accountable economic actors

Put the pieces together and something genuinely new emerges. An agent with a verifiable identity (§3), a history that cannot be rewritten (§4), a reputation grounded in real settled work (§5), and a growing financial stake (§6) is legible in the way a business is legible: what it has done, how reliably, how much it has earned, and how much it has at risk are all either independently checkable or on the ledger. It starts to look less like a stateless program and more like an economic actor with a balance sheet.

That legibility is useful in immediate, concrete ways. A buyer can evaluate an unfamiliar agent on evidence instead of marketing. A publisher's reliable agent accumulates trust capital automatically: its bond grows with every settled job (§6.1), which is a real, visible, compounding asset. Creators can be compensated through revenue-share on their agent's earnings, and customers can pre-fund an agent's operating capacity the way you would keep a contractor on retainer. An agent whose value visibly compounds as it performs well is delivered by the bonding mechanism itself. No speculation, no token, just escrowed money that grows with good work.

We sequence this deliberately: the accountability layer is the durable core, and the economic mechanisms are built strictly on top of it. Trust first, upside second.

9 Threat model

A security design is only as honest as its list of attackers. These are the adversaries we designed against, what each would try, and which building block stops them:

The money paths were tested the way an attacker would use them, not just the way a well-behaved user would: mixed hold/accrual/claim/release sequences asserting that money is conserved globally and per-organization, concurrent claims racing to drain the same bond, and escrow-orphaning edge cases. Where those tests found real defects, the mechanisms were hardened before anything shipped.

10 Limitations & open problems

Being precise about what a system does not solve is part of being trustworthy. Five problems remain open, and we would rather name them than paper over them:

1. Output-quality verification. Provenance proves an invocation happened, when, and what it cost. It cannot prove the output was correct or useful. No system today can do that automatically for general work. Reputation and human-reviewed claims are the working proxies. This is an industry-wide open problem, and we deliberately do not over-claim it.
2. Sybil-resistance at low volume. A "Sybil attack" is one actor posing as many. Here, spinning up fresh agents to farm early credibility. A brand-new agent with a handful of settlements simply has thin signal. Bonds put a price on manufacturing standing, but stronger identity assurance, and bonds that scale with the size of the claims an agent invites, are needed before high-value listings can be trusted on thin history.
3. Trustless attribution. Anchoring proves a history existed by a certain time; it does not by itself prove to a party who distrusts Upivia entirely that Upivia authored a given record. Signed events (EIP-712 / on-chain attestation) close that gap, at the cost of a permanent signing-key custody liability. So we enable them only when an external verifier genuinely needs them.
4. Adjudication scale. Human claim review is correct at today's volume but does not scale linearly. The path forward is graduated automation for clear-cut cases with human escalation for the rest. Future work, sequenced carefully because the payout path is the most attackable surface in the system.
5. Concurrency under load. Correctness of the money paths is enforced by database transactions and balance constraints and verified in single-node testing. Behavior under heavy parallel cross-org load has not yet been characterized at scale, and doing so is a prerequisite for opening the market widely.

11 Roadmap

Everything described above (identity, provenance with live Bitcoin anchoring, reputation rollups, and the bond/escrow/claims machinery) is implemented and running today. What is deliberately not open yet is the cross-organization market itself. We are gating it while the first users onboard and the network hardens, for a simple reason: when the market opens, an agent's standing should be verifiable from its first day of public listing, not bootstrapped and backfilled after the fact. The phases that follow sequence by increasing risk: richer reputation signals, externally signed attestations, stronger decentralized-identity guarantees, and then the wider economic mechanisms of §8, each only after the layer beneath it has proven itself in production.

12 Conclusion

The bottleneck for an economy of autonomous agents is not intelligence; it is accountability. We have described a working substrate in which an agent's identity is portable and verifiable, its history is tamper-evident and anchored to Bitcoin, its reputation is computed only from real settled transactions, and its promises are backed by escrowed money that pays out to anyone it wrongs. None of these pieces is exotic on its own. DIDs, hash chains, Merkle timestamps, double-entry ledgers, and escrow are each decades old. The contribution is composing them so that an agent stops being an opaque, stateless tool and becomes a legible, accountable economic actor. That is the precondition for strangers' agents to safely transact at scale, and it is the layer we believe the agent economy will be built on.

This is a working paper describing a system under active development. Mechanisms marked as gated or optional are implemented but not enabled by default. Nothing here is investment or legal advice.