LOCKJAW Proof, custody, refusal, constrained execution

KCS / Blockchain Integrity Suite

Chain Key Custody

Privileged key custody for blockchain control planes.

KCS binds blockchain key usage to explicit policy, lineage, backend binding, and attested authority so possession of a key is never enough to force execution.

Layer Blockchain Integrity Suite
Status Local authorization and hostile reference surface implemented.
Boundary One system, one question

What it is

KCS binds blockchain key usage to explicit policy, lineage, backend binding, and attested authority so possession of a key is never enough to force execution.

What problem it solves

Most chain control planes reduce security to key storage quality. That leaves privileged execution vulnerable to signer misuse, backend drift, and narrative authority.

What it does

  • Authorizes protected key use against verifier-attested signer state, authority, policy, and exact request material.
  • Produces signed authorization, refusal, and inconsistency receipts for protected signing attempts.
  • Refuses widened, stale, mismatched, or optimistic custody claims.

What it does not do

  • It is not a generic wallet, signer cluster, or convenience custody layer.
  • It does not trust signer backends, operator narrative, or upstream subsystem claims by default.
  • It does not make refusal proof unnecessary; NEO remains separate.

Who it is for

  • Operators protecting privileged governance, treasury, bridge, and administrative chain keys.
  • Teams that need key use itself to stay bound to attested context rather than possession.

Where it fits

KCS is the blockchain custody boundary. It can supply refusal lineage to NEO and coexist with TXG and GAC without implicit trust.

Typical deployment context

Used for privileged signers, threshold controls, backend binding, and chain control planes.