How Do Tokenized Stocks Actually Settle On-Chain? Custodial Wrappers vs. Direct Issuance

Tokenized stocks can settle in two fundamentally different ways. A custodial wrapper settles a token whose issuer holds reference shares, while direct issuance makes the blockchain record part of the official shareholder register, so a permitted token transfer transfers the legal security (TechTimes on Securitize’s SECZ issuance).

Key Takeaways

A 1:1 backed token and a directly issued on-chain share may look similar in a wallet, but they have different legal objects, registries, rights, and failure modes.

In the custodial-wrapper model, the on-chain transaction updates token ownership. It does not by itself update the issuer’s share register or convey direct voting rights.

In the direct-issuance model, the token ledger is integrated with the official register, making a permitted token transfer a legal transfer of the security with its associated rights.

On-chain finality can make delivery and payment atomic at the protocol layer, but it does not erase the need for custody, transfer-agent operations, compliance checks, corporate-action handling, or redemption controls.

Builders should treat proof of backing, eligibility, redemption, price/NAV separation, and contract verification as first-class system components, not UI details.

The key question is: what does the token transfer legally move?

A familiar ticker, price, and wallet balance do not tell a developer whether a transaction moved an intermediary’s claim or the company’s actual security. That distinction is the settlement boundary.

In a third-party issuance, a regulated entity that is not the public company acquires and holds reference shares, then issues a token backed 1:1 by that holding. The token tracks economic exposure but is not recorded on the company’s own shareholder register and does not carry direct shareholder or voting rights. In issuer-sponsored issuance, the company integrates the blockchain record into its official shareholder register, making a token transfer a transfer of the underlying legal security with full ownership rights (TechTimes on Securitize’s SECZ issuance).

The distinction decides which database is authoritative, what a receipt proves, and how redemptions and corporate actions work. Larry Fink and Rob Goldstein state the invariant succinctly: “A bond is still a bond, even if it lives on a blockchain.” (BlackRock op-ed) The chain is a record and settlement environment, but the legal design determines what that record represents.

For builders, start with a sharper question than “is this asset on-chain?” Ask: which party recognizes this ledger entry as the authoritative ownership record, and under what transfer conditions? The rest of the architecture follows from the answer.

Model 1: a custodial wrapper settles the token, not the issuer’s share register

The reference-asset and token ledgers are separate systems

Backed Finance’s xStocks, distributed through Kraken, illustrates the third-party wrapper model. xStocks are Solana SPL tokens covering roughly 60 equities and ETFs, and are backed 1:1 by shares held at a Swiss prime broker. They trade 24/7 on-chain and 24/5 on Kraken’s order book, while redemption is limited to KYC-cleared qualified participants; the product is unavailable to persons in the United States, Canada, the United Kingdom, and Australia (Kraken xStocks overview).

Conceptually, this model has at least two ledgers:

The reference-share custody ledger. The issuer or its custody arrangement records the real shares held through the traditional market and prime-broker structure.

The token ledger. The blockchain token contract records which wallet controls each issued unit and executes the token’s transfer rules.

The 1:1 claim links these systems economically. It does not merge them. An on-chain transfer updates the second ledger. Unless a redemption or another off-chain process occurs, the beneficial or record ownership of the reference share held at the custodian has not changed with every block.

A wrapped share is therefore not just an ERC-20 or SPL balance with a price feed. It is a regulated claim whose system includes an issuer, custodian, eligibility program, and redemption path.

What minting and redemption must accomplish

A sound wrapper design needs a controlled supply relationship between reference shares and tokens. At a high level, an authorized issuance operation should verify that the issuer has obtained or allocated the corresponding reference asset before minting the matching token units. A redemption operation should burn or otherwise retire the redeemed tokens before releasing the relevant economic value through the issuer’s approved process.

The engineering property is not simply `totalSupply == reportedShares`; it is an audit trail for the authorized minter, each supporting mint event, redemption status, and controls against double issuance.

For xStocks, the stated backing is 1:1 through shares custodied at a Swiss prime broker, while direct redemption is restricted to KYC-cleared qualified participants (Kraken). That makes redemption a gated primary-market function, not a universal `redeem()` function available to every token holder. A retail holder’s practical exit route is generally a secondary-market sale to another eligible counterparty, not a request to receive the underlying share.

A permitted holder may have no direct path to convert the token into the reference share. Expose transferability, eligibility, and redeemability as separate properties in the contract, API, and product disclosures.

What finality means in the wrapper model

A wrapper transfer can provide a final, timestamped record that the token moved under the contract’s rules and can couple delivery to stablecoin payment. It is finality for the token transfer, not necessarily for the public-company share, which remains in the third-party custody arrangement until a separate authorized operation changes it.

