Take ERC-20's permissionless transfer and make non-compliant transfers architecturally impossible. This is the standard your team builds on — $28bn+ of tokenized assets run on it.
Recall the toy registry: transfer checked only the balance. ERC-3643 keeps the ERC-20 interface (so all tooling still works) but inserts a two-part checkpoint before any tokens move:
// ERC-3643 transfer — conceptually function transfer(address to, uint256 amount) public returns (bool) { require(!frozen[msg.sender] && !frozen[to], "wallet frozen"); require(identityRegistry.isVerified(to), "receiver not an eligible identity"); // ① WHO require(compliance.canTransfer(msg.sender, to, amount), "breaks a rule"); // ② WHETHER // ...only now move the tokens (same as ERC-20) }
Those two requires are the whole game. ① asks "is the receiver a verified, eligible holder?" ② asks "does this specific transfer break any rule right now?" If either fails, the transaction reverts (Lesson 2) — the transfer simply cannot happen. Compliance isn't checked by a back-office process after the fact; it's enforced by the token itself, atomically, on-chain.
ERC-20-compatible, plus privileged operations a regulator demands: mint / burn, freeze, forced transfer, and recovery. These live on the token and are callable only by the agent (see below).
The Identity Registry maps each wallet address to an ONCHAINID — an on-chain identity contract holding signed claims ("this person passed KYC", "is accredited", "is in Singapore"). A Trusted Issuers Registry says whose claims count (which KYC provider you trust); a Claim Topics Registry says which claims are required. isVerified(addr) returns true only if the address's identity has all required claims from trusted issuers.
A modular contract holding pluggable rule modules: max holders, max balance per investor, country restrictions, lock-up periods, daily volume caps. canTransfer(...) runs every module; all must pass. New rule → new module, no token rewrite.
Memorise the split: Identity = WHO may hold. Compliance = WHETHER this transfer is allowed. Token = the asset and the powers to intervene. Nearly every ERC-3643 question decomposes into those three.
This is the part that shocks people coming from permissionless crypto, and the part your regulators require. An agent (an accountable, named operator — at Marketnode, the transfer-agent function) can:
| Power | Why regulation needs it |
|---|---|
| Freeze (whole wallet or partial) | Sanctions, court orders, suspected fraud, disputes. |
| Forced transfer | Court-ordered reassignment; correcting an erroneous holding; estate succession. |
| Recovery | Investor loses their private key → reissue their balance to a new verified wallet. The shares are not lost. |
| Mint / burn | Issue new shares (subscription) or remove them (redemption). |
This directly resolves the Lesson 1 tension — "a blockchain removes a trusted intermediary; regulation requires one." ERC-3643's answer: keep the shared, tamper-evident ledger, but grant a named, accountable agent the surgical powers law demands. Not trustless — accountable. Note the security flip side: whoever controls the agent key controls these powers → this is exactly the Fireblocks / custody question from our chat, and we'll dedicate a lesson to it.
| ERC-3643 concept | Marketnode / fund world |
|---|---|
| Owner | Issuer / platform — deploys the token, sets the rules and registries. |
| Agent | Transfer agent / registrar — mint, burn, freeze, force-transfer, recover. |
| Identity Registry + ONCHAINID | The KYC'd investor whitelist — only eligible investors may hold shares. |
| Trusted Issuers | The KYC/AML providers whose verification the fund accepts. |
| Compliance modules | Offering terms encoded: jurisdiction limits, investor caps, lock-ups. |
| Token holders | Investors — but only ones the registry has verified. |
Notice what's still off-chain: the legal KYC documents, the issuer's authority, the oracle feeding NAV. ERC-3643 puts the enforcement on-chain while the source of truth for identity and law stays off-chain — the recurring institutional pattern.
From memory. Q3 interleaves Lessons 1 & 3.
transfer internally runs the identity + compliance checks and reverts (Lesson 2) if either fails — making bad transfers impossible without breaking compatibility.transfer's signature for compatibility but inserts identity + compliance require checks that revert on failure — atomicity (Lesson 2) does the enforcing.The definitive read for your role — skim the architecture sections: ERC-3643 / T-REX Whitepaper (v4). For a quick orientation first, Chainalysis — Intro to ERC-3643. The source contracts live at github.com/ERC-3643 if you want to read real code.
transfer / canTransfer from GitHub line-by-line? Or build a set of ERC-3643 interview questions (with model answers) you can use when hiring? Or see how a compliance module is actually written? Just ask.