@xyo-network/event-kit-http

Admit-and-enqueue delivery adapter for the D-002 wire profile:

1. HTTP-shaped admission gate over verifyWakeRequest + admitAndEnqueue
2. In-process wake queue + consumer
3. Idempotent wakeId handler wrapper
4. Fixed-window rate-limit hook

The public path never runs the reducer — only verify, authorize, and enqueue.

createWakeAdmissionGate handles source-aware envelopes. Supply a WakeAdmissionRoute, a durable AtomicWakeInbox<AdmittedWake>, an independent XL1 finalized head source, and the active-subscription authorizer from event-kit-statement-graph. The route pins the authorization chain, exact source/filter/subscription, source floor, and bounded range. Ethereum or interval progress cannot stand in for authorization-chain finality, and a live grant alone cannot activate delivery.

Request

POST /event-kit/wake
Authorization: Bearer <compact XYO wallet JWT>
Content-Type: application/json

<raw strict XYO wake Payload>

The JWT's signed eventHash must equal PayloadBuilder.dataHash(body). The audience, deployment, queue, controller, and lag budget come from immutable WakeAdmissionRoute configuration, and the finalized head comes from the receiver's own TrustedFinalizedHeadSource — neither is ever read from the request.

Responses

| Status | Meaning | |--------|---------| | 202 | Admitted and durably handed to the inbox | | 200 | Committed duplicate; the original receipt is returned | | 400 | Malformed Payload, bad range, or bad wakeId | | 401 | Credential does not authenticate this exact content | | 403 | Outside route/source scope, no live grant, or no exact active subscription | | 409 | jti or wakeId collision | | 429 | Rate limited | | 500 | Invalid receiver route configuration | | 503 | Grant view or inbox unavailable/stale |

5xx bodies omit details so adapter internals never reach the caller.

Evidence boundary

The gate itself runs the real profile: specs mint ES256K wallet JWTs from real XYO accounts in the Node and browser Vitest projects. Durability does not: createMemoryWakeQueue and createMemoryWakeInbox are single-process and lose state on restart. The historical core implementation plan's Gate 5 requires a durable adapter, so this package alone is local evidence, not partner or production qualification. That historical gate is not the on-chain publisher roadmap's Phase 5 Proxmox qualification.