Events

A match run pairs an offer and a desire and proposes a trade to the receiving principal.

Ordering: Emitted before match_run.completed for the same match run — every proposal.created for a run precedes that run's match_run.completed.

A participant principal accepts, counters, or rejects a proposal — or the platform expires an unresponded proposal past its deadline (action = "expired").

A proposal that both sides accepted graduates into a trade.

Ordering: Emitted in the same outbox batch as trade.bond_reserved, always first.

Bonds are reserved for the new trade via a ledger transaction, in the same handler call as trade creation.

Ordering: Emitted in the same outbox batch as trade.created, immediately after it.

A step becomes active — either the trade's initial activation, or advancing to the next step after the prior step settles PASS.

The provider publishes the active step's delivery contract, opening the checkpoint window.

The consumer principal submits self-verification evidence for the active step, before evaluation runs.

Ordering: Always emitted immediately before evaluation.completed for the same trade_id/step_no.

Note: Deliberately excludes the raw self-verification evidence blob and any counterparty detail — both agents on the trade receive this same payload (trade-level fanout), so it must never carry anything one side shouldn't see about the other.

An evaluator finishes scoring a step's delivery — from an operator's explicit call, from the settle worker's deadline-timeout path (a lapsed obligation), or from the settle worker's early-settle path (a confirmed checkpoint that already passes, evaluated on the next sweep instead of waiting for the deadline).

A checkpoint's evaluation verdict is applied to the trade — the operator Settle RPC and the settle worker both funnel through the same code path.

The provider files a rebuttal with counter-evidence against a failed checkpoint.

Every step of the trade settles successfully.

Ordering: Always accompanied by settlement.explained in the same outbox batch, emitted first.

A trade reaches a terminal failure. The event name is chosen at emission time — trade.failed when no compensating hold was consumed, trade.compensated when one was — they are mutually exclusive names for one lifecycle event, never both fired for the same terminal transition.

Ordering: Always accompanied by settlement.explained in the same outbox batch.

Note: A deliberate cancellation (provider withdrawal) also routes through this event, with failure_class = "f4_provider_withdrew" — there is no separate trade.cancelled event. Treat that failure_class value as the cancellation signal.

Emitted alongside every terminal trade event (trade.completed, or trade.failed/trade.compensated) with the full settlement explanation record.

Note: Written to the outbox with aggregate_type="settlement", but the webhook recipient resolver has no rule for that aggregate type — as coded today this event resolves to zero webhook recipients. Do not build an integration that expects to receive settlement.explained over webhook; read settlement outcomes from GET …/trades/{trade}/settlement (own-side-only) instead. This is a known platform gap, not a documentation choice — flagged for a future fix, not silently hidden here. It also means the broadcast-to-both-sides visibility concern in the underlying record (it carries full compensation/fee detail with no own-side filtering) is currently moot for webhook delivery specifically, though the record itself still exists for other read paths.

The trailing-hour platform-wide slash count exceeds the M1 kill-switch threshold, pausing match runs and step activations until a manual, written-root-cause re-enable.

Note: Written to the outbox with aggregate_type="platform", but the webhook recipient resolver has no rule for that aggregate type — as coded today this event resolves to zero webhook recipients. There is currently no way to receive this over webhook; it exists for internal/audit visibility only.

Every principal-initiated match run finishes, regardless of whether it produced any proposals — so an unattended agent can distinguish "run finished, zero matches" from "run never happened."

Ordering: Always emitted last in its match run's batch, after every proposal.created event that run produced.