Protocol preview · illustrative interface

Protect the route.
Describe the right.

DaemonPay separates payment evidence, entitlement issuance, holder proof, access policy, and resource delivery. This guide shows the intended developer contract without pretending the eventual public API is frozen.

Inspect a gate challenge DaemonPay overview

$ daemonpay verify request.json

issuer       merchant:7f3a…       trusted
audience     render-api            match
permission   render.create         granted
holder       ed25519:31c9…         proven
validity     2026-07-16/08-16      current
remaining    render 1000           reserve 1
decision     allow                 local
1man         application_data      false

STATUSThis is a design-level convention derived from the implemented Daemon Pay foundations. Names, JSON shapes, HTTP behavior, SDK calls, and CLI examples are illustrative until a versioned specification is published.PRIVATE ALPHA · CHECKOUT OFF

Five independent objects

Do not fuse commerce into authorization.

The resource declares a right. The offer describes ways to obtain it. A trusted event qualifies. The issuer creates signed evidence. The destination gate decides whether that evidence authorizes this exact request.

01Resourcerender-api:/v1/render

The operation being protected.

→

02Offertrial · prepaid · grant

The terms that produce a right.

→

03Eventsettled · approved · invited

Authenticated qualifying evidence.

→

04Entitlementissuer-signed capability

The holder’s bounded right.

→

05Gateallow · challenge · deny

The resource-side decision.

Do not collapse roles

A watcher may prove settlement but cannot sign an entitlement. The entitlement issuer may grant a right but cannot spend merchant funds. The gate can validate a right but does not inherit authority to identify the holder outside that request.

Machine-readable challenge

A denied request can explain how access begins.

When proof is absent, a gate can return the exact audience, permission, policy version, and relevant offers. The use of HTTP 402 below is a proposed DaemonPay convention; the final specification must define retry, cache, compatibility, and error behavior precisely.

GET /v1/reports/quarterly HTTP/1.1
Host: reports.example
Authorization: DaemonPay <presented-proof>

HTTP/1.1 402 Payment Required
Content-Type: application/json
Cache-Control: no-store

{
  "error": "entitlement_required",
  "resource": "reports:quarterly",
  "required": {
    "audience": "reports-api",
    "permissions": ["reports.read"],
    "minimum_policy_version": 3
  },
  "offers": [
    {
      "id": "reports-trial",
      "kind": "trial",
      "grant": {
        "requests": 25,
        "expires_after": "P7D"
      }
    },
    {
      "id": "reports-prepaid-1000",
      "kind": "purchase"
    }
  ]
}

CLIENT MAY

Start or purchase

Choose an offered trial or open one of the merchant’s supported checkout paths.

CLIENT MAY

Present or request

Use an entitlement acquired elsewhere or ask an authorized person or organization to grant access.

CLIENT MUST

Stop honestly

If no path applies, report that the resource remains unavailable. Never invent a free, public, or relayed fallback.

Portable right

Keep the entitlement understandable and small.

The right should carry authorization facts, not an accidental customer dossier. The example uses readable JSON for explanation; production serialization, signature envelope, canonicalization, field bounds, and algorithm identifiers remain versioned protocol decisions.

{
  "version": 1,
  "issuer": "merchant:7f3a…",
  "entitlement_id": "ent_01J…",
  "audience": ["render-api"],
  "holder": {
    "type": "key",
    "id": "ed25519:31c9…"
  },
  "grant": {
    "permissions": ["render.create"],
    "features": ["high_resolution"]
  },
  "limits": {
    "renders": 1000,
    "devices": 3
  },
  "validity": {
    "not_before": "2026-07-16T00:00:00Z",
    "expires_at": "2026-08-16T00:00:00Z"
  },
  "policy": {
    "transferable": false,
    "delegatable": true,
    "renewable": true,
    "revocable": true
  },
  "source": {
    "kind": "purchase",
    "offer_id": "render-1000"
  },
  "policy_version": 3
}

LOCAL VERIFICATION ORDER

Parse the exact versioned format and signature envelope.
Verify signature and pin an issuer authorized for this audience.
Match the intended service, permission, policy version, and resource constraints.
Require current validity and the correct holder-key proof.
Consult pinned revocation state under the declared freshness policy.
Reserve or atomically consume any finite unit before expensive work.
Bind the result to one request intent and reject replay.

