YinkoShield
Brief

architecture

The architectural case for execution evidence.

EEI is a layered architecture. Below: the primitives, the property they implement, and the engineering investment that makes the substrate run at scale.

the substrate at a glance

Five layers. Two are ours. Seven primitives between them.

The full stack is five layers — hardware at the floor, policy at the top. EEI is layers 02 and 03: the Trusted Runtime Primitive and the Execution Evidence Layer. The other three are adjacent — informational here, owned elsewhere. Click any primitive to expand it in place; multiple in the same layer can be open at once. Or hit expand all to read everything inline. Layer numbering follows YEI-001.

Layer 05 policy / decision systems · out of EEI scope

Issuer · Network · Processor · Edge · Dispute platform

Consume evidence, own all enforcement. EEI does not decide.

Layer 04 platform attestation · complementary, not replaced

Android Play Integrity · iOS DeviceCheck · TPM · StrongBox attestation

Attestation establishes the checkpoint. Runtime coherence establishes what happened between checkpoints.

Layer 03 · core execution evidence layer · what travels and how it is verified
·03

Evidence Token

[ evidence token · jws compact · es256 ] ·01 header alg · kid · typ . ·02 payload claims · signals · hash chain . ·03 signature ES256 [ two profiles — same cryptographic semantics ] Minimal Profile ~200 bytes device-id · attestation · intent hash fits inside ISO 8583 DE 48 Standard Profile ~300 bytes + signal class · network identity HTTP / OTel · forensic richness
JWS compact, ES256, inline with each request. Two byte-budget profiles — same verifier code path.

The Evidence Token is a JWS compact structure, signed ES256, carried inline with each request. Two profiles: Minimal (~200 bytes, fits ISO 8583 DE 48) and Standard (~300 bytes, richer inline context).

Same cryptographic semantics, same verifier code path, different byte budgets. The channel is an integration decision; the token is a trust decision.

Read the deep article →
·04

Local Evidence Ledger & Commander

[ local evidence ledger · commander channel ] device · on-device storage ·01 sign hash: 0xa3… ·02 sign prev: 0xa3… ·03 … append-only commander module decrypts signed-and-encrypted commands replies with signed forensic responses no infrastructure in the loop · pgp-analogous device key · operator key · sovereign operator encrypted command signed response forensic, attributable device-resident, hash-linked, sovereign — no third-party in the forensic path
The ledger is on the device. The Commander gives operators a signed channel to it without putting any third party in the path.

Every signed event is appended to a hash-linked, device-resident ledger. Tampering at any link breaks the chain visibly. The ledger does not leave the device.

The Commander module is the operator-controlled forensic channel into that ledger — encrypted commands in, signed responses out. PGP-analogous: the operator key authors, the device key replies, no third party in the loop.

Read the deep article →
·05

Zero Trust Bootstrap Protocol

[ zero trust bootstrap protocol · first init ] device ·01 generate keypair at first initialisation, in-TEE private stays in TEE public leaves once ·02 register public key over operator-controlled onboarding channel YinkoShield is not in this path public key only operator backend stores registered public key indexed by device id verifies any future evidence independently — sovereign private key never leaves · public key registered once · no key-escrow
Private key stays in the device's secure element. The operator registers the public key once and verifies all future evidence with it.

At first initialisation, the device generates a keypair inside its trusted execution environment. The private key never leaves. The public key is registered to the operator backend over an operator-controlled onboarding channel — a path that does not include us.

From that moment, the operator owns the verification material. Sovereign verification is a property the bootstrap establishes.

Read the deep article →
·06

Sovereign Verification

[ sovereign verification · no third-party in path ] device signs evidence evidence token jws · es256 operator verifier python · javascript · go · java 8-step verification pipeline uses registered public key no network call to YinkoShield PKI public keys YinkoShield · not in this path
Any party with the registered public key verifies independently. No YinkoShield endpoint, no licence check, no runtime dependency.

Any party with the registered public key verifies the evidence independently — exactly as it would for any standard PKI signature. There is no YinkoShield endpoint in the verification path, no licence check, no runtime dependency.

Reference verifiers exist in Python, JavaScript, Go, and Java. The eight-step pipeline — parse, resolve key, verify signature, validate claims, freshness, replay, sequence regression, trust level — is the same in every language.

Read the deep article →
Layer 02 · core trusted runtime primitive · where signing happens
·02

Trusted Runtime Primitive

