The problem with a token that circulates freely
An ERC-20 is like digital cash: it passes from hand to hand without asking who you are. Perfect for a cryptocurrency; useless for a security. If your token represents a stake, debt or right over an asset, it is — almost always — a security in the regulator's eyes, and a security has rules: who can buy it, from which countries, whether they're an accredited investor, how long they must hold it before reselling. A freely circulating token can't enforce any of those rules. The first transfer to an unverified wallet already put you out of compliance.
You could try to control it "off to the side" — with a database, manual reviews, promises. But then the rule lives off-chain, and anyone can bypass it. The idea of ERC-3643 is to put the rule inside the token.
What ERC-3643 is, in one sentence
It's a permissioned token for securities: an ERC-20 with two layers added, one for identity and one for compliance. Only wallets with a verified, eligible identity can hold or receive the token. If an unapproved wallet tries to receive it, the transfer reverts on-chain — it's not that someone blocks it afterward: the contract simply doesn't let it happen.
The stack, without the jargon
Beneath the token, five pieces do the work, each with a clear role:
ONCHAINID is the on-chain identity of each participant: a wallet holding "claims" that state things like "passed KYC" or "is an accredited investor." It doesn't store your personal data on-chain; it stores the verifiable proof that someone trustworthy reviewed it.
Identity Registry is the list of identities enabled for this particular token. It's the door: if your ONCHAINID is registered here, you can participate; if not, you can't.
Claim Topics Registry defines which claims this token requires. For example: "to hold this token you need the KYC claim and the eligible-residence claim." It's where the issuer translates the legal rule into a technical requirement.
Trusted Issuers Registry defines who has authority to issue those claims. Your KYC/AML provider (Sumsub, Onfido or another) acts as a trusted issuer: when it verifies an investor, it signs the claim on their ONCHAINID. The token doesn't trust anyone who says "I did KYC"; it trusts only authorized issuers.
Compliance is the module that applies the transfer rules on every move: per-investor limits, country restrictions, holding periods. It's the fine print of the offering, written in code.
What it looks like in a transfer
Every time someone tries to move the token, the contract asks a question before letting the transaction through: is the receiver in the Identity Registry, do they have the claims required by the Claim Topics Registry, signed by a Trusted Issuer, and does the operation satisfy the Compliance module's rules? If all yes, the transfer happens. If anything fails, it reverts. There's no grey zone.
That's the sentence that sums up the whole model: the law sets the rules, the code enforces them. The securities lawyer defines who can hold the token and under what conditions; ERC-3643 turns that definition into something that enforces itself, on every transaction, without relying on anyone's good faith.
Where our scope ends
It's worth being explicit, because this is the most-confused part. Braincoders deploys and configures the ERC-3643 contracts, integrates the KYC provider as a trusted issuer, and codes into the compliance module the rules that the lawyer defines. What we don't do is decide those rules: we don't define who is accredited, nor the token's legal nature, nor the resale restrictions. The legal specialist determines that, and we enforce it on-chain. ERC-3643 doesn't exempt you from having a good lawyer; what it does is make sure their work doesn't depend on no one bypassing the rules by hand.
Want to see how your legal structure maps to a permissioned token? Book a discovery call and we'll map it together.
