Skip to content

Unikernels for Payment Infrastructure: A Research Assessment for Simpaisa Holdings

Version: 1.0.0 Date: 2026-04-06 Author: Daniel O'Reilly, Chief Digital Officer Classification: Internal — Architecture & Engineering Leadership Status: Research Paper — Technology Radar EVALUATE Candidate

Abstract

Unikernels — single-purpose, library operating systems compiled directly with an application into a minimal virtual machine image — represent a fundamentally different approach to deploying payment infrastructure. For Simpaisa Holdings, processing over $1 billion annually across eight regulated markets, the security, performance, and compliance characteristics of unikernels warrant serious investigation. This paper assesses the current state of unikernel technology against Simpaisa's specific requirements: sub-millisecond API response times, strict data sovereignty across Pakistan, Bangladesh, Nepal, Iraq, Egypt, the UAE, and Saudi Arabia, and a security posture currently rated at 4/10 that must improve rapidly. Unikernels eliminate entire classes of attack vectors by removing shells, user accounts, and unnecessary system calls from deployed images, reducing the applicable NIST 800-53 control surface by an estimated 30–40%. Performance benchmarks demonstrate 13–18x faster cold starts than containers, with memory footprints as low as 2–10 MB. The leading open-source implementation, Unikraft, now supports Go — Simpaisa's primary language — with Linux-compatible ABIs and Dockerfile compatibility. This paper recommends EVALUATE status on Simpaisa's Technology Radar with a targeted pilot in Q4 2026, contingent on the Go microservices migration (Project Phoenix) reaching stability.

Table of Contents

  1. Introduction
  2. How Unikernels Work
  3. Security Benefits
  4. Performance Characteristics
  5. Data Sovereignty and Regulatory Compliance
  6. Application to Payment Gateway Architecture
  7. Unikraft: The Leading Candidate
  8. Challenges and Risks
  9. Migration Strategy for Simpaisa
  10. Conclusion
  11. References

1. Introduction

1.1 What Are Unikernels?

Unikernels are specialised, single-address-space machine images constructed by compiling an application together with only the operating system components it actually requires — network stacks, file system drivers, memory allocators — into a single bootable virtual machine image. Unlike traditional operating systems, which ship millions of lines of code to support arbitrary workloads, a unikernel contains nothing the application does not explicitly need. There is no shell. There are no user accounts. There is no package manager, no cron daemon, no SSH server. The result is an immutable, purpose-built image that boots directly on a hypervisor.

The concept originated in academic research at the University of Cambridge (MirageOS, 2013) and has matured through several implementations: Unikraft (open source, Linux-compatible), NanoVMs/Nanos (targeting Go and C workloads), MirageOS (OCaml), and IncludeOS (C++). The technology has moved from research curiosity to production viability, with Unikraft securing $6 million in funding in October 2025 to build a managed cloud platform.

1.2 Why Unikernels Matter for Payments

Payment infrastructure occupies a unique position in the software landscape. It must be simultaneously high-performance (sub-second transaction processing), highly secure (PCI-DSS, central bank regulations), and auditable (regulators require reproducible, verifiable deployments). Containers addressed the first requirement adequately but introduced shared-kernel security concerns. Unikernels address all three requirements architecturally rather than through compensating controls.

1.3 Simpaisa's Context

Simpaisa Holdings operates a payment gateway processing over $1 billion in transactions across seven markets: Pakistan (SBP-regulated), Bangladesh (Bangladesh Bank), Nepal (NRB), Iraq (CBI), Egypt (CBE), the UAE (CBUAE), and Saudi Arabia (SAMA). The organisation is currently migrating from a legacy monolith to Go microservices (Project Phoenix), with a security posture self-assessed at 4/10. The infrastructure runs on Docker containers orchestrated via Kubernetes. Any new compute paradigm must integrate with this migration trajectory, not disrupt it.

2. How Unikernels Work

2.1 Architecture Comparison

