Create in your wallet
Generate a short-lived Lightning invoice or a fresh one-time on-chain address. Paste the resulting request into the room.
WALLET → SIGNED ROOM EVENTDaemonPay™ 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.
The direct-room wallet handoff is a browser proof of concept. Interfaces are not a frozen public API. Private-alpha payment collection remains disabled. The peer-wallet handoff does not make 1Man a checkout provider.
01Resourcethe protected thing
02Offerhow a right is obtained
03Eventwhat qualified
04Entitlementthe bounded right
05Gatethe local decision
DaemonChat + DaemonCache + DaemonPay
Ask the person’s wallet. Keep 1Man out of the transaction.
Inside a directly connected DaemonChat or DaemonCache room, either participant can paste a fresh BOLT 11 Lightning invoice or BIP 321 Bitcoin URI created by their own receiving wallet. DaemonChat binds that request to the current room and peer keys, signs it, encrypts it again at the application layer, and sends it over the direct WebRTC channel.
The payer explicitly opens an external wallet. No payment target, amount, memo, wallet balance, “sent” notice, or receiver acknowledgment is posted to a 1Man transaction endpoint or added to chat-history custody.
Inspect without a middleman
The peer gets a local QR, copy control, and wallet link. DaemonChat checks bounded syntax and the Lightning checksum; the external wallet performs authoritative validation.
APP-ENCRYPTED WEBRTCVerify settlement yourself
The payer may say “sent.” The receiver confirms only after their own wallet sees the exact settlement. Those notices coordinate the call; neither is network proof.
1MAN SETTLEMENT AUTHORITY · NONEPrivacy boundary
Private transport is not “completely anonymous Bitcoin.” The counterparty sees the request; direct WebRTC can expose network addresses; Lightning participants and wallets can observe routing metadata; on-chain transfers enter a public ledger; and screenshots, clipboard history, or compromised devices can retain the request. Use a trusted VPN before the room if peer-visible IP addresses are unacceptable, and use wallet-native privacy controls for the payment itself.
Card-to-wallet is an external on-ramp
Fund self custody without pretending a card is anonymous.
The safest 1Man boundary is wallet first: open a self-custody wallet you chose, use its independent “Buy” or card on-ramp, review that provider’s identity, jurisdiction, fee, destination, refund, and privacy terms, and wait for your wallet to observe delivery before returning to the room.
A card issuer and regulated on-ramp commonly know the purchaser and transaction. A VPN does not erase card, bank, device, wallet-destination, or compliance records. 1Man must not collect the card, receive the fiat or Bitcoin, substitute the destination, or mark delivery from a provider callback alone.
Private-alpha gate
No card provider is hard-coded or advertised as live in this build. A future button requires a current, independently signed on-ramp manifest plus jurisdiction-specific legal, security, privacy, callback, direct-delivery, and real-wallet canaries. Until that evidence exists, use your own wallet’s reviewed funding path rather than trusting an unverified redirect.
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 what is protected
An endpoint, file, feature, build, stream, private page, model, community, storage allocation, server operation, or another exact resource.
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.