Per-user deposit destination on a single party without a memo field — is there a pattern?

Is there any way on Canton to give each end user a unique deposit destination string that routes to a single party we control, without the user having to fill in a memo/reason field?

Context: we operate a single receiving party on our own validator and need to attribute incoming CIP-0056 transfers to the end user who sent them. Today the options we know of are:

1. Sender attribution — the user pre-registers the parties they will send from, and we attribute by sender. Works with any wallet, but requires registration first.
2. Memo/reason metadata (“splice.lfdecentralizedtrust.org/reason”) — the exchange-integration pattern. Works when our app composes the transaction (CIP-0103), but on a manual transfer from a wallet UI the user has to type the memo into a separate field. We tried a BitGo-style “party?memoId=…” string and wallets do not parse it.
3. One party per user — not viable for us given party limits and custody constraints.

What we are looking for is closer to a virtual IBAN: one string per user that the user pastes as the recipient, that resolves on the sending side to “receiver = our party” plus an identifier we can read on receipt. Something like an alias/proxy party that forwards to a fixed destination while preserving who it was addressed to.

Related questions:

• CIP-0112 Accounts (“owner + provider + id”) seem to be the standard’s answer, but the account “id” is a separate input field, and V1 senders cannot set it at all. Is anyone working on a serialised “party + account” address format that wallets would parse from a single paste?
• Is there any known “magic party” / alias-party pattern for this (someone mentioned building one a while ago)? Registry-side resolution of the receiver account (the V1→V2 partial-compatibility case in CIP-0112 §5.4) would also do it, if any registry implements it.
• Wallet providers (Loop, Walley, Fireblocks, BitGo): is a recipient string with an embedded account id / memo on your roadmap?

Any pointers appreciated.

Since you’re custody the coin anyway you can indeed do this in a very simple way using external party but share the same key. So you don’t need to manage a lot of key. And you use a party-hint to identify account such as a::fingerprint a2::fingerprint All of these can come out of a single private key. It’s external party, so you won’t hit the limit and at the same time only a key to manage from your custodian perspective.

Another apporach you can consider is to using random deposit amount to distingush them in a short window.

Creator of Walley here. I think you’ve probably exhausted most of the options given the party limit onboarding network-wide. For magic addresses, it boils down to either memo or sender attribution. If you want the UX convenience of party id, then it would require party allocation per user. I know DA is actively trying to increase the upper bound on network wide party allocations, but it’s still going to be fixed (on the order of a couple million parties) for a long period of time even into next year.

You could do something clever where you allocate a fixed N number of deposit addresses and you can rotate through them with time allocation per user (each user holds a lock on the address for a fixed amount of time where you can attribute the deposits). This is just better resource management given the network allocation constraint.

Otherwise, I think virtual addresses would need to be supported at the protocol level by DA. Generally, party id’s represent custody on the network and hence why we don’t have anything like smart contract addresses like on Ethereum.

From the wallet angle, it could be that there’s a better way to process metadata through a singular field and move away from like filling in a memo, and instead just do like a generic tx field that encodes the party id, account, metadata, etc. for better UX. This would probably require a new CIP and adoption from all the wallets on the network. Nothing on the roadmap currently on this, and if work is done it would require a new wallet standard to be proposed, reviewed, and implemented.

Thanks, appreciated. One nuance: we don’t custody end users’ coins on Canton (they hold their own parties), and units only reach our party when they redeem. That said, the shared-namespace idea is neat, and we’ll keep it in mind if we ever need per-user receiving parties. Out of curiosity: do external parties hosted on a participant count towards its hosted-party limit?

On random amounts, we already use a unique amount as the key for proving control of a party at registration, but for the transfer itself the amount is the request size, so it can’t carry the identifier.

Thanks, that’s the confirmation we were looking for. For now we’ll go with sender attribution: users register and prove control of the parties they send from, and the same registered party receives their minted units, so it fits our flow well.

Where it breaks is the exchange/custodian case: an investor whose tokens sit on an exchange sends from an omnibus party that identifies nobody and can change at any time. A memo solves that on paper, but in practice users forget to fill it in, and every miss becomes a support case to recover funds.

So +1 on the single-field idea. A recipient string that carries party + account/memo, which every wallet parses by default on a plain copy/paste, would cover it. Some wallets already accept a party?memo=… style string, but it isn’t standard, so it breaks on others (e.g. the Splice wallet UI). If a CIP gets drafted for this, we’d be happy to contribute the use case and help review it.