On this page

Relayers & Runtime

Submit prepared proofs, check transaction status and finish pending settlement.

Relay a prepared request#

The holder sends a proof and public inputs. Before broadcasting, the relay checks the deployment and verifier, route, reserves and fee policy. Private witnesses stay in the browser.

The relay can refuse or delay submission. It cannot change the authorized recipient or outputs and keep the proof valid. Its own wallet appears as the public sender instead of the holder's transaction wallet.

How the wallet, Pool and disclosure tools fit together
How the wallet, Pool and disclosure tools fit together

Start the development runtime#

Run the queue bootstrap and API in separate processes with the same runtime directory. They use a disposable fork, public proof files and a test sponsor. Production operation needs its own deployment and service setup.

bash
# Separate terminals on the provisioned Linux development host:
node apps/privacy/runtime/queue-chain-bootstrap.cjs
node --experimental-strip-types apps/privacy/runtime/queue-api.cjs

Check before sending#

Check Pool and verifier identity along with current routes and assets. Estimate and simulate the transaction at a consistent block, then save its broadcast intent. After sending, check the receipt; simulation cannot guarantee the eventual result.

Give requests stable status lookups by transaction hash and chain state. If HTTP loses a response, use those lookups instead of automatically creating a second proof or transaction.

Run a payment worker#

SessionManager needs a durable merchant store and a backend that can submit claims. Its worker settles accepted vouchers and watches closure. Run paid provider jobs in your application separately.

Allow for RPC age, clock skew and confirmations inside the close window. The session backend checks read age; confirmations and readConfirmations affect when changes are observed. Stop acceptance on stale or backward state until it is reconciled.

Complete credits and actions#

A Portal keeper credits the recipient named by the invoice. An action finalizer appends the measured output already fixed by execution. Neither can choose a new private recipient.

Anyone can call these transitions, but they still need gas and available public witness data. Monitor unfinished work and offer the holder a direct way to finish it.