Proposed protocol

One clear mandate for one proposed action.

Zilch is exploring a bounded request model with explicit fields, a review step, expiry, cancellation before submission, and status that does not overstate what happened.

Prototype in development · This is a proposed model, not a live payment protocol.

Canonical fields

A mandate should make the reviewed scope legible to a person and deterministic to a future policy layer.

mandate_id: Synthetic identifier for this proposal.
item: Neutral description of the item under review.
amount_cap: The most the proposal may include.
currency: Currency stated by the synthetic example.
deadline: The point after which this proposal expires.
recurrence: One time unless a different future model is separately defined.
additional_fee_cap: The highest additional fee allowed by the proposal.
approval_required: Whether explicit user review is required before conceptual submission.
idempotency_key: A unique synthetic key intended to distinguish one attempt from another.

Synthetic mandate example

{
  "mandate_id": "synthetic-001",
  "item": "Household internet",
  "amount_cap": "126.40",
  "currency": "USD",
  "deadline": "Friday 16:00",
  "recurrence": "one_time",
  "additional_fee_cap": "0.00",
  "approval_required": true,
  "idempotency_key": "synthetic-attempt-001"
}

Proposed state sequence

Requested → Structured → Details checked → Awaiting approval → Approved → Submitted → Accepted → Settled → Credited

Later states describe concepts. The prototype does not contact a rail or biller and cannot produce real acceptance, settlement, or credit evidence.

Idempotency

A future implementation should use a unique key so a retry does not silently become a second action.

Expiry

When the deadline passes, the proposal expires. Continuing would require a new review.

Cancellation

A user can cancel before conceptual submission. Options after that point depend on a future rail and remain TBD.