Architecture

Confiroll is a pnpm/apps/ monorepo. The design principle behind everything below: the confidential work happens in the browser, and the server stays thin. Confiroll’s backend holds no user keys. It authenticates sessions, fee-bumps already-signed transactions, and relays them to the chain. Two live hosts run the deployment: the payroll-api BFF at https://api.confiroll.com, and the headless SDP at https://sdp.confiroll.com. Everything settles on the Stellar testnet.

​

The pieces

​

Repository layout

Every part of the system maps to one directory in the monorepo. When you read the source, this is where each responsibility lives:

​

How a confidential payout flows

The core write path (Fork B) keeps the employer’s keys in the browser and lets Confiroll sponsor the fee without ever holding a secret: The employer signs the inner transaction as its source account, so the confidential token’s from.require_auth() is satisfied by a plain signature, with no fragile auth-entry signing. Confiroll wraps that signed transaction in a fee-bump and pays the outer fee, so the employer spends 0 XLM. The amount is never an argument. It lives inside the proof. See The non-custodial model for why this “Fork B” design is the pivotal decision.

​

Request lifecycle: one Fork B transfer

Read the diagram above as a story. Here is the same path in prose, so you can see where each guarantee comes from:

1. You log in. The browser runs SEP-10 against payroll-api: it fetches a challenge from GET /auth/sep10/challenge?account=G..., signs it with your wallet, and posts it to POST /auth/sep10/verify. The API returns a session JWT whose sub is your G-address. The challenge is single-use and expires in 5 minutes.
2. The browser builds the transfer. Using your viewing key sk, the client encrypts the amount to the recipient’s public viewing key and generates the zero-knowledge proof with bb.js. The confidential_transfer call carries no plaintext amount.
3. You sign the envelope. Your wallet signs the inner transaction with a plain signTransaction. You are the transaction source, so source-account auth satisfies from.require_auth(). The signature never leaves as a secret: only the signed transaction travels.
4. The browser posts { signedXDR }. The request goes to POST /transfer with your session JWT in the Authorization: Bearer header.
5. The API checks the binding. requireSession validates the JWT, then the route asserts inner tx.source == session.sub. If you try to fee-bump someone else’s transaction, the API returns 403. A Privy session cannot use this route and returns 501; only SEP-10 sessions fee-bump.
6. The sponsor validates before it signs. It checks the contract allow-list, the fee cap, and the per-account quota. If it refuses, the API returns 422. If it accepts, it builds a CAP-15 fee-bump with an outer fee of twice the inner fee, signs the bump, and submits over Soroban RPC.
7. The chain settles. The confidential token executes the transfer. The RPC polls to SUCCESS, and the API returns { hash, status: "SUCCESS" }. The fee account on-chain is the sponsor, and your account moves by 0 XLM.

The sponsor never needs the employer’s secret. It only pays the outer fee. That single fact, plus browser-side proving, is what makes the path non-custodial and gas-free at the same time.

​

What runs where

​

Design principles

Three rules explain almost every choice in the codebase: Because those three hold, amounts stay hidden from the public, from other employers, and from Confiroll itself. That property has a name in these docs: Confiroll-blind.

​

Keep reading

​

FAQ