Enterprise Ethereum Alliance · R&D
A shared standard for investor eligibility in tokenized markets
Shibui is an open-source attestation adapter for ERC‑3643 security tokens. It lets a token answer “may this wallet hold this security right now?” from attestations issued on the Ethereum Attestation Service by any trusted KYC, AML or accreditation provider.
Public entry point
isVerified(address wallet) → bool
Called by the token's compliance hook on every transfer.
Claim topic policies
8
One canonical payload, eight independently configurable predicates.
Networks reachable today
11
EAS mainnet deployments Shibui can be deployed against unchanged.
Natively interoperable — wherever EAS is deployed
EAS deployments →Shibui adds no chain-specific assumptions: the same contracts read the same two schemas on every network where the EAS registry lives. Attestations are per-chain, so an investor is re-attested per chain rather than bridged.
Plus Sepolia, Base Sepolia, Optimism Sepolia, Arbitrum Goerli, Polygon Amoy, Scroll Sepolia and Linea Goerli testnets.
Opening statement
ERC‑3643 mandates an on‑chain identity check on every transfer of a security token. The reference implementation requires each investor to deploy their own identity contract, pins the token to one KYC‑provider ecosystem, and enforces only that an attestation exists — never what it says.
Shibui replaces that identity layer with a small stack of contracts that read EAS attestations, enforce each payload against a configurable policy per claim topic, and gate trust changes with a cryptographic audit trail.
Tokenization scales settlement. Shared identity semantics scale distribution — the same way shared messaging standards did.
The problem
Distribution breaks on one question
Tokenization modernizes issuance and settlement. Distribution still stalls on who may hold the asset, and when — because every participant answers that question in its own dialect.
Longer form: The Passport Problem — why tokenized markets need shared identity
Eligibility is fragmented
Each issuer defines “KYC”, “accredited” and “qualified purchaser” differently. Investors repeat identical checks per token and per venue. Expiry, revocation and sanctions updates are applied by hand.
The cost lands on distribution
Slower onboarding, higher servicing cost, inconsistent evidence across jurisdictions — and a compliance posture that depends on manual reconciliation rather than on the token itself.
Issuer-by-issuer vs. shared standard
| Capability | Issuer-by-issuer | Shared standard |
|---|---|---|
| Onboarding | Repeated checks and bespoke integrations | Reusable evidence recognized across assets |
| Eligibility updates | Manual, slow propagation | Expiry and revocation enforced on the hot path |
| Oversight | Fragmented evidence trails | Common definitions and an evidenceHash per claim |
| Provider choice | One provider ecosystem per token | Many trusted attesters per topic, rotatable |
Approach
A deliberately small core
01
Standardize what eligibility means
One canonical EAS payload — ten ABI fields covering KYC, AML, sanctions, source of funds, accreditation type, country and expiry — decoded identically by every topic policy.
02
Let issuers choose who they trust
Each token recognizes its own set of trusted attesters per claim topic. Adding one requires a live Issuer Authorization attestation, so trust changes leave a cryptographic trail rather than a config diff.
03
Make change predictable
Revocation, EAS-level expiry and payload-level expiry are all checked on the transfer path. Revoking a claim blocks future transfers immediately; it does not move, freeze or recover tokens already held.
Operational view
Same controls, less duplication
Today
Investor submits documents
Issuer A onboarding
own identity contract
Issuer B onboarding
own provider ecosystem
Manual reconciliation on every update
expiry · revocation · sanctions
Duplicated checks, slow propagation.
With Shibui
Investor verified once
Trusted attester
authorized on-chain
EAS attestation — Investor Eligibility
10 fields · evidenceHash · expiry
Token A
requires KYC + country
Token B
requires KYC + accreditation
One credential, many tokens, updates enforced at transfer time.
Scope
What is fixed, what stays yours
Standardized
The language
Claim topics and their policies
Investor Eligibility payload — 10 fields
Update semantics and evidence hash
Flexible
The implementation
Which attesters you trust, per topic
Identity / KYC backend and wallet flows
Governance and operating model
Out of scope — stays with the token contract
Reference
Claim topics shipped in v0.4.0
A token requires a subset of these topics. isVerified returns true only when every required topic has a live attestation from a currently trusted attester whose payload satisfies the topic’s policy.
The last column shows where the underlying fact actually lives before it ever reaches EAS. isVerified only ever reads the attestation payload — it never queries these systems directly.
| ID | Topic | Rule enforced on payload | Source system of record |
|---|---|---|---|
| 01 | KYC | kycStatus == VERIFIED |
Identity verification vendor e.g. Entrust Identity Verification (formerly Onfido), Jumio, Trulioo — document + biometric check at onboarding. |
| 02 | AML | amlStatus == CLEAR |
AML screening engine e.g. LSEG World-Check (formerly Refinitiv / Thomson Reuters), ComplyAdvantage, LexisNexis Bridger Insight. |
| 03 | Country | countryCode in allow-list or block-list |
Same record as KYC
Residence / citizenship captured in the same onboarding record — no independent system. |
| 07 | Accreditation | accreditationType in admin allow-set |
Third-party accreditation verifier Law-firm or CPA qualification letter, or the broker-dealer's own suitability file. No single dominant vendor — often manual. |
| 09 | Professional investor | accreditationType != 0 |
Derived — not a source
Threshold read on the accreditation record above. Flag any vendor pitching this as a separate feed. |
| 10 | Institutional investor | accreditationType == INSTITUTIONAL |
Derived — not a source
Same accreditation record, highest tier. Not independently sourced. |
| 13 | Sanctions check | sanctionsStatus == CLEAR |
Sanctions / PEP screening engine Same engines as AML — LSEG World-Check, ComplyAdvantage, Dow Jones Risk & Compliance — screened against OFAC, UN and EU consolidated lists. |
| 14 | Source of funds | sourceOfFundsStatus == VERIFIED |
Enhanced Due Diligence (EDD) file Held inside the AML platform or a dedicated case-management tool (e.g. NICE Actimize). Triggered for high-value or high-risk investors. |
Topic identifiers follow the ERC‑3643 claim-topic convention. Canonical schema strings live in script/RegisterSchemas.s.sol. The source-system column is reference material on typical industry providers — the actual vendor is issuer-selected and not endorsed by the EEA.
Acronym key
KYC — Know Your Customer
AML — Anti-Money Laundering
PEP — Politically Exposed Person
OFAC — Office of Foreign Assets Control (US Treasury)
EDD — Enhanced Due Diligence
EAS — Ethereum Attestation Service
ERC‑3643 — T‑REX permissioned security-token standard
UID — Unique Identifier (schema / attestation)
Testing whether there is appetite
Is this worth solving?
There is no working group yet, and no commitment being asked for. Shibui is a research artifact: a reference implementation built to find out whether shared eligibility semantics are a problem the market actually wants solved together. If the answer is yes, that shapes what comes next.
If this sounds familiar
You are an issuer, asset manager, venue, transfer agent, KYC or accreditation provider, and you are re-onboarding the same investors token by token.
What we want to learn
Whether the eight claim topics match your real requirements, where the payload is wrong or missing fields, and which evidence expectations you could actually sign off on.
What signalling means
A note, a comment, or a conversation — nothing binding. If enough participants signal interest, the EEA can convene a proper group. If not, this stays a public reference.
Is this a problem you have?
Tell us so — briefly is fine. Reach out through the EEA, or comment in the open on the repository or the article.
Read further
Resources
Landscape
Identity solutions reference map
On-chain primitives, credential standards, institutional platforms, pilots and Travel Rule networks — with adoption notes and limitations.
Open the map →Article
The Passport Problem
Why tokenized markets need shared identity — the argument behind Shibui, written for a non-technical audience.
Read on LinkedIn →Implementation
Repository and documentation
Contracts, schema definitions, architecture notes, gas benchmarks, integration guide and the audit report.
View on GitHub →What a pilot would prove
01
Reuse one eligibility attestation across two tokens with different topic requirements.
02
Revoke a claim and show the next transfer is blocked, with the reason attributable to a topic.
03
Rotate a trusted attester under multisig control and confirm the authorization trail.