npm - xoonya - Versions diffs - 3.1.9 → 3.1.10 - Mend

xoonya 3.1.9 → 3.1.10

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (4) hide show

package/README.md CHANGED Viewed

@@ -1,843 +1,111 @@
 # xoonya
-`xoonya` is the proof and review foundation for machine actions.
+**Deterministic proof & review engine with post-quantum verification** — for receipts, handoffs,
+governance, and the native **XNYA** machine-evidence format. xoonya is the proof-side half of the
+naxytra machine stack; the runtime/payments half is [xytara](https://naxytra.com/xytara).
-> New to the code? Read [`ARCHITECTURE.md`](ARCHITECTURE.md) first. It separates
-> the compact proof engine (the ~1,600-line crypto core in `proof_sdk.js`) from
-> the large machine-readable proof catalog, so the real engine is legible fast.
+It makes machine evidence **deterministic, portable, minimal, verifiable, and replayable**, and
+verifies it with both classical and **post-quantum** signatures.
-It exists to make machine evidence:
+## Proven live on Base mainnet
-- deterministic
-- portable
-- minimal
-- verifiable
-- replayable
+Post-quantum proof verification is real and demonstrated: a paid x402 call (gasless USDC on Base)
+routes to xoonya's `/execute`, which verifies a native **XNYA** proof bundle signed with a hybrid
+**Ed25519 + ML-DSA-65 (FIPS-204)** suite and returns a `verified_native_hybrid_signature` verdict.
+Adversarially, downgrade-to-classical and the unsigned `none` algorithm are both rejected.
-This repo is the proof-side half of the final two-repo public stack. It focuses on canonical events, receipts, proof bundles, and verification. It does not own pricing, catalogs, workflow orchestration, payment rails, or settlement policy.
+> Scope: XNYA is **machine-evidence verification** — a portable, deterministic check that a proof is
+> well-formed and cryptographically signed. It is **not** an identity, custody, settlement,
+> transport-security, or chain-finality claim.
-The 10-phase public program is now complete. `xoonya` is in terminal closeout posture rather than active milestone build posture.
+## What it does
-## Public Discovery
+The public proof loop is deliberately narrow:
-The broader stack now has a canonical human front door and a canonical machine doorway:
+1. **receive** a handoff or canonical event bundle
+2. **review** it
+3. **verify** it
+4. **emit** a durable proof bundle
-- https://www.naxytra.com/agents
-- https://www.naxytra.com/v1/agent-discovery-index
-- https://www.naxytra.com/v1/agent-discovery-index/summary
-- https://www.naxytra.com/.well-known/agent.json
+xoonya owns proof, review, and continuity. It does not own pricing, catalogs, workflow
+orchestration, payment rails, or settlement — those live in [xytara](https://naxytra.com/xytara).
-Use the human page when you want the shortest adoption landing page, and use the machine endpoints when a registry, crawler, or agent needs a stable public discovery surface.
-The shared control-plane contract documents are:
-- [OPERATIONAL_RECEIPT_CONTRACT.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/docs/architecture/OPERATIONAL_RECEIPT_CONTRACT.md)
-- [MACHINE_IDENTITY_REGISTRY_CONTRACT.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/docs/architecture/MACHINE_IDENTITY_REGISTRY_CONTRACT.md)
-- [CRYPTO_AGILITY_MATRIX.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/docs/architecture/CRYPTO_AGILITY_MATRIX.md)
-- [AUTHORITY_BINDING_LIFECYCLE_CONTRACT.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/docs/architecture/AUTHORITY_BINDING_LIFECYCLE_CONTRACT.md)
-- [PUBLIC_SURFACE_POLICY_CONTRACT.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/docs/architecture/PUBLIC_SURFACE_POLICY_CONTRACT.md)
-- [OFFLINE_VERIFIABILITY_AND_RECOVERY_CONTRACT.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/docs/architecture/OFFLINE_VERIFIABILITY_AND_RECOVERY_CONTRACT.md)
-- [ADAPTER_CERTIFICATION_CONTRACT.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/docs/architecture/ADAPTER_CERTIFICATION_CONTRACT.md)
-- [TRUST_PORTABILITY_BOUNDARY_CONTRACT.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/docs/architecture/TRUST_PORTABILITY_BOUNDARY_CONTRACT.md)
-- [SIGNED_AUDIT_PROVENANCE_CONTRACT.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/docs/architecture/SIGNED_AUDIT_PROVENANCE_CONTRACT.md)
-## Public Boundary
-The public adoption story is intentionally narrow:
-- receive a handoff or event bundle
-- review it
-- verify it
-- emit a durable proof bundle
-`xoonya` should expose proof, review, and continuity. It should not force outside builders to learn runtime treasury or operator internals just to use the proof layer correctly.
-## Universal Proof Shape
-`xoonya` is intended to be usable from:
-- CLI and terminal
-- direct API calls
-- chat and agent environments that can submit handoff bundles
-- hosted or embedded review flows
-- partner systems that need deterministic proof verification
-The shortest public proof loop is:
-- receive a handoff or event bundle
-- review it
-- verify it
-- emit a durable proof bundle
-- preserve governance and continuity context when needed
-The frozen proof-side fact model for `3.0.0` closeout is documented in:
-- [XOONYA_PROOF_TRUTH_MODEL.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/XOONYA_PROOF_TRUTH_MODEL.md)
-- [OPERATIONAL_RECEIPT_CONTRACT.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/docs/architecture/OPERATIONAL_RECEIPT_CONTRACT.md)
-Machine-readable proof-truth surfaces:
-- `GET /v1/proof-truth`
-- `GET /v1/proof-truth/summary`
-- `GET /v1/proof-truth/:object_id`
-The frozen multi-surface proof default-path model for `3.0.0` closeout is documented in:
-- [XOONYA_DEFAULT_PATH_MODEL.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/XOONYA_DEFAULT_PATH_MODEL.md)
-Machine-readable proof default-path surfaces:
-- `GET /v1/default-path`
-- `GET /v1/default-path/summary`
-- `GET /v1/default-path/:surface_id`
-The frozen bridge, governance, trust-portability, and verification followthrough boundary for `3.0.0` closeout is documented in:
-- [XOONYA_FOLLOWTHROUGH_TRUTH_MODEL.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/XOONYA_FOLLOWTHROUGH_TRUTH_MODEL.md)
-Machine-readable followthrough-truth surfaces:
-- `GET /v1/followthrough-truth`
-- `GET /v1/followthrough-truth/summary`
-- `GET /v1/followthrough-truth/:profile_id`
-The current proof breadth already includes:
-- canonical events, receipts, and proof bundles
-- result-package handoff review and run paths
-- bridge and compatibility review surfaces
-- governance, dispute, and signoff support
-- proof-side continuity for economic consequence carry
-- proof-adjacent integration registration and review
-It also already carries broader first-class proof and interoperability lanes for:
-- framework continuity across `langchain`, `langgraph`, `semantic_kernel`, `autogen`, `crewai`, and `llamaindex`
-- native and external verification methods such as `XNYA`, JWT assertion, DID VC, SD-JWT VC, signed-envelope, detached assertion, and partner proof-envelope compatibility
-- operator and artifact lanes such as telemetry, provenance, artifact distribution, shared signals, feature control, trust portability, and external proof import review
-If you want the broadest machine-readable census for these already-core proof lanes, inspect:
-- `GET /v1/integration-matrix`
-- `GET /v1/proof-bridge`
-- `GET /v1/telemetry`
-- `GET /v1/provenance`
-- `GET /v1/artifact-distribution`
-- `GET /v1/shared-signals`
-- `GET /v1/feature-control`
-- `GET /v1/adapter-certification`
-- `GET /v1/trust-portability-boundary`
-- `GET /v1/signed-audit-provenance`
-## One-Line After Install
-If you only run two commands after install, use:
-- `xoonya start-here`
-- `xoonya first-run`
-- `xoonya first-run --verify-native --pretty`
-- `xoonya release --summary`
-- `xoonya conformance`
-If you want the shortest machine-readable discovery path, inspect:
-- `GET /v1/providers`
-- `GET /v1/frameworks`
-- `GET /v1/integration-matrix`
-- `GET /v1/proof-bridge`
-- `GET /v1/telemetry`
-- `GET /v1/provenance`
-- `GET /v1/adapter-certification`
-- `GET /v1/trust-portability-boundary`
-- `GET /v1/signed-audit-provenance`
-If you are working on shared evidence, inspect the operational receipt contract pack:
-- `buildOperationalReceiptContractPack()`
-- `summarizeOperationalReceiptContractPack()`
-If you are working on machine identity, inspect the registry contract pack:
-- `buildMachineIdentityRegistryContractPack()`
-- `summarizeMachineIdentityRegistryContractPack()`
-If you are working on crypto agility, inspect the matrix pack:
-- `buildCryptoAgilityMatrixPack()`
-- `summarizeCryptoAgilityMatrixPack()`
-If you are working on binding lifecycle, inspect the lifecycle pack:
-- `buildAuthorityBindingLifecycleContractPack()`
-- `summarizeAuthorityBindingLifecycleContractPack()`
-If you are working on public route policy, inspect the surface policy pack:
-- `buildPublicSurfacePolicyContractPack()`
-- `summarizePublicSurfacePolicyContractPack()`
-If you are working on offline recovery, inspect the recovery pack:
-- `buildOfflineVerifiabilityRecoveryContractPack()`
-- `summarizeOfflineVerifiabilityRecoveryContractPack()`
-If you are working on adapter certification, inspect the certification pack:
-- `buildAdapterCertificationContractPack()`
-- `summarizeAdapterCertificationContractPack()`
-If you are working on trust portability boundaries, inspect the boundary pack:
-- `buildTrustPortabilityBoundaryContractPack()`
-- `summarizeTrustPortabilityBoundaryContractPack()`
-If you are working on signed audit and provenance, inspect the audit/provenance pack:
-- `buildSignedAuditProvenanceContractPack()`
-- `summarizeSignedAuditProvenanceContractPack()`
-## Start Here
-If you are new to the proof-side package, use this order:
-1. read [START_HERE.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/START_HERE.md)
-2. run `node examples/package_quickstart.js`
-3. run `npm run verify:all`
-4. use [FINAL_CONTRACT.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/FINAL_CONTRACT.md) and [SERVICE_CONTRACT.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/SERVICE_CONTRACT.md) as the durable public contract
-If you are reading the GitHub repo and want deeper product context beyond the npm starter path, continue with:
-- [WHY_XYTARA_XOONYA.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/WHY_XYTARA_XOONYA.md)
-- [PARTNER_READY_PATH.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/PARTNER_READY_PATH.md)
-If you want one concrete cross-repo adoption story, start with:
-- [CARRIED_HANDOFF_DEMO.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/CARRIED_HANDOFF_DEMO.md)
-If you want the shortest neutral external-adoption bundle, continue with:
-- [PARTNER_READY_PATH.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/PARTNER_READY_PATH.md)
-- [PUBLIC_DEMO_SCRIPT.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/PUBLIC_DEMO_SCRIPT.md)
-- [EXAMPLE_PATHS.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/EXAMPLE_PATHS.md)
-- `node examples/partner_proof_walkthrough.js`
-If you are integrating from outside the stack, also read:
-- [CROSS_RUNTIME_POSTURE.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/CROSS_RUNTIME_POSTURE.md)
-- [integrations/PROOF_INTEGRATION_PROCESS.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/integrations/PROOF_INTEGRATION_PROCESS.md)
-If you want the broader already-core proof continuity layers, continue with:
-- [XOONYA_NATIVE_PROOF_FORMAT.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/XOONYA_NATIVE_PROOF_FORMAT.md)
-- [XOONYA_NATIVE_ATOM_SPEC.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/XOONYA_NATIVE_ATOM_SPEC.md)
-- [XNYA_REFERENCE_IMPLEMENTATIONS.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/XNYA_REFERENCE_IMPLEMENTATIONS.md)
-- [OPERATOR_START_HERE.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/OPERATOR_START_HERE.md)
-- [XOONYA_FOLLOWTHROUGH_TRUTH_MODEL.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/XOONYA_FOLLOWTHROUGH_TRUTH_MODEL.md)
-## Production Path
-The intended production-facing proof path is now:
-1. receive the transaction-side handoff or default path artifact from `xytara`
-2. inspect the proof-side review posture
-3. confirm carry and run posture
-4. emit and verify the proof-native completion path
-The rest of this README explains the broader route ladder, but the public starting posture should now be understandable from that one proof-side path.
-For a direct one-line proof-side review of a carried handoff bundle, use the bundled CLI:
+## Install
 ```bash
-xoonya-review --file ./handoff.json --summary
+npm install xoonya
 ```
-For release-grade adoption posture, inspect:
-- `GET /v1/release-pack`
-- `GET /v1/release-pack/summary`
-- `GET /v1/release-pack/comparison`
-- `GET /v1/release-pack/comparison/summary`
-- `GET /v1/release-pack/adoption`
-- `GET /v1/release-pack/adoption/summary`
-- `GET /v1/release-pack/scenarios`
-- `GET /v1/release-pack/scenarios/summary`
-- `GET /v1/release-pack/launch`
-- `GET /v1/release-pack/launch/summary`
-- `GET /v1/release-manifest`
-- `GET /v1/release-manifest/summary`
-- `GET /v1/release-notes`
-- `GET /v1/release-notes/summary`
-- `GET /v1/release-center`
-- `GET /v1/release-center/summary`
-- `GET /v1/release-history`
-- `GET /v1/release-history/summary`
-- `GET /v1/phases`
-- `GET /v1/phases/summary`
-- `GET /v1/phases/phase-1`
-- `GET /v1/phases/phase-1/summary`
-- `GET /v1/publish-plan`
-- `GET /v1/publish-plan/summary`
-- `GET /v1/ecosystem-entry`
-- `GET /v1/ecosystem-entry/summary`
-- `GET /v1/launch-narrative`
-- `GET /v1/launch-narrative/summary`
-- `GET /v1/outreach-proof`
-- `GET /v1/outreach-proof/summary`
-- `GET /v1/announcement-pack`
-- `GET /v1/announcement-pack/summary`
-- `GET /v1/release-candidate`
-- `GET /v1/release-candidate/summary`
-- `xoonya-release --summary`
-- `xoonya-release --comparison --summary`
-- `xoonya-release --adoption --summary`
-- `xoonya-release --scenarios --summary`
-- `xoonya-release --launch --summary`
-- `xoonya-release --manifest --summary`
-- `xoonya-release --notes --summary`
-- `xoonya-release --center --summary`
-- `xoonya-release --history --summary`
-- `xoonya-release --phases --summary`
-- `xoonya-release --phase-1 --summary`
-- `xoonya-release --ecosystem --summary`
-- `xoonya-release --narrative --summary`
-- `xoonya-release --outreach-proof --summary`
-- `xoonya-release --announcement --summary`
-- `xoonya-release --candidate --summary`
-These surfaces package the current proof-side value story, first-contact proof-review CLI path, proof-center posture, handoff/review/governance surfaces, and integration breadth into one machine-readable launch boundary.
-For explicit runtime-economics carry, the proof-side handoff boundary now also accepts a canonical `handoff_bundle` wrapper from `xytara` so the economic consequence seam stays contract-shaped across the two repos instead of being reassembled ad hoc by callers.
-That same carried bundle can now also ride inside the normal result-package handoff path:
-- if `xytara` sends `handoff_bundle.economic_consequence_handoff_bundle`
-- `xoonya` will validate it through the existing bounded handoff logic
-- normal result-package review and run surfaces will expose compact economic-conformance review data automatically
-- direct-pay or non-metered handoffs remain unaffected
-The package and service now also expose a default proof center surface so the intended proof-native path is easy to inspect directly:
-- canonical event bundle v1
-- receipt v1
-- proof bundle v1
-- compact compatibility helpers preserved, but not treated as the public conceptual center
-- proof remains settlement-agnostic and workflow-agnostic by default
-The current `1.6.0` companion slice adds guided default proof loops on top of that proof center:
-- default proof-loop catalog and detail routes
-- a direct proof-loop run route for the canonical proof-native path
-- package helpers that build, verify, and summarize the proof bundle boundary in one step
-This keeps `xoonya` narrow while making the intended proof path easier to inspect alongside the newer guided transaction-loop work in `xytara`.
-The current `1.7.0` companion slice adds a lightweight transaction proof-handoff surface:
-- a transaction proof-handoff center that states the expected handoff contract
-- a direct handoff run path that turns transaction-side proof handoff data into a proof-native bundle
-- summary helpers that make the recommended proof follow-through explicit without widening proof scope
-The current `1.8.0` companion slice extends that same proof-side carry to richer grouped interaction spine handoffs:
-- an interaction-spine handoff center and summary surface
-- a direct interaction-spine handoff run path for composed transaction spines
-- proof-side summaries that preserve both pre-commit and committed-ref context without importing commerce logic
-## Proof Model
-The primary proof model is layered:
-1. `Canonical Event Bundle`
-2. `Receipt`
-3. `Proof Bundle`
-4. optional domain-specific `Profiles`
-That means the center of gravity is now:
-- `canonicalizeEvent(...)`
-- `hashEvent(...)`
-- `emitReceipt(...)`
-- `buildProofBundle(...)`
-- `verifyProofBundle(...)`
-- `listProofVerificationMethods(...)`
-- `getProofVerificationMethod(...)`
-### Verification Methods
-`xoonya` keeps proof verification method-agnostic. The proof bundle verifier uses a small method registry instead of treating every non-empty signature as equally verified.
-Current built-in methods:
-- `legacy-opreturn-v1` verifies the compatibility OP_RETURN receipt path.
-- `detached-assertion-v1` accepts an explicit detached assertion after canonical receipt checks; cryptographic verification is expected to happen outside this helper.
-- `xoonya-native-sha256-v1` verifies xoonya's native deterministic digest format.
-- `xoonya-native-signed-v1` verifies xoonya's native signed proof envelope with Ed25519, secp256k1, and P-256 implemented through the explicit suite registry. Other suites stay registry-only until validators exist.
-- `xoonya-native-anchored-v1` verifies xoonya's native anchor-binding proof envelope for chain, batch, finality, content-hash, or external attestation refs. It verifies the binding, not the external provider or chain truth itself.
-- `jwt-assertion-v1` accepts compact JWT assertion envelopes after canonical receipt checks; JWT signature, issuer, and audience verification remain external to this helper.
-- `did-vc-v1` accepts DID/VC proof envelopes after canonical receipt checks; DID resolution and VC proof validation remain external to this helper.
-- `sd-jwt-vc-v1` accepts SD-JWT VC disclosure envelopes after canonical receipt checks; issuer, holder binding, and disclosure verification remain external to this helper.
-- `signed-envelope-v1` accepts generic signed envelopes after canonical receipt checks; envelope-specific signature verification remains external to this helper.
-- `partner-proof-envelope-v1` accepts partner-specific proof envelopes after canonical receipt checks; partner verifier policy remains external to this helper.
-`algorithm: "none"` is not a registered verification method and does not verify. External proof methods are first-class registry entries, but xoonya does not pretend to replace their own cryptographic verifier stacks. The proof core checks the canonical receipt, method registration, and method boundary; issuer-specific validation stays with the relevant JWT, DID/VC, SD-JWT VC, signed-envelope, or partner verifier.
-Every verify result now says which of these happened through `verification_class` and `cryptographically_verified` (see "Verification Classes" below). Native signed and hybrid proofs bind `public_key_ref` to the key carried in the proof, not to the identity string; pass `trusted_public_key_refs` or `expected_public_key_ref` to bind an identity to its keys, and `strict: true` to refuse anything that was not cryptographically verified.
-### xoonya Native Proof Format
-xoonya Native is the optional native proof/result/attestation format direction for machine proof. It is not a replacement for JWT, OAuth, OIDC, DID/VC, or SD-JWT VC. Those remain interoperability lanes.
-The native standard is xoonya's own fixed-size hot-path commitment atom, cold-path proof envelope, semantic-free core bytes, and deterministic validation. The current implemented native methods are `xoonya-native-sha256-v1`, `xoonya-native-signed-v1`, `xoonya-native-anchored-v1`, and `xoonya-native-hybrid-v1`. The signed native method verifies Ed25519, secp256k1, and P-256 today. The hybrid native method verifies only registered runtime-supported suite pairs, with `ed25519+ml-dsa-65` as the current promoted baseline and other pairings staying non-claimable until runtime support and vectors exist. The anchored native method binds receipts to declared anchor/finality/attestation refs without claiming the external system has been independently verified by xoonya.
-The atom ladder is treated as native xoonya design, not a runtime dependency: `xoonya-native-atom/v1` is the 58-byte classical commitment atom, `xoonya-native-atom/v2` is the 70-byte PQ-horizon identity commitment candidate, and `xoonya-native-atom/v3-contingency` stays reserved for a future digest-family shift only if the underlying hash assumptions materially change.
-The canonical xoonya Native atom magic is `XNYA`. No other magic value is part of the xoonya Native atom standard. The formal atom spec ships inside the `xoonya` package first; a separate standards repo can be extracted later if external governance needs it.
-XNYA atom conformance now includes stable machine-readable reject codes and adversarial vectors. Passing only the happy-path vectors is not enough to claim xoonya Native compatibility.
-The native payload profile is now explicit: `xoonya-native-payload-profile/v1` uses the binary `XNYP` magic and typed fields with deterministic ordering, fixed-width integer encoding, unknown-field policy checks, and no floats or loose JSON semantics. The optional `xoonya-native-line-rate-frame/v1` wraps an existing 58-byte or 70-byte `XNYA` atom with a 2-byte checksum for transport fast rejection; it does not change the atom and does not claim signature, encryption, custody, settlement, or external finality truth.
-The `XNYA-compatible` mark is now defined as a conformance claim, not a marketing label. Implementations may use it only when atom bytes, payload profile rules, proof-envelope method behavior, adversarial vectors, and stable error codes match the published artifacts. The mark must not be used to claim unregistered or runtime-unsupported PQ/hybrid verification, live external-provider execution, chain finality, custody, identity/auth, or external issuer truth without separate verifier evidence. `xoonya-native-hybrid-v1` is now implemented only for registered runtime-supported suite pairs, with current first-class verification centered on `ed25519+ml-dsa-65`.
-The JavaScript `xoonya` package is the current canonical XNYA reference implementation. A Python candidate scaffold now verifies the XNYA atom, native atom adversarial, XNYP payload profile, line-rate frame, canonical event, receipt, and non-signed proof-bundle vectors independently. It also verifies Ed25519 native signed vectors when Python's optional `cryptography` package is installed, otherwise it reports the deterministic dependency gate. It is not yet a full second reference until always-on signature-suite parity, proof-bundle round trips, and the full promotion gates pass. Rust remains planned until a verified vector-parity implementation exists.
-Run `npm run verify:reference-python-crypto` to create an isolated temporary Python virtual environment, install the optional crypto dependency, and require the Ed25519 native signed vector to verify. Run `npm run verify:reference-rust-scaffold` to check the packaged source-only Rust scaffold and its non-promotion boundary.
-See [XOONYA_NATIVE_PROOF_FORMAT.md](./XOONYA_NATIVE_PROOF_FORMAT.md).
-See [XOONYA_NATIVE_ATOM_SPEC.md](./XOONYA_NATIVE_ATOM_SPEC.md).
-See [XOONYA_NATIVE_STANDARD_GOVERNANCE.md](./XOONYA_NATIVE_STANDARD_GOVERNANCE.md).
-See [XNYA_CONFORMANCE_MARK.md](./XNYA_CONFORMANCE_MARK.md).
-See [XNYA_REFERENCE_IMPLEMENTATIONS.md](./XNYA_REFERENCE_IMPLEMENTATIONS.md).
-See [CROSS_RUNTIME_POSTURE.md](./CROSS_RUNTIME_POSTURE.md).
-## Compatibility Surface
-Legacy compact receipt and profile helpers are still available during alignment:
-- `createReceipt(...)`
-- `verifyReceipt(...)`
-- `createReceiptV2(...)`
-- `verifyReceiptV2(...)`
-- `createProofEnvelopeV1(...)`
-- `verifyProofEnvelopeV1(...)`
-- `createxoonyaNativeAtomV1(...)`
-- `createxoonyaNativeAtomV2(...)`
-- `verifyxoonyaNativeAtom(...)`
-- `createEconomicReceiptProfileV1(...)`
-- `verifyEconomicReceiptProfileV1(...)`
-- `createRegistryProfileV1(...)`
-- `verifyRegistryProfileV1(...)`
-Those helpers remain verified so current receipt/profile consumers are not broken while the newer proof model becomes the primary public direction.
-## Package Quickstart
-Run:
+## Quickstart — CLI
 ```bash
-node examples/package_quickstart.js
+xoonya start-here                        # the shortest first-run path
+xoonya first-run --verify-native --pretty
+xoonya conformance --json                # run proof + adversarial vectors
+xoonya review --help
 ```
-The package quickstart demonstrates:
-- proof integration discovery and certification posture
-- staged proof-integration registration and snapshot export
-- legacy compact receipt verification
-- legacy proof-envelope verification
-- canonical event creation
-- canonical receipt emission
-- proof bundle construction
-- proof bundle verification
-- transaction proof-handoff follow-through
-- proof-side bridge carry for explicit economic consequence review when runtime economics need proof-adjacent preservation
-## Service Quickstart
+## Quickstart — SDK
-Run:
+```js
+const xoonya = require("xoonya");
-```bash
-npm start
-```
+// 1. emit a signed receipt for a canonical event
+const receipt = xoonya.emitReceipt(event, { /* receipt options */ });
-Then in another shell:
+// 2. build a portable proof bundle
+const bundle = xoonya.buildProofBundle({ ceb: event, receipt });
-```bash
-curl -X POST http://127.0.0.1:4310/v1/events/hash ^
-  -H "content-type: application/json" ^
-  -d "{\"event\":{\"version\":\"canonical-event-bundle/v1\",\"domain_id\":\"demo\",\"sequence\":\"1\",\"actor_id\":\"agent-1\",\"adapter_source\":\"curl\",\"event_type\":\"demo.event\",\"event_hash\":\"abababababababababababababababababababababababababababababababab\"}}"
+// 3. verify it anywhere, deterministically
+const result = xoonya.verifyProofBundle(bundle);
+// => { valid: true, verification_method: "xoonya-native-hybrid-v1",
+//      verification_state: "verified_native_hybrid_signature", ... }
 ```
-Environment example:
-- [`.env.example`](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/.env.example)
-Service environment variables:
-- `XOONYA_HOST`, `XOONYA_PORT` (or `PORT`): bind address and port.
-- `XOONYA_STRICT_VERIFY=1`: make every proof-bundle verification strict (only `cryptographic` results are `valid`).
-- `XOONYA_ACCEPT_PRIVATE_KEY_MATERIAL`: `true` or `false`. When `false`, or when it is unset and `RENDER` is set (hosted deployments), `POST /v1/receipts/emit`, `POST /v1/proof-bundles/build`, and the proof-center run routes reject any body containing a field matching `/private_key/i` with `400 private_key_material_not_accepted`. Sign locally with the SDK (`emitReceipt`, `buildProofBundle`) or the `xoonya` CLI and submit the signed receipt or bundle instead. Local runs without `RENDER` keep accepting private key material so the existing verifiers pass.
-Request bodies are capped at 1 MiB by byte count (a larger declared `content-length` is rejected before the body is read). `OPTIONS` returns `204` with an `allow` header, `HEAD` mirrors `GET` without a body, malformed percent-encoding in a path returns `400 invalid_path_encoding`, and unexpected handler failures return a generic `500 internal_error` with the stack logged server-side only.
-## Service Routes
-Primary proof-model routes:
-- `GET /health`
-- `GET /v1/proof-center`
-- `GET /v1/proof-center/summary`
-- `GET /v1/proof-center/native-standard`
-- `GET /v1/proof-center/native-standard/summary`
-- `GET /v1/proof-center/native-atom-spec`
-- `GET /v1/proof-center/native-atom-spec/summary`
-- `GET /v1/proof-center/native-atom-conformance`
-- `GET /v1/proof-center/native-atom-conformance/summary`
-- `GET /v1/proof-center/native-anchor-profile`
-- `GET /v1/proof-center/native-anchor-profile/summary`
-- `GET /v1/proof-center/native-payload-profile`
-- `GET /v1/proof-center/native-payload-profile/summary`
-- `GET /v1/proof-center/native-line-rate-frame`
-- `GET /v1/proof-center/native-line-rate-frame/summary`
-- `GET /v1/proof-center/native-conformance-mark`
-- `GET /v1/proof-center/native-conformance-mark/summary`
-- `GET /v1/proof-center/native-reference-implementations`
-- `GET /v1/proof-center/native-reference-implementations/summary`
-- `GET /v1/proof-center/import-adapter`
-- `GET /v1/proof-center/import-adapter/summary`
-- `POST /v1/proof-center/import-adapter/review`
-- `POST /v1/proof-center/import-adapter/review/summary`
-- `POST /v1/proof-center/import-adapter/run`
-- `GET /v1/proof-center/default-loops`
-- `GET /v1/proof-center/default-loops/summary`
-- `GET /v1/proof-center/default-loop`
-- `POST /v1/proof-center/default-loops/run`
-- `GET /v1/proof-center/transaction-handoff`
-- `GET /v1/proof-center/transaction-handoff/summary`
-- `POST /v1/proof-center/transaction-handoff/run`
-- `GET /v1/proof-center/result-package-handoff`
-- `GET /v1/proof-center/result-package-handoff/summary`
-- `GET /v1/proof-center/governance`
-- `GET /v1/proof-center/governance/summary`
-- `GET /v1/proof-center/bridge`
-- `GET /v1/proof-center/bridge/summary`
-- `GET /v1/proof-center/bridge/profile-support`
-- `POST /v1/proof-center/governance/interpretation-validate`
-- `POST /v1/proof-center/governance/coordination`
-- `POST /v1/proof-center/governance/dashboard`
-- `POST /v1/proof-center/governance/operator-view`
-- `POST /v1/proof-center/governance/admin-view`
-- `POST /v1/proof-center/governance/dashboard-pack`
-- `POST /v1/proof-center/governance/workflow-pack`
-- `POST /v1/proof-center/governance/signoff-pack`
-- `POST /v1/proof-center/governance/disputes/summary`
-- `POST /v1/proof-center/governance/disputes/case-review`
-- `POST /v1/proof-center/governance/disputes/action`
-- `POST /v1/proof-center/governance/disputes/case-bundle`
-- `POST /v1/proof-center/governance/disputes/resolution-pack`
-- `POST /v1/proof-center/governance/console-pack`
-- `POST /v1/proof-center/governance/handoff-bundle`
-- `POST /v1/proof-center/governance/review-link`
-- `POST /v1/proof-center/bridge/receipt-wrap`
-- `POST /v1/proof-center/bridge/validator-verify`
-- `POST /v1/proof-center/bridge/receipt-ledger-handoff`
-- `POST /v1/proof-center/bridge/economic-handoff`
-- `POST /v1/proof-center/bridge/economic-conformance-pack`
-- `POST /v1/proof-center/bridge/operator-review-pack`
-- `POST /v1/proof-center/bridge/compatibility-pack`
-- `POST /v1/proof-center/bridge/workflow-pack`
-- `POST /v1/proof-center/bridge/admin-pack`
-- `POST /v1/proof-center/result-package-handoff/review`
-- `POST /v1/proof-center/result-package-handoff/review/summary`
-- `POST /v1/proof-center/result-package-handoff/review/extension-readiness`
-- `POST /v1/proof-center/result-package-handoff/review/extension-boundary`
-- `POST /v1/proof-center/result-package-handoff/review/default-continuation`
-- `POST /v1/proof-center/result-package-handoff/review/default-boundary`
-- `POST /v1/proof-center/result-package-handoff/review/contract-summary`
-- `POST /v1/proof-center/result-package-handoff/review/contract-boundary`
-- `POST /v1/proof-center/result-package-handoff/review/contract-carry`
-- `POST /v1/proof-center/result-package-handoff/review/bridge-summary`
-- `POST /v1/proof-center/result-package-handoff/review/bridge-boundary`
-- `POST /v1/proof-center/result-package-handoff/review/bridge-carry`
-- `POST /v1/proof-center/result-package-handoff/review/bridge-run`
-- `POST /v1/proof-center/result-package-handoff/review/handoff-continuity`
-- `POST /v1/proof-center/result-package-handoff/review/handoff-intake`
-- `POST /v1/proof-center/result-package-handoff/review/handoff-intake-boundary`
-- `POST /v1/proof-center/result-package-handoff/review/handoff-intake-carry`
-- `POST /v1/proof-center/result-package-handoff/review/handoff-package-intake`
-- `POST /v1/proof-center/result-package-handoff/review/handoff-package-carry`
-- `POST /v1/proof-center/result-package-handoff/review/handoff-package-run`
-- `POST /v1/proof-center/result-package-handoff/review/execution-package`
-- `POST /v1/proof-center/result-package-handoff/review/execution-package-carry`
-- `POST /v1/proof-center/result-package-handoff/review/execution-package-run`
-- `POST /v1/proof-center/result-package-handoff/review/execution-contract`
-- `POST /v1/proof-center/result-package-handoff/review/execution-contract-carry`
-- `POST /v1/proof-center/result-package-handoff/review/execution-contract-run`
-- `POST /v1/proof-center/result-package-handoff/review/operating-contract`
-- `POST /v1/proof-center/result-package-handoff/review/operating-contract-carry`
-- `POST /v1/proof-center/result-package-handoff/review/operating-contract-run`
-- `POST /v1/proof-center/result-package-handoff/review/operating-interface`
-- `POST /v1/proof-center/result-package-handoff/review/operating-interface-carry`
-- `POST /v1/proof-center/result-package-handoff/review/operating-interface-run`
-- `POST /v1/proof-center/result-package-handoff/review/operating-integration`
-- `POST /v1/proof-center/result-package-handoff/review/operating-integration-carry`
-When `xytara` sends `handoff_bundle.economic_consequence_handoff_bundle`, `xoonya` now preserves a compact `economic_audit_summary` inside review output so proof-side operators can see the linked `account_ref`, `usage_meter_ref`, `credit_spend_ref`, `usage_units`, `pricing_band`, `payment_ref`, `settlement_ref`, `settlement_txid`, `settlement_finality_status`, `treasury_receipt_ref`, `proof_ref`, and `conformance_pack_ref` without re-deriving the carry by hand.
-- `POST /v1/proof-center/result-package-handoff/review/operating-integration-run`
-- `POST /v1/proof-center/result-package-handoff/review/operating-path`
-- `POST /v1/proof-center/result-package-handoff/review/operating-path-carry`
-- `POST /v1/proof-center/result-package-handoff/review/operating-path-run`
-- `POST /v1/proof-center/result-package-handoff/review/complete-default-path`
-- `POST /v1/proof-center/result-package-handoff/review/complete-default-path-carry`
-- `POST /v1/proof-center/result-package-handoff/review/complete-default-path-run`
-- `POST /v1/proof-center/result-package-handoff/review/handoff-run`
-- `POST /v1/proof-center/result-package-handoff/run`
-The result-package review surface now also returns a durability summary so the preserved execution, economic, and proof-facing context is easier to inspect before proof-native execution.
-It also now exposes an extension-readiness summary so the stable post-review proof boundary is easier to treat as a reusable seam.
-It now also exposes a reusable-default continuation summary so that same stable post-review boundary is easier to reuse as a standard proof-side default path.
-It now also exposes a compact reusable-default boundary summary so the proof-side default seam can be treated as a stable public boundary, not just a recommended path.
-It now also exposes composition-contract summaries so the proof-side default seam can be treated more clearly as a stable public contract across review and run.
-It now also exposes compact contract-carry summaries so the stable proof-side contract context is easier to inspect directly without expanding proof scope.
-It now also exposes bridge summaries, bridge-boundary summaries, and bridge-carry summaries so the proof-side review seam is easier to treat as an adapter-ready bridge without widening proof scope.
-It now also exposes a bridge-run summary so that same proof-side bridge can be read directly as the final run posture instead of only as review-stage carry.
-It now also exposes a handoff-continuity summary so the proof-side bridge can be treated more clearly as a stable handoff contract into proof-native execution.
-It now also exposes a handoff-intake summary and handoff-intake-boundary summary so that same handoff contract can be consumed more directly as a stable proof-native intake surface for future adapters without widening proof scope.
-It now also exposes a handoff-intake-carry summary so the same proof-side intake surface can be reused more directly as compact consumable carry instead of only summary or boundary posture.
-It now also exposes a handoff-run summary so that same handoff contract can be read directly as the final proof-native run posture instead of only as continuity guidance.
-The Wave B governance carry-over line adds a bounded governance center on the proof side:
-- governance interpretation validation for receipt-ledger and result-package follow-through
-- governance coordination emission for the next proof-side/operator handoff step
-- governance dashboard, operator-view, admin-view, dashboard-pack, workflow-pack, and signoff-pack packaging
-- dispute summary, case review, metadata-only dispute action, case-bundle export, and resolution-pack export
-- console-pack, handoff-bundle, and explicit review-link surfaces for compact operator carry into the proof-side review/run ladder
-This keeps governance review attached to the proof-side operating shape without widening `xoonya` into a runtime or economics system.
-The Wave E bridge carry-over line adds a bounded bridge center on the proof side:
-- receipt-wrap support for compact compatibility receipts when an outside bridge still needs that bounded surface
-- validator-compatible verification and receipt inspection posture for bridge-side review
-- receipt-ledger handoff packaging for compact proof-to-economics carry
-- operator review packs, workflow packs, admin packs, and compatibility packs so bridge-facing support breadth is easy to inspect without changing the public proof center
-This keeps the public story centered on `xoonya` while preserving the useful bridge, validator, and profile lineage as support surfaces instead of separate product identities.
-The current `1.18.0` line starts turning that adapter-consumable handoff surface into a clearer adapter-usable handoff package:
-- proof-side handoff-package intake summaries on top of the intake surface
-- proof-side handoff-package carry for compact usable package carry
-- proof-side handoff-package run summaries for direct default run posture
-- clearer handoff-package ids across intake, carry, and proof-native run posture
-This is intended to make the proof-side continuation path easier to use directly as a stable public handoff package instead of only a proof-native intake surface.
-The current `1.19.0` line starts turning that adapter-usable handoff package into a clearer adapter-ready execution package:
-- proof-side execution-package posture on top of the handoff-package path
-- compact execution-package carry for direct execution-ready posture
-- proof-side execution-package run posture for direct default proof-native run carry
-- clearer execution-package ids across package review, carry, and proof-native run posture
-This is intended to make the proof-side continuation path easier to execute against directly as a stable public package instead of only a package posture.
-The current `1.20.0` line starts turning that adapter-ready execution package into a clearer adapter-operable execution contract:
-- proof-side execution-contract posture on top of the execution-package path
-- compact execution-contract carry for direct operable proof-side carry
-- proof-side execution-contract run posture for direct default proof-native operation carry
-- clearer execution-contract ids across review, carry, and proof-native run posture
-This is intended to make the proof-side continuation path easier to operate against repeatedly as a stable public contract instead of only a package that is execution-ready by posture.
-The current `1.21.0` line starts turning that adapter-operable execution contract into a clearer adapter-stable operating contract:
-- proof-side operating-contract posture on top of the execution-contract path
-- compact operating-contract carry for direct stable proof-side operating carry
-- proof-side operating-contract run posture for direct default proof-native operating posture
-- clearer operating-contract ids across review, carry, and proof-native run posture
-This is intended to make the proof-side continuation path easier to depend on repeatedly as a durable public operating contract instead of only a contract that is operable in the moment.
-The current `1.22.0` line starts turning that adapter-stable operating contract into a clearer adapter-reliable operating interface:
-- proof-side operating-interface posture on top of the operating-contract path
-- compact operating-interface carry for direct reliable proof-side interface carry
-- proof-side operating-interface run posture for direct default proof-native reliable posture
-- clearer operating-interface ids across review, carry, and proof-native run posture
-This is intended to make the proof-side continuation path easier to rely on operationally as a durable public interface instead of only a stable operating contract shape.
-The current `1.23.0` line starts turning that adapter-reliable operating interface into a clearer adapter-integrable operating path:
-- proof-side operating-integration posture on top of the operating-interface path
-- compact operating-integration carry for direct integrable proof-side path carry
-- proof-side operating-integration run posture for direct default proof-native integration posture
-- clearer operating-integration ids across review, carry, and proof-native run posture
-This is intended to make the proof-side continuation path easier to plug into adapters directly as a durable public operating path instead of only a reliable interface shape.
+## Verification methods
-The current `1.24.0` line starts turning that adapter-integrable operating path into a clearer adapter-ready default path:
+xoonya verifies the **native XNYA** family and common **external** formats for interop:
-- proof-side operating-path posture on top of the operating-integration path
-- compact operating-path carry for direct default proof-side path carry
-- proof-side operating-path run posture for direct default proof-native path posture
-- clearer operating-path ids across review, carry, and proof-native run posture
+- **Native (XNYA):** `xoonya-native-sha256-v1`, `xoonya-native-signed-v1` (Ed25519 / secp256k1 /
+  P-256), `xoonya-native-hybrid-v1` (**classical + post-quantum**: ML-DSA-65 / FIPS-204,
+  SLH-DSA / FIPS-205), `xoonya-native-anchored-v1`.
+- **External:** `signed-envelope`, `detached-assertion`, `jwt-assertion`, `sd-jwt-vc`, `did-vc`,
+  `partner-proof-envelope`, `legacy-opreturn`.
-This is intended to make the proof-side continuation path easier to use as the obvious first public adapter path instead of only a path that is integrable with a little extra coordination.
+Conformance and adversarial vectors ship in `vectors/`; the `XNYA-compatible` mark is defined in
+[`XNYA_CONFORMANCE_MARK.md`](./XNYA_CONFORMANCE_MARK.md).
-The current `1.25.0` line starts turning that adapter-ready default path into a clearer adapter-complete default path:
+## As a paid service (x402)
-- proof-side complete-default-path posture on top of the operating-path path
-- compact complete-default-path carry for direct complete proof-side path carry
-- proof-side complete-default-path run posture for direct default proof-native complete path posture
-- clearer complete-default-path ids across review, carry, and proof-native run posture
+xoonya runs as a verification service you can pay per call. An agent pays
+[xytara](https://naxytra.com/xytara) with x402 for `adapter.xoonya.invoke` (tool
+`proof.verify-signature` / `proof.verify-bundle` / `proof.verify-envelope` / `proof.verify-receipt`);
+xytara routes to xoonya's bearer-authed `/execute`, which runs real verification and returns the
+verdict. It is billed only on a successful verification.
-This is intended to make the proof-side continuation path easier to adopt as the complete public default path an outside builder can use without needing private interpretation.
-The current `1.26.0` line finalizes that public shape into a cleaner production-ready package:
-- a publishable [START_HERE.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/START_HERE.md) onboarding path
-- clearer top-level README entry points for the default proof-side production flow
-- publishable contract, compatibility, and terminology docs carried in the package tarball
-- naming cleanup that keeps the public story anchored to `xytara` and `xoonya`
-This is intended to make the public proof-side package feel like a finished production-facing product instead of a strong stack that still assumes milestone-history context.
-- `POST /v1/events/canonicalize`
-- `POST /v1/events/hash`
-- `POST /v1/receipts/emit`
-- `POST /v1/proof-bundles/build`
-- `POST /v1/proof-bundles/verify`
-- `GET /v1/integrations`
-- `GET /v1/integrations/summary`
-- `GET /v1/integrations/snapshot`
-- `GET /v1/integrations/promotion-readiness`
-- `GET /v1/integrations/promotion-workflow`
-Preserved compatibility routes:
-- `POST /validate`
-- `POST /v1/receipts/verify`
-- `POST /v1/receipts/inspect`
-- `POST /v1/proofs/verify`
-- `POST /v1/profiles/economic/verify`
-- `POST /v1/profiles/registry/verify`
-## Verification
-Local verification commands:
-- `npm run verify:package`
-- `npm run verify:conformance`
-- `npm run verify:vectors`
-- `npm run verify:examples`
-- `npm run verify:service`
-- `npm run verify:tooling`
-- `npm run verify:forgery-resistance`
-- `npm run verify:all`
-The current verification covers:
-- proof integration discovery metadata and filtering
-- staged proof integration registration import and snapshot export
-- package export presence
-- deterministic event hashing
-- proof-bundle tamper detection
-- public conformance CLI execution through `xoonya conformance --json`
-- published conformance vectors
-- published adversarial vectors
-- package quickstart flow
-- service routes for both the primary proof model and the legacy compatibility layer
-- forgery resistance: key substitution with and without a trust root, strict-mode rejection of digest and structural results, hybrid PQ tampering and wrong-pin rejection, and result determinism
-### Verification Classes
-`verifyProofBundle(bundle, options)` and `POST /v1/proof-bundles/verify` (`{ "bundle": ..., "options": ... }`) return `verification_class`, `cryptographically_verified`, `strict`, and `trust_root_applied` next to `valid`:
-| `verification_class` | Methods | `cryptographically_verified` | Strict mode |
-| --- | --- | --- | --- |
-| `cryptographic` | `xoonya-native-signed-v1`, `xoonya-native-hybrid-v1` | `true` when valid | accepted |
-| `digest` | `xoonya-native-sha256-v1`, `legacy-opreturn-v1` | `false` | rejected: `digest_only_not_cryptographically_verified` |
-| `anchored_binding` | `xoonya-native-anchored-v1` | `false` | rejected: `digest_only_not_cryptographically_verified` |
-| `structural` | `detached-assertion-v1`, `jwt-assertion-v1`, `did-vc-v1`, `sd-jwt-vc-v1`, `signed-envelope-v1`, `partner-proof-envelope-v1` | `false` | rejected: `external_verification_required` |
-Default `valid` semantics are unchanged. Options:
-- `strict: true` (or env `XOONYA_STRICT_VERIFY=1`): only `cryptographic` results are `valid`.
-- `expected_public_key_ref`, `expected_classical_public_key_ref`, `expected_pq_public_key_ref`, `expected_hybrid_public_key_ref`: pin the exact key refs a native proof must carry.
-- `trusted_public_key_refs`: `{ "<identity_ref>": "<ref>" | ["<ref>", ...] | { "classical": ..., "pq": ..., "hybrid": ... } }`. Native signed proofs fail with `native_public_key_not_trusted` and native hybrid proofs with `native_hybrid_public_key_not_trusted` when the signing key is not pinned for that identity. Any trust-root option sets `trust_root_applied: true` and fails closed for identities that are not listed.
-Without a trust root, a native signed proof only proves that the carried key signed the receipt; `identity_ref` and `agent_identity` are not bound to that key by xoonya. `npm run verify:forgery-resistance` pins this behavior.
-Public conformance command:
+Run the server yourself:
 ```bash
-xoonya conformance
-xoonya conformance --json
+XOONYA_EXECUTOR_BEARER_TOKEN=... npm start   # exposes the paid /execute lane
 ```
-The conformance command verifies the published vector files shipped in the package. The positive set covers `legacy-opreturn-v1`, `detached-assertion-v1`, `xoonya-native-sha256-v1`, `xoonya-native-signed-v1`, `xoonya-native-anchored-v1`, `xoonya-native-hybrid-v1`, `jwt-assertion-v1`, `did-vc-v1`, `sd-jwt-vc-v1`, `signed-envelope-v1`, and `partner-proof-envelope-v1`. The adversarial set covers bad event versions, missing signatures, mismatched commitments, unsupported methods, ambiguous `none`, replayed receipt context, native digest tampering, native signed proof tampering, native anchored proof tampering, native hybrid signature and key-binding tampering, native-to-detached downgrade attempts, and receipt-id mismatches.
-Published proof hardening artifacts:
-- [conformance-vectors.json](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/vectors/conformance-vectors.json)
-- [adversarial-vectors.json](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/vectors/adversarial-vectors.json)
-- [CROSS_RUNTIME_POSTURE.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/CROSS_RUNTIME_POSTURE.md)
-## Control Files
-- `CROSS_RUNTIME_POSTURE.md`
-- `FINAL_CONTRACT.md`
-- `TERMINOLOGY.md`
-- `SERVICE_CONTRACT.md`
-- `COMPATIBILITY_NOTE.md`
-## Proof Integration Toolkit
-`xoonya` keeps its integration model narrower than `xytara`. The proof-side toolkit is for additive proof helpers only:
-- identity-material providers
-- attestation and evidence reference adapters
-- anchor reference adapters
-- profile verification helpers
-- compatibility-oriented proof integrations
+## Configuration
-This integration toolkit is broader than the proof verification method registry. Verification methods describe how a receipt or proof envelope is admitted at the proof boundary; integrations describe additive proof-side helpers, references, profiles, and staged third-party support that can be reviewed without changing the proof kernel.
+- `XOONYA_STRICT_VERIFY=1` — only cryptographically verified (native signed / hybrid) results pass;
+  digest and structural results are rejected.
+- `XOONYA_ACCEPT_PRIVATE_KEY_MATERIAL=false` — refuse private-key material on shared deployments;
+  sign locally with the SDK/CLI instead.
-The package now includes:
-- `validateIntegrationRegistration(...)`
-- `importRegisteredIntegration(...)`
-- `exportIntegrationRegistrySnapshot(...)`
-- `validateIntegrationRegistrySnapshot(...)`
-- `summarizeIntegrationPromotionReadiness(...)`
-- `summarizeIntegrationPromotionWorkflow(...)`
-- `summarizeIntegrationPromotionWorkflowList(...)`
-Those helpers are intended to normalize proof-adjacent integrations without letting pricing, workflow, or settlement logic leak into the proof kernel.
-For the lightweight external-builder path, use:
-- [PROOF_INTEGRATION_PROCESS.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/integrations/PROOF_INTEGRATION_PROCESS.md)
-For lightweight local review flows, `xoonya` also includes a small repo-local proof-side CLI when working from a cloned `xoonya` repository:
-```bash
-node scripts/registry_cli.js validate-registration --example verifier
-node scripts/registry_cli.js export-snapshot --registration_state staging_registered
-node scripts/registry_cli.js promotion-readiness --integration partner.verifier.lattice_notary
-node scripts/registry_cli.js promotion-workflow --integration partner.verifier.lattice_notary
-node scripts/registry_cli.js promotion-workflow-summary --source third_party_example --registration_state staging_registered --bundled false
-```
+See [`.env.example`](./.env.example) for the full list.
-That tooling is intentionally narrow: validate proof-integration registration posture and export filtered proof registry snapshots.
+## Learn more
-The proof-side readiness layer now also makes promotion posture explicit without expanding `xoonya` into a control plane:
+- Why two packages: [`WHY_XYTARA_XOONYA.md`](./WHY_XYTARA_XOONYA.md)
+- Native proof format: [`XOONYA_NATIVE_PROOF_FORMAT.md`](./XOONYA_NATIVE_PROOF_FORMAT.md) ·
+  atom spec: [`XOONYA_NATIVE_ATOM_SPEC.md`](./XOONYA_NATIVE_ATOM_SPEC.md)
+- Start here: [`START_HERE.md`](./START_HERE.md) · terminology: [`TERMINOLOGY.md`](./TERMINOLOGY.md)
+- Live: https://naxytra.com/xoonya
-- review-ready means a proof integration is staged and inspectable
-- default-eligible means it can participate in the proof-side default posture
-- production-default-ready means certification, maturity, bundled posture, and selection posture all line up
-- blockers are returned as data instead of being left implicit
-- promotion workflow summaries now show the next proof-side transition and the current recommendation without introducing approval state
+## License
+Apache-2.0. See [`LICENSE`](./LICENSE) and [`NOTICE`](./NOTICE).

package/RELEASE_NOTES.md CHANGED Viewed

@@ -1,11 +1,3 @@
-`xoonya` 3.1.9 turns proof verification into a paid, pay-per-call machine service while keeping every existing free verification path and the deterministic proof engine unchanged.
+`xoonya` 3.1.10 refreshes the public README and package metadata to lead with the proven capabilities: deterministic and post-quantum (Ed25519 + ML-DSA-65 hybrid) verification of the native XNYA machine-evidence format, demonstrated live via the paid x402 lane.
-This is the first release to carry the monetization backend: the proof verifier can now be offered as a metered service behind the runtime's x402 payment spine, and imported external proofs are verified cryptographically rather than only hash-bound.
-Highlights:
-- adds a bearer-authed `POST /execute` backend so proof verification can be sold per call behind the runtime's x402 settlement (fail-closed: 503 when the bearer is unset, 401 on a bad token, constant-time token comparison)
-- bills only on a positively-successful verification — unknown tool, unprocessable input, a structural reject, or a negative verdict all return non-2xx so the runtime never settles for a non-result
-- adds an optional paywall flag (`XOONYA_REQUIRE_PAID_VERIFICATION`, default off) that makes the free direct verify routes return 402 pointing to the paid lane, so the free HTTP path cannot undercut the paid product; `/execute` and `/health` always stay free
-- verifies imported external proofs (compact JWS and detached signatures) cryptographically with `node:crypto` instead of only binding their hash — a real cross-runtime verifier, with `alg:none`/alg-confusion/private-key material rejected
-- keeps the deterministic hash/sign/verify core, the native XNYA standard, the classical and post-quantum (ML-DSA-65, SLH-DSA-SHA2-128f) verification suites, the conformance and forgery-resistance vectors, strict-mode and trust-root options, and the canonical `https://naxytra.com/xoonya` product URL unchanged
+There is no change to the proof engine, verification behavior, vectors, or any route — this is a documentation and packaging refresh for public outreach.

package/START_HERE.md CHANGED Viewed

@@ -4,7 +4,7 @@ This is the shortest reliable path for understanding and using the public `xoony
 The phase program is now complete, so this file is the right starting point for a closed and release-shaped proof system rather than an in-flight milestone build.
-The product-side implementation, proof posture, and bounded hybrid verification work for the widened `3.0.0` finish line are now complete. The remaining step is the synchronized public `3.0.0` release cut, publish, deploy, and verification sequence documented in [NAXYTRA_3_0_0_RELEASE_CONTRACT.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/docs/release/NAXYTRA_3_0_0_RELEASE_CONTRACT.md) and [PUBLISH_PLAN.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/PUBLISH_PLAN.md).
+The product-side implementation, proof posture, and bounded hybrid verification work for the widened `3.0.0` finish line are now complete. The remaining step is the synchronized public `3.0.0` release cut, publish, deploy, and verification sequence documented in NAXYTRA_3_0_0_RELEASE_CONTRACT.md and PUBLISH_PLAN.md.
 If you are arriving from the broader public discovery layer, the canonical entry points are:
@@ -68,13 +68,13 @@ This is the fastest way to see the intended proof-side package story end-to-end.
 If you want the clearest cross-repo adoption path instead of the broad package tour, continue with:
-- [CARRIED_HANDOFF_DEMO.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/CARRIED_HANDOFF_DEMO.md)
+- CARRIED_HANDOFF_DEMO.md
 If you want the shortest neutral external-adoption bundle, continue with:
-- [PARTNER_READY_PATH.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/PARTNER_READY_PATH.md)
-- [PUBLIC_DEMO_SCRIPT.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/PUBLIC_DEMO_SCRIPT.md)
-- [EXAMPLE_PATHS.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/EXAMPLE_PATHS.md)
+- PARTNER_READY_PATH.md
+- PUBLIC_DEMO_SCRIPT.md
+- EXAMPLE_PATHS.md
 - `node examples/partner_proof_walkthrough.js`
 ## 3. Verify The Whole Package
@@ -91,8 +91,8 @@ This is the production-confidence check for the published proof package surface.
 For long-term product understanding, read:
-- [FINAL_CONTRACT.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/FINAL_CONTRACT.md)
-- [SERVICE_CONTRACT.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/SERVICE_CONTRACT.md)
+- FINAL_CONTRACT.md
+- SERVICE_CONTRACT.md
 - `GET /openapi.json`
 - `GET /asyncapi.json`
 - `GET /cloudevents.json`
@@ -117,23 +117,23 @@ For long-term product understanding, read:
 - `GET /v1/result-package-trust`
 - `GET /v1/event-systems`
 - `GET /v1/integrations`
-- [PROGRAM_STATUS.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/PROGRAM_STATUS.md)
-- [OPERATOR_START_HERE.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/OPERATOR_START_HERE.md)
-- [OPERATIONS_RUNBOOK.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/OPERATIONS_RUNBOOK.md)
-- [PROGRAM_COMPLETE_RELEASE.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/PROGRAM_COMPLETE_RELEASE.md)
-- [WHY_XYTARA_XOONYA.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/WHY_XYTARA_XOONYA.md)
-- [CARRIED_HANDOFF_DEMO.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/CARRIED_HANDOFF_DEMO.md)
-- [PARTNER_READY_PATH.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/PARTNER_READY_PATH.md)
-- [TERMINOLOGY.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/TERMINOLOGY.md)
+- PROGRAM_STATUS.md
+- OPERATOR_START_HERE.md
+- OPERATIONS_RUNBOOK.md
+- PROGRAM_COMPLETE_RELEASE.md
+- WHY_XYTARA_XOONYA.md
+- CARRIED_HANDOFF_DEMO.md
+- PARTNER_READY_PATH.md
+- TERMINOLOGY.md
 ## 5. If You Are Integrating From Outside
 Continue with:
-- [CROSS_RUNTIME_POSTURE.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/CROSS_RUNTIME_POSTURE.md)
-- [integrations/PROOF_INTEGRATION_PROCESS.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/integrations/PROOF_INTEGRATION_PROCESS.md)
-- [PARTNER_READY_PATH.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/PARTNER_READY_PATH.md)
-- [COMPATIBILITY_NOTE.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/COMPATIBILITY_NOTE.md)
+- CROSS_RUNTIME_POSTURE.md
+- integrations/PROOF_INTEGRATION_PROCESS.md
+- PARTNER_READY_PATH.md
+- COMPATIBILITY_NOTE.md
 ## 6. Production Reading Rule
@@ -155,5 +155,5 @@ If you want the shortest CLI-first read of the package after install, use:
 Use:
-- [PROGRAM_STATUS.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/PROGRAM_STATUS.md)
-- [OPERATOR_START_HERE.md](C:/Users/Yoga/Desktop/workspace/vscode_workspace_naxytra/naxytra/xoonya/OPERATOR_START_HERE.md)
+- PROGRAM_STATUS.md
+- OPERATOR_START_HERE.md

package/package.json CHANGED Viewed

@@ -1,7 +1,7 @@
 {
   "name": "xoonya",
-  "version": "3.1.9",
-  "description": "Deterministic proof and review engine for receipts, handoffs, governance, and verification.",
+  "version": "3.1.10",
+  "description": "Deterministic proof and review engine with post-quantum verification (Ed25519 + ML-DSA-65 hybrid) for receipts, handoffs, governance, and the native XNYA machine-evidence format. Verified live via the paid x402 lane.",
   "main": "index.js",
   "bin": {
     "xoonya": "bin/xoonya.js",
@@ -69,7 +69,14 @@
     "proof-bundle",
     "deterministic",
     "machine",
-    "evidence"
+    "evidence",
+    "post-quantum",
+    "ml-dsa",
+    "slh-dsa",
+    "pqc",
+    "xnya",
+    "ed25519",
+    "x402"
   ],
   "scripts": {
     "start": "node server.js",