Zivoe Internal · POC

Canton External Wallets · Decision Doc

Where does the deposit intent live — and what does the user receive?

Two independent decisions shape our first external-wallet proof of concept. This doc lays out the three options for each, how they compare, and a recommended path — so we can decide together.

Date · 12 June 2026 Status · For team discussion Scope · First external-wallet POC

The two decisions

Every option we've discussed is really an answer to one of two separate questions. Keeping them separate is the key to a clear conversation — any answer to the first can be paired with any answer to the second.

Decision 1 · The request

Where does the deposit intent live?

When a user wants to subscribe, where is that request recorded — and who signs it?

1
Backend intentZivoe's backend records the request off-ledger; the wallet only sends USDCx.
2
Zivoe-created DepositIntentZivoe writes the request on-ledger on the user's behalf; the wallet still only sends USDCx.
3
User-signed MintRequestThe current repo flow — the user's wallet signs a custom Zivoe DAML command itself.
Fastest to shipMost protocol-pure
Decision 2 · The asset

What does the user receive after deposit?

Once USDCx lands in the treasury, what represents the user's Zivoe position?

A
Backend positionA database record. Nothing new is issued on Canton.
B
Custom PCTokenThe repo's existing DAML holding, minted to the user's Canton party.
C
Standard Zivoe tokenA wallet-native, CIP-56-style token that external wallets can display and transfer.
Fastest demoMost wallet-native

Why Canton wallets change the picture

The whole decision space exists because a Canton wallet is not a simple key signer like MetaMask. Four facts drive everything below.

A wallet is more than a signer

The wallet's validator must see the user's private contracts, prepare transactions, and understand any DAML package it signs against — then show the user what they're signing.

Connectivity ≠ contract support

Canton dApp APIs handle transport and signing. They do not guarantee a wallet can exercise custom Zivoe DAML choices.

Standard transfers are the safe bet

Every candidate wallet is expected to support standard USDCx / CIP-56 token transfers first. That's the rail we can rely on today.

Custom commands are unproven

Support for third-party commands like IssuerRole.RequestMint is unconfirmed across Loop, DFNS, Send, and Cansai. Loop's public docs suggest limits around custom DARs.

Quick glossary for the discussion
Validator
The node a Canton party runs on. It stores that party's private contracts and prepares/signs its transactions.
DAML package / DAR
Zivoe's smart-contract code. A validator must have (and vet) a package before its parties can use those contracts.
CIP-56
Canton's token standard — the interface wallets use to display and transfer tokens like USDCx.
USDCx
The Canton-native USDC token users deposit with. Issued by its own registry, separate from Zivoe.
requestRef
The reference linking a Zivoe deposit request to its matching USDCx payment.
NAV
Net asset value — the price used to quote how much zVLT a deposit buys.

Decision 1 of 2

Where does the deposit request live?

Three ways to record the user's intent to subscribe. They differ in who signs the request, what the wallet must support, and how much we build — the user's USDCx transfer itself is the same standard payment in all three.

Option 1 ★ Recommended POC

Backend intent

The request lives in Zivoe's backend. The wallet only ever signs a standard USDCx transfer.

Flow

  1. Backend creates a deposit intent with a requestRef
  2. User's wallet sends USDCx to the treasury
  3. Backend watches the treasury and verifies the payment
  4. Zivoe issues the user's position
User signs
USDCx transfer only — one signature
Wallet needs
Standard USDCx transfer, ideally with request metadata or another proof-of-transfer

Pros

  • Easiest possible external-wallet POC
  • Works with any wallet that can send USDCx
  • No dependency on wallets supporting custom Zivoe DAML
  • Good fit for a first Loop / DFNS wallet integration
  • Proves the core question: can an external wallet fund Zivoe?

Cons

  • Subscription intent is off-ledger
  • Audit trail depends partly on backend records
  • Less protocol-pure than the current README flow
  • Needs careful matching & idempotency logic
What Zivoe builds (7 items)
  • Backend deposit-intent table
  • requestRef generation
  • Treasury USDCx event watcher
  • Payment matching: sender, receiver, amount, token, expiry, reference
  • Idempotency — one payment can never mint twice
  • Status machine: pending → paid → minted (or expired / failed)
  • Optional PCToken mint after payment

Choose when: the goal is to prove a real external-wallet USDCx deposit into Zivoe as quickly as possible.

Option 2 Likely step 2

Zivoe-created DepositIntent

Same wallet experience as Option 1, but Zivoe writes the request on-ledger for the user.

Flow

  1. Zivoe creates a DepositIntent on-ledger for the user's party
  2. User's wallet sends USDCx to the treasury
  3. Zivoe matches the payment to the intent
  4. Zivoe issues the user's position