[ trusted runtime primitive · wraps · monitors · signs ] application code your banking app · POS firmware · kiosk shell TRP — wrapping & coherence ·01 framework library Java framework / Foundation / UIKit ·02 libc open · read · write · mmap · exec ·03 syscall boundary user-space ↔ kernel OS · device hardware TEE · Secure Enclave · HSM · Strongbox continuous coherence check ·a observe every wrapped call, in order ·b measure runtime state · environment · trust basis ·c check coherence does this sequence match a trusted runtime? ·d sign JWS · ES256 · hardware-bound key loop · every event SIGNED EVIDENCE TOKEN to operator · with the transaction runtime coherence + decoupled policy no single check to disable · same evidence read at multiple control points runs on: Android · iOS · POS · SoftPOS · SST · ~13,000 hardware configurations · including 1 GB RAM, 2G/3G estates
The TRP wraps every call that crosses out of the application — at the framework, libc, and syscall layers — and runs a continuous coherence check. Each event is signed and emitted with the transaction. Same module across mobile, POS, and SST.

One platform-portable primitive runs in your application's user-land — Android, iOS, POS, SoftPOS, SST. It observes execution at the syscall level, measures the runtime, declares its trust basis, and signs evidence with a hardware-bound key.

The TRP is the substrate every other piece sits on. It is what makes a signed event a witness, not a claim.

Read the deep article →
·01

Runtime Coherence

[ runtime coherence · the interval between action and receipt ] today — backend infers what happened from the receipt user taps Pay action begins on device network receipt backend acknowledges silent gap · no infrastructure observes this with execution evidence — each step in the interval is signed, hash-linked, and reconstructable user taps Pay action begins ·1 runtime measured ·2 biometric ok ·3 payload hashed ·4 request signed network receipt + signed evidence four hash-linked events · one signed record · the interval is reconstructable sequence · ordering · device state · trust basis · all preserved
Today, the interval between a user action and the network's acknowledgement is a silent gap. Runtime coherence makes that gap a signed sequence — measurable, ordered, and reconstructable.

Backend systems prove receipt. Credentials prove identity at the moment of use. Between the two sits the device-side execution path — historically silent, the partition that adversaries operate inside.

Runtime coherence is the property the TRP delivers. A signed, hash-linked sequence of execution events, ordered, attributable, and reconstructible. The deep article walks through the architectural case in full.

Read the deep article →
·07

Threat Model

[ threat model · in scope · out of scope ] in scope → surfaced as evidence application-layer compromise overlay, accessibility abuse, hooking user-space manipulation repackaging, runtime injection, debug attach execution interference triggered, dormant, injection adversaries fabrication / replay unsigned events, mismatched hash chain out of scope · declared kernel-level compromise treated as platform-trust failure supply-chain compromise build-pipeline trust is the operator's domain backend infiltration covered by your own infrastructure security social-engineering of the user policy domain — evidence still records what executed
The model is deliberately narrow. We don't claim what we cannot defend — and what is out of scope is declared, not silently ignored.

The TRP defends against application-layer compromise, user-space manipulation, runtime injection, and the fabrication or replay of events. Those threats surface as evidence — not as silent failures.

What the TRP does not defend against — kernel-level compromise, supply-chain compromise, backend infiltration — is declared, not silently ignored. A narrow, honest model is the only one that survives a CISO's review.

Read the deep article →
Layer 01 device hardware · out of YinkoShield scope

TEE · Secure Enclave · HSM · Strongbox · TPM

The hardware floor we depend on — bounds the trust we declare.

why this isn't already in your stack

The gap is engineering cost, not awareness.

Execution evidence requires operating infrastructure that doesn't sit inside standard payment-engineering organisations. Three capabilities have to exist; we have spent thirteen years building them.

  • ·01

    Fragmented device populations

    Around 13,000 distinct Android hardware configurations today. The hardware abstraction layer was extracted from running it; the spec is the artefact.

  • ·02

    Chaos engineering for partition

    Network simulation, memory pressure, execution interruption. Ledger coherence under partition is not testable in standard CI — purpose-built infrastructure we maintain in house.

  • ·03

    Adversarial runtime testing

    Triggered, dormant, and injection-based attacks against the evidence layer. We validate detection of execution interference, not static presence of a threat.

This is what it costs to run execution evidence in production. This is why it doesn't already exist in your stack.

specification

YEI-001 is shared with regulators and qualifying partners under NDA.

The full specification, conformance checklists, threat model, and the agentic-payment extension are available on request. Reference verifiers in Python, JavaScript, Go, and Java accompany.

Request access to the specification