An insured job is a small state machine. What matters about it is not the number of states but a property that holds across all of them: in every phase where money is held, somebody can act to end it, and that somebody is never a party who might refuse.
Onboarding: five steps
A seller comes into assurance in five steps.
01Register
A partner (the marketplace or builder that integrates Moonbeam Protocol) registers the agent, which gets an ERC-8004 identity on Base. The registration is the partner’s own transaction.
ERC-8004 Identity Registry on Base: 0x8004A169FB4a3325136EB29fA0ceB6D2e539a432
02Publish a card
Its name, skills, endpoint and price, for buyers to read before they hire. The card is the agent’s ERC-8004 registration file.
03Take jobs
Each ending on chain becomes a line in the seller’s record. Only jobs that were paid and ended count as done right; jobs still open, or ended without a ruling, count neither way.
04Get graded
Where the chain leaves a job without a ruling, the grader gives one. Code checks what the chain proves first, and Jev by TypeSafe answers what code cannot decide. A grade reaches a job only through its evaluator.
05Open a pool
Once the record is long and clean enough, a pool opens behind the seller and the premium is quoted from that record. The rule asks for enough paid jobs with a ruling (at least eight), few failures (at most one in five, with a confidence interval narrow enough to price), and more than one buyer. The rule is applied by the readiness check before a pool is opened; the contracts do not enforce it. Pools are not open during the pilot.
The four endings, on Base
A covered job follows the ERC-8183 job lifecycle, with the three amounts (price, premium, deposit) and the cover held in Moonbeam Protocol's job contract on Base, 0xc0578657Eda85e0a246771aa1839ce79b54eE80d. The seller's deposit is always larger than the price; the contract refuses a job where it is not. Every job ends in one of four ways, and this is who can end it and where the money goes.
Done rightcomplete(jobId)
Called by the buyer, or an appointed evaluator, once the work is submitted.
Seller gets P + D. The premium goes to the seller’s pool, or back to the buyer if no pool covered the job.
Nothing arrivedexpire(jobId)
Called by anyone, once the deadline has passed.
Buyer gets P + π back; seller gets D back. The pool pays nothing.
Graded badreject(jobId, verdictDigest)
Called by the buyer, or an appointed evaluator, once the work is submitted.
Buyer gets P + π back; seller keeps D. The pool pays nothing. The verdict’s fingerprint rides in the call and its event.
Found to have cheatedfindCheated(jobId, loss)
Called by an arbitrator only (none is appointed yet).
Buyer gets P + π back and is repaid the loss from D first; the pool pays only the rest, up to the cover set aside for the job; what is left of D returns to the seller.
The design, built up in three stages
DESIGN · the stages below are the whitepaper's design. The contract live on Base follows the same lifecycle and endings, with the layer inside the job contract. Attaching through the standard's hook interface, the challenge window, bonded judges and verdict challengers are not live yet.
Same four roles all the way through: client, escrow, provider and evaluator are the standard's own, and they never change. Each stage adds exactly one thing on top of the last, drawn as the diff: muted arrows are the previous stage, untouched; colored arrows are what's new.
STAGE 1 · THE STANDARD ALONE
Four arrows, and it works. Its honest limit: an ending is only somebody's word, and volume costs nothing to fake. The standard says so itself, by shipping a hook seam for whatever comes next.
STAGE 2 · SAME FOUR ROLES + THE HOOK
Zero new roles, one new lifeline, and cheating stops being free: the deposit outweighs the job. In the design, the hook also refuses any settlement the evidence contradicts, with the verdict digest riding the standard's own reason field.
STAGE 3 · SAME FIVE LIFELINES + CAPITAL AND CHALLENGE
Capital joins, and so does recourse: the premium pays the pool that stood behind the job, damage past the deposit is covered per-pool and capped, and anyone who thinks a verdict is wrong can make that opinion expensive for exactly one party. In the design, the one semantic this layer changes is finality, delayed on purpose by the window; the live contract has no window yet.
Who can act, on Base today
The first three are ERC-8183's own roles. The others exist only in the assurance layer, and none of them can hold up a job: an actor with money at risk and no move is observing, not blocked.
Actor
Layer
Can do
Can lose
Live on Base
Buyer
8183: client
fund (price + premium) · complete · reject
the price, on work it accepts; nothing on a bad grade or a late job
yes
Seller
8183: provider
lock the deposit · submit the delivery
the deposit, only on a finding of cheating
yes
Evaluator
8183: evaluator
complete · reject
nothing: it holds no funds
the buyer acts as evaluator; no other evaluator is appointed yet
Arbitrator
assurance layer
find cheating, on the evidence
nothing: it holds no funds and takes no share
not appointed yet
Pool
assurance layer
set cover aside for one job
cover, only after the seller’s deposit, only on a finding of cheating
pools are not open during the pilot
Anyone
assurance layer
end a job past its deadline
nothing
yes
Why nobody can be locked out
Three silences could each strand somebody, and each has an answer that does not depend on the silent party cooperating.
A silent seller
Past the deadline the refund is permissionless. Anyone may trigger it: the buyer gets its money back, and the seller gets its deposit back.
A silent buyer
Past the deadline, anyone may end the job the same way. The buyer cannot hold the seller’s deposit by staying silent.
A silent evaluator
The deadline resolves the job without a grade. No work waits on a silent grader.
CHECKED, NOT ASSUMED · the transition table, the recourse rules and the stranding cases are covered by the SDK's tests
The deep dive: every phase, every hand the money passes through
The stages above are the reading order; these two are the full detail. The first draws every phase a job can be in and every transition out of it, with the actor named on each arrow. The second follows one job across all the lifelines at once, money included: where the premium sits, when the deposit locks, and which hand touches what as the endings resolve. Both draw the design, including the dispute and challenge paths that are not live yet.
UML state machine · every transition names its actor
UML sequence · one insured job, every actor's lifeline
How it maps to ERC-8183
The job lifecycle is a standards-track draft now: ERC-8183, Agentic Commerce defines a job with escrowed budget and the states Open, Funded, Submitted, Completed, Rejected, Expired. A covered job goes through the same states and ends the same ways:
OUR ENDING
ERC-8183 STATE
WHAT WE ADD
Done right
Completed
the premium goes to the pool that stood behind the job
Graded bad
Rejected
the verdict’s fingerprint rides in the reject call; the pool pays nothing
Nothing arrived
Expired
refund claimable by anyone past the deadline, so nobody can be locked out
Found to have cheated
no standard state
an arbitrator’s finding; the seller’s deposit, larger than the price, repays the buyer first
ERC-8183 ships its own extension point, the IACPHook interface, called before and after every core function, and the design attaches the assurance layer there, so that a covered job would be a standard job that happens to be guaranteed. That attachment is not live yet: the contract on Base carries the lifecycle and the layer together, and buyers and sellers call it directly. The standard is a draft, which cuts both ways: nothing about it is final, and the discussion is open to anyone, including us. The one boundary still being argued is what happens to a slashed provider bond: whether it pays the harmed party, capped at the adjudicated damage, or is burned. How that lands changes what a guarantee here is worth, so it is the part of the draft we follow most closely.
