Yours
Whether an investor is eligible at all. KYC, AML, accreditation, jurisdiction, suitability, lock-up terms — the decision and the evidence behind it stay in your systems, where they already are.
Part of the Tokenization Engine
Compliance the token cannot be talked out of
Permission lives on chain, in a registry the token reads on every single transfer. The token is an ERC-20 implementing ERC-7943, so the check is the instrument's own, not a wrapper around it. Nothing off chain can wave a transfer through — not your backend, not ours, not an operator with database access.
A compliance list is a set of wallets, each carrying two independent flags: may send, may receive. Lists are attached to tokens. A token consults the registry inside the transfer itself, so a wallet that is not permitted cannot receive units however the transfer was initiated.
The list lives outside the token deliberately. One list can gate several tokens, and an investor's permissions change without redeploying or upgrading anything.
Send and receive are separate
Two flags rather than one membership bit, because the situations that matter are asymmetric. An investor in a lock-up may receive and not sell. An investor under sanction may be stopped from sending while keeping their position, which is a very different act from confiscating it.
Both are ordinary permission changes — one transaction, no redeploy, effective on the next transfer.
transfer.check
transfer(from, to, amount)
canSend(from)?
canReceive(to)?
settle, or revert
It fails closed
A token with no compliance list attached cannot be minted and cannot be moved at all.
There is no unrestricted mode to forget to switch off, and no configuration flag whose default is permissive. A token that has not been wired up is inert rather than open, which is the behaviour you want from the state a token is in for the few minutes between deployment and setup.
Where the boundary sits
Ours
Turning that decision into an on-chain permission that holds, keeping the registry and your records in step, and making the enforcement something you can point an auditor at rather than assert.
Tokenistry does not provide legal, regulatory, KYC or AML services, and does not decide who is eligible. It engineers the layer those decisions have to survive contact with.
Roles, per subject
Creating a list makes the caller its administrator, and administering a token's compliance is a role held per token rather than globally. An account authorised to manage one token's lists has no authority over another's.
Deploying a token grants administration and nothing else — minting, burning and attaching compliance are each granted explicitly. Inconvenient exactly once, and the reason a compromised service cannot quietly do all three.
FAQ
Is this a separate service?
No. Enforcement is the on-chain compliance registry; the Tokenization Engine creates lists, sets permissions, attaches lists to tokens and mirrors the resulting state. There is no separate compliance service to deploy or operate.
Do you decide who is eligible?
No, and you should be wary of anyone who offers to. Eligibility is a regulated judgement about a person, made with evidence we never see. We consume the result and make it enforceable.
Can permissions be changed after issuance?
Yes. Adding, removing or altering a wallet's flags is a single transaction against the registry and takes effect on the next transfer. The token is not redeployed and holdings are untouched.
Do we have to re-permission everyone for each new token?
No. A list is not owned by a token: it holds wallets and their flags, and you attach it to as many tokens as it should govern. Attach an existing list to a second token and every wallet already on it is permitted there from the next transfer, with nothing re-entered and no second copy to keep in step. A token's answer is the union of the lists attached to it, so detaching withdraws exactly the grants that list contributed and leaves the rest standing. What a list does not model is the investor. Membership is by wallet, so someone holding through three wallets is three entries, and a fourth wallet has to be added to every list they belong to. Flags sit on the wallet inside the list rather than on the attachment, so a list carries the same permissions to every token it gates. Deriving those wallet entries from investor identity is the direction; reusing one set of wallets across many tokens already works.
What this module owns
Owns
- chain-facing eligibility state
- send and receive permissions per wallet
- the registry the token reads inside every transfer
- per-token list administration
Does not own
- KYC and AML systems
- the legal eligibility determination itself
- investor identity — membership is by wallet
- who your regulator says may hold the asset
Technical surface
Permission lists are their own resource, not a field on a token. One list can gate several tokens, and creating a list makes the caller its administrator.
- GET /v1/compliance/lists
- POST /v1/compliance/lists
- POST /v1/compliance/lists/{id}/permissions
- POST /v1/compliance/roles
- POST /v1/tokens/{token}/lists
- GET /v1/operations/{id}
Every mutating call carries an Idempotency-Key and returns an operation that is polled to a terminal state, so a retry returns the original operation instead of issuing a second one. Rejections before signing, conflicts and reverted executions are distinct failures rather than one generic error. The full schema is served as OpenAPI by the deployment itself.
Deployed as a container image with a Helm chart and Terraform modules, single-tenant in your own cloud account, against a PostgreSQL database you hold — see the deployment model.
Related
Permissions that hold outside your own database
We can map your eligibility decisions onto enforcement the chain applies for you.
Discuss your architecture