Skip to main content
Funding turns public USDC into a spendable confidential balance. Confiroll supports three routes, chosen by the loaded deployment and by where your USDC already sits. All three end with the employer’s balance ready to pay from, and all three are fee-sponsored, so you can fund a zero-XLM account.
The deposited total is public by design: deposit takes the amount as a public i128 argument, and the confidential token records it. What stays hidden is the per-recipient split and every ongoing balance once you start paying. Funding is confidentiality applied to the splits, not to the totals.
The always-runnable path for testnet. Confiroll mints its own testnet USDC and deposits it into the employer’s confidential balance:
1

Trustline

The employer adds a trustline to the testnet USDC asset.
2

Issue

The issuer pays test USDC to the employer.
3

Deposit

The employer deposits it into the confidential token (fee-sponsored).
4

Merge

A merge makes the deposited funds spendable.
The API reads the issuer secret from a sealed environment variable, falling back to the local stellar CLI keystore only for dev. That means the faucet runs in a stock container with no stellar CLI dependency, one of the custody-model consequences that made the API self-contained.
Both deposit and merge are fee-sponsored: the sponsor fee-bumps them the same way it fee-bumps a confidential_transfer, so funding costs the employer 0 XLM. See fee sponsorship for the CAP-15 fee-bump and its guard-rails.

​
The vault

Two of the three routes deposit through CctpVault, an employer-owned Soroban contract.
The vault is employer-owned. CctpVault is custodial to its owner by construction, and that owner is the employer (per ADR-006), never a Confiroll key. The vault exists because a contract can hold USDC through the asset contract with no trustline and no XLM reserve, whereas minting straight to a classic account would revert without a pre-provisioned trustline. The vault owner signs the fund call. See Soroban contracts for the vault’s functions and its nested-auth design.
fund does the bridge from public to confidential in a single call: it deposits vault-held USDC into the employer’s confidential balance, pre-authorizing exactly the nested asset transfer that the token’s deposit performs and nothing broader. The vault holds value; it holds no secrets, and only its owner can call fund or sweep.
The CCTP route requires funds to have actually been bridged (a real Base-Sepolia burn plus attestation). The self-issued faucet is the reproducible path that always works on testnet, and depositing classic USDC works whenever you already hold the underlying asset.

​
FAQ

No. The deposited total is public by design: deposit takes the amount as a public i128, and a CCTP mint records a public transfer into the vault. Confidentiality applies to the per-recipient splits you pay out and to ongoing balances, not to the funded total. The withdrawn amount is public too. Only the split and the running balances are hidden.
Use the testnet faucet when you just want self-issued test USDC and a path that always works. Use the CCTP bridge when you hold canonical USDC on another chain (Base Sepolia on testnet) and want it on Stellar. Deposit classic USDC when you already hold the underlying asset in a Stellar classic account. All three end in the same confidential balance.
No. deposit, fund, and merge are all fee-sponsored through the CAP-15 fee-bump, so a zero-XLM account can fund a confidential balance. The employer’s XLM delta stays 0 and the sponsor pays the network fee. For the employer walkthrough, see funding your account.