Overview
A Private Programmable Account is the programmatic, server-to-server surface for confidential disbursement on Ligetron: no browser, no wallet-popup signing, no dashboard. The Funding Party (or an integrator acting on its behalf) drives everything from a backend service or a scheduled job, against two surfaces:
| Surface | What it does |
|---|---|
| Eligibility | Query and maintain who is allowed to receive funds from the pool: the whitelist and blacklist. |
| Disbursement | Trigger a disbursement run: proves the batch, collects a funder authorization, and settles on-chain. |
| Account Operations | Operate on your own pool balance: enroll as a pool subject, transfer to another holder inside the pool, or withdraw out to a chain address. |
Both surfaces sit behind bearer-token authentication; see Authentication & API Access before making your first call, or jump straight to Getting Started for the shortest path to a working integration. Unfamiliar term? Check the Glossary.
There is no in-browser flow anymore. Disbursement is driven by a small service you run yourself, the disbursement agent, which holds your prover and calls out to the platform over an authenticated edge.
Infrastructure at a glance
Four things are involved, split across three trust boundaries: your own infrastructure, Ligero's, and the chain itself.
The only piece that runs on your side is the disbursement agent: it holds the prover and, in its default configuration, no private keys. Everything under "Ligero-Operated" (onboarding, API-key issuance, the pool-gate, and the relayer that submits fund()) is infrastructure Ligero runs on your behalf. The pool contract is the only piece that lives on-chain, on whichever chain your deployment is configured for.
Core concepts
Funding Party
The party that owns the account, controls the funder wallet, and authorizes every disbursement. Some literal API paths still say "employer" (e.g. POST /api/employers/onboard) for historical reasons, but nothing about this role is payroll-specific; it applies to any programmatic, recurring, or one-off private disbursement use case. This page and the rest of this section use "Funding Party" throughout; treat employer/employers in a path or field name as that same role.
Wallet public key (W)
Every participant, funder or recipient, is identified by the uncompressed public key of their wallet: the x and y secp256k1 coordinates concatenated as 128 lowercase hex characters, no 0x prefix. This is the value the ZK circuit and the pool-gate eligibility service actually bind to. It is not the wallet's on-chain address: an address only tells you where funds settle, not the identity a proof can verify against. Anywhere this section asks for a recipient, it means an address (which the platform resolves internally); anywhere it talks about eligibility, it means W.
Pool-gate
The standalone eligibility service that holds the whitelist and the blacklist of participant public keys and issues the signed eligibility material (whitelist signatures and blacklist non-membership proofs) that a disbursement proof needs as private inputs. A recipient whose W isn't whitelisted causes proof generation to fail closed; there is no on-chain fallback.
Disbursement agent
A small service you run yourself (co-located with your own infrastructure, not the Ligetron platform) that holds your GPU-backed prover and talks to the platform only over an authenticated outbound edge. It exposes the /api/disburse endpoint documented in Disbursement. It never sees or holds your recipients' private keys, and in its default configuration it doesn't hold your funder's private key either; see the signer options on that page.
Note commitment
For each recipient in a disbursement, the prover generates a note commitment that cryptographically binds the recipient's W, the amount, and random nonces. Only the commitment is published on-chain; none of its inputs are recoverable from it.
Earlier versions of this section described a browser-based dashboard (MetaMask/WalletConnect signing, an in-page prover) framed narrowly around payroll. That flow has been retired, and the framing has been generalized: disbursement is now driven entirely through the agent's HTTP API, and the funder's signature is produced by whichever FunderSigner you configure (a local key, a signing enclave, Fireblocks, or DFNS), never by a browser wallet popup.