01 · Privacy model
Hide the amount without hiding the existence of the payment
Lucent's sender and receiver remain public and verifiable. The amount is the confidential component. Each account balance is represented as a Pedersen commitment on the Grumpkin curve, so the chain can store and update committed value without learning the opening.
This is not anonymous cash. Observers still see which accounts interact and when. The narrower goal is useful for payroll, business payments, escrow, and other flows where counterparties may be known but the value should not be globally readable.
02 · Protocol
Spendable and receiving balances separate incoming value from spend authority
Every confidential account has a spendable commitment and a receiving commitment. Public deposits and incoming confidential transfers land in receiving. A homomorphic merge folds receiving into spendable without a proof. Withdrawals and outgoing transfers require an UltraHonk proof generated by the holder.
The public deposit amount is intentional. It lets the underlying USDC reserve remain auditable. Once value is inside the confidential system, transfer and withdrawal amounts are hidden behind commitments and proofs.
Bind a Grumpkin key set to the Stellar account.
Move public USDC into the receiving commitment.
Fold receiving value into spendable homomorphically.
Prove a valid confidential debit and recipient credit.
Prove a confidential debit and release public USDC.
03 · ZK pipeline
The browser proves; Soroban verifies
A Soroban contract cannot generate a proof. The holder's browser reconstructs the private opening, builds the witness, and produces the UltraHonk proof. The confidential-token contract delegates verification to a registry of circuit verification keys backed by native BN254 verification on Stellar.
If the proof is valid, the contract updates the old and new commitments without receiving the plaintext amount. This division keeps secret material client-side, but it also means browser performance and reliable local state are part of the security and usability model.
04 · Product architecture
Payroll and escrow expose the difference between a primitive and a product
PayrollVault orchestrates an atomic set of employee transfers, but it does not custody a plaintext salary table. The employer's browser generates one confidential-transfer proof per employee, and the vault routes the results as a single run. Each salary remains opaque to other employees.
Escrow is more difficult because the instance contract must eventually release funds without a human-held secret. Lucent pre-generates recipient and refund payout proofs before funding, stores them in a separate transaction because the combined proofs exceed Soroban transaction limits, and later selects one proof according to the escrow state machine.
That workaround has a serious trust caveat: the depositor derives the escrow instance secret while generating the payout proofs and must discard it. Retaining it could allow a re-spend that invalidates both stored outcomes. The design is acceptable for a testnet demonstration, not production custody.
05 · Compliance
Confidentiality and selective auditability can coexist
Every transfer emits two auditor ciphertexts - one associated with the sender channel and one with the recipient channel - encrypted to a registered Grumpkin auditor key. The authorized auditor can decrypt transfer amounts and balance checkpoints without requiring the users to reveal them again.
Lucent also supports selective disclosure for a holder to prove one specific payment amount to one counterparty off-chain. An allowlist and account-freezing policy can be enforced before confidential state changes, giving the product an explicit compliance layer rather than treating privacy and controls as mutually exclusive.
06 · UX engineering
A proof that takes seconds changes every interaction
A confidential payment is not an ordinary wallet transaction with a hidden field. The browser may need several seconds - and multi-proof flows can take tens of seconds - to derive keys, reconstruct state, build witnesses, and prove before the wallet can submit anything.
Lucent shows a proof-progress state immediately so the interface never appears frozen. Confidential keys are derived deterministically from a Freighter message signature and cached locally to avoid repeated signing prompts. The client also persists decrypted openings and re-verifies them against on-chain commitments because Stellar RPC event history is not a permanent private-state database.
Cross-origin isolation, WASM asset loading, wallet network selection, proof size, transaction limits, and local recovery are therefore part of the payment experience - not background implementation details.
07 · Reflection
What building Lucent made clear
The hardest part was not expressing C = vG + rH. It was preserving a coherent private state across browser, proof system, wallet, Soroban contracts, and product workflows while keeping users informed about what the machine was doing.
Lucent is testnet-only. The circuits and UltraHonk verifier backend are unaudited, the escrow secret-handling model is not production-safe, and local state recovery needs stronger backup semantics. Those limits are stated because confidential finance punishes ambiguity.
The broader lesson is that confidential payments are a full systems problem. Cryptography hides the amount; engineering determines whether the user can reliably create, verify, recover, audit, and understand the payment.