xytara 3.9.3 → 3.9.5

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 (2) hide show
  1. package/RELEASE_NOTES.md +5 -5
  2. package/package.json +1 -1
package/RELEASE_NOTES.md CHANGED
@@ -1,7 +1,7 @@
1
- `xytara` 3.9.3 keeps every delegation-log checkpoint retrievable, so a checkpoint anchored elsewhere by its digest can always be fetched and checked.
1
+ `xytara` 3.9.5 lets a provider be named by an ENS name it owns, checked against the name's own records on Ethereum (x402 `payee-name`, wg-identity#36).
2
2
 
3
- - **Durable checkpoints** — every checkpoint the runtime issues is stored in the durable runtime state. While the log head and the external binding are unchanged, the stored checkpoint is served again instead of being re-signed, so a restart or a deploy no longer replaces it (it is re-signed only if its signing keys are no longer published).
4
- - **Checkpoints by id** — `GET /v1/delegation-log/checkpoints` lists every issued checkpoint, newest first (id, `attestation_sha256`, head, binding tag, time; digests only), and `GET /v1/delegation-log/checkpoints/:id` returns one byte-identical, verifiable with the published keys. `GET /v1/delegation-log/checkpoint` still returns the current one.
5
- - **Anchoring record** — `scripts/record_delegation_checkpoint.js` now points the anchoring party at the checkpoint's permanent by-id URL.
6
- - **Verifier** — the delegation-log verifier runs two real server processes on one state file and checks that the unchanged head is served the same checkpoint after the restart and that it stays fetchable by id; the state-guard verifier checks the new collection is declared.
3
+ - **Provider ENS names** — registration accepts an optional `ens_name` (lowercase ASCII `.eth` names). The runtime checks it against Ethereum mainnet at registration and daily: the name's `org.x402.origins` record must list the provider's endpoint origin, its address record for the payout network (or a CAIP-10 entry in `org.x402.payto`) must list the payout address, and the name must be unexpired on chain time (ENSv2 and unmigrated ENSv1 names). Verdicts and reason codes follow the payee-name spec; a failed chain read is always `inconclusive`, never `false`. Records served off-chain (CCIP-Read) are not followed yet and read as inconclusive.
4
+ - **Receipts** — while the verdict is `payee-bound` for the record's current endpoint origin and payout address, signed delivery receipts carry `delivery.provider_name` (name, reason, `checked_at`, `expires_at`) next to `provider_id`.
5
+ - **Registry** — the name is owner-protected and not routing-material (setting or changing it never re-pends an active provider); a stored verdict is dropped when the name, endpoint origin or payout address changes. The public record shows the verdict but never the payout address. `POST /v1/provider-network/providers/<id>/name-check` re-runs the check (owner, at most once a minute, or the operator).
6
+ - **Verifiers** — the verdict logic, the RPC reader against a mock JSON-RPC, the registry rules, and an x402-paid call whose signed receipt names a bound provider.
7
7
  - Client package (thin): unchanged.
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "xytara",
3
- "version": "3.9.3",
3
+ "version": "3.9.5",
4
4
  "description": "Client for the hosted naxytra runtime: discover a capability, pay per call with x402 (gasless USDC on Base) or credits, get the deliverable and a signed delivery receipt you can verify offline. The runtime is a hosted service; this package is the client.",
5
5
  "main": "client.js",
6
6
  "exports": {