Avoid calling the event “share delivery complete.” A precise event is `wrapped_exposure_transferred`, with token amount, compliance status, payment transaction, and backing-attestation version.

Why wrappers can still be technically useful

The structure brings a reference asset into a token environment without changing the public company’s shareholder-record system. xStocks surpassed $10 billion in combined exchange and on-chain volume within six months of their June 2025 launch (Kraken acquisition announcement). Integrations still need to monitor issuer notices, backing-report cadence, redemption availability, restrictions, and corporate-action status.

Model 2: direct issuance makes the token ledger part of the security’s legal record

The issuer recognizes the blockchain transfer

Direct issuance changes the source of truth. The company issuing the security adopts a blockchain-native record as part of its official shareholder register. A permitted transfer on that record is not merely the movement of an intermediary’s claim; it is the movement of the company’s security, with full ownership rights (TechTimes on the issuer-sponsored model).

Securitize is the live reference case: it began trading as SECZ on the NYSE on July 2, 2026, and made $295 million of its own common stock available in blockchain-native form on Solana and Avalanche the same day (TechTimes coverage). This is issuer-sponsored stock, not a synthetic representation of another company’s share.

This is the model to study if you are working through the intersection of transfer agents, allowlists, and legal title. The related guide on tokenized public equities, transfer agents, settlement, and allowlists covers that operational surface in more detail.

The transfer-agent function becomes a protocol boundary

An official register has to answer questions a generic token contract does not answer: who is entitled to notices, who receives a distribution, which transfers are legally effective, how lost credentials are handled, and how the cap table is reconciled. In direct issuance, those answers must be synchronized with the blockchain state rather than reconstructed after the fact.

The chain need not replace every operational control. The requirement is authoritative reconciliation: the issuer and transfer-agent process must recognize permitted on-chain ownership, enforce restrictions, and handle exceptions and corporate events.

The practical model resembles a permissioned state machine around a token. A transfer request has at least four dimensions:

Identity: Is the sending and receiving address associated with a recognized account or legal owner?

Eligibility: Are both parties permitted to hold and receive this class of security under the applicable rules?

Amount and supply: Does the sender control the balance, and does the resulting supply reconcile to the authorized share count?

Register update: Does the completed chain transaction become the authoritative record of the recipient’s ownership, with the rights attached to that entry?

The last item is the structural break from a custodial wrapper. With a wrapper, the register update is generally on the token issuer’s ledger, while the public company’s share register stays unchanged. With direct issuance, the register update is the legal transfer.

Corporate actions are part of settlement design

A direct on-chain share needs a corporate-action design, not just an issuance design. Distributions, votes, stock splits, reverse splits, record dates, freezes, and communications all depend on a snapshot of the official holder record. If the blockchain entry is authoritative, the process must define which block, timestamp, or finalized ledger state establishes that snapshot.

Design for controlled exceptions such as lost keys, court orders, sanctions controls, and issuer-directed corrections. In a direct model, the transfer agent is a trust boundary connecting identity and legal title, and an allowlist constrains whether a proposed state transition can become legally effective.

NAV, reference prices, and the price that actually clears

Do not use a single field named `price` to describe a tokenized security. At minimum, distinguish a reference valuation or NAV from the price at which a token changed hands.

RWA.xyz makes this distinction explicitly: “price” is a secondary-market trading price, while total asset value or NAV is an issuer-reported valuation. The difference expresses a premium or discount (RWA.xyz methodology). For tokenized assets, secondary prices can form through bilateral negotiation, bulletin-board bid/offer systems, or auction windows, and restricted buyer pools can lead to persistent premiums or liquidity discounts. In professional private markets, liquidity discounts commonly run 10% to 30% (InvestHub pricing analysis).

A public-stock wrapper’s reference price is an anchor, not a guarantee that every on-chain swap clears there. Liquidity, linked-venue hours, restrictions, redemption access, inventory, and transaction costs affect execution. Direct issuance changes ownership, not necessarily venue depth or liquidity fragmentation.

A robust application should carry separate fields such as:

`reference_price` and timestamp, including the venue or calculation source;

`secondary_last_price`, bid, ask, and observed liquidity where available;

`nav_or_reported_value` and its calculation timestamp for assets where NAV is the relevant anchor;

`premium_discount_to_reference`; and

`price_status`, which can flag stale data, closed reference markets, or a thin secondary book.

This prevents displaying a reported backing value as a firm execution price. An oracle can provide a value but cannot manufacture liquidity or guarantee an eligible transfer at that value.

