Skip to main content

Reconciliation & Idempotency

Veyra coordinates several external systems that can be slow, duplicated, or temporarily unavailable:

  • Circle;
  • Arc RPC;
  • GitHub;
  • worker runtimes;
  • verifier runtimes.

The system therefore treats retries as a state-machine problem, not a repeated-button problem.

Transaction identity​

Economic actions store durable correlation identifiers before/while external work is submitted.

Examples include:

  • local transaction UUID;
  • idempotency key;
  • Circle challenge/transaction ID;
  • expected contract action;
  • Arc transaction hash/receipt;
  • expected commitment.

Reconcile before resubmit​

If a read fails after an external transaction may already have been submitted, Veyra first checks the existing transaction identifier.

It does not create a second transfer simply because status polling failed.

This rule is especially important for:

  • job funding;
  • job settlement/refund;
  • worker withdrawals.

Controller lease​

The execution controller uses a database lease so only one active controller advances shared workflow state.

Normal service restarts stop gracefully and release the lease before a replacement process takes over.

Runtime leases​

Worker and verifier tasks also use bounded leases/reservations.

Expired or failed leases can be recovered without treating missing output as successful work.

Duplicate-protection goal​

For one funded job, Veyra aims to converge to one authoritative chain of:

job
→ assignment
→ claim
→ PR/submission
→ verifier decision
→ settlement

rather than creating duplicate economic or repository side effects during retries.