Cryptography by purpose
The same 37 topics as the technical slide deck, organized by purpose, construction, proof actors and limitations. Equations explain relations rather than define wire encodings. Current, application-specific, optional, comparison and research paths are separate.
This is the technical deck’s source survey dated 2026-09-12, not a new cryptographic experiment. Implementation links identify baseline revisions; the source JSON flags snapshots containing working changes. The shared optimistic protocol is documented separately. Optimistic · Source JSON / SHA-256
A1 · Ristretto255 and Pedersen commitments
Current composition; scope below
C(v;r)=vG+rH,\qquad C(v_1;r_1)+C(v_2;r_2)=C(v_1+v_2;r_1+r_2)- Purpose
- Bind hidden prices, quantities and balances to subsequent proofs.
- Construction
- Use fixed value and blinding generators in a prime-order group; addition expresses conservation.
- Who proves and verifies
- Participants or MPC nodes construct commitments; zkPI and the VM verify the same points.
- Assumptions and limits
- Hiding and binding are separate properties. A commitment is not decryptable encryption and does not prove a range.
A2 · Schnorr knowledge and zero-value proofs
Current composition; scope below
z_vG+z_rH=T+cC,\qquad D=rH\;\Longrightarrow\;z_rH=T+cD- Purpose
- Prove knowledge of an opening or that a conservation residual has value zero.
- Construction
- Derive a challenge from the public statement and check the corresponding group equations.
- Who proves and verifies
- An owner proves alone or nodes interpolate responses for the public verifier.
- Assumptions and limits
- Knowledge of some opening does not imply zero. The residual needs a dedicated zero-opening relation and domain.
sigma · threshold_sigma · Merlin transcripts
A3 · Product, equality and cross-generator proofs
Current composition; scope below
C_c=bC_a+(r_c-br_a)H,\qquad C_1=vG_1+r_1H,\ C_2=vG_2+r_2H- Purpose
- Bind quantity times price to payment and the same amount across representations.
- Construction
- Share the relevant witness response between the product equations or two generator relations.
- Who proves and verifies
- zkfmi-zk proof constructors feed zkPI and note settlement verification.
- Assumptions and limits
- Two independent proofs do not establish witness equality. Fixed-coefficient aggregation must not allow errors to cancel.
sigma · settlement · Merlin transcripts
A4 · Bulletproofs and nonnegative amounts
Current composition; scope below
C=vG+rH,\quad 0\le v<2^\ell,\qquad \ell\in\{8,16,32,64\}- Purpose
- Exclude negative values and modular wraparound in amounts and residuals.
- Construction
- Aggregate bit constraints into an inner-product argument for supported widths.
- Who proves and verifies
- The owner uses RangeProof; the VM fixes commitments, range width and transcript.
- Assumptions and limits
- Range alone proves neither ownership, asset identity nor best price. The collaborative format is a separate implementation.
range · price_limit · notes · Bulletproofs, 2017/1066
A5 · Bit decomposition and collaborative ranges
Current composition; scope below
v=\sum_{j=0}^{\ell-1}2^jb_j,\qquad b_j(b_j-1)=0,\qquad C-\sum_j2^jC_j=\rho H- Purpose
- Prove ranges when no node owns the complete value.
- Construction
- Commit to bits, prove Booleanity and link their weighted sum to the original commitment.
- Who proves and verifies
- Nodes jointly generate the bit and linkage relations; public verifiers check them.
- Assumptions and limits
- This is a distinct proof format from the single-prover Bulletproofs route, with different cost and assumptions.
bitrange · threshold_range · threshold_gadgets
B1 · One-time destinations and recipient disclosure
Current composition; scope below
R=eG,\quad h=H_s(eV)=H_s(vR),\quad P=B+hG- Purpose
- Deliver a note without publishing a reusable recipient address.
- Construction
- Derive a shared scalar from ephemeral Diffie–Hellman and offset the recipient key.
- Who proves and verifies
- Senders construct outputs; recipients scan and derive their one-time spending key.
- Assumptions and limits
- Scanning and spending authority differ. Metadata and later spends can still create links.
B2 · Triptych and anonymous spends
Current composition; scope below
\exists i,x,\rho:\quad P_i=xG,\quad C_i-C_{\rm pseudo}=\rho H,\quad I=x^{-1}U- Purpose
- Prove ownership of an input in a set and detect repeated spending.
- Construction
- Bind ownership and amount to the same hidden index, with a linkability tag.
- Who proves and verifies
- The note proof adapter uses a pinned upstream Triptych core; the VM checks its bound statement.
- Assumptions and limits
- Anonymity depends on the candidate set and metadata. The experimental reference does not replace an independent audit.
note_membership · notes · Triptych, 2020/018
B3 · OR-DLEQ and Groth–Kohlweiss membership
Application-specific / optional
\bigvee_i\{X_i=xG\ \land\ N=xG_{\rm scope}\},\qquad \sum_i c_i=c- Purpose
- Prove selected membership and scope-linked knowledge in their particular application paths.
- Construction
- Compose discrete-log equality relations or a one-of-many membership argument.
- Who proves and verifies
- Application proof constructors and their corresponding public verifiers share the statement.
- Assumptions and limits
- These uses are separate from the current Triptych note-spend core. Names in the repository do not imply universal deployment.
or_dleq · oneofmany · kyb · Groth--Kohlweiss, 2014/764
B4 · Confidential assets and substitution resistance
Application-specific / optional
T=A_i+\gamma H,\qquad C_{\rm asset}=\alpha_iG+\rho H- Purpose
- Hide an asset selection while binding the correct asset and monetary relations.
- Construction
- Link asset tags, committed identifiers and amount representations across the proof.
- Who proves and verifies
- The asset-confidential note variant constructs and verifies these additional relations.
- Assumptions and limits
- Asset confidentiality belongs to a specific version. Public-asset routes do not acquire it automatically.
confidential_assets · confidential_notes · asset_link
C1 · Shamir sharing and Lagrange interpolation
Current composition; scope below
f(X)=s+a_1X+\cdots+a_tX^t,\quad s_i=f(i),\quad s=\sum_{i\in Q}\lambda_i s_i- Purpose
- Distribute a witness without giving each participant its complete value.
- Construction
- Evaluate a random polynomial and interpolate authorized subsets.
- Who proves and verifies
- The configured seven-party MPC and proof participants hold their own shares.
- Assumptions and limits
- A reconstruction threshold alone is not malicious security or availability. Collusion and protocol assumptions still apply.
shamir · oclob_readme · MP-SPDZ documentation
C2 · VSS and inconsistent-share detection
Current composition; scope below
A_j=a_jG+b_jH,\qquad s_iG+r_iH=\sum_{j=0}^{t}i^jA_j- Purpose
- Detect contributions inconsistent with the committed sharing polynomial.
- Construction
- Check a received share against coefficient commitments.
- Who proves and verifies
- Recipients validate inputs and proof contributions before using them.
- Assumptions and limits
- Detection is not automatic recovery or guaranteed completion; the remaining participants must satisfy protocol conditions.
threshold_gadgets · shamir · oclob_edge
C3 · MP-SPDZ and malicious participants
Current composition; scope below
[a]+[b]=[a+b],\qquad [a]\,[b]\ \xrightarrow{\text{対話・次数削減}}\ [ab]- Purpose
- Compute market relations over secret inputs.
- Construction
- Use the configured malicious Shamir engine, including interactive multiplication and degree reduction.
- Who proves and verifies
- Seven native processes run the pinned MP-SPDZ program.
- Assumptions and limits
- A single-host run does not demonstrate seven independent operators, WAN performance or resistance to arbitrary denial of service.
oclob_readme · proof_party · MP-SPDZ documentation
C4 · Collaborative public proofs
Current composition; scope below
z_i=k_i+c w_i,\quad z=\sum_i\lambda_i z_i,\quad T=\sum_i\lambda_i T_i- Purpose
- Produce a publicly verifiable relation without collecting the complete witness.
- Construction
- Combine witness-dependent responses with consistent challenges and interpolation coefficients.
- Who proves and verifies
- Nodes contribute shares and the ordinary public verifier checks the assembled Sigma relation.
- Assumptions and limits
- Correct aggregation must bind every contribution and the execution context; a collection of signatures is not this proof.
threshold_sigma · threshold_gadgets · threshold_range · threshold_quote
C5 · Quote, limit and fill relations
Current composition; scope below
\text{notional}=q p,\qquad\text{limit}-p\ge0,\qquad k_i-k_w\ge0- Purpose
- Express the exact application claim: notional, limit and eligible price comparison.
- Construction
- Bind quantity, price and ordered comparison values into separate relations.
- Who proves and verifies
- Application-specific QOMM and OCLOB adapters generate and verify their supported statements.
- Assumptions and limits
- A financial relation is not a proof of every market rule. The OCLOB transition attestation boundary is stated separately.
quote · threshold_quote · price_limit · settlement
D1 · Hybrid Ed25519 and ML-DSA-65 signatures
Current composition; scope below
\mathrm{Accept}=\mathrm{Verify}_{\rm Ed25519}(m,\sigma_E)\ \land\ \mathrm{Verify}_{\rm MLDSA65}(m,\sigma_P)- Purpose
- Authenticate an application message under both signature schemes.
- Construction
- Accept only when both verifications succeed for the bound suite and message.
- Who proves and verifies
- Application signers produce the hybrid encoding; recipients verify both components.
- Assumptions and limits
- Authentication does not make the curve-based monetary proof post-quantum. Neither half is an optional fallback.
signature · application_crypto · oclob_auth · dekyx · deccp · aethel_provider · RFC 8032 · FIPS 204
D2 · FROST threshold Schnorr signatures
Current composition; scope below
R=\sum_i(D_i+\rho_iE_i),\quad z_i=d_i+\rho_ie_i+c\lambda_i s_i,\quad zG=R+cY- Purpose
- Authorize a committee instruction without reconstructing its signing secret.
- Construction
- Bind nonce commitments, signing shares, participant set and message.
- Who proves and verifies
- The configured committee signs; the verifier checks the aggregate Schnorr signature.
- Assumptions and limits
- Nonce discipline, participant agreement and the chosen curve assumptions remain essential. This is not ML-DSA threshold signing.
zkpi · frost_cluster · RFC 9591
D3 · Ordering, PQ approvals and settlement quorum
Current composition; scope below
\text{順序認証}:5/7,\qquad\text{決済FROST}:3/7,\qquad\text{PQC承認}:\#\mathrm{valid}\ge q- Purpose
- Keep different authorization purposes explicit.
- Construction
- Ordering uses 5/7; settlement FROST uses 3/7; PQ approval checks the configured valid-signature count.
- Who proves and verifies
- Each application boundary checks its own committee and threshold.
- Assumptions and limits
- Equal node names or similar counts do not make these protocols interchangeable.
oclob_ordering · quorum · contract
D4 · DeKYX signed attributes and selective disclosure
Current composition; scope below
\mathrm{root}=\mathrm{Merkle}(H(q_1),\ldots,H(q_n)),\quad \mathrm{VerifyPath}(q_i,\pi_i,\mathrm{root})=1- Purpose
- Present authorized attributes without revealing the complete credential contents.
- Construction
- Authenticate a Merkle root and verify selected attribute paths.
- Who proves and verifies
- Issuers sign credentials; holders present; eligibility verifiers check issuer, scope and disclosed claims.
- Assumptions and limits
- Issuer trust and revocation remain application conditions. BBS+ and CL references are not the implemented credential format.
D5 · DeKYX holder knowledge and scope nullifiers
Current composition; scope below
C=xG+rH,\quad N=xG_s,\quad z_xG+z_rH=A+cC,\quad z_xG_s=B+cN- Purpose
- Bind a presentation to the holder and detect prohibited reuse within a scope.
- Construction
- Use linked knowledge relations and a scope-specific nullifier.
- Who proves and verifies
- The holder produces the presentation; the admission verifier checks the same witness and context.
- Assumptions and limits
- Scope choice controls linkability. A nullifier is not a universal identity or an assertion of every eligibility condition.
E1 · Hybrid key delivery and HKDF
Current composition; scope below
K=\mathrm{HKDF\!\!-SHA256}(ss_X\Vert ss_K\Vert ct_X\Vert ct_K\Vert\mathrm{suite})- Purpose
- Derive a delivery key from classical and PQ shared secrets.
- Construction
- Combine X25519 and ML-KEM-768 secrets, ciphertexts and suite context through HKDF.
- Who proves and verifies
- Sender and intended recipient derive the same transport key.
- Assumptions and limits
- KEM success does not prove the semantic correctness of the encrypted opening; authentication and context binding are still required.
kem · backend · sealed · RFC 7748 · FIPS 203 · RFC 5869
E2 · AES-256-GCM and ChaCha20-Poly1305
Current composition; scope below
(ct,tag)=\mathrm{AEAD.Enc}(K,nonce,plaintext,AAD)- Purpose
- Protect stored keys and delivered private payloads.
- Construction
- Authenticate ciphertext together with the nonce and associated context data.
- Who proves and verifies
- The selected storage or delivery component encrypts and the recipient rejects invalid tags.
- Assumptions and limits
- Nonce reuse and wrong associated data break the intended contract. AEAD is not a zero-knowledge proof of its plaintext.
sealed · selective_disclosure · oclob_edge · key_management · SP 800-38D · RFC 8439
E3 · Orders, permits and opening delivery
Current composition; scope below
\mathrm{Enc}_{pk_i}(s_i),\qquad (v,r)=\sum_{i\in Q}\lambda_i(v_i,r_i)- Purpose
- Restrict each share or recovered opening to its intended recipient.
- Construction
- Encrypt shares to node keys and reconstruct only for an authorized output recipient.
- Who proves and verifies
- Participants distribute inputs; the designated recipient combines sufficient opening shares.
- Assumptions and limits
- Recipients can learn their authorized plaintext. This does not imply that every process in a research coordinator is input-blind.
oclob_readme · opening_envelope · selective_disclosure
E4 · TLS 1.3, mTLS and PQ certificates
Current composition; scope below
\text{TLS 1.3}\ +\ \text{X25519MLKEM768}\ +\ \text{ML-DSA-65 certificate authentication}- Purpose
- Authenticate endpoints and protect specified transport paths.
- Construction
- Use the selected TLS policy, hybrid key exchange and certificate authentication.
- Who proves and verifies
- Clients and servers enforce the configured suite and peer identity.
- Assumptions and limits
- Application signatures and monetary proofs have separate policies. A TLS configuration claim requires the actual negotiated path.
tls · key_management · contract · oclob_readme · RFC 8446 · FIPS 204
E5 · scrypt, encrypted keys and key separation
Current composition; scope below
K_{store}=\mathrm{scrypt}(password,salt),\qquad ct=\mathrm{AES256GCM}_{K_{store}}(keys)- Purpose
- Protect persisted keys and separate their operational purposes.
- Construction
- Derive a storage key from password and salt, then apply authenticated encryption.
- Who proves and verifies
- The key store loads only authenticated data under the intended password and context.
- Assumptions and limits
- Password strength, access control, backup and recovery remain necessary. Encryption at rest is not threshold custody.
key_management · key · RFC 7914 · SP 800-38D
F1 · Hashes, HMAC and Merkle commitments
Current composition; scope below
d=H(\mathrm{domain}\Vert\mathrm{version}\Vert\mathrm{lengths}\Vert\mathrm{payload}),\quad tag=\mathrm{HMAC}_{K}(context)- Purpose
- Bind structured context and authenticate application records.
- Construction
- Domain-separate canonical encodings, versions, lengths and payloads.
- Who proves and verifies
- Each producer and verifier must serialize the same statement.
- Assumptions and limits
- A digest authenticates a reference; it does not establish the referenced computation or real-world asset.
canonical · admission · dekyx · notes · RFC 5869
F2 · Fiat–Shamir, Merlin and STROBE
Current composition; scope below
c=\mathrm{Challenge}(\mathrm{domain},\mathrm{statement},T_1,\ldots,T_k)- Purpose
- Turn interactive proof relations into reproducible noninteractive challenges.
- Construction
- Absorb domains, public statements and commitments before deriving challenges.
- Who proves and verifies
- Provers and verifiers run the same transcript state machine.
- Assumptions and limits
- Omitting or reordering a field can permit cross-context reuse. Transcript labels are part of the protocol contract.
pedersen · sigma · range · Merlin transcripts
F3 · Randomness, uniqueness and batched verification
Current composition; scope below
\sum_i\alpha_i E_i=0\quad(\alpha_i:\text{検証対象に適切に拘束した係数})- Purpose
- Generate fresh randomness and verify multiple equations efficiently.
- Construction
- Bind aggregation coefficients to the intended verification targets and use proper randomness sources.
- Who proves and verifies
- Proof, signing and verification components each enforce their own uniqueness rules.
- Assumptions and limits
- Batching is not permission to cancel arbitrary invalid equations. Nonce and operation uniqueness are distinct obligations.
sigma · notes · key_management · vm_verification
F4 · Audit viewing and spending separation
Application-specific / optional
v_s=H_s(\text{view},seed_v,scope),\qquad b_s=H_s(\text{spend},seed_b,scope)- Purpose
- Allow scoped inspection without handing over spending authority.
- Construction
- Derive different scoped viewing and spending secrets.
- Who proves and verifies
- Authorized viewers inspect only their granted scope; owners retain spend control.
- Assumptions and limits
- This is a disclosure-control boundary, not a consensus proof or a guarantee against metadata inference.
G1 · Adaptor signatures and cross-ledger PvP
Application-specific / optional
Y=yG,\quad s^{\prime}=r+cx,\quad s=s^{\prime}+y,\quad y=s-s^{\prime}- Purpose
- Link two individually specified settlement legs through a condition.
- Construction
- Complete an adaptor signature with a secret that can be extracted from the completed pair.
- Who proves and verifies
- Participants enforce the agreed signing and settlement sequence.
- Assumptions and limits
- Timeouts, finality and the two ledgers' failure assumptions remain necessary; this is not arbitrary multi-ledger atomicity.
G2 · Destination-bound finality receipts
Application-specific / optional
d=H(\mathrm{source},\mathrm{destination},\mathrm{leg},R_{before},R_{after},\mathrm{sequence})- Purpose
- Bind a source result to its intended destination and leg.
- Construction
- Sign source, destination, leg, state transition and sequence together.
- Who proves and verifies
- A receipt authority issues; the destination adapter verifies the exact context.
- Assumptions and limits
- The signer and its data source remain trusted. A signed receipt is not a light-client consensus proof.
cross_domain · cross_domain_finality · deccp
G3 · Miden STARK public audit
Application-specific / optional
R^{after}_i=R^{before}_{i+1},\qquad i=0,\ldots,n-2- Purpose
- Check continuity and correspondence among supplied public records.
- Construction
- Prove the fixed eight-slot public batch relation with the selected Miden program.
- Who proves and verifies
- The prover produces a STARK; a verifier compares independently obtained expected statements.
- Assumptions and limits
- This does not reverify signatures, consensus finality, hidden balances, ranges or best price. It is an optional audit path.
H1 · Salted hash commitments and research notes
Research or comparison path
C=\mathrm{SHA512}(domain\Vert context\Vert salt_{64}\Vert opening)- Purpose
- Study a note representation without relying on discrete-log binding.
- Construction
- Domain-separate SHA-512 with a 64-byte salt and distinguish recipient spending secrets from sender-known openings.
- Who proves and verifies
- The research wallet and wire layer reuse hybrid KEM and AEAD.
- Assumptions and limits
- Hash commitments are not additively homomorphic and do not contain their own opening proof. Full note acceptance remains a separate gate.
commitment · pqc_notes · pqc_notes_doc
H2 · Spartan-style R1CS and masked sumcheck
Research or comparison path
(Az)\circ(Bz)=Cz,\qquad \sum_{x\in\{0,1\}^m}g(x)=0- Purpose
- Connect distributed witnesses to a public proof of financial relations.
- Construction
- Reduce constraints through sumcheck and bind the final evaluation to a polynomial opening with masks.
- Who proves and verifies
- Owner-local workers and MPC produce evidence for an independent public verifier.
- Assumptions and limits
- This is an adapted research implementation. BN254 scalar arithmetic does not mean pairing use or inherited security of the entire adaptation.
cocode · cocode_integration · coCode, 2026/729
H3 · Code-based PCS, Merkle and folding
Research or comparison path
\mathrm{RS}(\mathrm{message}+\mathrm{mask})\ \to\ \mathrm{MerkleRoot},\qquad F_r=(1-r)E+rO- Purpose
- Commit to and open encoded polynomial evaluations in the research proof.
- Construction
- Combine coded masked messages, Merkle commitments and challenge-based folding.
- Who proves and verifies
- The collaborative research prover and public verifier enforce the declared relation.
- Assumptions and limits
- Code parameters, hiding, query soundness and adaptation details require their own analysis; do not promote from a component result.
pcs · cocode_transcript · cocode · coCode, 2026/729
H4 · Proving ciphertext correctness
Research or comparison path
ct=\mathrm{Encapsulate\!+\!AEAD}(pk,opening;\omega),\qquad C=\mathrm{Commit}(opening)- Purpose
- Prove that delivery ciphertext and commitment encode the same opening.
- Construction
- Constrain encapsulation and authenticated encryption inside the declared circuit.
- Who proves and verifies
- Research prover and verifier bind recipient key, randomness and opening.
- Assumptions and limits
- Circuit feasibility is distinct from complete live note settlement. Delivery success alone proves no plaintext equality.
pqc_notes · sealed · pqc_status · pqc_notes_doc
H5 · VOLE-in-the-Head and SHAKE128
Research or comparison path
\mathbf q=\mathbf t+\Delta\mathbf u\qquad\text{（VOLE相関の模式式）}- Purpose
- Measure an alternative proof construction in the comparison harness.
- Construction
- Check the declared VOLE correlation and associated transcript expansion.
- Who proves and verifies
- The measurement harness generates and verifies its comparison evidence.
- Assumptions and limits
- This is a measured comparison route, not the deployed financial-note proof.
I1 · Composition and end-to-end acceptance
Current composition; scope below
\text{受理}=\text{認可}\land\text{証明関係}\land\text{現状態}\land\text{一意性}- Purpose
- Accept an authorized, correct and unique transition against current canonical state.
- Construction
- Combine authorization, proof relation, state and uniqueness as simultaneous gates.
- Who proves and verifies
- Participant, application, MPC and VM each verify their assigned boundary.
- Assumptions and limits
- Guarantees do not add automatically. Real assets, legal finality, operations and independent review remain separate acceptance questions.
contract · settlement · reservation
Names do not establish implementation
BBS+ and CL signatures are future DeKYX options. Reserved ML-DSA-44 and SLH-DSA suite identifiers are not implemented providers. QOMM uses SHA-1 for its WebSocket handshake, not financial authorization. BN254 scalar arithmetic does not imply pairing or Groth16 use.