SSI Middleware Sandbox · Sepolia Privacy by design · GDPR Art. 25

Verifiable Credentials. For Financial Services.

Credential-gated access for financial services: the holder presents once, from their own wallet; the service receives a verdict — never the documents, never the claims.

1,653
Backend tests, measured at commit 6c5c00b
1
Deployed environment — a sandbox on Ethereum Sepolia
0
Claim values in OHNexus Protocol's own records — the verifier it operates keeps sessions in memory for its lifetime
EUDI
Wallet-ecosystem alignment in progress

The compliance stack is broken.
We remove the root cause.

The problem
KYC performed repeatedly

Every financial service repeats the same identity checks. Users submit the same documents to every provider.

Personal data stored everywhere

Raw documents, passports, and biometric data sit in siloed provider databases — each a breach waiting to happen.

No interoperability between providers

Compliance signals don't travel. A verified user at provider A remains unverified at provider B.

Regulations misaligned with architecture

GDPR mandates data minimisation. Most compliance stacks are architecturally incapable of it.

The OHNexus solution
Present once, decided every time

A credential presented from the wallet can satisfy every service whose policy accepts that type. Each service decides fresh, at the moment of access, from the presentation itself.

Zero raw data stored

OHNexus Protocol's own records hold outcomes and hashes, never claim values — no credential payload, no PII, no biometric data, by architecture. The verifier component OHNexus Protocol operates retains presentation sessions in memory for the lifetime of its process; that retention is upstream and is not claimed away here.

Portable across any provider

Credentials are SD-JWT VCs delivered over OpenID4VCI and presented over OpenID4VP — open standards, held in the user's wallet. No lock-in to any issuer or platform.

Privacy by design

GDPR Art. 25 is the design source: data minimisation at the data-model layer, shaped by an independent legal design review of the privacy model (March 2026) — a review of the design, not a current audit. A design commitment, not a compliance certification.

Three steps. One credential lifetime.

01 / VERIFY

Issue a verifiable credential

A trusted issuer — your KYC provider, an accredited authority, or the platform itself — issues an SD-JWT verifiable credential to the user's own wallet over OpenID4VCI. Signed by the issuer, bound to the holder's key.

02 / PRESENT

Present to a service

The user presents from their wallet over OpenID4VP, disclosing only the claims the service's policy names. The presentation is verified by a verifier the platform operates, and the issuer is checked against the platform's trusted-issuer registry.

03 / ACCESS

Access is decided, then anchored

The backend computes the verdict from the presentation and anchors the execution on Sepolia as hashes only — an execution id, the service code, a content hash. No identifier, no claim, nothing that names the holder. The service receives the verdict, never the credentials.

Three layers. Strict separation.

Layer 1

Verification

Cryptographic verification of SD-JWT credentials and presentations through a dedicated verifier service the platform operates. OHNexus Protocol's own stores keep no presentation payload — only a SHA-256 hash for audit correlation; the verifier's in-memory session retention is a separate, upstream matter. Issuer trust is checked against a control-proven registry.

SD-JWT VC OpenID4VP Key-bound issuer SHA-256 audit hash
Layer 2

Eligibility

Every service defines its own credential requirements — type, issuer, claim values, expiry. The eligibility engine evaluates all mandatory requirements in a single pass and writes a deterministic GRANTED or DENIED outcome. No caching. No stale state. Always a fresh evaluation at invocation time.

Claim-value matching Expiry enforcement Multi-credential
Layer 3

Execution

On AUTHORIZED, the protocol calls the publisher's provider API and, where the service declares it, issues a platform-signed credential to the user's wallet. The execution is anchored on Sepolia via the ServiceRequests contract as hashes — never a holder identifier. Provider endpoints receive no user credential data, no claim values, no PII.

On-chain anchor Auto-issued VC Zero PII forwarded

Built for two sides of the same market.

01

Financial Service Publishers

Fintechs, asset managers, regulated data providers

  • Publish gated services without building your own KYC infrastructure
  • Define credential requirements once — the protocol enforces them at every invocation
  • Receive a verdict — credential types and result — without ever seeing user documents
  • Auto-issue verifiable credentials to verified users post-execution
  • Each authorised execution anchored on Sepolia as hashes — never an identifier
02

Verified End Users