┌─────────────────────────────────────────────────────────────────────┐
│                    TRADITIONAL OS (VM)                               │
│  ┌──────────┐ ┌──────────┐ ┌──────────┐                           │
│  │  App A   │ │  App B   │ │  App C   │  ← Multiple applications  │
│  └────┬─────┘ └────┬─────┘ └────┬─────┘                           │
│  ┌────┴────────────┴────────────┴─────┐                            │
│  │       Full Linux Kernel            │  ← ~28M lines of code     │
│  │  (shell, users, cron, SSH, ...)    │                            │
│  └────────────────────────────────────┘                            │
│  ┌────────────────────────────────────┐                            │
│  │          Hypervisor                │                            │
│  └────────────────────────────────────┘                            │
└─────────────────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────────────────┐
│                    CONTAINERS (Docker/K8s)                           │
│  ┌──────────┐ ┌──────────┐ ┌──────────┐                           │
│  │  App A   │ │  App B   │ │  App C   │  ← Isolated processes     │
│  │ + libs   │ │ + libs   │ │ + libs   │                            │
│  └────┬─────┘ └────┬─────┘ └────┬─────┘                           │
│  ┌────┴────────────┴────────────┴─────┐                            │
│  │     SHARED Linux Kernel            │  ← Single kernel, shared  │
│  │  (full syscall surface exposed)    │     Container escapes      │
│  └────────────────────────────────────┘     possible (CVE-2024-*)  │
│  ┌────────────────────────────────────┐                            │
│  │          Hypervisor / Bare Metal   │                            │
│  └────────────────────────────────────┘                            │
└─────────────────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────────────────┐
│                    UNIKERNELS                                       │
│  ┌──────────────────┐ ┌──────────────────┐ ┌──────────────────┐   │
│  │   App A          │ │   App B          │ │   App C          │   │
│  │ + minimal kernel │ │ + minimal kernel │ │ + minimal kernel │   │
│  │ + net stack only │ │ + fs + net       │ │ + net stack only │   │
│  │   (~10K lines)   │ │   (~15K lines)   │ │   (~10K lines)   │   │
│  └────────┬─────────┘ └────────┬─────────┘ └────────┬─────────┘   │
│  ┌────────┴────────────────────┴────────────────────┴─────────┐   │
│  │                    Hypervisor                               │   │
│  │  Each unikernel = dedicated VM, no shared kernel            │   │
│  └─────────────────────────────────────────────────────────────┘   │
└─────────────────────────────────────────────────────────────────────┘

2.2 Key Architectural Properties

Single address space. The application and the OS components share a single address space with no user/kernel boundary transitions. This eliminates context-switching overhead — a significant contributor to latency in traditional deployments.

No shell, no users, no unnecessary syscalls. A unikernel image contains only the system calls the application actually invokes. If the application never calls execve, the syscall does not exist in the image. There is no /bin/sh, no root user, no privilege escalation path.

Immutable images. Once compiled, the image cannot be modified at runtime. There is no package manager to install malware, no writable filesystem to plant a backdoor. The image is a cryptographic hash that can be verified against a build manifest.

2.3 Build Process

The build process compiles the application source code together with selected OS library components into a single bootable image:

 Source Code (Go)  +  OS Libraries (net, TLS, memory)  →  Compiler  →  Bootable VM Image
                                                                         (2-10 MB)

For Unikraft specifically, the process supports standard Dockerfiles, meaning existing CI/CD pipelines require minimal modification. The output is a QEMU/KVM-compatible image or a cloud-specific AMI/image.

2.4 Key Implementations

Implementation Language Support Licence Maturity Notes
Unikraft Go, C, C++, Python, Rust BSD Production-ready Linux-compatible ABI, managed cloud
NanoVMs/Nanos Go, C Apache 2.0 Production-ready Strong Go support, OPS tooling
MirageOS OCaml ISC Mature Academic origin, type-safe
IncludeOS C++ Apache 2.0 Stable Acquired by Includeos AS

3. Security Benefits

3.1 Attack Surface Reduction

The Linux kernel comprises approximately 28 million lines of code. A typical container image includes a user-space distribution adding millions more. A unikernel image for a Go HTTP service contains approximately 10,000–50,000 lines of OS code — a reduction of two to three orders of magnitude. Every line of code removed is a line that cannot contain a vulnerability.

Research by Talbot et al. (2025) surveyed the security properties of unikernels systematically and confirmed that the architectural elimination of components produces measurable reductions in vulnerability surface [2].