On-chain settlement is faster only when you define the settlement object

Traditional U.S. equity settlement is commonly described as T+1. The proposed NYSE-Securitize Digital Trading Platform, by contrast, is designed for 24/7 trading and instant settlement funded with stablecoins (CoinMarketCap on the NYSE-Securitize platform). The comparison is directionally useful, but developers should not collapse all settlement into a clock-speed claim.

In a token transaction, delivery and payment can be coupled atomically: both move under the contract rules or neither does. Network finality provides a strong record of that token-level state change.

However, “instant” can hide unresolved layers. For a custodial wrapper, the real-share custody position, issuer controls, and redemption timetable remain separate from the token transfer. For direct issuance, legal effectiveness depends on the official register’s integration and the compliance logic around the transfer. In both models, fiat rails, identity checks, market hours for reference data, corporate actions, and exception management may have their own timing.

The useful implementation pattern is to model settlement as a set of explicit statuses, not a Boolean. For example:

```text trade_authorized payment_locked token_transfer_finalized register_effective OR wrapper_transfer_finalized post_trade_reconciliation_complete ```

The fourth state intentionally differs by model. In direct issuance, `register_effective` represents the legal security transfer. In a wrapper, `wrapper_transfer_finalized` confirms movement of the issuer’s tokenized claim. Treating those as the same event causes misleading statements about ownership and settlement completion.

For a broader look at how to reason about the market-infrastructure transition, see this on-chain securities and DTC settlement builder playbook.

A builder’s control plane for either model

1. Make backing evidence queryable and versioned

For a wrapper, record the issuer, custodian arrangement, declared backing ratio, report date, outstanding supply, and redemption status. Preserve prior versions. Do not label a custody statement as a live on-chain proof unless a verifiable feed supports it; show its report time and source.

2. Put compliance before the transfer, not after it

Both models can require identity and eligibility checks. In a wrapper, the issuer’s jurisdiction and redemption rules may narrow who can receive or redeem. In direct issuance, eligibility is tied to whether the transfer can take effect on the legal register.

Evaluate policy before the state change. The contract or controlled transfer layer should reject a transfer that fails an allowlist, identity attestation, holding restriction, or jurisdiction rule, while retaining policy version and reason code for audit without publishing unnecessary personal data.

3. Treat redemption as an asynchronous workflow

A redemption request crosses chain and off-chain systems, potentially including KYC review, issuer approval, token burning, and delivery instructions. Model it as observable states such as `requested`, `eligibility_review`, `accepted`, `tokens_escrowed_or_burned`, `completed`, and `rejected`, not as a synchronous promise.

4. Separate price oracles from entitlement oracles

A price feed answers what a reference market or reporting process says an asset is worth at a moment. It does not answer whether a wallet is eligible, whether the token is backed, whether redemption is open, or whether a recipient is on the official register.

Use different data paths and failure policies: price data can have a maximum age and circuit breaker, eligibility can need a signed credential, backing can be an issuer attestation, and legal title can be the finalized register state. One generic oracle interface risks substituting a market quote for legal entitlement.

5. Design deliberately for multiple networks

SECZ was made available in blockchain-native form on Solana and Avalanche, which shows why network scope belongs in the security model rather than being an afterthought (TechTimes coverage). Each supported chain needs a clear answer to a hard question: do balances on these networks represent one mutually exclusive authorized supply, or separate records that reconcile through a controlled bridge or registry process?

Never treat a bridge event as self-authenticating evidence of legal title. Define canonical supply, the authorized bridge or burn-and-mint path, replay protections, and reconciliation across ledgers. The patterns in managing smart contracts across multiple networks help address version drift and configuration divergence.

6. Verify the contract, then verify the system around it

Contract verification lets integrators inspect supply controls, allowlist checks, pause powers, and administrative roles. It does not prove that reference shares exist, a custodian is performing correctly, or a register is authoritative. Pair it with documented key-holder roles, upgrades, emergency stops, attestation sources, and incident procedures. Use the smart contract verification minimum security control as a baseline.

What this means for builders

Tokenized equities are not one settlement primitive. They are a family of legal and operational designs that may share a token interface while settling very different things. Build your integration around the authoritative registry, the rights carried by the token, and the exact point at which a transfer becomes effective, then make every remaining dependency visible.

If you are mapping the contract-side mechanics behind these flows, start with Autheo’s guide to deploying a first smart contract. The broader design problem is the kind of trust, identity, and deterministic settlement infrastructure distributed ledgers are meant to address, but the implementation must keep legal title, custody evidence, and policy enforcement as explicit parts of the system.