On-Chain Shareholder Register for Tokenized Equity: Legal Authority and Cap Table Integration

An on-chain shareholder register can be legally authoritative in some jurisdictions, but a blockchain record does not acquire that status automatically. The decisive questions are whether the issuer’s company law permits the register to be kept electronically or on a blockchain-based system, who is legally responsible for it, which information it must contain and when a transfer becomes effective.

A suitable adviser should combine corporate-law analysis with tokenisation and the design of the processes and controls that keep the records aligned. The engagement should identify the legal source of truth, connect each verified shareholder to an approved wallet, and define the update sequence, transfer controls and cap table reconciliation. 

Gofaizen & Sherle can support the legal and regulatory design of an asset-tokenisation project. The scope should also identify any input required from local counsel, the company secretary or registrar, the platform and other providers.

Can an on-chain shareholder register be legally authoritative?

Marketing language or a technology agreement cannot settle the question. Before work begins, the adviser should answer five questions:

1. What creates shareholder status? Issuer law may tie status to entry in a prescribed register or stock ledger.
2. Who keeps the record? The company or an authorised keeper may remain responsible even when a platform stores it.
3. What must it contain? Prescribed fields may include the holder’s name and address, share class, quantity and dates. If so, a wallet address is insufficient.
4. When is a transfer recognised? Does token movement require consent, evidence, eligibility checks or registration?
5. How is it accessed and corrected? Can the record be inspected, exported and rectified as required?

The legal share, ownership record and token ledger can be connected, but are not automatically the same.

How do the UK and Delaware illustrate the jurisdiction problem?

The answer changes with the issuer’s place of incorporation. Two examples show why a global conclusion is unsafe.

Which register architecture should the company choose?

Most projects start with one of the following models, sometimes as a hybrid. The company must state which record has legal priority.

The architecture must say which record controls, who confirms a discrepancy and how the other record is repaired.

What information should remain off-chain?

Shareholder identity should normally be separated from a public or widely replicated ledger. The on-chain layer may hold a wallet reference, class, quantity, status and event ID. A controlled off-chain system can hold the legal name, address, verification records, transfer documents and wallet-linking evidence.

For processing within the GDPR’s scope, the final EDPB Guidelines 02/2025, adopted on 7 July 2026, stress necessity, minimisation, data protection by design and effective rectification and erasure. They advise against placing personal data directly on-chain as a general rule and note that encrypted or hashed identifiers may still be personal data.

The data model should therefore define:

• the identity linked to each approved wallet and who may change that link
• the minimum on-chain data
• retention, access and correction rules
• wallet replacement or compromise procedures
• whether a data protection impact assessment is required.

How should issuance and transfer reconciliation work?

The workflow should treat a token transfer as a controlled corporate event, not as an isolated blockchain transaction.

1. Initiate the event. Classify the issuance, transfer, cancellation, conversion or correction and assign a reference.
2. Identify the parties. Confirm legal holders and approved wallets; complete required eligibility, sanctions and know-your-customer (KYC) checks.
3. Validate legal conditions. Check governing documents, restrictions, approvals and transfer evidence.
4. Approve the change. The company or authorised registrar accepts or rejects the event. It remains pending until then.
5. Update connected records. Apply the register entry and token action in sequence. If they cannot update as one controlled transaction, prevent an unregistered token position from appearing final.
6. Update the cap table. Recalculate holdings by class and issued, treasury, reserved or cancelled positions.
7. Reconcile and close. Compare identity, wallet, class, quantity, status and totals. Send differences to a manual queue for investigation.

Documents, platform status and investor interfaces must describe the point at which ownership legally changes consistently.

How are conflicts, errors and lost keys resolved?

The register design is incomplete until it covers exceptional events. “Blockchain immutability” is not a correction policy.

The operating rules should specify:

• which record controls if the statutory register, cap table and token ledger disagree
• who can freeze a pending or disputed position
• how an incorrect entry is reversed or superseded while preserving an audit trail
• how tokens are reissued or remapped after a verified lost-key claim
• how death, insolvency, sanctions, a court order or another forced-transfer event is processed
• who approves a correction and what evidence is required
• how affected holders, the company and providers are notified.

A lost private key should not automatically destroy the share. After verifying identity and entitlement, the company follows the approved process to freeze, cancel or remap the token position where the legal and technical design permits.

Who is responsible for each part of the register?

The operating model should allocate responsibility explicitly.

The final role map must identify third-party roles, any additional local-law opinions and provider confirmations.

What should an on-chain register architecture review deliver?

A useful engagement should produce documents that the legal and technical teams can implement together:

• a jurisdiction memorandum on register authority and transfers
• a source-of-truth decision and record hierarchy
• the data schema and identity-to-wallet model
• normal and exceptional-event process maps
• responsibility, approval and control matrices
• written rules for matching records, investigating differences and escalating unresolved cases
• required document and policy amendments
• privacy and security requirements, plus tests the system must pass before launch.

Each opinion should be dated, state its assumptions and separate register design from securities, offering, licensing, custody and trading analysis.

What information is needed to scope the review?

The adviser will normally need:

• the issuer’s country and legal form
• articles, bylaws or equivalent constitutional documents
• the shareholder agreement and all share-class terms
• the current statutory register and cap table
• recent issuance and transfer records
• the proposed token model, network and platform
• target holder and investor countries
• proposed identity, wallet and custody arrangements
• existing transfer restrictions and approval rules
• the intended relationship between token movement and legal transfer.

Implementation should start only after approving the source of truth, register keeper, data model, finality point, correction powers and reconciliation controls.

Discuss the legal and regulatory design of an on-chain register

Gofaizen & Sherle provides legal and regulatory support for asset-tokenisation projects. To discuss the required scope, provide the issuer jurisdiction, share class, current register, cap table, proposed platform and transfer rules.