User signs
USDCx transfer only — one signature
Wallet needs
Standard USDCx transfer; possibly visibility of a Zivoe contract as observer, but never exercises Zivoe choices

Pros

  • Better audit trail than a backend-only intent
  • Reference, price, amount & expiry recorded on-ledger
  • Still wallet-friendly — user only signs the transfer
  • Natural bridge from POC toward the production protocol

Cons

  • Requires designing & building a new DAML template
  • Observer visibility may force the Zivoe package onto the user's validator
  • The user didn't sign the intent — Zivoe created it for them
  • More moving parts than Option 1
What Zivoe builds (5 items)
  • New DepositIntent template: user & treasury parties, amount, quoted NAV, min output, requestRef, expiry, status
  • Backend flow to create intents
  • Treasury watcher matching USDCx transfers to intents
  • Completion / mint logic
  • Archive, expire & cancel choices

Choose when: we want external-wallet deposits plus a clean on-ledger request & audit record.

Option 3 Production path

User-signed MintRequest

The current repo flow — the user's own wallet signs the Zivoe subscription request on-ledger.

Flow

  1. User signs RequestMint on IssuerRole
  2. User signs the USDCx transfer to the treasury
  3. Issuer + treasury validate and accept the request
  4. PCToken is minted to the user
User signs
Custom RequestMint and the USDCx transfer — two signatures
Wallet needs
The custom Zivoe DAML package, arbitrary command submission, and USDCx transfer

Pros

  • Strongest protocol design
  • User intent is explicit, on-ledger, and user-signed
  • Matches the current repo README and DAML model
  • Best audit & compliance story

Cons

  • Hardest to achieve with today's external wallets
  • Wallet provider must vet & support custom Zivoe contracts
  • User likely approves two separate transactions
  • Many more failure states and UX complexity
What Zivoe builds (5 items)
  • Frontend flow coordinating two wallet actions
  • External-wallet integration for arbitrary DAML commands
  • Package deployment & vetting story with the wallet provider's validator
  • Request-lifecycle UX: request without payment, payment after expiry, rejections, duplicates
  • Requester-visibility changes so IssuerRole.requesters scales to many external users

Choose when: a wallet provider explicitly confirms support for third-party DAML app commands / custom DARs.

Option 1Backend intentPOC pick Option 2Zivoe DepositIntent Option 3User-signed MintRequest
User signs USDCx transfer only USDCx transfer only RequestMint + transfer (2 signatures)
Wallet must support Standard USDCx transfer Standard USDCx transfer Custom Zivoe DAML package & commands
Where the intent lives Zivoe backend (off-ledger) On-ledger, created by Zivoe On-ledger, signed by the user
Audit trail Backend records + USDCx transfer On-ledger intent + transfer Strongest — fully user-signed
Wallet-dependency risk Low Low High
Build effort Lowest backend only Medium backend + new template Highest wallet integration + vetting
Best for Fastest real-wallet POC POC with on-ledger audit Production-grade protocol

Decision 2 of 2

What does the user receive after deposit?

Once the USDCx payment is verified, something must represent the user's position. The three options trade demo speed against how “real” and wallet-native the asset is.

Option A Fastest start

Backend position

A database record of the user's position. Nothing new is issued on Canton.

Flow

  1. User sends USDCx
  2. Backend records the user's Zivoe position
  3. The app displays the balance
User holds
An off-ledger record in Zivoe's database
Wallet shows it
No — visible only in the Zivoe app

Pros

  • Fastest possible demo
  • Wallet never needs to display or store custom contracts
  • Perfect if the POC is strictly about deposit rails

Cons

  • Not actually tokenized on Canton
  • Weakest Canton-native story
  • Redemption & transfers stay backend-managed

Choose when: the POC only needs to prove external-wallet USDCx funding.

Option B ★ Preferred POC asset

Custom PCToken

Mint the repo's existing DAML holding to the user's own Canton party.

Flow

  1. User sends USDCx
  2. Issuer mints a PCToken owned by the user's party
  3. Holding is visible & managed via the Zivoe app
User holds
A real on-ledger DAML holding
Wallet shows it
Unlikely, unless the wallet's validator hosts the Zivoe package

Pros

  • Uses the contracts we already have
  • The user gets an actual DAML holding
  • Demonstrates true tokenization on Canton
  • Medium-complexity step once the USDCx rail works

Cons

  • External wallets may not display it nicely
  • The user's validator may need the Zivoe package to see & use it
  • Transfers / redemptions likely go through the Zivoe app UI

Choose when: the POC should show a Canton-issued Zivoe position, and wallet-native display isn't required yet.

