Naust: A deposit address per customer, no memo

Hi all,

I’m building Naust for HackCanton Season 3, and I’d like feedback from people who run deposits on Canton.

The problem it takes on came up in the thread Per-user deposit destination on a single party without a memo field: exchange withdrawals arrive from a pooled party that names nobody, the memo is the only clue, and every missed memo becomes a support case.

Naust gives every customer their own Canton party as a deposit address. When a transfer lands on it, Naust:

  1. sees the incoming CIP-56 transfer offer on the customer’s party,
  2. accepts it as that party,
  3. writes a DepositReceipt contract (signed by the business, observed by the customer’s party, so no other customer can see it),
  4. sweeps the holding to the treasury, and records the sweep on the receipt.

Each step checks the ledger before acting, and commands carry IDs derived from the deposit, so a crash at any point resumes without crediting twice or skipping a step.

It runs live on DevNet with real Canton Coin:

Where I’d value your input:

  • If you take exchange deposits on Canton, would a party per customer work with your setup, or does the party count push you toward leased addresses from a pool?
  • On a validator you run, is allocating a party per customer at sign-up something you’d do, or would you want the addresses under a separate participant?
  • Anything in the accept-and-sweep flow you’d handle differently, for example the traffic cost of about six transactions per deposit?

If anyone wants to try it beside their own node on TestNet, I’m glad to set that up. Replies here are perfect.

Thanks,
Jadon

  • If you take exchange deposits on Canton, would a party per customer work with your setup, or does the party count push you toward leased addresses from a pool?

Party per customer. Since Canton 3.6.1, on networks running protocol version 36, each new party no longer adds memory on your node.

  • On a validator you run, is allocating a party per customer at sign-up something you’d do, or would you want the addresses under a separate participant?

The same validator is fine. Create the customer parties through the Ledger API.

  • Anything in the accept-and-sweep flow you’d handle differently, for example the traffic cost of about six transactions per deposit?

Set up a preapproval on each customer address and on the treasury. Deposits then arrive without an accept step, and a deposit can’t bounce back to the exchange if Naust is down.

Sweep on a schedule, many deposits at once, instead of one by one. Your node then sends nothing when a deposit arrives, and one transaction per customer when you sweep.