Master Securityholder File: Which Records Could Form It?
Your token knows wallets and balances, not names. So which records would form the official owner list that the SEC proposal defines?
IN 30 SECONDS
The master securityholder file is the official list of holder accounts a transfer agent keeps. The SEC’s proposal, not yet in force, would let a blockchain be all or part of it. For an ERC-3643 token, that list could join on-chain balances with off-chain names and addresses.
KEY TAKEAWAYS · 3
- Under the proposal, the master securityholder file stays the official list, electronic, under the transfer agent’s exclusive control. A blockchain may be all or part of it.
- The token holds wallets and balances, not names or mailing addresses. Question 83 asks how to tie the two records together: an engineering question.
- Reconciling them at every indexed block is my design, not a rule of the proposal. Comments are due by 3 November 2026.
On this page
Which record is the master securityholder file?
IN SHORT Under the proposal, it’s the official list a transfer agent keeps under exclusive control. It may span linked systems, even a blockchain.
WORDS TO KNOW
- Master securityholder file
- The official list of holder accounts a registered transfer agent keeps.
- Position detail
- Under the proposal, each holder’s record in that list: who holds what, with name and contact details.
- Control book
- Under the proposal, the record of securities (or debt principal) authorized, issued and outstanding.
The proposed Rule 17ad-9(b) reads: “Master securityholder file is the official list of individual securityholder accounts maintained by a registered transfer agent. The master securityholder file shall be maintained in electronic form and may consist of multiple linked files or systems.”
The technology is the transfer agent’s choice, “provided the transfer agent maintains at all times exclusive control”. Page 56970 adds that a blockchain could be the file “or a component thereof, but it would not mandate it.”
The proposal would also widen the Position detail Under the proposal, each holder’s record in that list: who holds what, with name and contact details. See the glossary. It would hold at least the holder’s full name and a physical mailing address. The release’s examples add “a digital wallet address in the case of any tokenized security”.
That split is on purpose: the ERC-3643 registry stores no names or mailing addresses.
For each wallet, it stores an identity contract address and a country code.
Coming up next: So how do you keep the chain and the register in step?
How to keep the two records in step
IN SHORT My design: a reconciliation check compares the chain with the off-chain register at every block and flags each gap for a person to fix.
Question 83 asks how to link on-chain records (wallet, quantity, issue date) with off-chain ones. The goal: each token transfer “results in a corresponding transfer” in the file.
IN PLAIN WORDS
Rule 17ad-9 defines a “record difference” as specific kinds of mismatch between records. My check flags gaps close to those.
STEP BY STEP
Step 1. Read. At every block you index (a batch of transactions added to the chain), read balances, identity links and total supply.
- Read At every block you index (a batch of transactions added to the chain), read balances, identity links and total supply.
- Compare Flag a balance with no register row, a row with no tokens, a units mismatch, or a balance whose identity was deleted.
- Totals Compare total supply with the outstanding count, assuming every outstanding unit is minted on-chain and treasury units aren’t. Then compare outstanding with authorized.
- Store Store each result, at every block, not once a month.
ITEM GET
Two records, one list
Questions a builder can answer before 3 November
IN SHORT Several numbered questions in the release are about engineering: anyone who has shipped tokens for approved wallets only can answer them with facts.
Comment by 3 November 2026 under File No. S7-2026-30. Use the SEC’s form or rule-comments@sec.gov.
Sources: SEC proposal, Federal Register, full text PDF, ERC-3643 (Final), T-REX reference contracts.
FAQ
With ERC-3643 as set up here, none alone. The proposed file would be electronic, could span linked systems and would stay under the transfer agent’s exclusive control, and a blockchain may be all or part of it. Names and mailing addresses stay off-chain, so the file could join the on-chain state with linked off-chain records.
STAGE CLEAR
What you now know
- What the proposed file is: the official list, electronic, maybe several linked systems, under the transfer agent’s exclusive control.
- Why, in the ERC-3643 setup shown here, the token is only part of it, and why the two records need reconciling.
Check yourself
Tap or click a question to see the answer.
Bob loses his wallet, and an agent recovers his tokens to a new one under the same ONCHAINID. If the official list identified Bob by his wallet address, what would go wrong?
Unless someone updates it, the address on file no longer holds his tokens. The wallet changed; his ONCHAINID didn’t. That’s the point to make on Question 37.
You finished every stage published so far in this series. Back to the series map
Former CTO of Integra. Named author (1 of 5) of ERC-3643, first author of ERC-6960, co-author of ERC-7410, and co-author of ERC-8203, which is still a draft. Building production AI and regulated Web3 systems.
Have a project to ship or a role to fill?
Discuss your project or roleFollow the engineering notes
Get new articles on production AI and smart contracts by email.