TREASURY / ELPIS

Counterparties

Per-recipient trust, payment history, and the control that catches a substituted wallet.

What Elpis tracks

Field	Meaning
`name`	Human label for the recipient.
`category`	e.g. vendor, infrastructure, payroll, tax-authority.
`trustLevel`	NEW · KNOWN · TRUSTED.
`addresses`	The wallet address(es) on file for this recipient.
`paymentCount`	How many payments have settled.
`medianPayment`	Median settled amount, the basis for anomaly checks.

Trust levels

NEW — no history. The first payment requires a person, and payments are capped by new_recipient_max_amount.
KNOWN — has settled payments. Eligible for autonomy within limits.
TRUSTED — an established relationship; the highest autonomy.

The substituted-wallet control

The failure an amount limit cannot catch is the right amount paid to the wrong party. The most common route is a changed bank/wallet detail on a genuine invoice.

If a payment’s recipient address differs from the one on file, the action is frozen before any funds move.
policy.recipient_changed is a blocking rule — a person must resolve it, it cannot be waved through by a limit.
A counterparty can legitimately change address; the point is that it is a deliberate act with a record, not a silent one.

This is the control research names first when asked what actually catches commission. Elpis makes it blocking rather than a log line.

Amount anomalies

For a counterparty with at least three settled payments, an amount above anomaly_multiplier × medianPayment (default 3×) escalates to a person. The check uses the counterparty’s own history, not a global threshold, so a large vendor’s normal invoice is not treated as suspicious.

Categories and pools

Each pool lists the recipient categories it may pay. A payment to a category the pool does not allow escalates to a person. This is what keeps a payroll pool from funding a vendor, and a reserve pool from funding anything at all.