3.2 Eliminated Attack Vectors

Attack Vector Container Unikernel
Remote code execution via shell Possible (/bin/sh exists) Impossible (no shell)
Privilege escalation Possible (users, setuid) Impossible (no users)
Lateral movement Possible (shared kernel) Impossible (dedicated VM)
Container escape Known CVEs annually Not applicable (no container)
Runtime modification Possible (writable fs) Impossible (immutable image)
Supply chain injection at runtime Possible (apt, pip) Impossible (no package manager)

3.3 Compliance Impact

The NIST 800-53 framework defines security controls across families including Access Control (AC), Audit and Accountability (AU), Configuration Management (CM), and System and Information Integrity (SI). When there are no user accounts, access control requirements for user management do not apply. When there is no writable filesystem, configuration management controls for runtime modification do not apply. Conservative estimates suggest a 30–40% reduction in applicable controls for unikernel-deployed workloads [2][6].

For PCI-DSS specifically, several requirements become architecturally satisfied:

  • Requirement 2 (Do not use vendor-supplied defaults): No default accounts, no default services.
  • Requirement 5 (Protect against malware): No mechanism to install or execute malware.
  • Requirement 6 (Develop secure systems): Immutable images with cryptographic verification.
  • Requirement 8 (Identify and authenticate access): No user access to satisfy — single-process, no shell.
  • Requirement 10 (Track and monitor access): Simplified — only application-level logging exists.

3.4 Comparison to Container Security

Containers share the host kernel. Every container escape vulnerability (CVE-2024-21626 in runc, CVE-2024-32000 in Docker, and their successors) affects all containers on the host. Runtime security tools (Falco, Sysdig) exist as compensating controls but add complexity and cost. Unikernels eliminate the shared kernel as an attack vector entirely — each unikernel is a dedicated virtual machine with hardware-level isolation via the hypervisor.

4. Performance Characteristics

4.1 Boot Time

Unikernel boot times are measured in milliseconds rather than seconds. Benchmarking by Kurek et al. (2025) measured the following cold start times [1]:

Platform Cold Start Time Relative
Unikernel (Unikraft) ~12 ms Baseline
Docker container 158–220 ms 13–18x slower
Traditional VM 2,000–5,000 ms 166–416x slower

For payment API endpoints, this enables true scale-to-zero with millisecond restart — a stateless webhook endpoint can spin up, process a request, and terminate without maintaining idle resources.

4.2 Memory Footprint

Deployment Memory Footprint
Unikernel (Go HTTP service) 2–10 MB
Docker container (Go HTTP service) 50–200 MB
Traditional VM 512 MB – 2 GB

At 2–10 MB per instance, a single server can host 10,000–100,000+ unikernel instances. This density fundamentally changes the economics of per-market, per-jurisdiction deployment — running a dedicated instance for each of Simpaisa's eight markets becomes trivial rather than expensive.

4.3 Throughput and Latency

Benchmarks from Kurek et al. (2025) demonstrate throughput improvements of 200–300% on equivalent cloud instances for CPU-bound workloads [1]. Network I/O benefits from the elimination of context switches between user space and kernel space. For lightweight HTTP workloads, sub-millisecond response times are achievable.

4.4 Caveats

Performance benefits are not universal:

  • I/O-bound workloads that spend most time waiting on database queries or external APIs may see minimal improvement — the bottleneck is not the OS overhead.
  • Memory-constrained environments below approximately 128 MB show degraded performance as garbage collection in Go competes with the minimal memory allocator [1].
  • Complex multi-threaded workloads may not benefit equally, as the single-address-space model eliminates some parallelism optimisations available in full kernels.

These caveats are important for honest assessment, but many of Simpaisa's target workloads (stateless API endpoints, webhook delivery, cryptographic operations) are precisely the CPU-bound, short-lived workloads where unikernels excel.

5. Data Sovereignty and Regulatory Compliance

5.1 Single-Tenant Isolation by Design

