Payment states

Every payment Setrya makes is one Zcash transaction that pays one approved batch of partners. The transaction moves through a fixed set of states, and Setrya refuses any move that isn't on the list below. A state only changes on something Setrya observed from the wallet or the chain. Nothing advances on a timer.

The happy path

1. Preparing. You chose Prepare for an approved batch. The wallet builds a PCZT under FullPrivacy from Ironwood notes.
2. Prepared, awaiting authorisation. The wallet's inspection matched the approval, check by check. Nothing is signed yet.
3. Creating proofs and signing. You authorised with your password. The job re-inspects the stored PCZT, then proves and signs it.
4. Signed, not yet broadcast. The signed bytes and the txid are stored, encrypted, before anything leaves your server.
5. Broadcast. The network accepted the transaction.
6. In mempool. The chain server sees the transaction, but it is not in a block yet.
7. Confirming. It is in a block, with fewer confirmations than the project's target.
8. Confirmed. It reached the target, 3 confirmations by default.

Every state

Allowed moves

CANCELLED_BEFORE_SIGN, FAILED_PRE_BROADCAST and BROADCAST_REJECTED are final. After one of them you can prepare the batch again, which builds a new transaction under a new lineage and needs its own inspection and authorisation.

Every move also checks a version number on the transaction. If two workers try to move it at once, the second gets a CONFLICT error and changes nothing.

The inspection before signing

Preparing ends with the wallet's inspection of the PCZT, compared with the approval. Every check has to pass, or the transaction goes to FAILED_PRE_BROADCAST with nothing signed.

The diagnosis names the cause. Not fully shielded means a privacy check failed. Prepared transaction does not match approval means a payee, amount, total or fee check failed. The job runs the same inspection again on the stored PCZT before proving, so a transaction that changed in storage is never signed.

When the outcome is unknown

A broadcast that times out may still have reached the network. Setrya never builds a new transaction for it, because that could pay twice.

1. The transaction moves to BROADCAST_OUTCOME_UNKNOWN, and a reconcile job starts looking it up.
2. If the chain server finds it, it moves on to MEMPOOL_OBSERVED, CONFIRMING or CONFIRMED.
3. If the chain doesn't know it, it moves to INVESTIGATION_REQUIRED.
4. From there you have two choices on the payment's page:
   • Resubmit the same bytes. Setrya checks the chain first, then sends the identical signed transaction again, with the same txid. That cannot create a second payment.
   • Declare not broadcast. Allowed only when the chain has never seen the txid and the chain is past the transaction's expiry height, so the signed bytes can no longer be mined. You record a reason, and the transaction becomes FAILED_PRE_BROADCAST.

Reorgs

A transaction that was CONFIRMING or CONFIRMED and then shows up back in the mempool, or disappears, moves to STALE_OR_REORGED. Setrya keeps looking it up and moves it on as the chain settles. The reconcile job keeps watching a confirmed transaction until it is 10 confirmations past the target, because a reorg can still demote it until then.

One payment at a time

Only one transaction per payer account can be in flight between PREPARING and broadcast. Preparing takes a database lock on the account, and a second Prepare gets "Another payment from this account is being built or signed. Finish or cancel it first."

How payouts and periods follow

Each payout shows a simpler stage derived from its transaction. A payout counts as paid only when its transaction is CONFIRMED.

A period moves to In payment once any batch has a live transaction, and to Payments resolved once every batch is confirmed or finally failed, with at least one confirmed. Approve and pay walks through the screens.