Summary: Tokenized equity xStocks transform cap tables into programmable, compliant, and interoperable digital securities. In this guide, we’ll walk decision-makers and tech teams through the process of modeling data, ensuring compliant transfers, and automating corporate actions. We'll be using the latest standards (ERC‑3643, W3C VC 2.0, ISO 20022 mappings) along with industry-ready tools to make it happen.

Tokenized Equity ‘xStocks’ for Developers: Data Models, Transfers, and Corporate Actions

Decision-makers are looking for more than just buzzwords; they need a ledger that functions like a modern stock record, works seamlessly with your KYC stack, communicates with custodians, and simplifies corporate actions at the push of a button. In this post, we’ll dive into a solid blueprint we like to call “xStocks” -- a developer-friendly approach to tokenized equity that's built for compliance from the ground up, plays nicely with enterprise systems, and can be set up on today’s EVM chains.

Here’s what we’ll dive into:

• A data model that brings together on-chain tokens, verifiable identities, and off-chain cap tables in harmony
• Transfer logic that captures offering rules and handles cross-border restrictions
• Corporate action playbooks (like splits, dividends, buybacks, spin-offs, and M&A) that match up with ISO 20022 event types
• Handy code and configuration snippets that you can implement this quarter

Why Now

ERC-3643, the permissioned token standard, is officially Final and already in play across various platforms. Plus, it comes packed with a reliable identity stack known as ONCHAINID. Meanwhile, W3C's Verifiable Credentials v2.0 hit Recommendation status in 2025, enabling us to enjoy top-notch selective disclosure and revocation for a smoother user experience.

On top of that, OpenZeppelin’s governor and votes extensions have matured nicely, and the AA/4337 and Safe modules really help simplify the institutional controls we need. For more details, check out the full specification at eips.ethereum.org.

---

Architecture at a glance

xStocks is made up of three distinct layers that work together:

1) Token and Compliance (On-Chain)

• We're looking at an ERC-3643 security token that comes with pre-transfer compliance checks.
• It features an identity registry paired with a compliance module that pulls from ONCHAINID claims.
• You can also opt for ERC-1410-style “partitions” to represent different classes, series, or even locked tranches (part of the ERC-1400 family). Check out more details here.

2) Verifiable Identity and Eligibility (Hybrid)

• Users show off their W3C VC 2.0 credentials, which cover things like KYC/AML, accreditation, and residency.
• ONCHAINID keeps track of signed claim references (don’t worry, no PII is stored on-chain) and manages status through revocation lists (Bitstring Status List). You can check it out here: (w3.org).

3) Corporate Records and Integrations (Off‑Chain + Bridges)

• Your cap table is the real deal, all set in Open Cap Table Format (OCF), and it’s version-controlled plus event-sourced!
• We’ve got ISO 20022 corporate actions mapping for custodians and agents. You can whip up seev.031/033/036 equivalents straight from on-chain events. Check it out here: Open Cap Table Coalition.

This split reflects the current operational roles we have in place, all while allowing for complete automation wherever it's safe to do so.

---

Data model: concrete objects you’ll need

Here’s a straightforward xStocks schema that illustrates how chain objects connect to identity and cap-table info. Feel free to tweak it according to your regulatory requirements, location, and the complexity of your share classes.

{
  "Issuer": {
    "legalName": "Example, Inc.",
    "domicile": "US-DE",
    "ocfManifestUrl": "ipfs://.../ocf.zip",
    "governorAddress": "0xGov..."
  },
  "Token": {
    "standard": "ERC-3643",
    "address": "0xXSTK...",
    "symbol": "XSTK",
    "decimals": 0,
    "identityRegistry": "0xIDR...",
    "compliance": "0xCOMP...",
    "partitions": [
      { "id": "CLASS-A", "rights": ["Vote","Dividends"] },
      { "id": "CLASS-B", "rights": ["Vote (10x)","Dividends"] },
      { "id": "LOCKUP-2026", "rights": ["Non-transferable until 2026-01-01"] }
    ]
  },
  "Identity": {
    "holder": "0xHOLDER",
    "onchainid": "0xOID...",
    "claims": [
      { "topic": "KYC", "issuer": "0xKYCProv", "status": "valid", "ref": "vc:..." },
      { "topic": "ACCREDITED_US", "issuer": "0xAccProv", "status": "valid", "ref": "vc:..." },
      { "topic": "RESIDENCY", "value": "US", "status": "valid" }
    ]
  },
  "ComplianceRules": {
    "maxHolders": 2000,
    "jurisdictionRules": [
      { "from": "REGD", "to": "REGS", "blocked": true },
      { "country": "US", "lockupDays": 365 }
    ],
    "sanctions": { "oracle": "0xOFACFeed", "action": "freeze" }
  },
  "CorporateActions": [
    {
      "type": "CASH_DIVIDEND",
      "recordDate": "2025-12-01",
      "payableDate": "2025-12-15",
      "currency": "USD",
      "grossPerShare": "0.25",
      "withholdingRulesRef": "seev.031"
    }
  ]
}

