Shibui Enterprise Ethereum Alliance (EEA)
Filter
On-Chain Identity & Compliance Primitives
ERC-3643 / T-REX
On-ChainStandard
Led by Tokeny Solutions — co-authored by Joachim Lebrun
High adoption
The leading standard for regulated security tokens on Ethereum. Defines a six-contract compliance framework: token, identity registry, claim topics registry, trusted issuers registry, modular compliance. Each investor needs an ONCHAINID smart contract storing signed claims (KYC, accreditation, jurisdiction, AML). Enforces transfer restrictions on-chain deterministically.
Adoption
Blackrock, ABN AMRO, Société Générale Forge. 12%+ of tokenized RWA by standard. 15+ chains. Formal Ethereum EIP.
Limitations
Per-token identity silos. No ZK-native privacy — country codes visible on-chain. ~1.5M gas per investor contract. Claim topics not globally standardized. ONCHAINID tooling is vendor-specific (Tokeny).
ONCHAINID (ERC-734/735)
On-ChainIdentity
Led by Tokeny Solutions
Moderate adoption
The default identity backend for ERC-3643. Each investor deploys a smart contract as their on-chain identity (ERC-734: key management; ERC-735: claim storage). Claims are signed by trusted issuers and stored in the identity contract. Any smart contract can verify claims by calling the identity contract. Open source contracts, but practical tooling is Tokeny-specific.
Adoption
Deployed alongside every ERC-3643 token. Used in production by Société Générale Forge, ABN AMRO, and ~50+ token issuers.
Limitations
~1.5M gas per contract deployment. No cross-chain portability. No ZK privacy. Tooling lock-in to Tokeny SDKs. ERC-734/735 never formally finalized as ERC standards.
Ethereum Attestation Service (EAS)
On-ChainProtocol
Led by Ethereum Foundation / attest.org — open source
High adoption
A two-contract system (SchemaRegistry + EAS) enabling anyone to register schemas and issue attestations on-chain or off-chain. Each attestation carries: recipient, attester, schema, data, expiry, revocability, and a refUID enabling attestation chaining. Off-chain attestations use EIP-712 signatures at zero cost. Supports Merkle-root private data with selective disclosure. Deployed on 15+ EVM chains.
Adoption
Coinbase, Optimism, Base, Gitcoin Passport, Worldcoin. 15+ chains deployed. Used by Shibui as identity substrate.
Limitations
No canonical financial schemas — schema proliferation risk. No native trust framework (who is a trusted attester?). On-chain attestations are public by default. No ZK-native verification circuit.
ERC-7943 (uRWA)
On-ChainInterface
Led by community — EIP authors: multiple contributors
Early adoption
Universal Real World Asset interface defining three view functions — canSend(), canReceive(), canTransfer() — that abstract the identity/compliance system behind a standard hook. Any token standard (ERC-20, ERC-721, ERC-1155) can implement this interface. The compliance system behind it is fully pluggable. Costs 5–10k gas per check vs 50k+ for full ERC-3643 modular compliance.
Adoption
Referenced by Shibui. Growing recognition as the right abstraction layer. Adopted as the interface pattern for next-gen compliance contracts.
Limitations
Interface only — says nothing about what checks happen inside. No metadata or credential standards. Not yet widely deployed in production. Standard still maturing.
Polygon ID (Privado ID)
On-ChainZK
Led by Polygon Labs → rebranded Privado ID (2024)
Growing adoption
W3C VC-based identity system with native ZK proof generation. Uses Iden3 circuits (credentialAtomicQuerySigV2 / MTPV2) to prove credential predicates (e.g. "age ≥ 18", "accredited = true") on-chain via Groth16 proofs without revealing the credential. The EmbeddedZKPVerifier contract gates smart-contract functions behind ZK proof verification. Issuer ecosystem for financial credentials is limited.
Adoption
Deployed on Polygon, Ethereum, and L2s. Used by DeFi protocols for KYC-gating. Strongest ZK credential model surveyed.
Limitations
No regulated financial credential issuer ecosystem. Proving time is non-trivial. No canonical financial schemas. Issuer infrastructure requires technical depth. Rebrand disrupted ecosystem momentum.
Securitize DS Protocol
On-ChainPlatform
Led by Securitize — Carlos Domingo, CEO
High adoption
Proprietary compliance protocol for tokenized securities. v4 uses investor-centric identity model (multiple wallets per investor identity) with EIP-712 attestations. Centralized registry tracks compliance status per investor. Platform manages KYC, AML, accreditation via partner network. Handles BlackRock BUIDL, KKR, Hamilton Lane funds. Largest tokenized fund platform by AUM.
Adoption
BlackRock BUIDL ($2B+). KKR, Hamilton Lane, Apollo funds. SEC-registered transfer agent. Dominant US platform for tokenized private securities.
Limitations
Proprietary — not ERC-3643 compatible. No cross-platform credential portability. Investor credentials locked to Securitize. Centralized registry creates single point of failure. No open standard.
Credential & Sovereign Identity Standards
W3C Verifiable Credentials 2.0
StandardVC
Led by W3C Credentials Community Group — Manu Sporny (Digital Bazaar)
High adoption (institutional)
The canonical credential envelope standard (W3C Recommendation, May 2025). Fields: @context, type, issuer, validFrom, validUntil, credentialSubject, credentialStatus, proof. BBS+ cryptosuite (bbs-2023) enables unlinkable selective disclosure — a holder derives proofs revealing only chosen attributes. Bitstring Status List handles revocation. SD-JWT variant (RFC 9901) enables selective disclosure for JSON credentials.
Adoption
eIDAS 2.0 mandates SD-JWT + mdoc. Used by Project Guardian, JPM Project EPIC, FATF TAP protocol, EBSI (EU). The dominant standard for institutional digital credentials.
Limitations
No canonical financial schemas — each issuer defines their own. JSON-LD parsing complexity. Multiple proof formats (BBS+, SD-JWT, Data Integrity) fragment the ecosystem. No on-chain native integration path.
GLEIF vLEI (ISO 17442-3)
StandardEntity ID
Led by GLEIF (Global Legal Entity Identifier Foundation) — Stephan Wolf, CEO
Growing — early institutional
Verifiable LEI credential system on top of the 2M+ LEI registry. Trust chain: GLEIF Root → Qualified vLEI Issuer (QVI) → Legal Entity VC → Official Organizational Role (OOR) / Engagement Context Role (ECR). Built on KERI (Key Event Receipt Infrastructure) with self-certifying identifiers and ACDC (Authentic Chained Data Containers). Designed as the canonical financial entity identifier for digital credentials.
Adoption
ISO 17442-3:2024 published. Piloted by ESMA, BIS, major banks. FATF 2024 update expands Travel Rule to LEI. BIS CPMI harmonization initiative. ~2M LEIs globally.
Limitations
KERI/ACDC tooling ecosystem is nascent. Not yet Ethereum-native — no on-chain verification contract. QVI ecosystem small. GLEIF issuance process is not real-time. Individual (natural person) identity requires separate framework.
eIDAS 2.0 / EUDIW
RegulationEU
Led by European Commission — DG CONNECT
Mandatory by Dec 2026 (EU)
Government-mandated digital identity wallet framework for EU citizens. Person Identification Data (PID) carries 30+ attributes (name, birth date, nationality, address) with mandatory selective disclosure in SD-JWT and ISO 18013-5 (mdoc) formats. Uses OpenID4VCI for issuance and OpenID4VP for presentation. Banks and PSPs must accept EUDIW for Strong Customer Authentication by December 2027. Authentic Sources include financial and company data.
Adoption
Mandated across EU 27 member states. December 2026 wallet availability deadline. December 2027 bank/PSP acceptance deadline. Largest government-driven digital identity deployment globally.
Limitations
EU-only scope. Implementation fragmented across member states. No direct on-chain integration path defined. mdoc and SD-JWT format split creates dual implementation burden. Natural persons only — no entity identity coverage.
W3C DID (Decentralized Identifiers)
StandardIdentity
Led by W3C Decentralized Identifiers Working Group
Moderate adoption
A W3C Recommendation (2022) defining a URI scheme for verifiable, self-sovereign digital identifiers independent of any centralized registry. A DID resolves to a DID Document containing public keys, verification methods, and service endpoints. Methods include did:web (domain-anchored), did:key (self-describing), did:pkh (blockchain address), did:ethr (Ethereum), and 100+ others. Foundation for W3C VC issuers and holders.
Adoption
Used by FATF TAP protocol, EUDIW (did:web for issuer), vLEI ecosystem, EBSI. Foundational identifier layer for all W3C VC deployments.
Limitations
100+ DID methods create fragmentation. did:web relies on DNS/HTTP — centralized dependency. No single resolver standard. Method quality varies enormously. Key rotation complexity. No financial sector canonical DID method defined.
SpruceID / DIDKit
ToolingVC
Led by Spruce Systems — Wayne Chang, CEO
Developer adoption
Open-source toolkit for W3C DID and VC operations. DIDKit provides cross-platform credential issuance, verification, and wallet capabilities in Rust/WASM/FFI. Rebase provides credential schema registry. SpruceID Wallet offers EVM-native credential storage. Used by state/government identity pilots (Colorado mDL) and enterprise blockchain identity. Ethereum Login (EIP-4361) co-authored by Spruce.
Adoption
Colorado digital driver's license. EIP-4361 (Sign-In with Ethereum) standard. Used by FATF TAP reference implementation. Open source with active community.
Limitations
No financial-sector credential schemas. Limited institutional issuer ecosystem. Developer-oriented — requires significant integration work. No production financial identity deployments documented.
Traditional Finance Identity & Messaging Infrastructure
ISO 20022
StandardMessaging
Led by ISO TC68 — maintained by SWIFT as Registration Authority
Universal in traditional finance
The global standard for financial messaging. Its PartyIdentification component carries LEI, BIC, structured addresses (15 fields), and private-identification fields (national ID, passport, tax ID, date/place of birth). Party roles span debtor, creditor, instructing/instructed agents, intermediary agents, ultimate debtor/creditor. Securities settlement messages (sese.023) carry full party chains with CSD identifiers. Mandatory for all major payment systems by 2025.
Adoption
Mandatory in SWIFT, TARGET2, Fedwire, CHAPS, SEPA. $5T+ daily. All major CSDs. The richest party-identification model in global production finance.
Limitations
Assumes confidential point-to-point channels — not designed for public ledgers. No cryptographic binding between party ID and on-chain address. Not machine-verifiable in real time. Schema complexity is enormous.
LEI / GLEIF Registry
StandardEntity ID
Led by GLEIF — governed by Financial Stability Board (FSB)
Mandatory for regulated entities
ISO 17442 — a 20-character alphanumeric code identifying legal entities globally. The GLEIF database holds 2M+ LEIs with associated legal name, registered address, parent/child entity relationships, and status. Required by MiFID II, EMIR, Dodd-Frank, and FATF Travel Rule. The global standard for legal entity identification in finance. Public, queryable API with full entity data.
Adoption
2M+ LEIs. Mandatory for regulated entities in EU, US, and 40+ jurisdictions. Required in SWIFT messages, securities filings, derivatives reporting. The anchor for vLEI.
Limitations
Annual renewal — can be lapsed. No cryptographic verifiability (vLEI solves this). Covers legal entities only — no natural persons. Renewal process can be slow for new entities.
FIX Protocol — Parties Block
StandardTrading
Led by FIX Trading Community
Universal in electronic trading
The Parties component block (PartyID + PartyIDSource + PartyRole) is the most flexible identity model in trade execution. Supports 14+ identifier types (BIC, LEI, CSD code, FDID, national ID) via PartyIDSource and 30+ roles (executing firm, clearing firm, custodian, beneficiary, sub-custodian) via PartyRole. Settlement-specific roles (values 27–32) define the full DvP counterparty chain. Used in every equity and derivatives trade on every major exchange.
Adoption
Used by every electronic trading venue globally. NYSE, NASDAQ, CME, LSE, Euronext. The de facto standard for order, execution, and settlement identity in capital markets.
Limitations
Point-to-point — no public verifiability. Identifiers are not cryptographically bound to parties. No DLT integration path defined. Role taxonomy is extensive but static.
ISDA CDM 6.0
StandardDerivatives
Led by ISDA — maintained by FINOS (Fintech Open Source Foundation)
Growing institutional adoption
Open-source standard model for financial products, trades, and lifecycle events. Party model: {partyId: PartyIdentifier[], name, businessUnit, person: NaturalPerson[], account}. Models 19+ lifecycle events (settlement, transfer, novation). v6.0 adds DigitalAsset type acknowledging blockchain-native assets. CDM Tokenized Assets Working Group extending the model for tokenized instruments. Used by DTCC, Barclays, Goldman Sachs in production.
Adoption
DTCC, Barclays, Goldman Sachs, JPMorgan in production. Adopted by ISDA, ICMA, ISLA. 100+ financial institutions contributing. FINOS open-source governance.
Limitations
Primarily derivatives-focused. Digital asset extensions still maturing. Complex model — steep learning curve. No direct on-chain execution integration. Party identity model is flexible but not standardized to LEI/DID.
SWIFT KYC Registry
InfrastructureKYC
Led by SWIFT
High adoption (correspondent banking)
A centralized repository of standardized KYC data for financial institutions engaged in correspondent banking. Holds ~6,000 FI profiles across five data areas: identification, ownership/UBO, business type, compliance programs, and tax. Each profile contains several hundred data points. SWIFT validates data and controls access. Institutions upload once and share with any correspondent. Reduces bilateral KYC duplication across the global correspondent network.
Adoption
~6,000 financial institutions. Used by global correspondent banks to streamline due diligence. SWIFT's blockchain initiative (2025) integrates this data with tokenized asset settlement.
Limitations
FI-to-FI only — not investor identity. Centralized and SWIFT-controlled. Not cryptographically verifiable. No API for real-time on-chain consumption. Annual subscription cost. Covers institutional counterparties, not retail/investor KYC.
Institutional Settlement & Identity Platforms
Kinexys by J.P. Morgan
PlatformBank-Led
Led by J.P. Morgan — Umar Farooq (formerly), Naveen Mallela (Digital Assets)
$2T+ daily volume
JPMorgan's blockchain-based settlement platform (formerly Onyx/JPM Coin). Identity = existing JPM banking relationship. Permissioned access gated by bank onboarding. Issues tokenized bank deposits (JPMD) as settlement asset. Project EPIC explores W3C VC-based portable identity for multi-institution DeFi. Processes cross-border payments, repo, FX. Partior (JPM + DBS + Temasek) extends to multi-bank interoperability.
Adoption
$2T+ daily on Kinexys Digital Payments. BlackRock, Siemens, 300+ institutional clients. Deutsche Bank completed first EUR blockchain transaction via Partior (Sept 2025).
Limitations
Identity = JPM banking relationship — excludes non-clients. Permissioned, proprietary. No interoperability with external credential frameworks without custom integration. Project EPIC still at PoC stage.
Canton Network (Digital Asset)
PlatformPrivacy
Led by Digital Asset — Yuval Rooz, CEO
High institutional adoption
A privacy-preserving blockchain platform built on Daml smart contracts with sub-transaction privacy. Party identity = cryptographic Daml party identifier; legal identity is deferred to the application layer. Canton Network connects Canton-based applications (Broadridge DLR, DTCC tokenization, Goldman Sachs GS DAP) via synchronization. BIS RLN US PoC validated at 1M TPS on Canton. Identity interoperability relies on off-chain legal agreements.
Adoption
Broadridge DLR ($8T/month repo). DTCC (SEC no-action Dec 2025). Goldman Sachs GS DAP. ASX (Australia). ~50 financial institutions on Canton Network.
Limitations
Legal identity deferred to application layer — no standard credential framework. Not EVM-compatible. Daml is proprietary smart contract language. No standard on-chain binding to LEI/DID/VC.
Fnality International
PlatformSettlement
Led by Fnality — consortium of Barclays, HSBC, Lloyds, Santander, UBS + others
Live (GBP, pilot stage)
Multi-currency settlement network using tokenized central bank money (Utility Settlement Coin concept). Identity = central bank access / bank membership in the Fnality consortium. Participants are regulated financial institutions vetted at the central bank level. No external credential framework — identity is the regulated bank status itself. Designed for wholesale interbank settlement and payment-vs-payment flows.
Adoption
GBP system live (2023). USD, EUR planned. Backed by 20+ global banks. Bank of England supervised. First production wholesale DLT settlement network.
Limitations
Identity = bank membership — no external credential portability. FI-only access. Each currency is a separate legal entity and network. DvP with external asset chains requires custom bridging.
DTCC Tokenization Service
InfrastructureCSD
Led by DTCC — Brian Steele, President Clearing & Securities Services
Launching H2 2026 (SEC no-action Dec 2025)
DTC tokenization service enabling DTC participants to register wallet addresses for tokenized securities. Each participant OFAC-screened before wallet registration. Digital Omnibus Account at DTC reflects all token holdings. DTCC retains a "root wallet" override. Tokens are not the securities — they are instructions for DTC to record transfers. Beneficial ownership tracked off-chain by broker-dealers. Preserves the street-name model.
Adoption
SEC no-action relief December 2025. Launch H2 2026. 5,000+ DTC participant network. If adopted, covers the majority of US equity and bond settlement infrastructure.
Limitations
DTC-participant identity only — not investor identity. Beneficial ownership remains off-chain at broker-dealer level. No standard credential framework for wallet-to-identity binding. Preserves opacity of street-name model.
Central Bank & Regulatory Pilot Programs
Project Guardian (MAS)
PilotRegSandbox
Led by Monetary Authority of Singapore — with DBS, J.P. Morgan, SBI Digital Markets
Active pilots — production-adjacent
MAS-led initiative testing tokenized asset markets with regulated institutions. Identity model: W3C Verifiable Credentials issued by regulated trust anchors (DBS, JPM, SBI) gate access to modified DeFi protocols (Aave Arc). Proved that VCs can serve as institutional trust anchors preserving counterparty privacy. ICMA Fixed Income Framework produced DvP settlement guide distinguishing payment-leg identity (banking AML) from delivery-leg identity (securities eligibility).
Adoption
50+ institutions across 13 pilot workstreams. Live trades in tokenized bonds, FX, funds. Most advanced regulatory sandbox for tokenized finance. ICMA framework published as global reference.
Limitations
Singapore-jurisdiction primary focus. VC schemas are pilot-specific — not standardized across workstreams. Cross-border legal recognition of VCs not yet established. Pilot conditions differ from production compliance requirements.
Project Agorá (BIS)
PilotBIS
Led by BIS Innovation Hub — with 7 central banks + commercial bank consortium
Active development 2024–2025
BIS-led initiative building a unified ledger where wholesale CBDC and commercial bank deposits share a programmable platform. Identity flows through the depositor-bank relationship. Compliance metadata — geographic attributes, transfer type, party identification — is embedded directly into the token. Aims to streamline pre-validation by sharing compliance data across banks, eliminating redundant screening in cross-border payments.
Adoption
Fed, ECB, Bank of England, Bank of Japan, BdF, SNB, MAS participating. 40+ commercial banks. Most significant multilateral CBDC interoperability initiative active today.
Limitations
Wholesale only — no retail identity model. Compliance metadata embedding in token raises privacy concerns. Cross-jurisdictional legal framework not resolved. Identity standard not yet defined — deferred to Phase 2.
Regulated Liability Network (RLN)
PilotMulti-Bank
Led by NY Innovation Center (NYIC/Fed) — with BofA, Citi, HSBC, JPM, Wells Fargo, Mastercard
PoC completed — commercialization TBD
A shared-ledger concept where each token is a regulated bank liability, carrying that institution's compliance framework. Built on Canton/Daml with sub-transaction privacy. Identity = being a regulated bank participant. Legal working group concluded that using DLT does not alter the legal treatment of deposits. US PoC validated technical feasibility at 1M TPS. UK PoC followed. No new legal instruments required.
Adoption
US PoC: BofA, Citi, HSBC, JPM, Mastercard, Wells Fargo. UK PoC: separate consortium. Technical feasibility proven at scale. Regulatory clarity established — no new law needed.
Limitations
No investor-level credential framework. Identity = bank membership. Commercialization path unclear after PoC. No EVM compatibility. Legal framework covers US/UK only. Interoperability with non-bank tokenized assets undefined.
Travel Rule & VASP Identity Frameworks
IVMS101
StandardTravel Rule
Led by interVASP Messaging Standards Working Group (JMLSG)
Industry standard for Travel Rule
The FATF Travel Rule data standard defining originator and beneficiary data schemas for VASP-to-VASP transfers. Defines NaturalPerson (name identifiers, geographic address, national ID, date/place of birth) and LegalPerson (name, LEI, registered address). 11 national identifier types including LEIX (LEI). Used by Notabene, Sygna, VerifyVASP, and the TAP protocol. The TAP protocol wraps IVMS101 in W3C Verifiable Presentations.
Adoption
Used by all major Travel Rule compliance vendors. Coinbase, Binance, Kraken, major VASPs. Reference data model for FATF R.16 compliance globally.
Limitations
VASP-to-VASP only — not designed for securities or institutional DvP. No on-chain format. Pairwise exchange — no broadcast/discovery. Jurisdictional thresholds vary ($1K in EU, $3K in US). No ZK privacy option.
TAP Protocol (TAIP)
StandardProtocol
Led by Notabene — open protocol, multi-stakeholder
Early adoption — growing
Transaction Authorization Protocol — wraps IVMS101 in W3C Verifiable Presentations exchanged between DIDs (did:web, did:pkh). TAIP-10 defines the IVMS101 VC format. The most direct bridge between Travel Rule compliance and the W3C credential ecosystem. Enables selective disclosure of originator/beneficiary data. Signed by institutional DIDs, making VASP identity cryptographically verifiable.
Adoption
Notabene reference implementation. Growing VASP adoption. Positions Travel Rule data as the first widespread deployment of W3C VPs in financial services.
Limitations
VASP-only scope. did:web reliance on DNS. Not yet adopted by legacy TRP protocol users. Standardization not yet complete. No securities/DvP applicability defined.
Notabene / VerifyVASP / Sygna
PlatformTravel Rule
Three competing Travel Rule networks — Notabene (NYC), VerifyVASP (Singapore), Sygna (CoolBitX)
Hundreds of VASPs each
The three dominant Travel Rule compliance networks enabling VASP-to-VASP IVMS101 data exchange. Each operates as a permissioned network of verified VASPs. Notabene uses TAP/W3C VP. VerifyVASP uses its own encrypted P2P protocol. Sygna integrates with CoolBitX's exchange clients. All three participate in cross-network interoperability (TRISA/TRUST frameworks). Key function: VASP identity discovery + compliant data exchange before on-chain transfer.
Adoption
Notabene: Coinbase, Crypto.com, 200+ VASPs. VerifyVASP: Asia-Pacific heavy, 300+ VASPs. Sygna: CoolBitX exchange clients. Combined: majority of regulated global VASP activity.
Limitations
Three incompatible networks — sunrise problem persists. VASP-only scope. No securities or institutional DvP coverage. Data exchange pre-transfer but no on-chain proof generated. Subscriber costs limit small VASP adoption.