Skip to main content
authorized_settler lets a payment commitment name an additional submitter without changing who signed the payment update. The distinction is simple:
  • authorized_signer signs the payment update.
  • authorized_settler can submit that signed update on-chain.

​
Why it exists

Many teams do not want to run settlement operations themselves. They may prefer a third party to handle relaying, batching, invoicing, compliance checks, or payment operations. authorized_settler gives them a protocol-level way to delegate submission while balances stay in protocol state. Common examples:
  • payment gateways
  • invoicing providers
  • compliance and KYT services
  • operator hubs
  • internal payment operations services
For the larger network pattern that often sits on top of this feature, see Operator hubs.

​
Additive, not exclusive

authorized_settler does not remove the payee’s right to settle. If a commitment includes authorized_settler, then either of these may submit it:
  1. the payee owner, or
  2. the delegated settler named in the signed message.
This preserves the always-available direct settlement path while still allowing operational delegation. See Design principles for why this matters.

​
Where it applies

authorized_settler only applies to unilateral commitment messages:
  • settle_individual
  • settle_commitment_bundle
It does not affect cooperative clearing rounds. Clearing rounds are keyed to the signed participant roster, not to a delegated unilateral submitter.

​
Example

const message = createCommitmentMessage({
  payerId: channel.payerId,
  payeeId: channel.payeeId,
  tokenId: 1,
  committedAmount: nextAmount,
  messageDomain,
  authorizedSettler: operator.publicKey,
});
After the message is signed by the channel’s authorized_signer, either the payee or operator.publicKey may submit it.

​
Operator payment is separate

authorized_settler does not automatically pay the operator. If the operator should be compensated, model that payment as its own ordinary channel commitment. In practice that means flows like:
  • payer → provider for the service itself
  • provider → operator or payer → operator for settlement or coordination services
Keeping operator compensation on its own channel makes it durable and cumulative instead of embedding it as a one-off field in the unilateral commitment message. It also lets the operator’s inbound balance participate in bundle or cooperative settlement.

​
What it is not

authorized_settler is not an escrow primitive. It does not:
  1. give the delegated settler control over the amount
  2. make the delegated settler the only party allowed to settle
  3. add dispute-resolution logic
  4. let an external program control settlement policy on-chain
It is strictly delegated submission for unilateral settlement. Everything else stays in the payer’s hands.

​
See also