Settlement Signals™
When delegated work ends in a verdict (accepted, rejected, or overturned on dispute), some system downstream has to act on it: pay the invoice, hold the payment, release the hold. Today that system acts on a workflow status someone could have set by hand. A Settlement Signal is the same instruction with proof attached: SETTLE, HOLD, or RELEASE, signed, so the system that moves the value can verify the verdict behind it before acting, even when the verdict was rendered at another company.
Mechanically: when a gated verdict closes a chain, AGLedger emits the signal to the payment, ERP, or ticketing system you subscribe. The 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 it acts. AGLedger does not move money; it produces the signed verdict that authorizes the systems that do.
Settlement Signals are one payload class on the Notify channel - not the whole of it. Notify delivers every kind of durable signed event; this page owns one of them: the structured instruction that turns a terminal verdict into an authorization a value-moving system can act on and prove. For where this sits next to the agentic-commerce payment protocols, see what AP2, ACP, and x402 leave out of scope.
USPTO 19/565,072 · Signed verdict → settlement instruction, bound to the chain · SETTLE / HOLD / RELEASE · Cross-Org
Last updated: 2026-06-11 · API v1.2.0
The three signals
One terminal verdict, one signal
Settlement Signals are a closed enumeration: SETTLE, HOLD, and RELEASE. Each corresponds to a specific terminal moment in the gated lifecycle. Only gated verdicts produce signals; the signal is the outbound expression of the verdict the principal rendered, signed by the originating Server's instance key - the same key that signs the chain - with the accountable principal named inside the payload. Delivery is by Notify webhook, signed by default with Ed25519 RFC 9421 HTTP Message Signatures. The receiving payment system verifies it against the Server's published verification 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 accept 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 reject 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 rules engine, re-run against the latest completion with expanded tolerance bands, flips a prior reject to accept. 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 the Gate dispute mechanism for the full Tier 1 lifecycle.
Firing points
Tied to terminal verdict state, not to API calls
A signal fires exactly once per terminal transition. Whether the verdict came from /verdict, 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 gate has no verdict to settle. Settlement Signals are the actionable tail of a gated span; if you want signals, your contract type needs a completion schema. How that verdict is rendered and signed is owned by the Gate - this page picks up at the terminal state.
Cross-organization
One signal stream across organizational boundaries
In cross-organizational work a verdict can be rendered on either Server. The signal projects across the federation transport 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 peer-to-peer signed-message transport is owned by Federation; the subscription, signing, retry, and circuit-breaker delivery mechanics are owned by Notify.
Intellectual property
USPTO 19/565,072
The patent covers the mechanism, not the webhook. A unit of delegated work is cryptographically signed and hash-chained through every hand-off, carried through review and a signed accept-or-reject verdict, and only then terminated by a settlement instruction bound to that verdict and the exact chain position that produced it. The three states - SETTLE, HOLD, and RELEASE, with explicit RELEASE semantics on automated dispute overturn - and the instruction's provability as it crosses an organizational boundary are the claimed novelty. The webhook is only how the signal leaves the building.
This mechanism is the subject of US non-provisional patent application 19/565,072, filed 2026-03-12. Settlement Signal is a trademark of AGLedger LLC (USPTO application SN 99881099, filed 2026-06-12).
The Settlement Signal API and 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. A Settlement Signal fires on the terminal verdict of a tamper-evident chain - the payload carries the record ID, the verdict, the named 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 gated lifecycle that produces the verdict a Settlement Signal acts on - how accept or reject is rendered and signed.
The channel that carries Settlement Signals as one payload class - signing schemes, retries, dead-letter replay, verification.
Peer-to-peer signed-message transport that projects a signal from the verdict-rendering Server to the side that owns the payment system.
The 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.