Gankpo architecture — overview.

The Gankpo ecosystem rests on a single cryptographic core, gkp_core, on top of which every application — Suite, Reader, Wallet, Gateway, documentation portal — is built. This page presents the broad lines of that architecture.

Section 1 — The three roles

Gankpo follows the holder-issuer-verifier model:

  • Issuer: the organisation that issues a sealed document or credential. It holds a signing key.
  • Holder: the person or organisation that receives the document or credential. They can store, present, and transmit it.
  • Verifier: the person or organisation that receives a document or credential and verifies its authenticity.

This model is aligned with W3C recommendations for verifiable credentials and with the European EUDI Wallet architectural framework.

Section 2 — The gkp_core engine

gkp_core is a proprietary Rust cryptographic engine of 38,000 lines, across 93 source files. It contains:

  • cryptographic primitives (signature, encryption, hashing, key derivation);
  • parsers and encoders for the .gkp, .gksend, GKP1 formats;
  • the multi-signature chain model (GKPR);
  • X.509 and CMS adapters for PKI interoperability;
  • the revocation model.

It is covered by 48 integration test files and 10 binary conformance vectors.

Section 3 — The applications

The applications in the ecosystem are application binaries that build on gkp_core through a FFI C interface:

  • Gankpo Suite (Tauri v2) — creation, sealing, verification on the desktop.
  • Gankpo Reader (Tauri v2 + mobile) — offline verification on desktop and mobile.
  • Gankpo Wallet (Capacitor) — credential holding and presentation on iOS and Android.
  • Gankpo Gateway (Rust axum) — server-side orchestration, REST API.
  • Documentation portal — public documentation.

Section 4 — Integration with secure keystores

Gankpo integrates with the hardware keystores available on each platform:

  • iOS: Secure Enclave via CryptoKit.
  • Android: Android Keystore, StrongBox when available.
  • macOS: Keychain Services.
  • Windows: CNG and TPM via the Microsoft Platform provider.
  • Linux: PKCS#11 for external HSMs.

Using a hardware keystore is recommended for issuer keys in production.

Section 5 — Offline-first model

Verifying a .gkp document, a .gksend envelope, or a GKP1 credential requires no network call at the time of the operation, provided the verifier has locally:

  • the issuer's public key;
  • the applicable revocation list, synchronised according to the local policy.

Public-key and revocation-list updates happen during online synchronisation phases, at a cadence defined by each deployment.

Section 6 — Deployment

Gankpo Gateway is distributed as a container image. A typical deployment includes:

  • a Gateway instance;
  • persistent storage for keys and logs;
  • an upstream TLS gateway (reverse proxy).

Higher-load deployments can horizontally scale the Gateway and distribute load through a balancer.

Section 7 — Further reading