Zoom out. You can now name the parts — this lesson connects them into one system you can sketch on a whiteboard, defend in a design review, and probe in an interview.
Why this, now? Your mission is to design architecture and judge what your team builds. That means holding the whole platform at once: the journey of a single fund share from creation to redemption, and — the architect's central decision — where the on-chain / off-chain boundary sits at each step. Get the boundary right and the system is compliant, auditable, and not needlessly expensive. Get it wrong and you've either leaked private data on a public chain or rebuilt a database with extra steps.
The lifecycle of one fund share
Follow a single share through its life. Each stage reuses something you already know.
An investor is KYC'd off-chain; the result is written on-chain as a verified identity (ONCHAINID + Identity Registry, Lesson 4). The issuer's agent then mints tokens to the investor's verified wallet against their subscription. Tokens cannot be minted to an unverified wallet.
2 · Registry / Transfer Agent — the golden record
The on-chain token ledgeris the share register. The transfer agent maintains the legally authoritative record — often a dual book: traditional book-entry and the on-chain ledger, kept in sync via Transfer events (Lesson 3). This is the WisdomTree model.1
3 · Custody — who holds the keys
Holding a token = holding the private key to its wallet (Lesson 2). Institutions don't keep keys on a laptop — they use custodians / MPC (Fireblocks, Anchorage) with policy controls. Self-custody, third-party custody, or omnibus-vs-segregated wallets is a core design choice.
4 · Secondary transfer — investor to investor
A holder transfers to another. The token enforces the identity + compliance checkpoint (Lesson 4): the receiver must be verified and the transfer must pass every rule module (jurisdiction, lock-up, holder cap). Non-compliant transfers revert — settlement and compliance happen in the same atomic step.
5 · Servicing & Redemption — income and exit
Coupons / dividends / NAV come from an oracle / accountable feed (Lesson 1). Distributions are paid (often off-chain rails, sometimes on-chain stablecoin). At exit, the agent burns the investor's tokens against redemption proceeds. The share's life ends where it began — at the agent.
The on-chain / off-chain boundary (the real architecture)
This single table is the heart of the lesson. For each thing, an architect asks: does this need a shared, tamper-evident, multi-party source of truth (on-chain) — or is it private, high-volume, or legally-anchored elsewhere (off-chain)?
On-chain (shared truth)
Off-chain (private / authoritative elsewhere)
Token ledger (who owns what)
KYC documents & personal data (privacy + GDPR)
Transfer + compliance enforcement
The KYC process; identity verification
Identity attestations (claims: "is verified")
Legal authority, fund prospectus, contracts
Audit trail of transfers (events)
Private keys (custody)
Whitelist / eligibility state
NAV calculation, accounting, fees
The governing principle: put on-chain only what benefits from being a shared, tamper-evident record between distrusting parties. Everything else — especially anything private or voluminous — stays off, with only a hash or attestation anchored on-chain if proof-of-integrity is needed. (Storage is your most expensive resource — Lesson 2.)
Blue = on-chain enforcement & shared ledger. Gold = off-chain systems that trigger it and stay in sync via events. Note every arrow crossing the boundary is a trust/integration point to design.
The architectural decisions you own
An engineering leader doesn't write the contract — they make (and defend) these calls:
Decision
The trade-off in one line
Which chain
Public L1 (cost, congestion) vs L2 (cheaper, newer) vs permissioned (control, less interop). Lesson 7.
Custody model
Self vs third-party; segregated vs omnibus wallets. Lesson 6.
On/off-chain split
What must be shared truth vs what stays private. (This lesson.)
Upgradeability
Immutable safety vs ability to fix bugs / change rules. Lesson 6.
Oracle / data feeds
Who attests NAV & events, and how it's trusted. (Lesson 1.)
Event indexing / reconciliation
How off-chain books stay provably in sync with the chain.
The Marketnode lens & interview angles
The platform is mostly integration. The clever on-chain contract is a small core; most of the build is the off-chain systems and the boundary crossings (portal → mint, KYC → attestation, events → back office). Budget and hire accordingly.
"Walk me through what happens when an investor subscribes" is a perfect senior-interview question. A strong answer names the KYC→attestation→verified-mint flow and notes tokens can't reach an unverified wallet. A weak one says "we add them to the database."
"Where would you NOT put data on-chain, and why?" separates architects from enthusiasts. Listen for privacy, cost, and "anchor a hash instead."
Retrieve it (don't peek)
From memory. Interleaves Lessons 1–4.
1. Where should an investor's passport scan and KYC documents live, and why?
Correct. Personal data is private and voluminous — it stays off-chain. Only a claim/attestation ("is verified") goes on-chain, where shared eligibility truth is useful.
Reconsider. Public chains are world-readable and storage is costly — never put personal documents on-chain. Keep them off-chain; anchor only a verified-status attestation.
2. In this architecture, what keeps the transfer agent's off-chain books in sync with the chain?
Correct. Contracts can't call out (Lesson 2); they emit events. The back office subscribes to Transfer events — the reconciliation feed (Lesson 3).
Reconsider. A contract can't call an API. It emits events; off-chain systems subscribe to that log to stay in sync.
3. At redemption, an investor exits the fund. What is the on-chain action and who performs it?
Correct. Redemption removes shares from existence — the agent burns the tokens (Lesson 4) while proceeds are settled. Issuance mints; redemption burns.
Reconsider. Exiting the fund destroys the shares: the agent performs a burn against redemption proceeds. Minting is for subscription, not exit.
I'm your teacher — ask me. Want to redraw this diagram for a specific Marketnode product (a tokenized money-market fund, a structured note)? Or turn the "decisions you own" table into a design-review checklist you can actually use? Just ask.