Treasury & controls
The approval boundary is yours.
ProxyPay evaluates policy and reserves a proposed action. Authorising it is something only merchant-controlled keys can do — by design, and by the absence of any signer in our code.
Vault topology
- Parent governance account
- One multi-approval account per retailer, with a quorum of named seats. It governs the accounts below it. ProxyPay holds no seat.
- Location receiving accounts
- One receiving address per location, used as the recipient in payment requests for that location.
- Central treasury
- Where consolidated funds sit between store sweeps and the exchange transfer.
- Per-location refund vaults
- Refunds leave from a dedicated vault per location, so a refund can never draw on the day’s takings by accident.
Refunds
A refund is a new, merchant-initiated transfer. ProxyPay checks it against the original payment before it is ever presented for approval, and holds the reservation for as long as the outcome is uncertain.
confirmed_refunds
+ reserved_refunds_in_flight
+ this_proposed_refund
<= original_confirmed_amountThe check is made inside the transaction that reserves the refund, against locked rows, so two managers proposing at once cannot over-refund a payment between them.
- A refund binds the original payment, the payer, the verified receiving-account owner, the source vault, the destination, the network, the mint, the exact amount, the reason, and the authenticated actor, role and device.
- Before any handoff that could make broadcast status uncertain, ProxyPay records a submission hold.
- A timeout, a missing callback or an unknown result does not release anything. It stays on hold until authoritative evidence and a named reviewer clear it.
- The displayed proposal is compared field by field with the decoded action before approval. A mismatch is a denial, not a best-effort continuation.
Sweeps and close-out
Close-out summary
At the end of the day, requests issued, payments observed, exceptions still held and refunds in flight are reconciled into one summary. Chain facts and POS facts are kept separate; a POS fact never stands in for missing chain evidence.
Store to central
A consolidation proposal binds the exact source, the central destination, the network and mint, caps per transfer and per period, residual balances, the pause state, and a fresh signer-health reading. Fragmented proposals share one atomic period counter.
Central to exchange
One review proposal per entity, date and policy path, held pending the merchant’s quorum. A direct store-to-exchange transfer is denied by default.
Approval
A manager or the retailer’s quorum approves on merchant-controlled keys. ProxyPay records the decision; it cannot make it.
Observation
Capacity stays reserved from proposal through submission and any unknown result. Only authoritative confirmation consumes it, and only authoritative terminal failure releases it.
Signer health
Approval capacity is a live operational fact. How many seats can actually sign right now decides what the system will let you propose.
| Seats reachable | State | What is permitted |
|---|---|---|
| 5 of 5 | Normal | All configured actions, within policy caps. |
| 4 of 5 | Degraded — replace | Normal actions continue. Replacing the missing seat becomes required work, not a reminder. |
| 3 of 5 | Critical — close-out only | Only unchanged, pre-authorised close-out actions, including bounded store-to-central consolidation. Transfers to an exchange are forbidden. A deadline moves the state to a terminal pause. |
| Fewer than 3 | Stop directing funds | New funds must not be directed to these accounts. There is no lower threshold, and no ProxyPay or vendor fallback exists. |
There is no key of last resort
ProxyPay holds no seat, no share and no recovery key. Recovery is a documented set of possession checks, drills and replacements that the retailer runs with its own people. We help you rehearse it; we cannot perform it for you.