Retail investors, institutional participants, regulated individuals

  • Complete identity verification once — reuse across every connected service
  • Credentials live in your own wallet app, never on our servers
  • Selective disclosure — share only what each service requires
  • Sessions expire automatically; no persistent access without re-verification
  • Portable across platforms via open standards — SD-JWT VC, OpenID4VCI, OpenID4VP
⚖️
GDPR Art. 25
The design source. Data minimisation at the architecture layer, shaped by an independent legal design review of the privacy model (March 2026) — not a current audit, not a compliance certification.
📋
MiFID-style gates
A MiFID credential type exists in the platform registry today. What a gate requires is the publisher's own policy, written in plain language; the platform makes no regulatory claim on their behalf.
🔐
EUDI Wallet ecosystem
SD-JWT VC over OpenID4VCI / OpenID4VP. Alignment with the EUDI wallet ecosystem is in progress — it is the work, not yet a claim.

Engineered for verification without disclosure.

Wallet-held keys
The holder's keys live in the holder's wallet. Login is a proof of key control, a presentation is key-bound, a settlement is signed by the holder's own key — the platform never holds a holder's private key.
Key-bound issuer identity
The issuer's identity is its signing key. No registry, no gas. Holder binding by key thumbprint, never by a name.
OID4VCI + OID4VP
Industry-standard credential issuance and presentation protocols (SD-JWT VC). Walked end to end with the Sphereon wallet; EUDI/HAIP wallet compatibility is in progress.
High-performance backend
Memory-safe API server with all business logic tested in isolation. No raw credentials stored at any layer. Privacy-first by architecture.
Cloud infrastructure — one sandbox environment
Infrastructure as code, pinned deploys, least-privilege access, HTTPS end to end. One environment: dev.ohwnly.eu.
On-chain execution anchoring
Every authorised execution is anchored on Sepolia as hashes — execution id, service code, content hash. Service providers receive the verdict — no user data forwarded, no holder identifier on chain.

What exists today.

Completed

Protocol core — 1,653 backend tests passing

Full Verify–Eligibility–Execution stack, with the business logic tested in isolation from any cloud dependency.

Completed

Wallet-native presentation

Credentials are held in the user's own wallet app and presented over OpenID4VP. No custodial wallet, and no browser wallet of ours — the holder brings their own.

Completed

On-chain execution anchoring

ServiceRequests contract deployed on Ethereum Sepolia. Every AUTHORIZED invocation anchored with a cryptographic execution ID.

Completed

Publisher service lifecycle

End-to-end: draft wizard → validate → publish → credential-gated invocation → auto-issued VC to user wallet.

Completed

Publisher Studio and embed

Institutions write their policy in plain language in the Publisher Studio, and verify inside their own sites through the embed — their server receives the verdict, the browser leg carries no authority.

Running now

Sandbox on dev.ohwnly.eu

One deployed environment, on Ethereum Sepolia. Every shipped presentation path was walked there end to end with the Sphereon wallet. Not a production service.

Component Status
Verification Engine Sandbox
Eligibility Service Sandbox
Execution & Issuance Sandbox
Holder wallet External — Sphereon 0.8.0 walked
Publisher Dashboard Sandbox
On-chain Anchor Sandbox
Oracle Runner Dev
EUDI / HAIP wallet support In progress — walked today with Sphereon
Production Not yet — sandbox only

The financial system runs on trust. But trust today means handing over your passport to every gatekeeper. We built OHNexus so that proof of trust becomes portable — held by the user, verified by math, never stored by anyone.

Nikolay Gyuneliev — Founder, ØHNexus Protocol
Nikolay Gyuneliev
Founder, OHNexus Protocol

A working sandbox.
Built for regulated financial infrastructure.

OHNexus Protocol runs today as a sandbox on dev.ohwnly.eu for financial service providers and institutional participants who want to see credential-gated access work end to end. An assistant explains and guides — it never decides; every verdict is computed by the backend from a presentation. Schedule a demo to walk it with us.

Sandbox on dev.ohwnly.eu — walked with a real wallet
A dedicated verifier service behind the presentation leg
EUDI wallet-ecosystem alignment in progress

The identity layer
financial services deserves.

Privacy-preserving. Cryptographically verifiable. Built on open standards. OHNexus is the middleware between who you are and what you can access.