Settlement Signals
When a verification verdict reaches terminal, AGLedger emits a Settlement Signal — SETTLE, HOLD, or RELEASE — to the payment, ERP, or ticketing system that actually moves value. The signal payload carries the signed verdict, the chain position, and the public-key fingerprint that signed the terminal entry, so the downstream system can verify what it received against the chain before acting. AGLedger does not move money; it produces the signed record that authorizes the systems that do.
USPTO 19/565,072 · SETTLE / HOLD / RELEASE · Webhook-delivered · Federation-aware
Last updated: 2026-05-25 · API v0.25.4
The three signals
One verdict, one signal
Settlement Signals are a closed enumeration: SETTLE, HOLD, and RELEASE. Each one corresponds to a specific terminal moment in the verification lifecycle. The signal travels by webhook, signed by default with Ed25519 RFC 9421 HTTP Message Signatures against the originating Server's vault key — the same key that signs the chain. The receiving payment system verifies it against the Server's public keys with no shared secret, so a settlement instruction is provable to a third party as it crosses a company boundary.
SETTLE
Fires when a record reaches terminal FULFILLED — the principal accepted the delivery, or the rules engine rendered PASS in auto mode. Tells the downstream system that the verdict is positive and value movement is authorized.
HOLD
Fires when a record reaches terminal FAILED — the principal rejected the delivery, or the rules engine rendered FAIL in auto mode. Tells the downstream system that the verdict is negative and value movement is blocked.
RELEASE
Fires on dispute Tier 1 auto-overturn — when the verification engine, re-run against the latest completion with expanded tolerance bands, flips a prior FAIL to PASS. Tells the downstream system that the prior HOLD was resolved in the performer's favor and the corresponding value movement may now proceed. Opening a dispute does not fire a signal; only a successful automated re-adjudication does. See disputes for the full Tier 1 mechanism.
Firing points
Tied to terminal record state, not to API calls
A signal fires exactly once per terminal transition. Whether the verdict came from /outcome, from the rules engine in auto mode, from a cascading auto-rollup of a parent record, or from dispute Tier 1 auto-overturn — the path into the terminal does not change the signal contract. Subscribers always see one signal per verdict.
Notarize-only records do not fire signals. A record that terminates at RECORDED with no verification phase has no verdict to settle. Settlement Signals are part of the verification path; if you want signals, your contract type needs a completion schema.
Cross-organization
Federation projects signals so subscribers see one stream
In cross-organizational work, a verdict can be rendered on either Server. AGLedger projects peer-emitted signals into the local event surface so a downstream system subscribed to one Server sees every signal that touches it — whether the verdict was rendered locally or on a counterparty's Server.
Two event types separate origin at the subscription level rather than by payload inspection:
signal.emitted— the local Server fired the signalsignal.received— a peer Server fired and we projected it
Subscribe to both for full visibility into cross-org verdicts. The webhook subscription, signing, retry, and circuit-breaker mechanics are documented on the webhooks page.
Intellectual property
USPTO 19/565,072
The Settlement Signal mechanism — a three-state cryptographically grounded webhook authorization tied to a federated verdict, with explicit RELEASE semantics on automated dispute overturn — is the subject of US non-provisional patent application 19/565,072, filed 2026-03-12. The trademark Settlement Signal is applied for under USPTO trademark filings owned by AGLedger LLC.
The Settlement Signal API and webhook event surface are covered by the standard AGLedger license. See /license for the controlling terms.
What makes it different
Authorization from a signed verdict, not from a workflow status
Most webhook-based settlement systems fire on workflow transitions: a record was marked complete, a button was clicked, a status changed. AGLedger Settlement Signals fire on terminal verdicts inside a tamper-evident chain — the signal payload carries the record ID, the verdict, the principal and performer identities, the chain position, and the public-key fingerprint that signed the terminal entry. The downstream system can verify offline that the signal it received is the one the chain says fired.
The RELEASE state is the part the model makes possible. Opening a dispute does not fire a signal. RELEASE fires only when expanded-tolerance re-adjudication proves the prior verdict was too strict. Downstream payment and ticketing systems see a structured re-adjudication signal tied to a signed verdict, not a manual override.
Related capabilities
The verdict that fires a Settlement Signal — how the accept or reject is rendered and signed.
In cross-org workflows the Settlement Signal projects from the verdict-rendering Server to the side that owns the payment system.
Delivery mechanics: the two signing schemes, retry policy, dead-letter replay, and how to verify a signal against the Server keys.
The SCITT and outcome routes that emit a Settlement Signal and the predicate that carries it on-chain.
Why a transparency-service receipt plus a Settlement Signal is the missing primitive for agent-to-agent commerce.