One Member, Many Wallets:
Persistent Identity for Credit Union Custody

There's a quiet assumption buried in most tokenization stacks: that the wallet is the member. Identity and eligibility get attached to a wallet address, so the moment that address changes, everything attached to it has to be rebuilt.

But wallets change constantly. An institution moves positions between custodians. A member replaces an address after losing a key. A treasury spreads holdings across several wallets. In every case the verified member is the same person — but if eligibility lives on the address, each new address spawns a fresh record to reconcile, and every reconciliation is another chance for ownership or compliance data to drift out of sync.

Joachim Lebrun, co-creator of ERC-3643, framed this precisely in a recent note on persistent identity accounts: the tokenized-securities world has to distinguish between the investor and the wallet they use. The verified investor should persist while wallets come and go.

For credit unions, the stakes aren't just records to reconcile. They're regulatory.

The Standard Already Solves Half of It

ERC-3643 and the ONCHAINID framework it builds on give you the mechanism: a persistent identity account linked to multiple approved wallets, with an Identity Registry that verifies the required claims before a transfer is allowed. We already deploy one of these per credit union, on-chain, on Base — the CU owns it, we're the software layer. What we added is the part Lebrun points at: a single member identity can now hold many approved wallets. Switch custodians, rotate keys, recover a lost-key wallet — the identity and its KYC claims stay intact, no rebuild, no re-KYC.

We didn't reinvent that binding. It's the open standard. We implemented it for a specific regulated reality.

The Hard Part Isn't the Linking. It's Proving It Happened.

This is where a credit union's needs split from a generic tokenization platform. An examiner doesn't just need the system to work — they need to see that it worked. When a member's wallet changes, that's a material event in a regulated lending relationship. Who authorized it? When? Was the identity's KYC claim still valid at that moment? Did eligibility carry over, or did someone quietly re-approve a wallet that shouldn't have qualified?

So every wallet change emits a compliance receipt — linked, unlinked, rotated — as a first-class output, not a log line. Each one captures the member identity, the wallet, the custodian, the on-chain transaction, and the timestamp. An examiner can pull the full binding history for any member and read the chain of custody in plain terms: this identity, these approved wallets, these changes, each attested.

Every competitor is building faster pipes. We build the platform that explains itself to the examiner — and the explanation is the moat.

The Self-Custody Handoff

One detail worth surfacing, because it's where custody models collide. Linking a wallet on-chain has to be authorized by a wallet already tied to the identity. When we hold the escrow key for a member, we can sign that. When a member holds their own wallet, we can't — and we shouldn't pretend to.

So in the self-custody case the system doesn't fail and it doesn't fake a link. It records the wallet as pending and hands back exactly what the member's own wallet needs to sign to complete the binding. Custodial where it should be, out of the way where it shouldn't be — and the compliance record reflects the true state either way: pending until the member signs, active once they do.

Why Credit Unions Need Both

140 million Americans belong to a credit union. The ones holding crypto have had no compliant path to borrow against it without selling and triggering a taxable event. Building that path means building custody flows regulated institutions can stand behind — which means custody changes can't be a black box.

Persistent identity is what lets a member's relationship with their credit union survive the messy reality of wallets. Examiner-readable evidence is what lets the credit union prove that relationship stayed compliant through every change. You need both.