DeKYX: decentralized know your X

A reusable identity and participation-qualification layer for systems that must verify eligibility without learning more identity than one action needs. X may be a person, a legal entity, a device, a service or an autonomous agent. The application never receives the holder's secret; it receives a verified, scoped result.

source: dekyx/README.md · crate dekyx-core; the Aethel binding is aethel-dekyx in the aethel repository · research implementation, not certified as a KYC/KYB system

Credential and presentation flow

sequenceDiagram
    participant G as Governance
    participant I as Credential issuer
    participant H as Holder
    participant D as DeKYX verifier
    participant A as Application
    G->>D: Register issuer, key epoch, namespace and policy
    H->>H: Generate subject secret and commitment
    H->>I: Credential request + proof of possession
    I->>H: Signed scoped credential
    I->>D: Signed revocation status list
    A->>H: Exact presentation context and requirements
    H->>D: Anonymous presentation + selected qualification proofs
    D->>D: Verify issuer, signature, status, scope, context and replay
    D-->>A: VerifiedEligibility / scoped subject line

Core objects

Object	Purpose
`IssuerDefinition`	an issuer, its key epoch, namespace, subject kinds and validity window
`IssuerDirectory`	validated issuer epochs and current revocation lists
`CredentialRequest`	binds a holder-created commitment to an issuance proof
`Credential`	issuer-signed scope, policy, commitment and qualification root
`RevocationStatusList`	issuer-signed, epoch-ordered set of revoked credential digests
`PresentationContext`	binds a proof to one audience, action, request, nonce and expiry
`AnonymousPresentation`	proves possession and selected qualifications for that context
`VerifiedEligibility`	non-serialisable result produced only after verification
`PresentationLedger`	consumes a nullifier-context pair and rejects replay

Privacy model

The holder generates the subject secret and proves knowledge of the commitment opening at issuance; the issuer does not receive the secret. Qualification leaves are committed in a Merkle root, and a presentation reveals only the leaves the application's policy requires, proving they belong to the signed root. The challenge includes audience, action, request, nonce and expiry, so a transcript for one operation cannot be moved to another.

A subject line is derived from issuer, scope, policy and scope nullifier. It stays stable when the same holder receives a replacement credential under a rotated issuer key, so an application can enforce one line or one limit without learning a legal identity. Different scopes use different nullifier bases and re-randomised commitments. OCLOB uses this to cap one legal entity's concurrent orders; DeCCP uses it to admit a clearing member by subject line rather than by name.

This version is scope-pseudonymous, not issuer-unlinkable. An Ed25519-signed commitment is stable inside one credential and may be correlated with the issuer's issuance record. Deployments that need issuance unlinkability need a rerandomisable credential scheme, such as a reviewed BBS+ or CL-signature adapter. That is stated in the README and repeated here because it is the property a reader is most likely to assume.

Revocation, rotation and replay

Every accepted issuer-key epoch must have a signed status list. A missing or stale list fails closed; an older list cannot replace a newer one.
Key rotation registers a strictly higher epoch and bounds earlier epochs by a grace instant. A grace instant before the old key's start is the immediate-compromise path. Previously verified application records remain application state; the retired key cannot authorise a new presentation.
PresentationLedger consumes the pair of scope nullifier and presentation context. Re-randomising the proof does not make the same action reusable. The host must persist this ledger in authenticated storage, because rolling it back re-enables a replay.

Persistence boundary

IssuerRegistry cannot be deserialised around its validation; IssuerDirectory restores only through a validated record conversion; credentials, status lists, presentations and contexts are wire data verified before use; and VerifiedEligibility is deliberately not serialisable. It is an output of verification, never a trusted input.

Integration

flowchart TB
    CORE["dekyx-core
credential and presentation verification"]
    AA["aethel-dekyx (aethel repo)
optional artifact binding"]
    A["Aethel
credit and guarantee eligibility"]
    C["DeCCP
clearing-member admission"]
    O["OCLOB, QOMM, others
policy-specific eligibility"]
    AA --> CORE
    AA --> A
    CORE --> C
    CORE --> O
    Z["zkPI / DeFMI"] -. "no direct credential dependency" .-> CORE

zkPI and DeFMI do not define credentials; a host may require DeKYX eligibility before creating or settling an instruction. The instruction crate's issuer module carries its own KYB credential path over the same one-of-many and or-DLEQ gadgets, which predates DeKYX and is the vetting roll described on the DeFMI page.

What a deployment still has to define

Issuer governance, evidence standards, corporate-group resolution, revocation operations, data-retention policy, and jurisdiction-specific KYC/KYB obligations. Cross-issuer anti-Sybil policy requires a shared governance or registry decision outside the crate. The published revision passed test, clippy, fmt and release build on Linux with the locked graph; that is a build gate, not an audit.

← DeFMI DeCCP: clearing →