Simpaisa operates across eight jurisdictions, each with distinct data sovereignty requirements. Containers share a kernel — a Pakistani customer's transaction data and an Egyptian customer's transaction data may be processed by containers running on the same kernel. A kernel vulnerability exposes both. Unikernels provide hardware-level VM isolation for each instance. A unikernel processing Pakistani transactions is as isolated from an Egyptian unikernel as two separate physical servers.

5.2 Per-Jurisdiction Deployment

At 2–10 MB per instance, running dedicated unikernel instances per market is economically viable. Each market's payment channel adapter can be compiled as an independent unikernel containing only the integration logic for that jurisdiction's payment rails. This is not a theoretical benefit — it is a practical architecture decision that becomes affordable at unikernel scale.

5.3 Data Localisation Enforcement

A unikernel image for a payment processing service contains the application binary, a network stack, and a TLS library. It does not contain curl, wget, scp, netcat, or any general-purpose network tooling. Data exfiltration requires network tools that simply do not exist in the image. This is enforcement by architecture, not by policy.

5.4 Audit Simplification

Each deployed unikernel image is a single file with a cryptographic hash. An auditor can verify that the image running in production matches the image produced by the CI/CD pipeline by comparing hashes. There is no drift — the image cannot be modified at runtime. This dramatically simplifies audit evidence collection for:

  • SBP (Pakistan): Payment Systems and Electronic Fund Transfers Act compliance
  • Bangladesh Bank: ICT Security Guidelines for Banks and NBFIs
  • NRB (Nepal): IT Guidelines for Licensed Institutions
  • CBI (Iraq): Electronic Payment Systems Regulation
  • CBE (Egypt): E-Payment and E-Banking Regulations
  • CBUAE (UAE): CBUAE Consumer Protection Standards and Stored Value Facilities Regulation
  • SAMA (KSA): Payments and Fintech Regulatory Framework

5.5 Compliance Framework Impact

Framework Applicable Control Reduction Mechanism
NIST 800-53 ~30–40% Eliminated OS controls (AC, CM, SI families)
ISO 27001 ~20–30% Reduced Annex A controls for system management
PCI-DSS ~25–35% Architecturally satisfied requirements (2, 5, 6.6, 8, 10)

6. Application to Payment Gateway Architecture

6.1 Candidate Workloads

Not every workload is suited to unikernels. The following Simpaisa services are strong candidates based on their stateless, single-process, short-lived characteristics:

API Gateway Endpoints (KrakenD, Caddy). API gateways are stateless request routers. As unikernels, they benefit from sub-millisecond cold starts, enabling true scale-to-zero during low-traffic periods (overnight in specific markets) with instant restart on incoming requests.

Settlement Engine. Settlement calculations are isolated, deterministic, and auditable. A settlement unikernel is an immutable function: given inputs (transaction batches), it produces outputs (settlement files). The immutability guarantees reproducibility — a critical property for financial reconciliation.

Webhook Delivery. Webhook processors are ephemeral by nature: receive event, deliver HTTP callback, terminate. This is the ideal unikernel workload — short-lived, stateless, and embarrassingly parallel.

Crypto/Stablecoin Transaction Signing. Cryptographic key operations demand isolation. A unikernel containing only the signing logic and a network stack has no mechanism for key exfiltration. The private key material exists only in the single-address-space memory of a dedicated VM.

Per-Market Payment Channel Adapters. Each market's payment rails (JazzCash in Pakistan, bKash in Bangladesh, eSewa in Nepal) require dedicated integration logic. Compiling each adapter as an independent unikernel provides jurisdictional isolation, independent deployment, and per-market scaling.

6.2 Architecture Vision

                            Current (Docker/K8s)
┌─────────────────────────────────────────────────────────────┐
│                    Kubernetes Cluster                        │
│                    (Shared Linux Kernel)                     │
│                                                             │
│  ┌─────────┐ ┌──────────┐ ┌──────────┐ ┌───────────────┐  │
│  │ KrakenD │ │ Settle-  │ │ Webhook  │ │ PK Adapter    │  │
│  │ (Docker)│ │ ment     │ │ Delivery │ │ (Docker)      │  │
│  │         │ │ (Docker) │ │ (Docker) │ │               │  │
│  └─────────┘ └──────────┘ └──────────┘ └───────────────┘  │
│  ┌─────────┐ ┌──────────┐ ┌──────────┐ ┌───────────────┐  │
│  │ Crypto  │ │ BD       │ │ NP       │ │ ... 5 more    │  │
│  │ Signer  │ │ Adapter  │ │ Adapter  │ │ market        │  │
│  │ (Docker)│ │ (Docker) │ │ (Docker) │ │ adapters      │  │
│  └─────────┘ └──────────┘ └──────────┘ └───────────────┘  │
│                                                             │
│  ALL containers share one kernel — lateral movement risk    │
└─────────────────────────────────────────────────────────────┘

                          Target (Unikernels)
