Product · Vesting

Confidential vesting on FHEVM

Per-user manager clones hold encrypted token balances. Schedules live on chain in plaintext (start, end, cliff, interval) while amounts stay opaque to everyone except the operator and the recipient — by ACL grant, not by trust.

Where to start

The shape of confidential vesting

One manager per operator

Aria's wallet calls the factory's createManager once. The factory deploys a LibClone with CREATE2 — the clone address is deterministic, the clone is owned by Aria, and every vesting she opens from now on lives inside it. The plaintext (schedule shape, role grants) is on chain; the amounts are encrypted handles.

Vesting = encrypted handle + plaintext schedule

createVesting takes a recipient, a {start, end, cliff, interval}, and an amount. The amount is encrypted client-side via the Zama RelayerWeb before it ever leaves the SDK. The contract stores the ciphertext and grants ACL to the operator + recipient. Anyone else sees a 32-byte handle, nothing more.

Claim picks the right fee branch

Manager clones charge either gas-side or token-side fees. ClaimArgs is a discriminated union by FeeType. Resolve the manager's config once with useManagerFeeInfo, then pass the matching variant — useClaim picks the right argument shape at compile time.

ACL is append-only, on demand

Adding a tax authority or auditor as a viewer doesn't unlock the funds — it just adds their address to the handle's ACL list. SDK hooks like useDiscloseToParty + useBatchDiscloseHandlesToParty cover the common patterns.

Reference

The lookup layer. Every exported type, error class, role, event, and ABI lives in a dedicated table — copy-paste-ready, no MDX prose between you and the import.