• ERC‑3643 is pretty cool because it gives you everything you need: the token, identity registry, trusted issuers, claim topics, and compliance contracts. It makes sure that only addresses that are identity-verified and following the rules can hold or transfer shares. The official implementation and documentation are packed with factory interfaces and detailed events for any identity changes you might need to track. Check it out here: (eips.ethereum.org).
• W3C VC 2.0 is all about keeping your credentials private while still giving you the standard revocation you need with the Bitstring Status List. You can store pointers and hashes on ONCHAINID, so your Personally Identifiable Information (PII) stays off-chain. It's a smart approach! Learn more at (w3.org).
• When it comes to cap tables, OCF is the way to go. It's basically a JSON schema and event stack that captures everything from classes and vesting to conversions and transactions, all with validators and Excel converters thrown in. Think of OCF as your golden cap-table artifact for audits and board packs--super handy! Get the details here: (open-cap-table-coalition.github.io).

Tip: Set Token.decimals to 0 if you're dealing with whole shares. To keep track of those sub-share economic rights (like DRIPs), you can either create separate “fractional” partitions or manage them with off-chain accounting to steer clear of any rounding issues.

---

Transfer semantics: permissioned by design, user‑friendly in practice

xStocks uses pre-transfer checks instead of random allowlists.

• Core pattern: When you call token.transfer, it checks in with Compliance.canTransfer(from, to, amount). This, in turn, looks at whether IdentityRegistry.isVerified(to) and considers a bunch of rules like holder limits, lockups, and residency. If something goes awry, the transfers will fail with specific codes and easy-to-understand messages (you might like the ERC-1404 style messaging if you want a simpler interface). (eips.ethereum.org)

Solidity Sketch (Adapted to ERC‑3643 Surfaces):

function _update(address from, address to, uint256 amount) internal override {
    if (from != address(0) && to != address(0)) {
        (bool ok, uint256 code) = ICompliance(compliance).canTransfer(from, to, amount);
        require(ok, ICompliance(compliance).messageFor(code));
        require(IIdentityRegistry(identityRegistry).isVerified(to), "Recipient not verified");
    }
    super._update(from, to, amount);
    ICompliance(compliance).transferred(from, to, amount); // post-hook
}

What to Encode in Rules

• Jurisdictional Rails: We’ve got to think about things like Reg D vs. Reg S flowback rules, plus those nifty residency codes (you know, the ISO‑3166 country codes stored in the Identity Registry). And let’s not forget about the holder count ceilings--like the limit of 2,000 holders for certain US thresholds. Check out more about this here.
• Lockups and Cooling-Off Periods: Different partitions can have their own rules, like “LOCKUP‑2026.” Using ERC‑1410 partition IDs helps keep things clear for both investors and agents. You can dive deeper into this on GitHub.
• Sanctions and Restricted Lists: We need to set up a call to a signed oracle because if a sanction pops up, we want to freeze or force a transfer through the controller operation. The ERC‑1400 family has got your back with controller and forced transfer primitives (looking at you, ERC‑1644). More details can be found here.

Identity and Revocation:

• Make sure to use ONCHAINID claims with issuer registries. If you ever need to revoke a KYC claim, just know that Identity Registry events will kick in, and any future transfers will come to a screeching halt until the claim is restored. Check out the details here.
• If you lose your keys, don’t stress! You can burn and mint your recovery with ERC‑3643 and ONCHAINID once you prove you still have control. This process is clearly laid out as a supported flow, so you’re in good hands. More info can be found here.

Operator experience:

• The Safe + ERC‑4337 module offers multi-signature policies, staged operations, and gas abstraction for issuer operations like minting on close and contract execution. It’s been thoroughly audited and is already in use in production. Check it out here: (docs.safe.global)

Proof of Maturity

• ERC‑3643 is officially marked as “Final” and is currently in active production. The association mentions that there are tens of billions of tokens that have been tokenized using this stack. (eips.ethereum.org)