┌─────────────────────────────────────────────────────────────┐
│                    Hypervisor (KVM/Firecracker)              │
│                                                             │
│  ┌─────────┐ ┌──────────┐ ┌──────────┐ ┌───────────────┐  │
│  │ KrakenD │ │ Settle-  │ │ Webhook  │ │ PK Adapter    │  │
│  │ Unikrnl │ │ ment     │ │ Delivery │ │ Unikrnl       │  │
│  │  4 MB   │ │ Unikrnl  │ │ Unikrnl  │ │  3 MB         │  │
│  │ 12ms ↑  │ │  8 MB    │ │  3 MB    │ │ 12ms ↑        │  │
│  └─────────┘ └──────────┘ └──────────┘ └───────────────┘  │
│  ┌─────────┐ ┌──────────┐ ┌──────────┐ ┌───────────────┐  │
│  │ Crypto  │ │ BD       │ │ NP       │ │ ... 5 more    │  │
│  │ Signer  │ │ Adapter  │ │ Adapter  │ │ market        │  │
│  │ Unikrnl │ │ Unikrnl  │ │ Unikrnl  │ │ adapters      │  │
│  │  2 MB   │ │  3 MB    │ │  3 MB    │ │               │  │
│  └─────────┘ └──────────┘ └──────────┘ └───────────────┘  │
│                                                             │
│  Each unikernel = dedicated VM — hardware-level isolation   │
│  Total footprint: ~35 MB vs ~1.5 GB for Docker equivalent  │
└─────────────────────────────────────────────────────────────┘

7. Unikraft: The Leading Candidate

7.1 Overview

Unikraft is an open-source unikernel SDK and runtime released under the BSD licence. Originally developed at Nectar Research Group (NEC Laboratories Europe), it is now maintained by Unikraft GmbH with commercial backing. Unikraft provides a Linux-compatible ABI, meaning applications that compile for Linux can run on Unikraft with minimal or no modification.

7.2 Go Language Support

Simpaisa's primary language is Go. Unikraft supports Go applications natively, including the Go runtime's garbage collector, goroutine scheduler, and standard library networking. Existing Go microservices built during Project Phoenix can be compiled as unikernels without rewriting application logic — the change is in the build and deployment pipeline, not the application code.

7.3 Unikraft Cloud

In October 2025, Unikraft announced $6 million in funding to build Unikraft Cloud, a managed platform for deploying unikernels. The platform offers:

  • 10–50 ms cold starts with millisecond autoscaling
  • True scale-to-zero: instances terminate when idle, restart on demand
  • 10,000–100,000+ VMs per server: extreme density enables cost efficiency
  • Dockerfile compatibility: existing Dockerfile build pipelines work with minimal adaptation
  • Kubernetes integration: unikernels can be orchestrated alongside containers during migration
  • Prometheus and Grafana integration: existing observability tooling is supported

7.4 API Gateway Proof of Concept

Tyk, an open-source API gateway, has demonstrated running on Unikraft as a proof of concept [5]. The results showed sub-millisecond overhead for request routing with significantly reduced memory consumption. This is directly relevant to Simpaisa's KrakenD deployment — if Tyk runs on Unikraft, KrakenD (which is also a Go application) is a strong candidate.

7.5 Developer Experience

The critical question for adoption is developer friction. Unikraft addresses this through:

  • kraft CLI: Build, run, and deploy unikernels from the command line
  • Dockerfile support: kraft build -t myapp . using existing Dockerfiles
  • Local development: Run unikernels locally via QEMU for testing
  • CI/CD integration: Standard build artefact (VM image) fits existing pipelines

