Multi-Party Authorization — QuantumHandshake™

01The control you already trust

Every serious system already requires more than one party.

It has names your risk and audit teams live by — four-eyes, dual control, maker-checker. The rule never changes: no single person, key, or credential can approve a critical action alone.

1

Wire transfer — maker & checker

A high-value payment is entered by one officer and released by another — often with a third approver above a threshold. One set of hands never completes it.

2

The vault — two keys, two people

The safe needs two physical keys turned together. Neither keyholder can open it alone — by design, not by policy.

3

Key ceremony — M-of-N on the HSM

Hardware security modules already split trust: it takes, say, 3 of 5 custodians to unseal a root key. Quorum is a control banks operate today.

4

Payments network — approval chains

Large transfers pass through segregated duties and multi-party sign-off before they settle. Separation of duties is regulatory muscle memory.

5

Governance — board quorum

A resolution isn’t valid until enough directors are present and agree. The decision belongs to the quorum, never to one chair.

02The gap

Then everyone signs in with a single credential.

The Blind Spot

Then a customer or employee logs in with one username, one password, one session token — and that single credential talks straight to the core. If it’s phished or a session is hijacked, the attacker acts alone. Digital access is the one place four-eyes was never applied.

03How QuantumHandshake enforces it

A quorum in front of access — and the core refuses to act without proof of it.

Every login becomes a proposal an independent set of validators must sign. The application will not release sensitive data or complete a sensitive action until it can verify the quorum agreed. No quorum, no access.

Handshake

Session bound to the identity.

Quorum

Independent validators co-sign.

Access

Granted only on proof of quorum.

1

Login — BCQP™ post-quantum handshake

The session is opened and cryptographically bound to that identity. A stolen token alone cannot be replayed.

2

Proposal — a single thing to vote on

The login or sensitive action becomes a signed, well-formed proposal submitted for finality.

3

Quorum signs — M-of-N independent validators

Each validator holds its own key on its own machine and independently co-signs. A configurable threshold must agree.

4

Core verifies — proof before access

Before releasing data, the application checks the finality record: status finalized, proposal matched, and signed count ≥ quorum required. The validators never reach into the core — the core demands proof they agreed.

# the gate, in plain terms — the record must prove:
status == FINALIZED  AND  proposal matches this session  AND  signed_count ≥ quorum_required
# anything less → the request is refused.

Quorum met → proceed

The action is authorized and completes. The approval is written as a tamper-evident, quorum-signed record — provable later, alterable by no one.

Quorum not met → fail-closed

Access is denied, not degraded. The system would rather pause than approve something it can’t fully witness. It never trades safety for convenience.

Go deeper

Validator roles, quorum thresholds, and finality records: see the NSQC™ Consensus page.

04Scaling the quorum

The committee size is policy, not architecture.

10→1000s

The committee size is policy, not architecture. A reference deployment may run ten validators; a large bank might run a hundred, a consortium a thousand — with the quorum threshold (M-of-N) set to the institution’s own risk appetite. More independent signers means more resilience and a higher bar to forge. The security comes from distributing the keys, and you decide how widely.

05Deployment models

Run the quorum however your trust boundary is drawn.

The same mechanism deploys across trust topologies — you choose who holds the keys and where the witnesses live.

Single institution

Private

The bank runs every validator itself, across separate systems and teams — enforcing internal separation of duties no single admin can bypass.

Multiple institutions

Consortium

Members co-sign each other’s critical events. No one member — and no one member’s compromise — can forge a finalized approval.

Internal + external

Hybrid

Some witnesses inside the bank, some held by partners, auditors, or a regulator — independent eyes on the events that matter most.

Open verification

Public–permissioned

Anyone may verify the sealed record; only vetted parties may sign. Public-grade transparency with permissioned control.

06Side by side

Conventional access vs. quorum authorization.

	Conventional login	QuantumHandshake
Who authorizes	A single path — one token / session	An independent quorum — M-of-N signers
A stolen session	Often equals full access	Useless — bound to the identity and gated on quorum
The record	Server logs an admin can edit	Tamper-evident, quorum-signed, provable
Under partial failure	Tends to fail open / degrade	Fails closed — no quorum, no access
Cryptography	Classical — harvestable today, breakable later	Post-quantum (ML-KEM / ML-DSA / SLH-DSA)
Relationship to OIDC / FAPI / mTLS	—	Sits alongside them, adding quorum + PQC

07What we say — and what we don’t say yet

Honest scope.

Honest scope. Figures such as “7-of-10” describe a reference deployment; committee size and quorum threshold are configurable per institution. Post-quantum algorithm profiles (ML-KEM / ML-DSA / SLH-DSA) are applied where implemented. QuantumHandshake complements existing identity standards (OIDC, FAPI, mTLS) rather than replacing them. Formal certification (e.g. FIPS 140-3 / CMVP) is a roadmap item and is not claimed here. QuantumHandshake™ and BCQP™ are marks of Quantum Handshake Ltd.

The four-eyes principle, enforced by cryptography.