Whitepaper

payrail is a payout rail for finance teams that pay many counterparties in stablecoins: contractors, vendors, affiliates, marketplace sellers and refund queues. It takes a payout file, commits it on-chain as a hash, requires a second signer to approve that exact payload, and then settles every recipient in one transaction against an allowance from a treasury the team controls.

The design goal is not lower fees alone; it is to make a spreadsheet-driven process enforceable. The controls a finance team normally documents in a runbook — separation of duties, no double payment, no silent edits after approval — become properties of the contract.

Paying 200 contractors on-chain today means either 200 individual transfers signed by one person, or a script with a hot key and no review step. Both are operationally weak:

• No separation of duties. Whoever builds the list also sends the money.
• No commitment. The list can change between review and execution, and nothing proves what was approved.
• Weak idempotency. A timed-out run is retried by hand, and someone gets paid twice.
• Reconciliation by screenshot. There is no export that ties transfers to invoice references and a batch identity.
• Fee unpredictability. Gas priced in a volatile token makes the cost of a payroll run unquotable.

Arc removes the last problem — USDC is the gas token with stable pricing and deterministic sub-second finality. payrail addresses the other four.

Two components: a stateless client that validates and hashes payout files, and PayoutDistributor, an AccessControl + Pausable + ReentrancyGuard contract holding no balance.

The client and the contract compute the same hash, so the browser can prove locally what will be accepted on-chain:

payloadHash = keccak256(abi.encode(token, recipients[], amounts[]))

submitBatch(batchId, token, total, recipientCount, payloadHash)
  → status Pending, stores payloadHash and submittedBy

approveBatch(batchId)
  → requires msg.sender != submittedBy, status Approved

executeBatch(batchId, recipients[], amounts[])
  → requires keccak256(abi.encode(...)) == payloadHash
  → status Executed (set before transfers)
  → safeTransferFrom(treasury, recipient, amount) per row

Because status is written before any transfer and Executed is terminal, a reentrant or repeated call cannot pay twice. The recipient list itself is not stored on-chain — only its hash — which keeps calldata cost the dominant term and avoids permanent storage of a payroll roster.

Residual risks: an admin key that can grant roles and change the treasury (keep it on a Safe), an unlimited allowance if the treasury approves maxUint256 (approve per-batch amounts for tighter control), and the fact that this code is not audited. Ten Foundry tests cover the happy path and each of the reverts above.

Cost per run is one transaction plus one ERC-20 transfer per recipient, priced in USDC. On Arc, fees are stable rather than a function of a volatile gas token, so a payout run can be quoted before it is signed. Splitting a 2,000-row file into four capped batches costs four transactions and four approvals — no per-recipient signing.

• Arc only: Arc mainnet is not publicly available, so the app is testnet-first and reads its chain from configuration.
• Amounts are public on-chain; only references stay off-chain.
• No scheduling, no fiat on/off ramp, no tax forms — payrail is the settlement leg.
• Not audited. Treat v0.1 as a testnet reference implementation.

The console is live on Arc. Start with the docs or open the payout console.