Enterprise Ethereum Alliance

Shibui / EEA research

A shared model for
investor eligibility

May this wallet hold this security right now?

Shibui is an open-source attestation adapter for ERC-3643 security tokens. This proposed model lets tokens evaluate investor eligibility using Ethereum Attestation Service (EAS) attestations from trusted KYC, AML or accreditation providers.

See how it works Share your requirements

Research artifact v0.4.0, April 2026 Apache-2.0

Eligibility topics
8
Fields in one EAS payload
10
EAS mainnet networks
11
How Shibui fits into ERC-3643

ERC-3643 checks investor eligibility on the transfer path. Its reference implementation links investor wallets to ONCHAINID identity contracts and checks required claims from trusted issuers. It supports multiple trusted issuers; identity deployment and management depend on the onboarding flow.

Shibui replaces that identity layer with a small stack of contracts that read EAS attestations, validate the shared payload against a configurable policy per claim topic, and gate trust changes with a cryptographic audit trail.

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.

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.

Compare issuer-by-issuer onboarding with the proposed model
Issuer-by-issuer vs. proposed shared model
Capability Issuer-by-issuer Proposed shared model
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 Bespoke provider integrations per token Many trusted attesters per topic, rotatable

Read the argument: The Passport Problem ↗

How it works

One payload. Three responsibilities.

One 10-field EAS payload is evaluated through eight independently enforceable eligibility policies.

  1. Standardize what eligibility means

    Every topic policy decodes the same Investor Eligibility payload. Fields may support multiple topics or carry shared metadata, so eight topics do not mean eight fields.

    See all 10 payload fields
    1. Investor identity
    2. KYC status
    3. AML status
    4. Sanctions status
    5. Source-of-funds status
    6. Accreditation type
    7. Country code (ISO 3166)
    8. Expiration timestamp
    9. Evidence hash
    10. Verification method

  2. 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. Administration is role-gated, with multisig governance in production.

  3. Make change predictable

    Revocation, EAS-level expiry and payload-level expiry are checked on the transfer path. Revoking a claim blocks future transfers immediately; it does not move, freeze or recover tokens already held.

In practice

Same controls, less duplication

Issuer-by-issuer

  1. An investor submits documents.
  2. Issuer A registers the identity; Issuer B builds its own provider integration.
  3. Each issuer reconciles expiry, revocation and sanctions updates.

Duplicated checks, slow propagation.

With Shibui

  1. A trusted, on-chain authorized attester issues an Investor Eligibility attestation per chain.
  2. The payload contains 10 fields, including evidence hash and expiry.
  3. Token A checks KYC + country. Token B checks KYC + accreditation.

Reusable across tokens whose trust and policy requirements it satisfies. Updates are enforced at transfer time.

Networks and underlying standards

The same contracts read the same two schemas wherever EAS is deployed. Attestations are per-chain: investors are re-attested on each chain rather than bridged.

Ethereum, Base, Arbitrum One, Arbitrum Nova, Optimism, Polygon, zkSync, Scroll, Linea, Blast and Celo.

Plus Sepolia, Base Sepolia, Optimism Sepolia, Arbitrum Goerli, Polygon Amoy, Scroll Sepolia and Linea Goerli testnets.

EAS deployments ↗

Built on Ethereum Attestation Service and ERC-3643, with EthTrust SL Level 2.

Scope

A shared language. Your implementation.

Defined by this model

  • Claim topics and their policies
  • Investor Eligibility payload, 10 fields
  • Update semantics and evidence hash

Chosen by each issuer

  • Which attesters you trust, per topic
  • Identity / KYC backend and wallet flows
  • Governance and operating model

Forced transfers, freezes, lost-key recovery, lock-ups and holder caps remain with the token contract. Cross-chain canonicity and tax / FATCA / CRS reporting are outside Shibui's scope.

Technical reference

Eight eligibility topics, one shared payload

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.

Public entry pointisVerified(address wallet) → bool

Called by the token's compliance hook on every transfer.

Provider examples expand in the last column. The verifier reads the attestation payload; it never queries those source systems directly.

Scroll the table sideways to see rules and source systems.

Eight eligibility topics shipped in v0.4.0
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.

ERC-3643 does not prescribe numeric topic IDs. This implementation follows an ONCHAINID-style convention commonly used in ERC-3643 deployments. Canonical schema strings live in script/RegisterSchemas.s.sol. Provider examples are reference material, 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)

Get involved

Is this worth solving together?

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 you are an issuer, asset manager, venue, transfer agent, KYC or accreditation provider re-onboarding the same investors token by token, we want to hear from you.

Tell us what would need to work

Do the eight topics match your requirements? Which fields are wrong or missing? What evidence expectations could you sign off on?

A note, a comment, or a conversation is enough. If enough participants signal interest, the EEA can convene a group. If not, this stays a public reference.

Signal interest ↗Comment on the repo ↗

Read further

Resources

Identity solutions reference map

On-chain primitives, credential standards, institutional platforms, pilots and Travel Rule networks, with adoption notes and limitations.

Open the map →

The Passport Problem

Why tokenized markets need shared identity, the argument behind Shibui, written for a non-technical audience.

Read on LinkedIn →

Repository and documentation

Contracts, schema definitions, architecture notes, gas benchmarks, integration guide and the audit report.

View on GitHub →
What a pilot would prove
  1. Reuse one eligibility attestation across two tokens with different topic requirements.
  2. Revoke a claim and show the next transfer is blocked, with the reason attributable to a topic.
  3. Rotate a trusted attester under multisig control and confirm the authorization trail.