Skip to main content
Redeeming is the exit from the confidential rail: cAROUSD is burned and the same amount of public test stablecoin is paid back to your wallet. Unlike the other operations, redemption is two-legged: the burn and the payout are separate on-chain transactions, both driven by the background worker.

​
Make the call

Requirements mirror the other spending calls: a custodial wallet, enough cAROUSD, ETH for gas, and amount as a decimal string. The 201 means the redeem is validated and queued; everything after that happens in the background.

​
The two legs

  1. Leg 1 (burn). The worker checks your decrypted cAROUSD balance, then signs and broadcasts the burn; the cAROUSD leaves your confidential balance and txHash is set. In backed mode the burned amount is then publicly decrypted (that single value becomes public, a requirement of verifiable payout); in float mode the funds move to the operator confidentially.
  2. Leg 2 (payout). Once the burn confirms (SETTLING), the operator pays stablecoin 1:1 to your wallet. Its transaction hash lands in settlementTxHash, and the row becomes SETTLED.
Check payout on the settled transaction for what actually arrived. It is normally amount less any redeem fee (shown in payout.fee). Confidential transfers do not revert when the balance falls short, they move nothing: if the wallet’s cAROUSD is spent elsewhere before the burn, the redeem settles with nothing paid, payout.amount "0" and payout.partial true. A null payout on a settled redeem means it was not recorded; treat it as unknown rather than as amount paid. Status flows QUEUED → PENDING → SETTLING → SETTLED. FAILED is terminal and only reachable before anything moved on-chain: a failed pre-flight check while QUEUED, or a reverted burn while PENDING, with the reason in error and errorCode. Once the burn has confirmed, the row stays SETTLING until the payout lands; it is never failed with your cAROUSD already burned.

​
Poll to completion

Settlement runs in the background worker; polling only observes it. Poll until a terminal status:
Backed-mode settlement waits for the Zama KMS to publish the public decryption of the burned amount, so SETTLING normally lasts a little longer than a plain confirmation; the worker re-checks every 30 seconds. A redeem that sits in SETTLING for much longer usually means the decryption is delayed or the operator is short of gas or liquidity; both are platform-side. See Troubleshooting.

​
Failure modes

Request problems fail the POST; execution problems fail the transaction row later (status: "FAILED" with error and errorCode), and a failed redeem never burned anything. There is no redeem_settlement_failed any more: a payout that cannot be sent yet keeps the row in SETTLING and is retried, never failed. Once settled, grab the notarized receipt with GET /transactions/{id}/nota; it reflects both legs.