---

Corporate actions: automation patterns that align with ISO 20022

Here's a good rule of thumb: make sure to emit rich, machine-readable on-chain events for each step of the corporate action lifecycle. And don’t forget to map those events to ISO 20022 “seev” messages for the issuers and custodians who are still on the SWIFT train.

Reference messages:

• seev.031 CorporateActionNotification (this one's for announcing events)
• seev.033 CorporateActionInstruction (used for gathering holder elections)
• seev.036 CorporateActionMovementConfirmation (this confirms postings)
• seev.032/.034 status updates as needed (iotafinance.com)

Here are some handy patterns for those everyday situations you might run into.

Cash dividend (fixed)

• On-chain:
  • First up, let’s snap a pic of the voters/holders on the record date using those handy ERC20Votes checkpoints. And to keep things tidy, we can reference “past votes” with the OZ Governor/Votes. You can check out the details here: (docs.openzeppelin.com).
  • Next, we’ll distribute using ERC‑2222 (that’s the Funds Distribution Token). This way, holders can easily claim their fair share, and we’ll make sure to get the transfers right between the record and payable dates. More info can be found here: (github.com).
• Off-chain:
  • Once the board gives the thumbs up and we set the record date, we’ll whip up the seev.031. And don’t forget, we’ll create the seev.036 once the payment is posted. You can read more about it here: (iotafinance.com).

Implementation note: OpenZeppelin has pulled the plug on ERC20Snapshot in version 5. Instead, you should use the historical checkpoints from ERC20Votes for anything related to governance and entitlements. This is the go-to approach these days. Check it out here: (docs.openzeppelin.com)

Stock dividend / bonus issue

• Mint extra tokens proportionately into each eligible partition while keeping class rights intact. Generate CorporateActionMovementPreliminaryAdvice and MovementConfirmation equivalents in your integration layer. (iotafinance.com)

Forward or reverse split

• Forward split: Mint (ratio‑1) extra shares for each holder and keep the token decimals at 0 to dodge any fractional drift.
• Reverse split: Burn shares per holder and manage rounding with “cash in lieu” paid through the ERC‑2222 fund. Let’s make sure the final confirmation matches up with seev.036. You can check it out here: (iotafinance.com).

Buyback / tender offer

• Start an “Offer” contract that:
  • Shares the price range and the maximum cap
  • Lets holders make their choices (similar to seev.033)
  • Keeps tendered shares secured in a specific section
  • Wraps up DvP in stablecoin and handles burn/treasury transfer at the end
• Compliance: Keep an eye on eligibility for incoming tenders (identities might have changed since the record date).

Rights issue / subscription

• Each holder gets a “RightsToken” based on their class, and there’s a set time to exercise it; they can’t be transferred unless local laws allow it.
• When you exercise, it mints new equity at the subscription price. If rights aren’t exercised, they simply expire with event logs for seev.036.

Spin‑off

• Distribute newco tokens to holders on the record date in a proportional manner. If newco is permissioned, replicate verified holders using identity claims migration scripts. Generate linked event IDs to maintain parent/child mapping in the downstream systems.

Mergers (asset deal or share exchange)

• Create a Swap/Migration contract:
  • Take in old shares by partition
  • Check to make sure closing conditions are met (like governor votes and regulatory flags)
  • Instantly issue new shares or cash consideration
• If you're working with Delaware corporations, make sure your chain ledger meets DGCL stock-ledger requirements (think identity-verified owners and exportable registers). Initially, ERC-884 laid out some ideas for aligning with DGCL; these days, ERC-3643 along with identity and document management steps in to cover those needs in a more flexible way. (eips.ethereum.org)

Institutional Interfaces

• DTCC and key players are revamping their Corporate Actions (CA) pipelines using ISO 20022. Make sure your off-chain adapters can both emit and ingest seev messages. This way, you’ll be ready to connect with custodians both now and in the future. You can find the timeline and specs available to the public. Check it out here!

---

Governance and voting that enterprises accept

• Consider using OpenZeppelin’s Governor with ERC20Votes for handling board or shareholder actions. This framework is super popular--lots of projects like Compound are using it--and it's constantly improving with fresh counting and delegation tools in Contracts 5.x. Check it out here.
• Don’t forget about weighting by class! If you’re encoding class-specific votes (like giving Class B a 10x weight), make sure you reflect that in the Governor’s vote supply reference or think about using partitioned proposals.

AA-powered controls:

• Safe + ERC‑4337 module for board approvals and issuer operations: You can batch, sign policies, and automate CA steps while keeping track of everything with audit trails. Check it out here!

---

Practical, shippable examples

1. Deploying an ERC‑3643 Token with the Factory

• Go ahead and use the official T‑REX factory interface. Just fill out the TokenDetails and ClaimDetails, and you'll be able to deploy your token along with the identity/compliance bundle all in one go. Check it out here: (docs.erc3643.org)

2) Eligibility via W3C VC 2.0