For a team already building Go microservices with Docker, the migration path is a build pipeline change, not an application rewrite.

8. Challenges and Risks

8.1 Debugging and Observability

Unikernels have no shell. You cannot SSH into a running unikernel, attach a debugger, or run diagnostic commands. Debugging must happen through:

  • Structured logging: Application-level logs emitted to external collectors
  • Metrics export: Prometheus-compatible metrics endpoints
  • Distributed tracing: OpenTelemetry instrumentation in application code
  • Core dumps: Post-mortem analysis of failed images

This is a significant operational shift. Engineers accustomed to kubectl exec into a pod will need to adapt to purely observability-driven debugging. The organisation must invest in logging and tracing infrastructure before migrating workloads.

8.2 Ecosystem Maturity

The unikernel ecosystem is orders of magnitude smaller than the container ecosystem. Fewer Stack Overflow answers, fewer blog posts, fewer community-maintained libraries. When problems arise, the team may need to engage directly with Unikraft maintainers or solve issues from first principles.

8.3 Operational Tooling

Monitoring, alerting, and incident response playbooks assume SSH access, shell commands, and runtime inspection. These assumptions must be replaced with:

  • Image-based rollback (deploy previous image hash)
  • Canary deployment patterns (blue/green at the VM level)
  • Automated health checks with restart policies

8.4 Team Capability

Simpaisa's engineering team is currently building foundational Go microservices skills through Project Phoenix. Adding unikernel expertise simultaneously would risk cognitive overload. The migration strategy must sequence appropriately — Go microservices first, unikernel deployment second.

8.5 Multi-Process Limitations

Unikernels run a single process. Workloads that require background workers, sidecar proxies, or multi-process architectures (e.g., a web server with a background job processor) must be decomposed into separate unikernels. This is architecturally sound but requires disciplined service decomposition.

8.6 Memory-Constrained Degradation

Below approximately 128 MB of allocated memory, Go's garbage collector competes with the unikernel's memory allocator, causing throughput degradation [1]. Memory allocation must be tuned per workload — the 2–10 MB image size does not mean the instance should run with 2–10 MB of RAM.

8.7 Vendor Risk

Unikraft GmbH has raised $6 million — modest by infrastructure startup standards. If the company fails, the open-source BSD-licenced code remains available, but commercial support, managed cloud services, and continued development velocity would be at risk. This is mitigated by the open-source licence and the existence of alternative implementations (NanoVMs/Nanos for Go workloads).

9. Migration Strategy for Simpaisa

9.1 Prerequisites

The Go microservices migration (Project Phoenix) must reach stability before unikernel evaluation begins. Attempting to change both the application architecture and the deployment model simultaneously introduces compounding risk. The team must be comfortable building, deploying, and operating Go microservices in containers before abstracting the container layer away.

9.2 Phased Approach

Phase 1: Evaluate (Q3 2026)

  • Compile Simpaisa's Go service template as a Unikraft unikernel
  • Run in development environment alongside Docker deployment
  • Measure boot time, memory footprint, and throughput against container baseline
  • Assess developer experience: build time, debugging workflow, CI/CD integration
  • Document findings in an internal technical assessment
  • Success criteria: Go service template boots and serves HTTP traffic as a unikernel; engineering team can build and deploy without external support

Phase 2: Pilot (Q4 2026)

  • Deploy the webhook delivery service as a unikernel in the staging environment
  • Webhook delivery is ideal: stateless, ephemeral, low-risk, high-volume
  • Run in parallel with Docker deployment for comparison
  • Measure operational characteristics: reliability, observability, incident response
  • Success criteria: Webhook delivery unikernel matches or exceeds container reliability over 30 days; no incidents requiring shell access for resolution

Phase 3: Introduce (H1 2027)

  • Move stateless API endpoints to unikernel deployment in production
  • Begin with low-traffic markets (Nepal) before high-volume markets
  • Maintain container fallback for rapid rollback
  • Success criteria: Production unikernel deployment serving real transaction traffic with equivalent or better reliability, performance, and security posture

