Quorly

Demo

About

Quorly is invoice approvals and stablecoin payouts, run from Slack, where the approval is proven to come from a live human and the payout is released by a key quorum rather than by our application. The problem. Today "approve" is a button click authenticated by a session cookie. A stolen laptop, a hijacked cookie or an over-eager automation can click it, and the audit trail records only that a click happened. Meanwhile the invoice itself waits days in a tool nobody opens, and the contractor chases payment. How it works. A contractor DMs an invoice PDF to the Slack bot, or files it from the dashboard. Claude reads the document and extracts the amount, invoice number and description. Quorly routes it against the company's spend policy and notifies only the people who actually hold authority to approve it. Above a dollar threshold the approver must pass a live World ID Selfie Check before their approval counts. Once the quorum is satisfied, a Privy server wallet releases the payment in stablecoin on Base Sepolia, and the transaction hash lands on the invoice. Approvals scale with risk. Under $500, one approval and no biometric check. $500 to $5,000, one approval with a live selfie. Above $5,000, two approvers each with a check under three minutes old. Nobody can approve their own invoice. What makes the guarantees real. Each Selfie Check proof is bound to one invoice and one approver, expires in minutes, and is burned before verification, so a stale or replayed proof records nothing. The treasury is owned by a 2-of-3 Privy key quorum with its spend policy enforced inside a secure enclave: "two approvals required" is not a flag in our database that we could flip, it is the wallet's owner. The payout is an eth_sendTransaction carrying a threshold of quorum signatures, so Privy's enclave checks the signatures and the policy in one pass and either broadcasts or refuses. Engineering. A Go backend owns all state. Approvals and their payout jobs are written in the same transaction, a transactional outbox, so an approval can never exist without its payout being scheduled. The job queue lives in Postgres using SELECT … FOR UPDATE SKIP LOCKED with leases, jittered exponential backoff and dead-lettering, because a message broker would reintroduce the dual-write problem the outbox exists to solve. Everyone on the roster gets their own Privy wallet, so being paid means holding the money rather than waiting on a bank. Also in Slack. Mention the bot and it answers from your real invoices — what is waiting on you, where a payment got to, why you cannot approve something — and hands you the link into approving it. It has no tools and no database access; every fact is assembled server-side first, so it cannot invent an amount or an invoice. Live at quorly.xyz

How it's made

The stack. A Go backend owns everything — policy, Privy, World ID, Slack, and the worker pool — and is the only thing that touches Postgres. Next.js 15 on the front is a client: it forwards the viewer's Privy token and renders what comes back, so authorisation is decided in exactly one place. Foundry for QUSD, the test settlement token on Base Sepolia. Deployed with Docker and Caddy on a single box, Postgres on Neon. The queue is the interesting part. Approvals and their payout jobs are written in the same transaction — a transactional outbox — so an approval can never exist without its payout being scheduled, and vice versa. That's why the queue lives in Postgres rather than a broker: a broker reintroduces the dual-write problem the outbox exists to solve. Workers claim with SELECT … FOR UPDATE SKIP LOCKED, hold leases so a crashed worker's job becomes claimable again, retry with exponential backoff jittered across [d/4, d] to desynchronise a fleet, and dead-letter rather than silently dropping. A RetryLater return reschedules without consuming an attempt. Privy gives the guarantee the product is built on. The treasury is a server wallet owned by a 2-of-3 key quorum with an enclave-enforced spend policy: settlement token only, allowlisted payees, per-transfer ceiling. "Two approvals required" isn't application state we could flip; it's the wallet's owner. Every member also gets their own Privy wallet, so being paid means holding the money. World ID Selfie Check is used as a risk signal, never as identity. It's medium-assurance — liveness and facial similarity, no one-person-one-account guarantee — so authority still comes from the quorum. Selfie Check answers one narrower question: was a live human behind this click? We mint a signed rp_context per approval and record its nonce as a single-use challenge bound to one invoice and one approver, burned before verification so a slow verify can't be raced. Claude reads the invoice PDF and extracts amount, number and description. A second model on OpenRouter powers the Slack assistant, which gets no tools and no database access — every fact is assembled server-side and passed in as context, because retrieval the model controls is retrieval nobody can audit, and this system moves money.