• To kick things off, you'll need to issue a VC credential called “AccreditedInvestorUS.”
• Make sure to expose a JOSE/COSE proof.
• Also, don’t forget to post a hash and claim topic on ONCHAINID.
• If the accreditation ever lapses, you can revoke it using the Bitstring Status List (and rest easy knowing there’s no PII on-chain).

For more details, check out the official announcement at w3.org.

3) Dividend Distribution with ERC‑2222

• On the record date T, check out ERC20Votes.pastVotes(holder, Tblock). From there, you can figure out the gross amount on a pro-rata basis. Next, make sure to fund the FDT. Holders can either withdraw anytime they want or set up an auto-sweep for custodians. (github.com)

1. Buyback tender

• The offer.acceptTender() function shifts the shares that have been tendered into a special “TENDER‑LOCKED” area. After the proration is done, we’ll settle it with stablecoin and call token.controllerBurnFrom(). Don’t forget to publish that seev.036 confirmation. Check it out here!

---

Best emerging practices (do these first)

• Go with ERC‑3643 as your go-to for permissioned equity. It's finalized, audited, and has the backing of the ecosystem (like ONCHAINID and trusted issuer registries). Check it out here.
• Keep your identity proofs up to par with W3C VC 2.0. Make sure to use selective disclosure and the Bitstring Status List for revocation. You can find more info here.
• Don’t forget to maintain an OCF cap-table bundle alongside your on-chain state. Automate bidirectional sync and continuous validation; you'll be grateful when audit time rolls around. More details here.
• Line up your CA event logs with ISO 20022 seev semantics; generate seev.031/033/036 for agents. This will help reduce risks when connecting with banks or custodians. Learn more here.
• Utilize Safe + 4337 modules for all your issuer operations and treasury movements; stick to maker-checker and policy controls. You'll appreciate that extra layer of security! For more details, click here.
• Opt for ERC20Votes snapshots instead of the outdated snapshot utilities; it’s the way to go in OZ 5.x. Check it out here.
• If you need some basic restriction messaging for a better user experience, consider borrowing ERC‑1404’s two-function interface on top of ERC‑3643 to standardize user errors. More info here.

---

Deep implementation details that save time

Rounding and Fractional Shares

• Hold onto those whole-share tokens! When it comes to reverse splits and fractional entitlements, calculate the “cash in lieu” using ERC-2222 distribution in USD-stablecoin. This way, you can sidestep those pesky dust balances. Check out more details here.

International Flowback Controls

• Set up Reg D/Reg S flowback filters for each country in the Identity Registry using the ISO‑3166 code linked to the holder's identity. Make sure to block any disallowed paths both server-side and on-chain to avoid any “leakage” during P2P transfers. (ercs.ethereum.org)

Lost Key Recovery

• Create a formal runbook: first, check the identity using re-issued VCs; then, rotate the ONCHAINID keys; finally, burn and mint the replacement tokens. Make sure to use time-lock controller actions and get Safe approvals. You can find more details here: (docs.onchainid.com)

Audit Surfaces

• Make sure to emit clear events: IdentityStored, Modified, Unstored, ComplianceRuleChanged, CorporateActionAnnounced, ElectionReceived, EntitlementCalculated, and PaymentPosted. Just a heads-up, the ERC‑3643 identity storage already takes care of emitting those identity events. You can check out more details here.

Vendor and CSD Connectivity

• DTCC is all about ramping up CA automation and rolling out ISO 20022 for announcements and allocations. Make sure your adapter is set for seev message generation and can handle inbound parsing. Check out more details on their website.

Governance Upgrades

• OpenZeppelin Contracts 5.x introduces some cool new governance features! Make sure to check out the release notes to keep an eye on counting overrides and delegate vote override patterns. A bunch of DAOs have made the jump from GovernorBravo to the OpenZeppelin Governor, so it’s a good idea to handle your issuer governance in a similar way. (blog.openzeppelin.com)

