The Inevitable: The Wallet Is the Right Record. Here Is the Missing Piece.

Picture a transfer agent's record for one holder of a tokenized share. No name, no mailing address. Just a wallet address, a quantity and an issue date. That is a better record than the one it replaces. Months later an instruction arrives to move those shares. The address is the same and the shares never moved. The transfer agent now needs one more answer: who can authorize this transfer today?

The Brick: Five Firms Ask the SEC to Make the Wallet the Record

On November 3, the last day for comments on the SEC's proposed transfer agent rules (File No. S7-2026-30, Release No. 34-106246), a joint letter came in from Brian Crist of Figure, Billy Miller of Securitize, David L. Becker of Equiniti, Salman Banaei of Plume and Eli Cohen of Centrifuge. Each company is a registered transfer agent or affiliated with one, and the letter is careful and well argued.

Their principal ask is “a fully principles-based approach” that does not mandate collecting a holder's name and physical mailing address, and recognition of “the superior reliability of electronic identifiers such as digital wallet addresses” for tokenized securities (pp. 12 to 13).

We filed on the same file on October 29, on one narrow question: how a transfer agent links a wallet address to a securityholder, and how it keeps that link and any eligibility determination current. Their letter makes the case for the wallet as the record. It also leaves out the one thing that makes that case hold, and that is what our letter is about.

Why the Wallet Wins

They are right, and on more than one count.

A transfer agent does not need to hoard personal data to do its job. They warn that mandatory collection would force transfer agents to “amass repositories of personally-identifiable information,” much of it serving no transfer agent function, and they write that “Data minimization is itself a form of investor protection” (p. 6). We agree. A name and a street address in a database are a breach waiting to happen, and they tell you little about who can move a token.

As an entry in a record, an address beats a name. Names are shared and change. An address “cannot be forged, duplicated, or confused with another holder's identifier” (p. 6).

Tokens also bring controls paper never had. Where a token's contract includes “freeze, pause, or forced-transfer functions exercisable by the transfer agent or issuer,” transfer restrictions “can be applied to the relevant wallet address immediately and programmatically” (p. 7). That is a real improvement on manual stop-transfer procedures.

And they keep the bar high. Transfer agents “would remain obligated to identify each record holder to the exclusion of all others” (p. 3). That is the right standard, and the wallet can meet it.

Where the Letter Stops Short

Here the letter goes too far. It describes a wallet address as “unique to the holder and immutable,” providing “a one-to-one mapping between the identifier and the holder” (p. 4), and says it “is permanently and immutably linked to the securities held in that wallet” (p. 7). The address is immutable, and it is linked to the securities. But it names a key arrangement, not a person, and nothing about the address maps it one to one to a holder. Who controls it can change, and the letter's case rests on treating that as fixed.

As we put it in our letter, “A wallet address is a public string. Anyone can name one, and naming it shows nothing about who controls it.” What ties an address to a holder is evidence of control, and it is simple to get: the holder signs, with the address, a message naming the transfer agent, the holder's record and a value used once. For a contract wallet, the signature is checked by asking the contract, under ERC-1271.

Control can also change without any transfer. In a smart contract wallet, the keys that may authorize a transaction are set by the contract and can be swapped by a transaction, while the address stays the same. Under EIP-7702, an ordinary key account can set contract code to run for it, which may let other keys act while the original key keeps its authority. Either way the security does not move, so no transfer is presented to the transfer agent. The release ties registration to knowing “who has legal authority to authorize transfers,” and that answer can change while the address and the position stay put.

The letter's answers to this are all about onboarding or cleanup. Where warranted, a transfer agent can use “blockchain analytics tools to confirm the association between the address and a single record holder” (p. 4). Intermediaries run customer identification “at the point of onboarding” (p. 12). A holder “who changes digital wallet addresses” should “notify the transfer agent” (p. 8). Freeze and forced transfer handle problems after the fact. None of these tells the transfer agent who controls the address when the next instruction arrives. A holder whose signer changed has not changed addresses, so there is nothing to notify, and the record goes stale with no trace in the transfer journal.

Eligibility works the same way. The release describes “wallet whitelisting,” determining whether an address meets credentialing requirements. A whitelist entry reflects the credential on the day it was added. Accreditation attestations expire or are withdrawn. Sanctions designations are added. Authorizations are revoked in one ledger transaction. In our letter's words, “An approved list compiled at onboarding is a record of eligibility on the day each address was added. A check made when a transfer is presented is a record of eligibility at the time of transfer.”

Completing the Wallet Record

None of this argues for keeping the mailing address. The wallet is still the better record. But on its own it does not do what the letter says it does. A wallet address can be the identifier of record with four things alongside it, the four sections of our letter.

1. Evidence of control at the start. A reasonable basis to believe the holder controlled the address when the link was made, such as a signed message, kept with the position detail.
2. A control check at each instruction. A check of the address's control arrangement when the transfer agent processes an instruction or transfer, since that arrangement is public network state readable at any block.
3. An eligibility check at transfer. A check of the credential behind the whitelist when a transfer is presented, with the list as “a cache of that determination, and the check at transfer as the control that keeps it current.”
4. A record that outlasts its retention period. A signed record of each determination that staff can check for alteration without relying on the transfer agent's systems, with a signature that lasts the retention period. NIST's draft transition plan lists ECDSA as “Disallowed after 2035,” and a six-year record made in 2030 must be kept into 2036. Signing with ML-DSA under FIPS 204, alone or beside a classical signature, is one way to meet that with standards available today.

InsumerAPI does the third and fourth and part of the second, and we sell it, so weigh this with that interest in mind. The check is public chain state and can be built without us. Ours reads that state, evaluates the conditions the transfer agent sets and returns a signed yes or no. It can check whether the address is a plain key account, an EIP-7702 delegation or contract code at the block checked, and whether an attestation someone else made about the address is present and has not expired or been revoked. Each attestation is signed twice: ES256 and a post-quantum ML-DSA-65 signature, with keys published by JWKS and verifiable offline. It does not verify anyone's identity and it decides nothing. The transfer agent verifies the holder's signed message, checks the address that signed, reads the signed answer and decides whether to process the transfer. The signed answer becomes the record.

Put together, that is what the five firms are after: less personal data on file, and a record that shows who could authorize the transfer on the day it happened.

What to Do Next

The comment period closed on November 3, and both letters are on the file for the Commission to weigh. Ours is on sec.gov, and our earlier filings make the same case for checking at the moment of the trade. The conditions behind the second and third checks, including account_code and eas_attestation, are on the conditions page.

If you run a transfer agent or issue tokenized securities: when an instruction arrives for an address you recorded a year ago, what do you check before you process it?