Describe what is protected
An endpoint, file, feature, build, stream, private page, model, community, storage allocation, server operation, or another exact resource.
DaemonPay entitlement API
Gate access without building an account empire.
Turn a verified payment, trial, grant, contribution, invitation, or approval into one signed right. Put a small gate in front of the resource. Let the product ask only whether that right is valid now.
Interfaces shown here are illustrative, not a frozen public API. Private-alpha payment collection remains disabled.
01Resourcethe protected thing
02Offerhow a right is obtained
03Eventwhat qualified
04Entitlementthe bounded right
05Gatethe local decision
Sell access, not accounts
The product defines the right. DaemonPay carries the proof.
Most developers want to ship an application, API, file, stream, private build, server, or useful service—not a second company made of registration, password recovery, billing tables, feature flags, webhooks, trial counters, and license checks.
DaemonPay separates the commercial event from the access decision. A provider can protect one route first, then reuse the same rights model across the rest of the product.
Describe how access begins
Price, trial, period, quantity, feature scope, device count, expiry, renewal, transfer policy, and the right issued after completion.
Verify what happened
Payment is one option. A grant, invitation, donation, contribution, voucher, beta approval, purchase order, or another trusted event may qualify too.
Issue only the intended right
Bind audience, holder, permissions, limits, validity, policy version, delegation, transferability, renewal, and revocation into signed portable evidence.
Enforce where the resource lives
Validate at the application, destination sidecar, owner-operated proxy, or an explicitly selected published ingress. The resource remains authoritative for use.
Collect at the gate
Ask for value at the moment value is understood.
Instead of sending someone through a generic pricing maze, the protected resource can explain the exact missing right: start a small trial, buy a finite allowance, renew a period, request approval, use an organization entitlement, or present a right acquired elsewhere.
After a qualifying event, the issuer creates the entitlement and the client retries the original request. Mutating operations use an idempotent request intent so checkout cannot accidentally perform the job twice.
The client asks for one protected operation.
The destination gate verifies issuer, holder, audience, right, validity, limits, and policy.
Only when proof is missing does the gate return relevant trials, purchases, grants, or approval paths.
A trusted issuer turns the verified event into a bounded signed right.
The gate validates the new proof, atomically consumes any allowance, and the resource responds.
Authority boundary
A payment observer can report an exact settlement; it cannot mint access. For self-custodied Bitcoin or Lightning, funds go to the merchant-controlled wallet while the watcher has no seed, spend, sweep, refund, or treasury authority. A client cannot provide its own price or declare itself paid. The merchant or explicitly delegated rights holder authorizes issuance, and the resource validates the right under its own policy.
One gate, many products
Every protected action is a request for a right.
The same model works for a one-time download, a recurring membership, a metered API, an invitation-only cohort, a private server, or a usage allowance. Each product still chooses its own terms, path, application behavior, and failure policy.
Requests and operations
Offer free calls, prepaid quantities, monthly allowances, administrative scopes, or access to an experimental model.
Features and builds
Grant one feature, edition, release channel, device allowance, support term, private build, or export operation.
Pages, files, and streams
Protect an archive, early release, download count, private event, feed, preview, or creator-controlled channel.
Storage, compute, and bandwidth
Meter explicit units, reserve capacity before expensive work, settle actual use, and release unused reservations.
Membership and cohorts
Bind a finite membership, sponsored seat, beta cohort, organization role, or invitation to a key instead of a marketing profile.
High-risk actions
Require fresh online state, stronger holder proof, a particular device, multiple approvers, or a narrow administrative window.
Private origin, portable access
Selling access does not require publishing the machine.
The ordinary Daemonet path remains direct: an authorized client reaches the owner-controlled host through WireGuard, verifies origin HTTPS, and presents the entitlement to a destination-side gate. The host serves the application bytes.
1Man may introduce the endpoints, discover an acceptable entitlement, or operate an explicitly selected service. It does not silently become the checkout, reverse proxy, customer database, or application data path.
Integrate at the depth you need
Start with policy—not a billing rewrite.
An existing application can adopt the gate without learning every payment rail. A new application can inspect the complete decision and shape its own experience. Branding, support, terms, refunds, checkout choice, and lawful customer requirements remain with the provider.
Owner-operated gate
NO APPLICATION CODEAttach route and entitlement policy in front of an existing service. Public ingress is used only when the owner explicitly publishes that resource.
Destination sidecar
LOCAL CONTROLRun a small verifier beside a private application for validation, challenge responses, metering, revocation state, and forwarding.
Application middleware
ROUTE POLICYDeclare the required audience and permissions on a route, then consume the verified decision from request context.
Explicit application decisions
FULL PRODUCT LOGICLet one entitlement choose standard, HD, UHD, download, export, administrative, or other precisely defined behavior.
Know only what the transaction requires
The gate needs authority—not a biography.
Ordinary verification may need a holder proof, issuer, audience, permissions, validity, remaining usage, revocation state, and policy version. It does not inherently need a legal name, email address, phone number, social account, employer, browsing history, advertising profile, unrelated purchases, or complete wallet history.
Physical delivery, tax records, regulated products, age controls, healthcare identity, contracts, or refunds can require more. DaemonPay does not erase those duties; it keeps unrelated customer data out of the entitlement gate by default.
- holder-key proof
- issuer and audience
- permission and limits
- validity and revocation
- policy version
- legal identity or contact list
- advertising profile
- unrelated purchase history
- other services used
- complete payment history
- shipping and tax records
- regulated verification
- contract evidence
- refund and support records
- explicitly consented recovery
Privacy claim
No email does not automatically mean anonymous. Payment method, network behavior, device state, merchant records, and use patterns may still link activity. DaemonPay’s honest goal is to minimize unnecessary linkage and make stronger, documented privacy modes possible.
What DaemonPay is—and is not
A connective layer between an event and an enforceable right.
DaemonPay can normalize evidence, issue and verify entitlements, meter finite use, carry revocation state, and produce distinct payment, entitlement, and usage receipts. It is not automatically the payment processor, wallet, marketplace, account provider, or resource host.
A portable rights model, strict issuer boundary, gate convention, local verification path, metering contract, and failure model.
A bank, exchange, custodian, universal payment processor, compulsory marketplace, advertising identity, master customer database, or replacement for legal and tax obligations.
Optional managed entitlement integration, checkout operations, availability, witnessing, support, or explicit publication without acquiring merchant funds or universal issue authority.
IMPLEMENTED FOUNDATIONStrict offer, settlement-evidence, receipt, entitlement, metering, provider-challenge, watcher, and portable-verification components exist in repository code and tests.PUBLIC LAUNCH GATEThe public API remains provisional. Real wallet, provider, policy, legal, accounting, support, and paid-customer canaries are still required; checkout is disabled in private alpha.
Describe the right. Gate the resource.