---

Example: Delaware C‑Corp, Reg D primary, Reg S affiliate

• Setup
  • Start by deploying the ERC‑3643 bundle, which includes the Token, IdentityRegistry, and Compliance components.
  • For claiming topics, go with KYC_BASIC, ACCREDITED_US, and RESIDENCY. Make sure you have trusted issuers lined up--these will be your KYC vendors. You can find more about this here.
  • On the off-chain side, you'll want to migrate your current cap table over to OCF. Make sure to include classes Common A and Super‑Voting B, and then commit everything to IPFS for those immutable references. Check it out here.
• Primary issuance
  • Go ahead and mint Common A shares into the “REGD‑LOCKUP‑365” partition. Common B shares will be reserved for the founders but remember to set up a vesting schedule using OCF. The vesting itself will stay off-chain, but make sure to enforce those transfer locks on-chain.
• Secondary controls
  • It's important to block any flowback from REGS to REGD holders for a specified time period. Transfers should be denied if IdentityRegistry.to.country is "US" and from.partition is "REGS." More details can be found here.
• First dividend (cash)
  • Once the board gives the green light and the Governor proposal passes, you’ll issue a CorporateActionAnnounced. Fund the ERC‑2222, set the record date as T, and allow holders to claim after the payable date. Don't forget to generate seev.036 confirmations for the custodians. More on this is available here.
• Later: 3‑for‑1 split
  • Time to mint an extra 2 shares for each holder. If any fractions arise from legacy odd lots, pay “cash in lieu” via FDT. Just confirm that through seev.036. You can dive deeper here.

---

What about ERC‑1400 vs. ERC‑3643?

• ERC‑1400 was a game-changer with its ideas on partitions, controller operations, and document management, and those concepts are still pretty handy. However, ERC‑3643 has come in strong as a final solution that focuses on identity and includes a thoroughly audited suite along with active associations. Nowadays, a lot of teams kick things off with 3643 and pick and choose elements from 1400 and 1410, like partitions, as they see fit. By 2025, independent analyses are expected to confirm this shift in the industry. (github.com)

---

Security and compliance notes

• Make sure to audit everything that can affect supply or change compliance, like controllers, factories, oracles, and such. Stick with trusted libraries like OpenZeppelin Contracts 5.x, and always keep an eye on the latest security advisories. You can find more info on their site: (contracts.openzeppelin.com).
• When it comes to identity data, steer clear of storing any personally identifiable information (PII) on the blockchain. Instead, go for VC 2.0 with privacy-preserving revocation. Only keep hashes or claim references in ONCHAINID. More details can be found here: (w3.org).
• Just a heads up, this article is packed with technical information but it’s not legal advice. Make sure to double-check any regulatory interpretations with your legal team.

---

Implementation checklist

• Choose your chains and pick a custody model; get your Safe up and running with the 4337 module for issuer operations. (docs.safe.global)
• Set up ERC‑3643 using the factory; configure your IdentityRegistry, Trusted Issuers, Claim Topics, and Compliance settings. (docs.erc3643.org)
• Integrate KYC/Accreditation as VC 2.0 credentials; connect issuer public keys; and get your Bitstring Status List hosting sorted. (w3.org)
• Align the cap table with OCF; set up continuous validation and take snapshots as needed. (open-cap-table-coalition.github.io)
• Add ERC‑2222 for your distributions; make sure to document your CA event taxonomy and ISO 20022 mapping. (github.com)
• Get your governance in place with OZ Governor and ERC20Votes; prepare proposal templates for different CA types. (docs.openzeppelin.com)
• Run those test scenarios: lost-key recovery, dealing with sanctions hits, revocation processes, and handling cross-border transfer blocks.

---

Bottom line

xStocks isn’t just a test run; it’s a practical solution you can actually roll out today. With ERC‑3643 (Final), you get permissioned tokens and identity-gated transfers, making things super secure. Plus, W3C VC 2.0 brings you portable, privacy-first credentials. Don't forget about ISO 20022 mappings--these allow you to talk the custodian language like a pro. When you mix all this with OCF, OpenZeppelin governance, and Safe modules, your equity turns into a dynamic system that’s auditable, automatable, and robust enough for enterprise use. Check it out here: (eips.ethereum.org)

Looking for a solid implementation plan, a reference architecture, and a pilot CA run (whether it's a dividend or split) in just 6-8 weeks? 7Block Labs has been there, done that, and we’re excited to lend a hand!