High-risk rights can require fresh online introspection. Ordinary bounded rights should remain locally verifiable when the provider’s declared policy permits.

Integration depth

The application can know as little or as much as it needs.

Every mode preserves the same issuer and resource boundaries. A managed ingress is never implied: if a third party carries application bytes, that is a separately selected and disclosed data-path role.

01 · OWNER GATE

Protect existing routes

Declare route matches, required rights, finite consumption, and relevant offers in owner-controlled policy. Forward only after validation.

GET /reports/** → reports.read

02 · LOCAL SIDECAR

Keep the origin private

Run the verifier beside the application for challenges, local proof checks, revocation synchronization, counters, and private forwarding.

Daemonet → sidecar → app

03 · MIDDLEWARE

Attach policy to code

Extract proof, request a decision, add the result to request context, then let the handler focus on product behavior.

Require("reports.read", handler)

04 · EXPLICIT LOGIC

Branch on exact rights

Use verified features and limits to select quality, export, model, administrative, or another product-specific behavior.

decision.Has("video.uhd")

Finite use and retries

Money must not make duplicate work—or unlimited capacity.

A metered operation reserves estimated units, performs the work, settles actual use, and releases the remainder. An issuance or consumption retry returns the prior result for the same idempotency key instead of creating another grant or charge.

01Validate

Check proof and policy.

02Reserve

Atomically hold estimated units.

03Perform

Run the exact bound operation.

04Settle

Commit actual consumption.

05Release

Return unused reservation.

PAYMENT CONFIRMED · ISSUE DELAYED

Use one stable event identifier and idempotent issuance. Retry returns the same entitlement or an explicitly linked replacement.

ENTITLEMENT ISSUED · CLIENT GONE

Recover through the result artifact, local Daemon state, or a separately opted-in minimal recovery mechanism.

CHECKOUT UNAVAILABLE

Existing valid rights continue where policy allows; inability to sell does not silently cancel prior access.

REVOCATION STATE STALE

Apply the declared fail policy: closed, recent synchronized state, read-only, or fresh proof. Never guess.

USAGE SERVICE UNAVAILABLE

Reject metered work, use a bounded offline allowance, or permit only non-metered operations. Never create unlimited use.

MUTATING REQUEST RETRY

Bind checkout and entitlement to a request-intent identifier; the origin guarantees at-most-once execution.

Release requirements

A smaller integration still needs disciplined security.

DaemonPay removes duplicated product plumbing; it does not remove adversaries, key operations, financial obligations, or failure handling. These are protocol requirements, not optional polish.

Trust server-side offers

The client selects an offer identifier. The authoritative price, asset, destination, terms, and grant come from signed merchant configuration.

Authenticate events

Validate provider signature or source, amount, asset, destination, offer, status, finality, event time, and uniqueness.

Scope every issuer

A trial key must not inherit enterprise-administration authority. Bound issuance by audience, offer, right, quantity, environment, and time.

Bind valuable rights

Require holder-key control for high-value entitlements. Keep long-lived secrets out of URLs, history, referrers, logs, and screenshots.

Prevent replay

Use canonical requests, nonces, idempotency keys, atomic counters, exact request binding, and signed service identity.

Rotate and minimize

Publish key validity and revocation, test migration, and avoid logging complete proofs, payment secrets, content, or unrelated identity data.

Data-domain separation

One operator does not need one unrestricted customer profile.

Even if a company operates several roles, the payment system, entitlement issuer, access gate, resource service, and analytics system can retain different minimal facts under different access and deletion policies.

Payment systemconfirms the qualifying event

Entitlement issuerknows which right it issued

Access gatedecides whether a proof authorizes this request

Resource serviceperforms the allowed operation

Analyticsreceives only explicitly selected measurements

Daemonet path

A private service can bind to its Daemonet interface and terminate HTTPS on the owner host. 1Man can coordinate identity and entitlement metadata without receiving application bytes. An explicit Daemon Hub or another selected gateway is a different mode with a declared data-path role.

Provisional developer contract

Describe policy instead of constructing a billing company.

Inspect the current implementation Return to DaemonPay

Before production use, pin the eventual versioned protocol and complete wallet, provider, accounting, legal, support, revocation, restore, and paid-customer release canaries.

Protect the route.Describe the right.