Referee
The webycash-referee is a separate
native Rust hyper service that arbitrates the conditional leg of a swap. It is not implemented in
this website and it never holds your funds. It observes commitments and proofs, and releases an
arbitrable signature only when the conditions are met. It serves peers and agents identically
(PA2AP).
Public endpoints
The referee publishes a read-only status endpoint and its signing key. These are public links; the website never proxies them and never forwards secrets.
Keyserver: https://extro.network
What it can see
- +Immutable signed limit orders and their public commitments (order id, amounts, price).
- +Ciphertext and its hash for encrypted bearer delivery payloads.
- +Recipient PGP fingerprint and recipient public-key commitment.
- +ZKP proof bytes, public inputs, circuit id/version, and verifying-key commitment.
- +Signatures, session/nonce bindings, and per-transition audit-log entries.
- +Public token hashes used to bind a fill to an order, not the bearer plaintext.
What it cannot see
- −Bearer secret plaintext for Webcash or Voucher legs.
- −Wallet private keys, seed material, or decrypted payload contents.
- −Both halves of a MuSig2 secret-signature path for an ARK 2-of-2.
- −Any ability to move funds unilaterally, on any rail.
- −User balances, wallet inventory, or off-order holdings.
Why this is not custody
- •It never receives bearer secret plaintext, so it cannot redeem Webcash or Voucher.
- •It never holds both partial signatures of an ARK 2-of-2, so it cannot unilaterally release.
- •It only releases an ARK partial signature against fresh proof the other leg reached the required state.
- •Every release is conditional, idempotent, signed, and audit-logged; it arbitrates, it does not hold.
Runtime model
- •A native Rust hyper service (Lambda-equivalent handler), not a generic edge Worker or interpreted runtime.
- •Swap progress lives in a transactional store, advanced only by compare-and-set so a transition cannot double-apply.
- •Single-instance: at most one active instance owns in-flight swaps; there is no multi-writer race on the store.
- •Every transition is conditional, idempotent, signed, and audit-logged. The referee arbitrates; it never holds funds.
Refund & abort
Abort and refund are distinct. An aborted swap does not auto-refund — the refund leg releases only against a signed acknowledgement from the bearer seller.
Ack-gated refund
An aborted swap refunds only against a signed acknowledgement from the bearer seller. There is no automatic refund; the refund leg releases on the signed ack, not on a timer.
Cap-exhaustion stays aborted
If the referee exhausts its release cap, the swap stays aborted. The ark-provider recovers its side independently via the ARK refund timeout — the referee does not force a refund.
Restart aborts in-flight (availability)
Because a single instance owns in-flight swaps, a restart aborts those swaps to the refund path. This is an availability tradeoff of the single-instance model, not a custody or atomicity property.
§4.5 bearer front-running (accepted, bounded)
The §4.5 race is accepted and bounded: the ark-provider bears at most one swap of exposure. This is the same bounded-risk, non-atomic bearer leg already documented — not a custody admission.
Fail-to-deliver flow
A paid action can fail cleanly after pre-check rather than half-settling. The high-level flow:
- 1
Pre-check
A paid action validates inputs before any irreversible side effect.
- 2
Explicit failure
If delivery cannot complete, the scheme fails after pre-check rather than half-settling.
- 3
Signed failure receipt
The referee/maker returns a signed failure receipt bound to the order and party commitments.
- 4
Holder callback
A callback fires to the original holder to invalidate or rotate the bearer secret.
- 5
Idempotent hook
The wallet hook is idempotent by (swap_id, kind, payload_hash); replays are no-ops.
- 6
No proof from push
Push delivery is never trusted as proof of processing; a signed wallet ack or independent rail post-check decides state.