Option C Later · product goal

Standard Zivoe token

Issue a wallet-native, CIP-56-compatible token that moves around Canton freely.

Flow

  1. User sends USDCx
  2. Zivoe issues a standard CIP-56 token
  3. The wallet displays & transfers it natively
User holds
A standard, registry-issued Canton token
Wallet shows it
Yes — native display & transfer

Pros

  • Best long-term wallet compatibility
  • High chance wallets display & transfer it naturally
  • Cleanest if Zivoe assets should move outside the Zivoe app

Cons

  • Most upfront token-infrastructure work
  • Current PCToken design likely needs to change
  • Still needs subscription / redemption logic around the token

Choose when: wallet-native Zivoe assets and broad interoperability become the product goal — not for the first POC.

Option ABackend position Option BCustom PCTokenPOC pick Option CStandard token
What the user holds Database record (off-ledger) On-ledger DAML holding Standard CIP-56 token
Wallet displays it No Unlikely without the Zivoe package Yes — natively
Uses current contracts n/a Yes — as-is Needs redesign
Transfer & redemption Backend-managed Via the Zivoe app UI Wallet-native
Canton-native story Weakest Medium Strongest
Build effort Lowest Medium Highest
Best for Deposit-rails-only demo Tokenization demo Wallet-native product

How to decide

Two questions resolve each decision. The orange path marks the recommended route for the first POC.

Decision 1 · the deposit request

Driven by one thing: confirmed wallet capability.

Deposit request decision tree No / unconfirmed Yes, confirmed No Yes Has the wallet confirmed support for custom Zivoe DAML commands? Need the request record on-ledger from day one? Option 3 · MintRequest user-signed · strongest protocol production path, not first POC Option 1 · Backend intent ★ Build this POC first Option 2 · DepositIntent on-ledger audit · likely step 2

Decision 2 · the issued asset

Driven by what the demo must prove.

Issued asset decision tree deposit rails only a Canton-issued position No Yes What must the demo prove? Must the wallet display & transfer it natively? Option A · Backend position fastest · off-ledger record Option B · Custom PCToken ★ Preferred POC asset Option C · Standard token wallet-native · later
question outcome recommended outcome recommended path

Recommendation

The recommended POC: one signature, standard rails, real verification

Start with the combination that depends on nothing unproven. Every step below uses wallet capabilities we can rely on today, while still proving the end-to-end story.

Backend intent + Standard USDCx transfer + Backend verification + Backend position → PCToken
1

User connects an external Canton wallet; the app captures the user's party ID.

2

Backend creates a deposit intent: requestRef, user & treasury parties, USDCx amount, quoted NAV price, expected output, expiry.

3

Frontend asks the wallet to send USDCx to the treasury, carrying the requestRef / proof metadata.

4

User approves a single, standard USDCx transfer in their own wallet.

5

Backend watches the treasury's USDCx activity for incoming transfers.

6

Backend verifies sender, receiver, token, amount, requestRef and expiry — and that the intent wasn't already used.

7

Backend marks the intent paid.

8

Issuer records a backend position (stage 1) or mints a PCToken to the user's party (stage 2).

9

Backend marks the intent complete; the app shows the user's position.

The build sequence

Each stage is a strict superset of the previous one — nothing built early is thrown away. We only climb a rung when the demo (or a wallet provider) demands it.

Stage 1POC

Backend intent + USDCx + backend position

Prove the deposit rail end-to-end with the least machinery.

Stage 2POC

Swap in a real PCToken mint

Same rails — the user now receives an on-ledger DAML holding.

Stage 3Next

Add the on-ledger DepositIntent

Moves the request record onto the ledger for a clean audit trail.

Stage 4If supported

Full user-signed MintRequest

Only once a wallet provider confirms custom DAR / command support.

Stage 5Product-driven

Wallet-native Zivoe token

When external display & transfer become a product requirement.

Open questions for this discussion

What we should walk out of the meeting having answered — or having assigned an owner to answer.

Wallet & provider

  • Which provider do we target first — Loop, DFNS, Send, or Cansai?
  • Does that wallet support USDCx transfers with metadata, or another proof-of-transfer?
  • Will the provider's validator vet & host the Zivoe DAML package if we mint PCTokens?

Backend & matching

  • How does the backend observe the treasury's USDCx activity?
  • Can we reliably correlate a transfer to its requestRef?
  • What happens on late, wrong-amount, wrong-sender, duplicate, or missing payments?

Product & compliance

  • Does the first demo issue a backend position or go straight to PCToken?
  • What is the minimal UI flow for the POC?
  • Is KYC / allowlisting handled off-ledger first, or through on-ledger requester configuration?