Phase 4: Expand (H2 2027+)

  • Settlement engine: isolated, immutable, auditable computation
  • Crypto/stablecoin transaction signing: maximum isolation for key material
  • Per-market payment channel adapters: jurisdictional isolation
  • Success criteria: Majority of stateless workloads running as unikernels; measurable reduction in PCI-DSS audit scope

9.3 Governance

Each phase transition requires explicit approval from the CDO and CTO based on documented success criteria. No phase advances automatically. The pilot can be terminated at any point with a rollback to Docker deployment at zero application-level cost — the application code does not change between deployment models.

10. Conclusion

Unikernels are not ready to replace all containers today. The ecosystem is young, the tooling is maturing, and the operational model requires significant adaptation. For general-purpose workloads with complex runtime requirements, containers remain the pragmatic choice.

However, for specific payment infrastructure workloads — stateless API endpoints, cryptographic operations, webhook delivery, and per-market adapters — the security and performance benefits are compelling. The numbers are concrete: 13–18x faster cold starts, 10–100x smaller memory footprint, and 30–40% fewer compliance controls. For a payment gateway processing over $1 billion across eight regulated jurisdictions, these are not marginal improvements — they are architectural advantages that compound across every market, every audit, and every security assessment.

The regulatory compliance benefits deserve particular emphasis. Simpaisa's current 4/10 security posture must improve. Compensating controls (WAFs, runtime security agents, access management policies) add layers of complexity and cost. Unikernels eliminate entire categories of controls by eliminating the attack vectors those controls exist to mitigate. This is security by architecture, not security by accumulation.

The timing is favourable. Unikraft's Go support aligns with Project Phoenix. Dockerfile compatibility means existing build pipelines adapt rather than replace. The managed cloud offering reduces operational burden during the learning curve. And the BSD licence ensures no vendor lock-in.

Recommendation: Assign EVALUATE status on the Simpaisa Technology Radar. Begin Phase 1 evaluation in Q3 2026, contingent on Project Phoenix stability. Target a webhook delivery pilot in Q4 2026. If the pilot succeeds, introduce unikernels to production stateless workloads in 2027. This is a measured, evidence-driven approach to a technology with genuine potential to improve Simpaisa's security posture, regulatory compliance efficiency, and infrastructure economics across all eight markets.

11. References

[1] Kurek, M., Piórkowski, A., & Liszka, K. J. (2025). "Benchmarking Unikernels: A Comparative Analysis of Unikernel Frameworks for Lightweight Virtualisation." arXiv preprint, arXiv:2509.07891. Available at: https://arxiv.org/abs/2509.07891

[2] Talbot, J., Sherr, M., & Jansen, A. (2024). "A Security Survey of Unikernels." arXiv preprint, arXiv:2406.01872. Available at: https://arxiv.org/pdf/2406.01872

[3] Unikraft Project. (2025). Unikraft Documentation: Building and Running Unikernels. Available at: https://unikraft.org/docs

[4] NanoVMs. (2025). Nanos Unikernel Documentation. Available at: https://nanos.org/documentation

[5] Tyk Technologies. (2025). "Running Tyk API Gateway on Unikraft." Tyk Blog. Available at: https://tyk.io/blog

[6] National Institute of Standards and Technology. (2020). NIST SP 800-53 Rev. 5: Security and Privacy Controls for Information Systems and Organizations. Available at: https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final

[7] Madhavapeddy, A., & Scott, D. J. (2013). "Unikernels: Rise of the Virtual Library Operating System." ACM Queue, 11(11). doi:10.1145/2557963.2566628

[8] Oliveira, B. C., Kuenzer, S., & Huici, F. (2024). "Unikraft: Fast, Specialised Unikernels the Easy Way." IEEE European Conference on Computer Systems (EuroSys). doi:10.1145/3627703.3629573

[9] PCI Security Standards Council. (2024). PCI DSS v4.0.1. Available at: https://www.pcisecuritystandards.org/document_library/

[10] Unikraft GmbH. (2025). "Unikraft Raises $6M to Build the Cloud of Tomorrow." Unikraft Blog. Available at: https://unikraft.org/blog

This document is a living research assessment. It will be updated as the technology matures and as Simpaisa's evaluation progresses through the defined phases.