Document anchor
Ties a payment to the invoice, order or receipt it settles — the control against paying the wrong party.
The gap it closes
On-chain verification proves a transfer happened with a given amount and status. It cannot prove the payee was correct — the chain confirms your own record, faithfully. A wrong-party payment is a document-side failure, so it needs a document-side control: a payment should know which document it is for.
How it works
{
"accountId": "acc_vendors",
"amount": "1250.00",
"address": "0x…",
"label": "Acme",
"documentRef": "INV-1042"
}| Behaviour | |
|---|---|
| Below the threshold | Optional. The control does not apply. |
| At or above the threshold | A document is required; without one the payment waits for a person. |
| Obligation-driven payments | Cite the obligation automatically — the commitment is the document. |
| Recalled or refunded | The anchor stays with the original action, so the paperwork history survives. |
Configuring it
The threshold is the policy row document_anchor_threshold (default $10,000). Set it to 0 to disable the control, or lower it for a treasury where every payment should be documented. The rule is policy.document_anchor and the approval reason is the same id.
Where the reference appears
- REST:
documentRefin the proposal body; returned on every action. - MCP:
documentRefon thepropose_paymenttool. - Ledger: stored on the action row, so the reason a payment existed is queryable later.
Not a full three-way match
The anchor is a schema place for the document, not an ERP. A full three-way match — invoice against order against receipt, with line items and tolerances — is the natural extension, and this is where it will live.